[rfc-i] Requested follow-up from last night's plenary
dhc2 at dcrocker.net
Mon Nov 8 14:56:12 PST 2010
On 11/9/2010 5:29 AM, Ted Hardie wrote:
> "The RFC Series is the Internet technical community's official
> medium, through which it communicates with itself and the rest of
> the world."
> In addition to being needlessly grandiose, this statement is simply
> wrong. Internet technical community members communicate among
> themselves and to the world in a variety of ways, but the RFC
> series has not been a primary mode of that communication for many
Perhaps you missed the word 'official'. It's usage is not a matter of
grandiosity but merely a (correct) assertion of formal role.
Perhaps you don't think that RFC's are 'official' publications? Perhaps you'd
care to offer your description of what role and job you think RFCs perform?
Perhaps you feel that:
> In the current model, it documents the outcomes of specific
> process in the IETF, the IAB, the IRTF, as well as providing an
> outlet for specific related documents identified by an independent
is that requested description?
That's how you'd characterize a standards specification? I can see the
academic, linguistic and process-analytic basis for justifying such a modest
term, but really it seems so anemic given the effort to produce the documents,
the IETF's view of their role and the world's view of their role.
> If the bodies above have a document series by which they
> communicate, it is the internet-draft series, which is fully open
> and allows anyone to post a draft as a statement in any ongoing
Perhaps you missed the stated role of Internet Drafts.
It is quite explicit, as is IETF management when describing the role of I-D:
"Internet-Drafts are working documents of the IETF,
Internet-Drafts have no formal status,"
That language is problematic for a role as an /official/ channel.
> The draft goes on to propose a complete reorientation of the RSE
> role put forward in RFC 5260 in a series of changes which it
> blandly describes as "modest". Two paired statements make this
> As written, this declares the RFC Editor to be the lead of this
And you think this deviates from RFC 5620???
Perhaps you missed its own statements:
"1. Identifying appropriate steps for RFC Series continuity;
2. Exercising executive-level management over the implementation
of policies, processes, and procedures established
3. Taking proposed changes to the community,
4. ...participating in reviews of the RFC Publisher, RFC
If that does not sound like a/the leader of the RFC Editor, exactly how would
you describe the aggregation of these duties?
Please note that RFC 5620, itself, using the term "executive-level management".
Are you aware of cases in which that kind of phrase is used to describe people
who are /not/ leaders of the activities in which they participate?
> Contrast this to the text in RFC 4844:
1. Are you saying that a conflict in language between 5620 and 4844 must be
taken to have 4844 provide controlling text and that we should not actually fix
ambiguities, conflicts and impracticalities in either of those documents?
2. Are you saying that someone hired to suggest changes to the RFC Model and
changes to the related job descriptions is somehow constrained from making
3. Are you saying that RFC 4844's own language:
"...As such, the
RFC Editor is the implementer handling the editorial management
of the RFC Series"
does not describe a person who is the 'lead'?
> document moves this to the general lead of this activity, a change
> I cannot agree is modest.
You think that the two, previous people who held the job comparable to the RSE
were not leaders of the RFC Editor? Really?
You might want to review what role Postel and Braden played with respect to the
> The document states that this leadership would be "as it is
> practiced in a typical not-for-profit organization" along with
> specific community driven practices (seek input, foster volunteers,
> supervise according to procedures). This is not the correct model
> for a document series 90 per cent of whose output is standards
> documents representing hard-won consensus. Those have to be led by
> the communities producing the documents.
Apparently you have missed the distinction between leadership and work with
respect to content, versus leadership and work with respect to the publication
activity. I had thought that this distinction had been drawn vigorously and
often. They are quite different.
I thought Glenn had been making that quite clear in each of his document and his
I do not recall having anyone outside of the RFC Editor leading its work.
> The document also describes a change to the RSAG model, which it
> describes as "marginally expanded". In fact,the RSAG in this
> document has a major change, buried in Appendix A, section 2.
> Where the body of the document and RFC 5620 state that the RSAG is
> not responsible for hiring the RSE, this gives the constituents of
> the "search and selection committee", which includes 2 members of
> the RSAG.
So your concern is not with the proposal for the hiring process or with RSAG
providing some of the voting members to that process? Your objection is to the
word "marginally"? You are merely offering technical editing input to Glenn's
> This methodology, in which the role of the IAB is to formally
> appoint rather than select and vet is, in fact, a major change; it
Perhaps you missed the previous effort to hire an RSE and then to actually hire
the TRSE. In broad strokes, it largely conformed to what Glenn has described in
the language you quote.
As for being a major change, well yeah, the processes for 'hiring' Postel and
then Braden were certainly different from this.
But again, you do not offer comment about the actual process being proposed.
Presumably that lack of comment means you do not take exception to the proposed
> moves the RSAG from being an oversight body to being one which is
> advisory only.
The RSAG has never been an oversight body. It has always been a frankly
informal advisory group.
If only that had been made clear, such as by adding the word "advisory" to the
name of the RSAG...
> ... as has the overall reporting structure for the RSE, who
> now appears to report to three bodies but to be fully responsible
> to no one.
It's a shame that the above text was a throw-away line in your review, buried in
the midst of what is really an entirely unrelated line of criticism, since it's
one of the key problems in the current situation for the RSE.
> actual mechanism by which an RSE would be managed is unclear:
> o report to the IAB for general matters and to the IAOC for RSE
> contract requirements while following community direction.
> This frankly seems to be deliberate, part of the document's effort
> to support the RSE acting with very significant autonomy.
You think that "report to the IAB for general matters" defines "significant
autonomy"? Please explain.
As for the current proposal's having too little clarity about lines of authority
over the RSE, that is certainly correct. However the real issue there is a
lingering ambiguity about this, among the IAB and IAOC. It's lingering because
there are competing, reasonable views.
This does need to be wrestled into clarity and pragmatic utility, but frankly at
this point, I've come to believe that that is not something that the TRSE can
It needs to be resolved by the IAB and IAOC. And it needs to be resolved by
them, IMO, rather than their hired consultatnt because they have strongly
competing views, predating his hiring and still providing some tension. Worse,
each of the views has some justification...
> First, I personally felt that the critical piece of independence
> being maintained from our historical model was an independent
> stream and an independent stream editor.
You might want to review that actual history of the RFC Editor and the repeated
references to its autonomy. Those references were not merely limited to what we
are now calling the Independent Stream. It referred to the entire operation of
the RFC Editor.
> In the plenary
> discussion, it was made clear that the RFC Editor stream was seen
> as important because it allowed the RFC Editor to publish documents
> about the series without the review and approval of any of the
> independent streams. That makes no sense to me. The RFC Editor
> function reports to the IAB, which controls one of the streams; if
> the RSE does not have the agreement of the IAB for a proposed
> document, it does not have the level of community support that
Oh. You want the RSE to gain the approval of the IAB for publication of the
April 1st RFCs? For a style manual? For xml2rfc documentation? You really
want to add that sort of review and approval to the IAB's load? Please explain
how that is a) necessary, and b) productive.
> The document further considers the RSE to have executive authority
> over matters relating to "internal" issues of the overall RFC
> editor function.
> Given that the RFC Editor function is split, an internal matter
> might, in fact, be management related to the work of the
> publication group; this is a seriously different model than where
> we started with this.
Really? You mean that Postel and Braden did not have direct management
authority for the equivalent functions of the RFC Editor? I'd be interested in
hearing the basis for your claim, since it deviates so massively from my own
> A much
> simpler model in which the reporting structure is clearly from the
> RSE to the IAB and in which the role is much more clearly
> coordination among the streams is needed.
There is certainly a principled line of argument for that particular definition
of the RSE job.
What it does, however, is to leave a collection of strategic management,
marketing and enhancement tasks for the RFC Editor office unassigned.
Given the role of the RFC series as a strategic Internet resource, who will
perform these strategic tasks that are a natural part for any publication service?
> attempts to recreate that authority at the executive level,
> presumably as a check on the authority of the bodies the running
> the individual streams.
Huh? A check on the authority of the streams?
Perhaps you missed the rather forceful distinction that has been made between
the content of the RFCs and the publication operation?
More information about the rfc-interest