[rfc-i] draft-iab-rfc-editor-model-00

Olaf Kolkman olaf at NLnetLabs.nl
Fri Oct 17 08:06:59 PDT 2008




Hello John,


Before going into responding to what you brought up in your mail and
with reference to
http://www.rfc-editor.org/pipermail/rfc-interest/2008-October/000752.html
I would like to try and clarify where we are in the the process.

October 1 the IAB decided, having been privy to the discussion on
rfc-interest, to go with the model as was described on the website,
discussed and somewhat refined on this list, and is now documented in
draft-iab-rfc-editor-model-00. Earlier I agreed that using a webpage
was not the best idea and the draft should have been published in an
earlier state.

This was a pragmatic step, a RFC Editor rebid is on the IAOC's todo
list for next year. However the decision did not close the door on the
model being the final model: it specifically allows to tweak the model
based on experience and running code.

The next step is to publish the current draft as an RFC. But before
doing so it needs the following substantive work:

   - The IAB suggested (see the link above) that a subcommittee would
     be formed to assist both the IAOC and IAB during the selection
     process. That sub committee is made of members that have
     demonstrated interest and/or experience in/with the RFC series and
     editorial processes. It is appointed by the IAB and IAOC.  The
     task is to provide the IAB and IAOC with recommendations and the
     hope is that that subcommittee will be able to keep an eye on the
     how the various bidders and candidates for the different functions
     would interact and be compatible.

   - The document needs a clear and crisp description of the selection
     process based on the 4333 description and taking into account the
     first point.

   - The document needs to be clear that it is expected to be updated
     based on experiences gained with the first implementation cycle.

I plan to address these ASAP.

The next step is an announcement that the IAB intends to publish the
document followed by publication as an RFC after a 2 weeks feed-back
period. (I don not expect that the announcement will result in a
completely new and better idea about the model). But that does not
close the door on tweaks and improvements to the model and its
description: it provides a starting point (more on that in my detailed
responses below).

The IAOC will take up the task of creating statements of work and
sending out an RFI for various functions, those may provide us
valuable feedback and may refine the requirements etc.

With that preample, here follows a response to the specific points.



 > On Oct 7, 2008, at 3:11 AM, John C Klensin wrote:
 >
 > Hi.
 >
 > A few brief comments on this document which I suggest is not ready
 > for prime time, much less implementation by the IAOC.  I am going to
 > try to avoid nit-picking and focus on main issues, but there are
 > many nits to be picked.
 >
 > (1) The document is very confused about whether the term "the RFC
 > Editor" refers to the entire set of activities that make up what has
 > been referred to as "The RFC Editor Function" in the last several
 > years (and is the RFC 4844 definition) versus the single individual
 > referred to in Section 3.1 of this document.  The term cannot refer
 > to both the whole and its parts.  If you want to change the 4844
 > definition, you need to be very explicit about it... and this
 > document needs to explicitly update 4844.


One could probably debate wether RFC 4844 defines the "RFC Editor" or
the "RFC Editor function" but lets go there because I agree that using
the two terms may create confusion in certain context depending on the
scope they are used. Providing more clarity would be useful.

Would adding something like the following to section 3.1 work?

   RFC 4844 uses the term "RFC Editor" or "RFC Editor function" as the
   collective set of responsibilities for which this memo provides a
   model for internal organization. This memo uses the same term for
   one of this organizational components. In general the intended
   meaning of the term will be clear from context. If the meaning is
   not clear users of the term are adviced to refer to this memo when
   the organizational component is intended.

I don't think we should change the "RFC Editor [function]" as the name
of the functional component although if there is a good synomnym to
"function" to refer to the organizational component that may be a good
way to distinguish the terms. Here is where a native speaker could
help: "RFC Editor officiate" maybe?

 >
 > (2) The restriction in Sections 3.1 and 3.2 to a "single person"
 > unnecessarily and unreasonably restricts the IAB and IAOC in finding
 > the right combination of skills for these roles (which I believe may
 > be far more difficult to fill with people of adequate skill,
 > perspective, and experience than the IAB and IAD anticipate).  If
 > you want to make a single person _responsible_ for each role, that
 > is fine, but the details of how the roles are organized should be a
 > matter of negotiation with or about the designated person or entity.
 > It is worth noting that the "Originally ... single person" statement
 > from RFC 4844 is true only if one goes back to the early 1970s.
 > While there was a single responsible individual for many years, the
 > RFC editing function has been a team effort since the first half of
 > the 1980s.


IMHO I think the document clearly lays out the responsibilities but
does not go into the details on how these responsibilities are
implemented. In other words, if a selected individual would hire a
secratary to do the work that is allowed by the model.

Changing "single person" into "single entity" would allow for more
flexibility during the RFI process. Note though that the RFC4333 like
process is really intended to select an individual. So that change
might only apply to the RFC Editor function. ( I would like to point
out that the Indep Stream Ed. is selected by the 4333 process and that
it is left the IAOC, possibly through an RFI, to sort out if selection
through a bid or an 4333 process is the best option for the RFC Editor
function.


 >
 > Incidentally, the IAB should be aware that, in many legal documents,
 > the opposite of "single person" is not "multiple people" but
 > "married person".  I presume it is not your intent to impose that
 > particular constraint :-)

Heheh.. this is where a non-native document editor needs an
alternative. Trying to come up the opposite of "multiple people" the
only thing I can come up with is a "single person" or "individual".

 >
 > (3) The document confuses job descriptions ("the entity doing this
 > is expected to do/ responsible for ...") and qualifications
 > required/ expected for those positions.  For example, the fifth
 > paragraph ("The first alternative...") of Section 3.1 says "...seek
 > a person with the listed qualifications..." but there are no listed
 > qualifications, only a list of tasks for which the RFC Editor
 > (presumably the narrow definition) is responsible.  That is, unless
 > the "listed qualifications" refer to the text from 4844 and hence
 > includes "expert technical editor and series editor...".

Listed qualification refers to:
   "The RFC Editor is a senior managerial position with a strong
    understanding of the IETF process and seasoned management skills.
   "

(2nd paragraph below the enumeration)

I anticipate a comment similar to the comment below, i.e. that this
description may be too vague.


 >
 > A different problem occurs in Section 3.2, where there actually as a
 > list of qualifications, but several of them are so vague as to be
 > useless in guiding the IAOC, which is _not_ supposed to be making
 > policy.  For example, "Technical competence" is required, but
 > without qualification as to area.  Possible completions of that
 > bullet point might involve publication management, the Internet at
 > various layers, or, if Independent Submissions might include essays
 > about refreshments at meeting breaks, one might seek an Independent
 > Submission Editor who was technically competent at baking cookies.
 > Probably one wants what used to be the key qualification for IAB
 > members -- broad technical experience and perspective across the
 > whole range of Internet technologies and applications and the
 > ability to work effectively with portions of that spectrum in which
 > one is not personally expert.


There is (in my view) a shared understanding that the qualifications
you list above are the ones that apply, although it has not been
documented. I will address this by making these qualifications more
explicit in version 01 of the draft.


 >
 > Unless the members of the IAB have broad experience with the role of
 > the Independent Submission Editor and the knowledge and skills
 > required to do that job, the process described in RFC 4333 could be
 > described as picking someone in a beauty context (a technical term)
 > with judges who do not have experience with the subject matter.  Not
 > a happy prospect.
 >

This is recognized and intended to be addressed by the subcomittee to
advice IAOC and IAB during the selection.


 >
 > (4) Finally, key parts of the Production job are not listed or are
 > represented by hand waving.  For example, responsibility (3)
 > involves dialogue with authors, but, for some of the tracks, the
 > authors are not the only ones involved in those dialogues.

How about:
  - Engaging in dialogue with authors, document shepherds, IANA, and/or
    stream dependend contacts when clarification is needed.


 > Responsibility (9) says "Forwarding ready-to-publish documents...",
 > but the determination of what is "ready" can be quite complex and,
 > again, may differ by track.

Introducing a new responsibility:

- Establish publication readyness of the document through communication
   with the authors, document shepherds, IAMA and/or stream dependent
   contacts.

I could add a clarifying sentence: this is the process that currently
takes place during "AUTH48".


 > And Responsibility (10) may raise
 > difficulties with confidentiality of processes that have never been
 > public, since as author-editor dialogue during Last Call (a dialogue
 > that often involves members of the body responsible for the track
 > and, in this model, may involve the (individual) RFC Editor.
 > Perhaps that dialogue should be completely public and even open to
 > comments and appeals while it is in progress, but making that
 > decision through the back door of this document would be
 > inappropriate at best.

That is not the intention. The RFC Publisher has the responsibility
(5) to provide storage of records. (period, not the responsibility to
publish those records). Responsibility (10) is intended to make sure
the records flow from a to b.


 >
 > And, as with the discussion above under (3), there are no stated
 > qualifications for the RFC Production operation other than,
 > presumably, the ability to perform the listed tasks.

This is also the case for the RFC publisher but I think that for these
two functions there are no special qualifications needed on top of the
need to perform the listed tasks.

 >
 > If you are expecting the IAOC to write an RFP, these issues need to
 > be nailed down sufficiently that the community understands what it
 > is agreeing to; otherwise, the IAB is delegating authority to a body
 > whose work (since this is part of contracting) may be largely
 > secret.

The keyword in the above paragraph is sufficient, and that is a
subjective parameter.

While the model is being implemented we will gain more experience
based on feedback on the RFIs, the detailed work on the statements of
work and during contract negotioations.

Even after the selections have been made and people have been
appointed, and contracts have been signed we may learn that those who
assume the roles will define to some extend how things work out. Maybe
not so much that they lead to significant changes in the model.



Appreciating your involvement and your comments,

--Olaf Kolkman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20081017/8afae04b/PGP.bin


More information about the rfc-interest mailing list