[rfc-i] a possible refinement to draft-iab-rfc-editor-model

Leslie Daigle leslie at thinkingcat.com
Tue Mar 31 12:39:50 PDT 2009


Taking some of your points out of order --

 > Is the IAB agreeable to devolve some of its powers to the RFC Editor
 > Framework when it comes to policy decisions?

I'm not on the IAB, and could only speculate about what the IAB might be 
agreeable to.  However, I will observe that there is some murkiness even 
today about which policy decisions are made by the RFC Editor and which 
by the IAB.  That has been a situaion in evolution for some time now.

So -- from my perspective, the important thing to do is get some clarity 
about how/when the IAB has responsibility, and make the RFC 
Editor-specific decision making environment a little more concrete.

 > Will the IAB or the RFC Editor Framework be responsible for the
 > "consistency and continuity" of the RFC Series?

Yes.  :-)  From my perspective:    The committee should be composed of 
people with more immediate expertise that will help ensure the 
consistency and continuity in a broader base than a single individual 
(RSE).  The IAB, however, retains the responsiblity for making sure 
*that* committee works, and whether any broader changes to the structure 
are needed over time.

Re. transparency -- the evolution is to ensure that there is room for 
discussion of wide-ranging series impacting process activities.  The 
actual functions of the components are contractual, and not particularly 
subject to discussion (though publicaton of operational statistics is 
important).  Finding the dividing line between those 2 ends of the 
spectrum is, I think, the current source of tension.


SM wrote:
> Hi Leslie,
> At 11:29 20-03-2009, Leslie Daigle wrote:
>> This is some text I've been batting around to try to address some of the
>> issues that came up on rfc-interest in mid-January, about empowering the
>> RFC Series Editor so that they can enforce some level of consistency
>> across the pieces of the model, and providing enough support to make
>> that real.
> The refinement is an interesting read as it tries to identify the 
> problem areas.
>> While some of that can clearly be a good thing, figuring out what is
>> good, and what is random is going to be hard, and we're currently
>> looking at the backpressure coming from only:
>>      . the IAD (who has one or 2 other things to do, too)
>>      . the IAB (which is not an operational decision-making body)
>>      . the document (draft-iab-rfc-editor-model) -- which is subject
>>        to interpretation
>>      . community comments  (directed where, exactly?)
> I'll commenting on the last item.  Up to now, the discussion has been 
> centered around the IAB and the number of bits to use in the RFC Editor 
> model.  There hasn't been any discussion about a mechanism for community 
> input.  What we have, in my opinion, is a publisher for the RFC Series 
> answerable to the IAB only.  One might argue that this is work in 
> progress and that is room for refinement once the bits are aligned in 
> flying formation.  There has been a semblance of a discussion (on 
> another mailing list) a week or so ago about the RFC Editor.  There is a 
> lack of transparency, or should I say lack of communication, in the 
> operations of the RFC Editor.  This may suit our purposes for now.
> The community needs more information about the operations of the RFC 
> Editor for them to be able to comment.  Otherwise, we will only see 
> gripes when someone is unhappy about a decision of the RFC Editor.  The 
> IETF Community, for example, uses mailing lists for discussion and to 
> interact with various bodies.  There are generally request for comments 
> before decisions are taken.  I don't think that the model of "talk to 
> the IAB and it will talk to the RFC Editor" is a good one.  That seems 
> to be the current model if we take the debate about the "Abstract" as an 
> example.  That's certainly not a policy decision in my opinion.
>> The Proposal
>> ------------
>> If the missing piece is the container function, let's put it back into
>> draft-iab-rfc-editor-model.  Leave all the 4 functions (mostly) as they
>> are, but introduce the RFC Editor Function (or Framework) committee as
>> the focal point for binding them together, and populate it with living
>> people, not an inanimate document.
>> Specifically:  The RFC Editor Framework is a committee chartered by the
>> IAB to oversee the interpretation and evolution of the RFC Series (as
>> defined in RFC4844).  This takes the place of one of the advisory
>> committees described in draft-iab-rfc-editor-model.  This committee
>> "holds the flame" of the RFC Series, providing interpretation of the
>> current definition, indicating when current implementation is in need of
>> improvement, and invoking appropriate community discussion when change
>> is needed.  It provides consistency and constancy of the RFC Series
>> interpretation over time, and is a resource for the IAD in setting and
>> managing contracts. It is responsible to the IAB:  any of its decisions
>> are appealable to the committee and then to the IAB.  [I'm having a hard
>> time really imagining WHAT decisions it will make, let alone why they
>> would be appealable, but it seems important to specify].    The
>> committee provides guidance to the RSE, who in turn provides guidance to
>> the IAD for any decisions with contractual implications for the ISE,
>> Production House, or Publisher.
> Will the IAB or the RFC Editor Framework be responsible for the 
> "consistency and continuity" of the RFC Series?
> Is the IAB agreeable to devolve some of its powers to the RFC Editor 
> Framework when it comes to policy decisions?
> Regards,
> -sm


      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com

More information about the rfc-interest mailing list