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

Brian E Carpenter brian.e.carpenter at gmail.com
Thu Nov 18 11:59:24 PST 2010

On 2010-11-19 02:58, Andrew Sullivan wrote:
> 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.

Let me try some arguments.

1. Broad:

We need the RFC series to be a solid, well respected,
authoritative publication method, widely accepted as neutral with
respect to various vendors and service providers. That means
it needs lots of checks and balances and a transparent process.

The IETF process alone isn't enough for that, because it can always
be suspected of a certain degree of capture by major vendors.
This is why we also need two major streams and review methods in
addition to the IETF and IAB streams: the IRTF/IRSG stream to represent
the research community, and the Independent stream as a publisher
of properly reviewed contrarian or alternative opinions and mechanisms.
(The hypothetical RFC Editor stream is somewhat secondary.)

To make such a document series work, it requires consistent
oversight at more than an administrative or production level;
there needs to be a proactive source of strategy and policy that
is responsive to the wider community (not just the IETF community).
The IAB is chartered only with very general oversight:
"The IAB must approve the appointment of an organization to
act as RFC Editor and the general policy followed by the RFC Editor."
Therefore, the RFC Editor (however it is organized) requires a
strong and broad leadership function that can propose and implement
this general policy, as well as supervising the associated
production and publication work.

2. Narrow:

[I have some difficulty here, because I don't see how a narrow
model makes any sense, but here goes. Excuse me if this reads
like caricature.]

The IETF, IRTF and IAB processes produce trustworthy documents
and there is no need for additional checks and balances.
The Independent stream has no particular value (various crypto
algorithms, proprietary protocols, and the material rejected
by IETF WGs and ADs, can be published elsewhere). All that is
needed is someone to publish a style manual and act as go-between
between the production house, the publisher, and the IAD when
there's a contract issue. When something goes serioulsy wrong,
the IAB will give up Internet architecture for a few months to
micro-manage the details.

   Brian Carpenter

> 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?
>> That's the part that is strange.  It is not as if any of us lack 
>> experience within this community or especially with the RFC process.  
>> Apparently a tutorial is needed about the RFC Editor, for those reviewing 
>> the proposal?
> It's fun to put up straw people to knock them down, but where I went
> to school it was also a fallacy.  I won't speak for others, but I'm
> not asking for a tutorial.  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
> all I, personally, am asking for.  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.  That'd be good, because it would free up the
> time I'm spending on this particular penance for my many sins, since
> there wouldn't be anything to review.
>> Does the proposal specify functions that are unfamiliar?  Do you think 
>> those functions do not need to be performed or that they should be 
>> performed elsewhere?
> 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.
> 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.
>> 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.  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.
> I hope this makes my perspective clear.  I understand that there is to
> be a new draft in the future.  I will read it.  I don't expect to have
> much more to say about the topic until it comes out (although if Glenn
> wants clarification about anything I've said, he is welcome to contact
> me).
> A

More information about the rfc-interest mailing list