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

Danny McPherson danny at tcb.net
Fri Mar 20 19:05:31 PDT 2009


On Mar 20, 2009, at 12:29 PM, Leslie Daigle wrote:
>
> Pieces Flying in Formation -- or not
> ------------------------------------
>
> The problem stems from the fact that we have taken something that was
> once one organization, with loose ties of responsibility to the IAB,  
> and
> are breaking it up into 4 separable parts that are (contractually)  
> bound
> to the IAOC.   All the tinkering has been to try to draw lines and
> arrows to describe how the pieces will fly together, and how the IAB
> will (or will not) have some continued oversight role for some or  
> all of
> it, and the IAOC/IAD for other aspects.  As described today, the  
> pieces
> are aligned and have some kind of formation.  As we go forward, forces
> will pull them apart as they each respond to needs and requirements in
> their own area.  It's not actually clear that the roles will even  
> start
> out from where they are today:  the first implementors want to "fix"  
> them.

Can you clarify what you mean by "the first implementors want to
"fix" them"?

> ...

>
> 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.

What does "guidance" actual entail in your vision here?

> This committee is chartered with as much formality as, say, the IRTF:
> it's not a subcommittee or a temporary kludge.  The IAB appoints a  
> chair
> for it (N.B.:  this does not need to be an IAB member).   Ex officio
> voting members are:  the RSE and the IAD.   The rest of the voting
> committee members (say, 6?) are selected based on their experience and
> interest in the RFC Series, and they serve at the pleasure of the IAB
> (though the selection process should probably include
> suggestions/nominations from the RSE, and the committee clearly has to
> be selected to work well with the RSE).  Additionally, each RFC stream
> has a (non-voting, non-member) liaison to the committee.
>
> To reiterate, because it is important:  the committee members are
> selected for their experience to help make this function work, NOT as
> "representatives" from different bodies.
>
> Either the RSE or this committee works with the IAB for purposes of
> fulfilling the IAB oversight role for the RFC Editor function.  [This
> unrolls to:  the IAB is outside this RFC Editor Framework box, and the
> IAB retains its oversight role, without having to get into the details
> it doesn't track today.  The IAB can clearly name a members to the
> committee, if it so desires.  The RSE is the natural liaison to the  
> IAB.]

In general, this RFC Editor Framework model seems to make
sense to me.  One of the concerns I've heard now several
times from folks whose input I consider quite valuable on
this topic is that breaking the currently monolith into
4 separate functions is risky at best, and this just might
provide some of the glue needed to keep things "together
in flight".

I'm quite interested in what others who are much more
versed in this topic have to say about your idea.

> Other notes
> -----------
>
> The scorecard would then be:
>
> 1. "hold the flame of the RFC Series" -- RFC Editor Framework  
> committee
> 2. "manage the contracts" -- IAD
> 3. "have the voice of authority when something needs to be  
> addressed" -- RSE
> 4. "oversight" -- operational oversight is the RSE/the RFC Editor
> Framework committee, while the longer term strategic oversight of the
> overall function remains with the IAB
>
> The RFC Editor Framework committee is the group that would be the  
> first
> line of input for discussions on the SOW and bid review for future  
> bids.

And this is the function that the IAOC-appointed subcommittee
is serving today, correct?

> This formalizes one of the 2 proposed advisory committees in
> draft-iab-rfc-editor-model.
>
> This suggests the RSE should be an appointment, not a contract, or  
> else
> the lines of "advises the IAD in contract choices" is really ugly.

That's fine, although "advises" is itself still a bit ambiguous.

> The latter further suggests we're going to need some language about
> conflict of interest here, and maybe elsewhere in the contractors.
>
> The RSE then has to be someone who a/ has deep knowledge of the RFC
> Series and/or technical publication series b/ has the cycles to lead  
> and
> review RFC system questions, and c/ knows that the RFC Series is vital
> to the IETF but serves the larger Internet technical community.   
> It's a
> tall order, but maybe not impossible.

Indeed..

-danny



More information about the rfc-interest mailing list