[rfc-i] My comments on http://www.ietf.org/id/draft-kowack-rfc-editor-model-v2-00.txt

[Dave CROCKER]

Andrew,

On 11/18/2010 5:58 AM, Andrew Sullivan wrote:
> On Wed, Nov 17, 2010 at 09:37:15PM -0800, Dave CROCKER wrote:
>> His mandate was to formulate recommendations, but now he's being told to
>> formulate a transcription of his thinking.  Different task.
>
> Well, then, why in the world should we even bother commenting?  We
> have recommendations.  According to you, we're done, no?  Why am I
> wasting my time on this?

I was under the impression that /our/ task was to comment on the recommendations 
and possibly suggest changes, rather than to assign new tasks.

It's pretty simple.  We do it all the time.  (Although alas, we also add new 
requirements at the last minute frequently, too.)

None of the people participating on this list is all that young or new to the 
IETF or the RFC process.  (We should all take note of the fact that SM is the 
only "younger generation" participant, which means that we have not engaged the 
rest of the community in this rather essential exercise.)

So, for example, you cast a particular issue about the breadth or authority 
or... of the RSE job.  You haven't really said what you prefer, although yes, 
you've given a qualified statement of adequacy of the breadth aspect of the 
spec.  Some folk have come pretty close to saying what they prefer, but there is 
no engaged discussion about the tradeoffs.  Instead we've assigned Glenn the 
task of telling us his reasons.

When I offered my explicitly biased alternative labeling for the scope/authority 
choice, it was intended to provoke some statements of preference.  And I made a 
point of stating /why/ I thought a particular choice was appropriate.  I think 
it curious that no one seems very interested in tackling that rather basic 
matter of substance about the RSE job.


>  I don't have intimate knowledge of the RFC
> Editor's job, and I can easily imagine that there are plenty of
> details that need to be in a job description (there are such details
> in the existing draft) but for which I don't have any context in which
> to make a judgement.  If I make a recommendation about a course of
> action, it is just automatic that I would have a reason why.

That's the difference between doing the development of something versus doing 
the review.  RFC's that provide specifications typically do not explain their 
choices.  They specify them.  While it's true that our late stage processes 
often include efforts to second-guess the folks who did the development, it's 
rarely helpful and always causes extensive delays.  The exception is when a 
choice seems extraordinary or problematic.

And indeed, if someone sees any part of the recommendation that way, they ought 
to ask explicitly for reasons, but they also should explain why they think the 
choice extraordinary or problematic.

However I believe that nothing in the proposal that is extraordinary, from an 
organizational design standpoint, except the extent to which it uses 
community-based processes. I suspect that all or nearly all of us has plenty of 
professional experience around organizations, sufficient to evaluate the bones 
of this proposal.

Why, then, is there such resistance to engaging in the particulars?


>  And Glenn is in the happy position
> of having spent a year doing a job about which he is making a
> recommendation -- exactly the basis on which the recommendations were
> to be developed, as I understood things.  But perhaps you're right and
> reasons are not needed.

I didn't say that reasons were not needed.

(good to see that straw statements are an equally opportunity distractor.)


> I think you will find that I sent a message to this list while we were
> still in Beijing which argued that that distinction is where the
> fundamental issue is.  In that message, I suggested that _if_ we
> accept the broad construction, then the particular recommendations in
> the draft were (to me) more or less good enough.

And I think you will find that I called out your posting as exceptional with 
respect to actually seeking an engaged discussion.


> I still don't know what to think about the broad/narrow choice.  I
> will tell you that finger-wagging, accusatory (not to say
> condescending) messages to the list make me feel like my initial
> impulse to put my head under the covers was the right one.

You mistake irritation for condescension.  Or, of course, I didn't encode the 
irritation properly.  I'm pretty embarrassed with our community enclave, for the 
way we are handling this.


>> This is an on-going service.  Problems arise, but the "problem" the RFC
>> Editor is to "solve" is production of RFCs, archiving them, and making
>> them available to the community.  The other "problem" is looking for
>> opportunities and requirements for enhancements. What other sort of
>> problems are you thinking should be cited and solved?
>
> That is a useful additional way to think about the broad and narrow
> constructions.  The second "problem" you list there is in fact part of
> what's up for debate: is the RSE a job that has that function?  Does
> someone need to do it, and if so, is the RSE the right person?  As I
> have previously suggested, the draft (or the summary, whatever it is
> we're supposed to be talking about) could be very much enhanced by
> saying _anything at all_ to justify the view that the RSE is in fact
> the right person for this.

Sometimes, the real disconnect in an exchange is that one of the parties cannot 
fathom that the other party needs to be told something that the first party 
thinks is so basic, no one could possibly need to be told it.  I have a guess 
that that is one of the factors here.

The RFC Editor is an institution and a critical-path service.  Specifying a 
single person to own responsibility for its long-term planning and enhancement 
-- as well as for resolution of the occasional, serious problem -- is a classic, 
basic organizational structuring requirement.

Volunteer, committee-based efforts that have broad scope usually result in quite 
a lot of whimsy.  They certainly cannot be relied upon to have sustained focus 
on a particular topic at a particular time.  Purely as an example, expecting the 
IAB to look out for strategic issues concerning the RFC Editor would be a 
massively misguided mistake.  That's not a criticism of the IAB; it's an 
observation about its nature.  Don't ask people or groups to do things that they 
are designed not to do.  (I hope folks note the phrasing of that last sentence.)

Similarly, the folk in the trenches of an operation /must not/ be tasked with 
strategic work.  It will distract them from their line operations work, and it 
typically does not well-suit their skill-set.  (Again, that's not a criticism; 
it's in the nature of the different jobs.  I was once hired for a computer 
operations job /in spite of/ my knowing how to program...)

If someone thinks that the on-going tasks of organizational review and 
collaborative enhancement do not need to be done for this essential institution, 
please explain why.

If someone thinks that these on-going tasks should be done by someone other than 
the RSE, please say who, and please explain how that will be practical and reliable.


 >  Leslie pointed out in this thread that the
> recommendation about opportunities and "outreach" in the draft as it
> stands is a potentially large sink of resources.  I think it could
> take all the RSE's time.  It strikes me that that part of the job
> could easily swallow the production-of-RFCs function, and that is at
> the very least worrisome.

And yes, that's a specific concern that needs specific discussion or, at least, 
clarification.

However note that the RSE could treat almost any activity as a large sink.  So I 
suspect the right question is how to direct and/or assess whether they are 
balancing their use of time properly.

Perhaps they should report to someone who provides such guidance?  If there is 
more "contractual" constraint that should be provided, what is it?

We need to be very careful that we do not over-specify RSE job constraints here.

This is not a mechanical job and the amount of change in recent years means that 
it really is not a fully understood yet.  The person filling it needs to develop 
it, or we will not find the sort of person we /ought/ to want.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net