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

[Leslie Daigle]

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