[rfc-i] My comments on http://www.ietf.org/id/draft-kowack-rfc-editor-model-v2-00.txt
dhc2 at dcrocker.net
Thu Nov 18 12:19:47 PST 2010
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,
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.
More information about the rfc-interest