[rfc-i] a possible refinement to draft-iab-rfc-editor-model
leslie at thinkingcat.com
Fri Mar 20 11:29:33 PDT 2009
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
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.
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
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
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
. 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
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.
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.]
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