John C Klensin
john+rfc at jck.com
Fri Oct 17 12:48:54 PDT 2008
Thanks for the detailed response. I'm going to try to trim your
notes and respond to a few points below. Please note that I'm
adopting the role of devil's advocate for a significantly
different model in the hope of clarifying the situation and its
risks. Were I charged with finding a plan that would work
given a number of constraints, I would probably respond more
moderately. In particular, while it is well within the IAOC's
authority to set a schedule without consulting the community and
reaching consensus, I am not sympathetic to any argument that
implies that the community should accept a half-baked job on
something important because of such a schedule. If the IAOC has
made an unrealistic commitment, let the IAOC dig itself out from
I look forward to the completion of the "substantive work" you
identify in your note and for an opportunity for the community
to comment on that work.
--On Friday, 17 October, 2008 17:06 +0200 Olaf Kolkman
<olaf at NLnetLabs.nl> wrote:
> > On Oct 7, 2008, at 3:11 AM, John C Klensin wrote:
> > (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
> > years (and is the RFC 4844 definition) versus the single
> > 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
> > definition, you need to be very explicit about it... and
> > 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
> 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.
To be blunt, this statement is equivalent to "You should not be
confused but, if you are confused, you should go back and look
at the definition that confused you and see if it is more clear
when you read it again. Repeat until either you are not
confused any more or stop caring."
> 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
> help: "RFC Editor officiate" maybe?
Certainly not. My own recommendation is that you leave "RFC
Editor function" alone, for compatibility with existing
documents and usage and rename the [single person] role in your
picture to something else, perhaps "RFC Advisor" or "RFC
Coordinator" or something of that nature. Given that the job
description addresses only a tiny fraction of the traditional
"RFC Editor" role, that it has no actual document editorial
responsibilities, etc., there should be no reason to try to bind
the historical title to it.
> > (2) The restriction in Sections 3.1 and 3.2 to a "single
> > unnecessarily and unreasonably restricts the IAB and IAOC
> in finding
> > the right combination of skills for these roles (which I
> believe may
> 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
> secretary to do the work that is allowed by the model.
You may recall that there was a long debate during the pre-IASA
period about the "single person" designation for the IAD. The
conclusion was that "single person" meant "single person" and
that the IAOC did not have the authority to split that job up,
or hire more people than one for it, without consulting the
community. If you mean "single entity that could be either one
person or a team with a clearly-identified responsible
leader/coordinator", please just say that.
> Changing "single person" into "single entity" would allow for
> flexibility during the RFI process. Note though that the
> RFC4333 like
> process is really intended to select an individual. So that
> might only apply to the RFC Editor function. ( I would like to
> 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
> through a bid or an 4333 process is the best option for the
> RFC Editor function.
I really cannot comment on this in a way that you are likely to
find useful given your assumptions and plans. I continue to
believe that the 4333 process, applied to this sort of task,
virtually guarantees selection of someone who does not
understand the task by a group of people whose qualifications do
not include understanding the task. 4333 may be entirely
appropriate for the IAOC. The goal is to find someone who is
representative of the IETF community to sit on the IAOC and
bring the IETF community's perspective to it, not to find and
place on the IAOC someone whose main qualification is, e.g.,
that of being a financial strategy expert. In the case of the
Independent Stream Editor, you are selecting a person with
critical individual decision authority, not
someone who is expected to bring a particular perspective to a
team. And the IAB members are, again, not selected with
experience with that sort of role as a primary criterion. I'm
also concerned that the 4333 process puts too large an emphasis
on the views of the people in the narrow IETF community while
the Independent Submission function should operate on behalf of
the much broader Internet technical community.
> > Incidentally, the IAB should be aware that, in many legal
> > 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" would, at least, not have those peculiar and odd
semantics. But seem comments above about "person" versus
> > (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
> > paragraph ("The first alternative...") of Section 3.1 says
> > a person with the listed qualifications..." but there are
> no listed
> > qualifications, only a list of tasks for which the RFC
> > (presumably the narrow definition) is responsible. That
> is, unless
> > the "listed qualifications" refer to the text from 4844 and
> > includes "expert technical editor and series editor...".
> Listed qualification refers to:
> "The RFC Editor is a senior managerial position with a
> understanding of the IETF process and seasoned management
That is a job description or a description of the person in the
position. It is not a statement about qualifications. While it
could be rewritten into a qualification statement, that
statement would, indeed, be too vague without additional
information. For example, do you expect the person who takes
that position to have experience in senior-level management? If
"yes", in what sort(s) of organization? And does the IAB
really believe that a position that has no direct reports and no
clear authority chain is a "senior managerial position"? The
chart, the description, and various discussions sound like this
is rather more of a senior, and somewhat autotonomous, _staff_
position reporting to and supporting the IAOC and/or IAD with
responsibility for carrying out certain tasks (none of which are
classically "management") and ensuring that the RFC Editor
[function] functions effectively and efficiently.
> > Unless the members of the IAB have broad experience with
> the role of
> > the Independent Submission Editor and the knowledge and
> > 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.
The people who would be the most useful members of that
subcommittee probably include those who would be the best
candidates for the position. But, if the IAB and IAOC selected
a member of the subcommittee as Independent Submission Editor
based on the subcommittee's advice, there would be cries of
conflict of interest and/or cronyism. On the other hand, if the
IAB leaves the most plausible candidates for the Independent
Submission Editor off the subcommittee in order to make them
eligible, then the IAB might be essentially making the decision
in a way that makes the subcommittee's advice largely
irrelevant. So, good luck with that plan.
> > (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.
Better, but not really satisfactory. The question is about how
substantive technical decisions are made while the description
of the Production operation does not assume that it contains
even enough skill to evaluate whether or not such a decision is
> > Responsibility (9) says "Forwarding ready-to-publish
> > 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
> with the authors, document shepherds, IAMA and/or stream
Again, an improvement, but still a source of concern given the
> I could add a clarifying sentence: this is the process that
> currently takes place during "AUTH48".
FWIW, I believe that incorporating the "AUTH48" terminology or
activity explicitly into the model would be a mistake. I think
that some of your comments above imply that we will end up
moving toward a situation in which there is a need for a final
review by the approving body after author signoff and before
publication. That will slow things down and add work, but I
believe that, in this model in which there is no reason to trust
the technical depth and understanding of the Production house,
that is where we will end up --after the first or second
screw-up, if not proactively.
> > And Responsibility (10) may raise
> > difficulties with confidentiality of processes that have
> never been
> > public, since as author-editor dialogue during Last Call (a
> > that often involves members of the body responsible for the
> > 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
> > decision through the back door of this document would be
> > inappropriate at best.
> That is not the intention. The RFC Publisher has the
> (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.
That needs some clarification in the document, because it will
almost certainly be read the other way.
> > And, as with the discussion above under (3), there are no
> > 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.
See above. If you de-skill that role enough, limit the
Independent Submission Editor's function to that stream, and
don't give the RFC Editor/Coordinator an approval function on
individual documents, you will have ended up adding to the
workload of the IESG, IAB, and IRTF Chair, all of whom are
volunteers and most of whom are already overworked.
> > 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
> > secret.
> The keyword in the above paragraph is sufficient, and that is a
> subjective parameter.
Yes. And I am suggesting that, given the community concerns
about the IAOC inventing policy without community consultation
-- and the agreements that would not happen that were part of
the IASA "treaty"-- the vagueness of the existing text is not
> While the model is being implemented we will gain more
> 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.
So you expect people to sign contracts, presumably for fixed
amounts of money and with performance/delivery criteria, to
perform tasks that will be defined as they go along, possibly
for a collection of management and approval chains that are also
not defined when the contracts are signed? Good luck.
More information about the rfc-interest