[rfc-i] a possible refinement to draft-iab-rfc-editor-model
leslie at thinkingcat.com
Sun Mar 22 15:29:58 PDT 2009
Danny McPherson wrote:
> 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"
> Can you clarify what you mean by "the first implementors want to
> "fix" them"?
Sorry -- it was short hand: just that there is no doubt anyone taking
up a role will want to make improvements and efficiencies to fit their
own processes/view of the world. And that such changes might not be
perfectly aligned with other changes/the rest of the system.
>> 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?
Largely advice and different perspectives. It is not "directive" in the
sense of "you must do X", although it should be clear that the RSE ought
to address input from the committee even if he doesn't follow it, and
ditto for the IAD.
>> 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?
Yes. (Again, this is a suggestion that seems to make sense now, but
it's not a driving requirement of the committee structure, IMO).
>> This formalizes one of the 2 proposed advisory committees in
>> 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.
Yours to discover."
leslie at thinkingcat.com
More information about the rfc-interest