olaf at NLnetLabs.nl
Wed Oct 22 07:37:58 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
I'll reply to some snippets of your mail because I hope to address
most of the comments in a forthcoming version of the draft.
> 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.
I will post version 02 of the draft shortly. I've addressed a number
of the points you raised in a, I hope, satisfactory manner. I'll have
to review what I wrote in a day or two, besides that allows others to
chime in as well.
> 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."
Blunt, but fair.
The document now uses "RFC Series Editor" or "Series Editor" for short.
> 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.
Addressed, i think, by using this wording:
The RFC Series Editor, or Series Editor for short,
is an individual (or a team with a clearly-identified
individual that assumes the teams responsibilites)
> 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.
I am sympathetic to your argument but I don't have an alternative. So,
this is a point where I hope that version 2 will clarify as much as
possible by allowing the IAB and IAOC to be assisted by subject matter
experts but without introducing a new body or structure.
>> 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.
Yes, yes, and yes,
Either we fare blind and we end up in a situation where the decision
is a beauty contest, or the IAB and the IAOC find external expertise,
are aware of the above pitfalls, and make an informed decision. I
think the latter is the best choice between evils in absence of an
> 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
> at issue.
> 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.
I propose adding the following explicit responsibility:
o Identify where editorial changes might have technical impact
and seek clarification.
One of the issues that I read between the lines of your response is
that the IAOC might blindly select the lowest bidder ant that that may
cause all kind of ugliness. I thought it was well understood that the
IAOC (and the IAB for that matter) do not take price as the only
consideration and that the quality of work, understanding of the
process as well as continuity (basically all IETF interests) are all
factors that are important when a vendor for a service is selected.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 235 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20081022/c3c17d08/PGP.bin
More information about the rfc-interest