[rfc-i] a possible refinement to draft-iab-rfc-editor-model
leslie at thinkingcat.com
Fri Apr 10 15:17:25 PDT 2009
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)
. Separating initial population of the board from the eventual
population of it; using the existing RFC Editor advisory board
for the initial population
RFC Series Advisory Group (RSAG)
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
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 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 RFC
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 IAB retains its oversight role and is responsible for ensuring
that adequate community discussion has been held on any such significant
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.
It is envisioned that the RSAG will be composed of 6 appointed full
members serving staggered 3 year terms, plus the RSE. 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 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.
> 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.
> 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).
> 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
> 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.
Yours to discover."
leslie at thinkingcat.com
More information about the rfc-interest