[rfc-i] Requested follow-up from last night's plenary

Dave CROCKER dhc2 at dcrocker.net
Mon Nov 8 20:07:53 PST 2010


Ted,

On 11/9/2010 7:53 AM, Ted Hardie wrote:
>I've still not caffeinated,

As I recall there was some research many years ago about the need to reestablish 
one's psychological state when attempting to continue an activity involving 
skill.  If you learned something while under the influence of acid, you needed 
to drop some again to get back to the skill.  I find myself wishing you'd waited 
for the caffeine...


> On Tue, Nov 9, 2010 at 6:56 AM, Dave CROCKER<dhc2 at dcrocker.net>  wrote:
> The Internet technical community is broader even within the IETF
> than you could judge by looking at the author list of the RFC
> series.

You've raised the artificial constraint that the RFC series only represents or 
only pertains to or is exclusively defined by or... its aggregate set of authors.

Besides being artificial, your premise is plainly wrong.  At the barest minimum, 
you need to include the rather massive list of folk in the aggregate set of RFC 
Acknowledgement sections.

More reasonably it needs to include everyone who in any way participated in the 
discussions that produced those documents and the meetings that produced them, 
but probably also needs to include everyone who receives announcements about 
emerging IETF work and submitted RFCs.  (This starts to include the kid over in 
Borneo that I met 12 years ago...)

Somewhere around this point, we do in fact start to get a reasonable -- if rough 
-- definition of "The /IETF/ Community".

This then can lead naturally to a legitimate debate about the differences 
between the IETF technical community and the Internet technical community, and 
possibly about the small set of additional series that might qualify as 
"official" series of this broader community.

(There will probably need to be a small diversion, to debate whether the term 
"IETF" covers such areas as the IRTF and IAB and Independent Stream and....)

The outcome of this debate well might produce a recommendation that the 
proposal's phrasing be changed to use the more constrained "IETF Technical 
Community", but it almost certainly will produce frustration at the level of 
effort and emotion spent, to make a one word editing change that isn't normative.


> As I noted below, I think it is plenty to describe the series as the
> output specific groups and processes.  This may be anemic,
> but it is closer, at least in my opinion, to correct.

This casts each RFC as independent of any larger community and that, again, is 
plainly wrong.  RFCs goes through an extensive, broader community process and, 
if only for that fact, therefore represent that broader community.

I'll even suggest that, to the extent the broader community does not feel 
invested in these documents, the broader community has reneged on its 
responsibilities...


>> Perhaps you missed the stated role of Internet Drafts.
...
> I did not.  But as I have noted elsewhere, I think one of the
> consistent problems with how we've analyzed this space
> is thinking of the RFC series in isolation from that input series.

There is a difference between opening a discussion and mis-characterizing an 
existing role.

A discussion about the role of I-Ds might well be appropriate in the current 
context.  But that was not what your text did.


>>> As written, this declares the RFC Editor to be the lead of this
>>> activity,
>>
>> And you think this deviates from RFC 5620???
>>
>> Perhaps you missed its own statements:
...
>> If that does not sound like a/the leader of the RFC Editor, exactly how
>> would you describe the aggregation of these duties?
>
> The text you quote above says "executive-level management
> over the *implementation* of policies...".  This document
> raises that to be the executive lead over the whole activity.
> Yes, I do see that as different.

Ahh.  So the critical objection you have is over the word "implementation" and, 
apparently, you think that an executive's involvement in implementation is 
mundane and does not involve leadership over the relevant activity.  This 
differs from the executives' performance that I have seen or been required to 
perform.

It also forces a particularly narrow use of the word "implementation" in an 
environment that demonstrably has multiple meanings for it, such as using it 
differently to mean writing code and then to deploy it.  Since we are talking 
about documents and publication processes, we have less experience abusing the 
word, but we nonetheless ought to be cautious about Procrustean tendencies with 
its interpretation.


>> 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?
>
> Nope, but I think the contrast is important.

Then it would have been nice if you had engaged that contrast in your previous 
note and dealt with it, or at had done that in your response.


>> 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
>> particular recommendations?
>
> Nope, but I think where it shifts things from 4844 is
> an important place to look at the real impact of the
> changes.

I am pretty sure that it is good to look in lots of places for the effects and 
implications of changes.


>> 3.  Are you saying that RFC 4844's own language:
...
>> does not describe a person who is the 'lead'?
>
> I'm a fan of implementation-led design, but I don't think the
> language you quote above represents the same kind of
> executive management this document lays out.

So it is probably good that the proposal did not constrain itself to this 
particular quotation only, isn't it?


>>>        This
>>> 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 RFC Editor...
>
> The base model has shifted since then, something the document
> is pretty clear on.  From the time the I* successfully claimed the
> right to re-bid the contract, things have been different.

So it is probably good that the Proposal observed that it described a return to 
the gist of the original model, adapted to the current environment.

But one can even argue that the model hasn't changed all that much.  There were 
evolutionary pains as Postel negotiated arrangements with the IAB and the IETF 
for various kinds of activities, conditions and constraints.  (Remember that he 
sat on the IAB.)  He wasn't an "employee" but the pragmatics meant that he 
wasn't 100% independent either.)

More interestingly, your assertion that the base model has shifted refers to 
what occupants of the job?  Braden?  He operated under a different model? 
Someone else?


>>>  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
...
>> I thought Glenn had been making that quite clear in each of his document and
>> his presentation.
>>
>
> I think his presentation was far better at this than the document.

That's delightful to hear, but it would probably help more to hear something 
substantive concerning your strong assertion that "This is not the correct model 
for..."


>> 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 proposal?
>
> This is a very substantive role change.  I wish to highlight that this is
> not a marginal expansion and to note that I personally think that
> the role change should not go forward.  Having a body which is
> self/RSE selected have an equal voice in the selection of the
> RSE to the voice of the managers of the streams which rely
> on the RFC-Editor's work does not make sense to me.

OK.  That's was a bit challenging to extract from your previous -- and even 
current -- marginal focus.

Certainly a concern that the RSAG members are actually lackeys of the RSE is 
worth paying attention to, for the selection process.  I'm certain that the long 
track record of having an RSAG that merely parrots the preferences of the RSE 
gives us a solid basis for worry.  In looking over the list of RSAG members, I 
can see how well founded that worry is.

But seriously, the conceptual basis for your concern does have a philosophical 
legitimacy, when seeking formal purity in selection processes.  Fortunately, 
pragmatics moderate that concern, as do some structures elsewhere in the I* 
community that share this bit of pragmatic impurity.

The core requirement is that selection be performed by a diverse group with 
relevant expertise and singular focus.  (One is tempted to refer to it as a 
Design Team.)


>>> 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.
>
> I did not miss it.  My understanding of the root issues may differ from
> yours.

May?  Oh, you optimist.

But I don't see how that observation pertains to your assertion of a major 
change that actually is merely a continuation.  (I'm inviting you to respond to 
the substance of your concern.)


>> 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 process.
>
> I thought I did at the bottom the mail; a much simpler model in which
> the RSE reported to the IAB implied for me that the IAB did that
> selection.  I assume that they would do so by involving others,
> but I think this is their hire.

1. It's probably better to have such a key point be explicit rather than implied.

2. In case you were not aware of how the failed RSE hiring and the actual TRSE 
hiring were conducted.  It was a variant of the model that is being proposed. 
There is more formality and diversity in how the committee is populated.  And 
perhaps the authority of the committee is greater.  But the essential model is 
quite similar.


>>> 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...
>
> And if only in the current model it only advised.

Well, criticizing those changes in the current proposal is both substantive and 
plausible.

But your original statement was "moves the RSAG from being an oversight body" 
which is an inaccurate assertion of historical fact.


>>> ... 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
...
>
> I am glad you caught it then.

Luckily, I had already been caffeinated.

And I was wearing my glasses.


>>>         the
>>> 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.
>
> I believe splitting the two weakens the oversight very considerably.

I'm extremely sorry to report that I agree with you.  I also think that fuzzy 
reporting and authority lines are problematic.

As for your assertion that this arrangement was motivated by a desire to ensure 
RSE autonomy, I've no idea what the basis for that particular assessment is, 
since it doesn't match the history or the information I've gleaned from 
discussions with IAB and IAOC folk.


>> 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,
...
>> It needs to be resolved by the IAB and IAOC.
>
> And it is my turn to wish this comment was not buried in a
> a response to my comment.


Perhaps you would have wished that I had gotten up to the mic and make a direct 
and explicit and strong recommendation to this effect?

Oh wait.  I did.


>>>       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?
>
> The TRSE and Independent stream editor were approved last February.
> Had I had any available humorous RFC candidate, I would have sent it
> Neville.  Would it have been sent on from him to Glenn?

Perhaps I missed it, but I haven't heard anyone claim that Neville manages the 
April 1st mechanism.

But as interesting as that question is, I fail to see how it is relevant to your 
apparent assertion that the IAB needs to approve all documents issued directly 
by the RSE.

Happily your next segment is on point...

>>   For a style manual?  For xml2rfc documentation?  You really
>> want to add that sort of review and approval to the IAB's load?
...
> I don't think the number of documents in "style manual" and
> "xml2rfc docs" is going to break the IAB.

So the answer is yes.  You want the IAB to micromanage the work of the RSE.

Please explain why this extensive consumption of senior talent is required. 
Perhaps it is to ensure that no senior talent will seek the job of RSE?


>>> 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?
...
> Postel and Braden ...   Had
> either delegated to a bright graduate student the selection of
> independent-stream RFCs, they could have taken the same
> independent-stream RFCs, they could have taken the same
> delegation back.  No RSE can do that now, as we have a
> separate ISE.  The publication house relationship has also
> changed.


Given the reference to the ISE, you are again confusing content management with 
production management.  The reference to 'internal' refers to the latter, not 
the former.

To be clear:  They managed the operation.  The current proposal is that the 
person in the equivalent position continue this simple, well-established line of 
management for internal operations.

Since you appear to object to such a clean and established model of management, 
can you clarify what model you think will work better and why?

Your phrase "No RSE can do that now" is unanchored.  I've no idea what you are 
referring to.

As for publication house relationship changes, are you suggesting that 
subcontracting a task eliminates or otherwise changes accountability and 
oversight for that task?


>>>     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.
...
>> What it does, however, is to leave a collection of strategic management,
>> marketing and enhancement tasks for the RFC Editor office unassigned.
>
> The problem is actually that it assigns responsibility for considering
> change without granting the authority to institute the change.  That's
> not an easy position to be in, but granting the authority to an RSE,
> however "tempered" by consultation is not better.  The RSE has to
> get at least the IAB on with changes, as they are the root-level
> stuckee here.

You appear to believe that the proposal assigns broad, unencumbered authority to 
the RSE for making sweeping, abrubt and unaccountable changes to any aspect of 
the RFC Editor they want to.  I'll bet you really don't mean that.

The proposal is laced with a variety of qualifiers that make clear things will 
be much more nuanced and contingent, such as:

      "   4.  liaise and work with the IAB so that the IAB may be confident
        there has been sufficient community review before significant
        policies or policy changes are adopted"


>>> This
>>> 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?
>
> No, I did not.  But we've gone from someone who needs to make sure
> no stream goes down some crazy path (like choose Flash as an output
> format) without bringing the others along to something with much more
> considerable autonomy, including the publication of its own stream.

Perhaps I did not clearly enough comment on your confusion about the difference 
between content and production.  Output format falls under the latter.  Streams 
deal with the former and not the latter.

As for "publication of its own stream", I'll assume that you simply really did 
need that caffeine...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


More information about the rfc-interest mailing list