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

Ray Pelletier rpelletier at isoc.org
Sat Apr 11 00:39:29 PDT 2009


Thanks for the clarifications and progressing this important  
governance feature
of the RFC Series.  I would like to give a view from my perspective as  
the IAD.

On Apr 10, 2009, at 6:17 PM, Leslie Daigle wrote:

> Hi,
> Following up some discussion in San Francisco, and acknowledging the
> need to send specific text rather than handwaving, here is a specific
> proposal for committee I suggested earlier.
> Two particular changes:
>   . Name of the committee -- "Framework Committee" meant nothing
>     to some people.  Proposed "RFC Series Advisory Group (RSAG)"
>     (per Russ' suggestion to rfc-interest)

The 'Advisory Group' name suggests a different governance relationship  
than I think is needed.
I would consider the group more the RFC Series Oversight Committee  
(RSOC), which I believe
better suggests its role and responsibilities, and its position vis a  
vis the RFC Series Editor
and the IAB better.
>   . Separating initial population of the board from the eventual
>     population of it; using the existing RFC Editor advisory board
>     for the initial population

I think this would change slightly, but more inline
> RFC Series Advisory Group (RSAG)
RFC Series Oversight Committee (RSOC)  (and replace throughout)
> The purpose of the RFC Series Advisory Group (RSAG) is to provide
> expert, informed guidance (chiefly, to the RSE) in matters affecting  
> the
> RFC Series operation and development.  Such matters include, but are  
> not
> limited to, issues in operation of the RFC model components, and
> consideration of additional RFC streams, to give a sense of the  
> range of
> topics covered.

The RFC Series Oversight Committee (RSOC) would 'carry the torch' for  
the RFC Series.
It would oversee the work of the RSE, who would undertake the day-to- 
day responsibilities.
Policies would be adopted by the RSOC.  Initial appeals of RSE actions/ 
decisions would be
from the RSE to the RSOC and then to the IAB.

> The RSAG is chartered by the IAB.  As such, it operates  
> independently of
> the IAB to fulfill that charter,  and provides periodic reports to the
> IAB via the RSE.

> It is composed of members selected for their
> experience and interest in the RFC Series, to provide consistency and
> constancy of the RFC Series interpretation over time. The committee
> provides guidance
through its decisions
> to the RSE, who in turn addresses immediate
> operational issues or opportunities with the ISE, Production House, or
> Publisher. In cases where  these issues have contractual side-effects
> the RSE provides guidance to the IAD.    The RSAG also serves to  
> provide
> advice to the RSE on longer-term, larger-scale developments for the  
> Series.
> This informs the proposals the RSE takes to the community for
> discussion, and the IAD/IAOC as proposals for implementation.
> The RSAG will assist the RSE in identifying and leading community
> discussion of important issues and opportunities facing the RFC  
> Series.

The RSE will propose community discussions on important issues and  
facing the RFC Series to the RSOC for its approval to take to the  
community.  The RSOC
might also initiate that discussion with the RSE.

> The IAB retains its oversight role and is responsible for ensuring
> that adequate community discussion has been held on any such  
> significant
> topics.
> The RSAG does not select or appoint the RSE, or any other component of
> the RFC Editor model, although it acts as an important resource for
> informing any selection process.

The RSOC would act as the nominating committee in a community  
selection process
to identify and qualify candidates to be the RSE.  The RSOC would make  
a recommendation
to the IAB, which would make the appointment.  The RSOC would also  
develop with
community input and subsequent IAB approval the Statements of Work for  
each of the
RFC Series functional areas, including the RSE, the Independent
Submissions Editor, the RFC Production Center and the RFC Publisher.
> It is envisioned that the RSAG will be composed of 6 appointed full
> members serving staggered 3 year terms,  plus the RSE.

Change to 7 and include the IAOC Chair since the IAOC will be  
responsible for implementing
the model contractually; and the IAD in a non-voting capacity who will  
effect and enforce
the contracts.


> Each RFC stream
> will appoint a liaison to the RSAG to provide context specific to  
> their
> stream.   The full members will serve at the pleasure of the IAB --
> appointed by the IAB, and if necessary, removed by the IAB. The final
> selection mechanism for the RSAG is not yet determined, but should
> favour selection of members identified by the RSAG and RSE as having
> appropriate competence and experience to contribute to the success of
> the RSAG. There is no requirement or expectation that RSAG members  
> will
> be IAB members.
> In order to assist with a smooth transition of the RFC Editor  
> function,
> the members of the existing RFC Editor Editorial Board who are willing
> to do so are asked to serve as an interim RSAG, effective as of the  
> time
> of approval of this document.  Within one year from the time the RFC
> Editor function transitions to the new 	model and after  
> consideration of
> the operation of the new model in practice, the interim RSAG and RSE
> will formulate a recommendation to the IAB about the regular  
> composition
> and selection process for the permanent RSAG.
> Leslie.
> Leslie Daigle wrote:
>> Hi,
>> 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.
>> Note -- this is my own noodling; if this list things it (or a  
>> revision
>> of it) makes some sense, we can hope the IAB might take it up ;-)
>> And I apologize I have not found a way to make it short; I'm sure it
>> would be much better if I could.
>> Comments appreciated.
>> Context:
>> The status in draft-iab-rfc-editor today is something like trying  
>> to get
>> a bunch of work done through individual I-D's and a strong leader  
>> -- as
>> opposed to doing work in WG with a charter and a chair.  Sometimes it
>> works.  The ADs may or may not approve the result.  But it is not  
>> at all
>> the same thing as a WG process.  A framework.
>> The RSE will have to either invent the RFC (series/editor) charter
>> themselves or will eternally be chasing around individual  
>> components to
>> operate to the RSE's specifications:  without an environment in which
>> the RSE's change of specification can be discussed and understood
>> against the overall mission.
>> As has been noted on this list before,  the IAB has an important to
>> play, but it's doubtful it can fulfill enough of an *operational*
>> oversight role, because that is not the focus of the Internet
>> *Architecture* Board.
>> So, the key things I'm trying to address here are: 1/ ensuring the  
>> RFC
>> Editor retains enough structure to be coherent, 2/ keeping the IAB
>> involved but not operational , and 3/ getting an RSE job shaped up  
>> that
>> might reasonably be filled by something other than a superhuman  
>> (which
>> would be fine, but perhaps not something we want to gate the  
>> process on).
>> The executive summary:  I'm proposing that one of the advisory
>> committees mentioned in draft-iab-rfc-editor-model be populated as an
>> RFC Editor framework committee, chartered as an activity of the IAB  
>> (not
>> to say made up of IAB members).
>> Preamble
>> --------
>> In mid- to late-January, there was discussion on the rfc-interest  
>> list
>> about the responsibility and support for the RSE:  a general push to
>> give the RSE "hiring/firing" authority over other components in the
>> model, and general pushback against inserting the RSE into an
>> operational role with other contractors.   It was just one of the
>> discussions around which parts of RFC responsibility fell where, and
>> whether or how to draw all the intricate lines of responsibility  
>> between
>> the components defined in draft-iab-rfc-editor-model.
>> As an out-of-band remark at the time, I mooted the idea of standing  
>> up a
>> properly-structured, other, separate entity that would have a
>> relationship to the IAOC and the IETF, but would be the  
>> organizational
>> wrapper for the RFC Editor.   I.e., it would have the responsibility,
>> organizationally, for letting and managing the contracts for the RFC
>> Editor functions, just as we have them today.  The RSE would be the
>> manager of the function.  The role of the RSE is then clear, as is  
>> the
>> relationship of the other functions to the RFC Editor organization.  
>> Like
>> the IASA.
>> As a theory, it had some traction:  it could provide the right  
>> structure
>> for the various concerns of managing control.  In practice -- it is  
>> not
>> at all clear there is energy or wherewithal to pursue it at this  
>> time.
>> But, it seemed valuable to figure out what aspects could be retrieved
>> from the concept that would be workable in real time and space.   
>> Here we go.
>> 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.
>> 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?)
>> And, while it has been suggested that the RSE should provide
>> backpressure by having "executive authority" the reality is that the
>> contract lines run to the IAOC, and we've created a situation where  
>> we
>> can't tease out how we should identify the perfect candidate for the
>> overburdened role.
>> So, maybe we should tease out the "hold the flame of the RFC Series",
>> "manage the contracts", "have the voice of authority when something
>> needs to be addressed", and the "oversight" aspects of the role.
>> 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.
>> 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.]
>> 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.
>> 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.
>> 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.
>> Leslie.
> -- 
> -------------------------------------------------------------------
> "Reality:
>    Yours to discover."
>                               -- ThinkingCat
> Leslie Daigle
> leslie at thinkingcat.com
> -------------------------------------------------------------------
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list