This document is hard to comment on because it raises, and
mixes, a number of separate issues. A large number of those
involve questions that the RFI responses might reasonably
address; I have omitted those from these comments unless they
are directly related to more immediate issues.
The document is repetitive internally and duplicates material
from other materials. In particularly, Appendix B duplicates
much of the material on pages 3 - 5. I have not made these
comments longer by pointing out each place a particular problem
occurs.
Major issues:
(1) This document is heavily dependent on the IAB's RFC Editor
model document. It is unfortunate that the comment cutoff on
this document occurs while that one is still being tuned. In
RFC Editor process language, there is a clear normative
dependency between this one and the IAB document and final
decisions cannot be made on this one before that one has
solidified. IMO, closing the comment period on this one
before the IAB signs off on that one is not consistent with the
spirit of the comments and commitment made during and after the
Minneapolis Plenary.
(2) That dependency is particularly important for two reasons.
First, the RFC Editor Model document leaves a number of loose
ends which the community has been assured will be straightened
out by the IAOC and the RPI, RFP, and ongoing management
processes without the community having to be involved. That is
fine as long as the issues involved are administrative details.
But there is nothing in BCP 101 and its relationship to RFC
4846 that permits the IAB to delegate fundamental policy
decisions to the IAOC. The RFC Editor Model document is still
not clear on where the IAB believes the boundary lies. For
the record, any decision on that subject presumably creates an
appealable event, with an appeal timer that does not start
until at least the date on which the IAB hands the document off
to the RFC Editor.
To the extent to which RFC3932bis is relevant (I suggest in
(10), below, that it is not), almost the same comments about
normative dependencies would apply to it.
(3) The second reason is, in some respects, almost the
opposite. The RFI goes well beyond either the draft RFC Editor
Model document or RFC 4844/ 4846 in assigning critical-path
responsibilities to the IAB. The two RFCs carefully avoid
getting the IAB into a position in which it much respond to a
particular issue on a specific timeframe in order to permit
others to do jobs for which they are contractually obligated.
But the SOW here appears to require just that sort of
commitment from the IAB and presumably for the IAB to be able
to make decisions that involve the informed actions of the vast
majority of its members. Without that, either
possibly-important decisions are made by a few individuals, in
the dark, and with no real community input or accountability or
the various contractual actors are unable to proceed with their
work. I note that willingness and a commitment to work
actively on this sort of matter is not part of the IAB role
description in RFC 2850 nor is it part of the IAB job
description most recently given to the Nomcom. If the RFI is
going to assume this level of commitment by the IAB, it would
be useful to know that at least the current IAB membership has
accepted that responsibility and obligation.
(4) If a potential responder for some of these roles is,
individually or organizationally, an active part of the IETF
community and standards process (or of the community that might
present Independent Submissions to the Independent Submission
Editor), there is a potential for at least the appearance of
conflicts of interest. It seems to me that a key question for
the RFI is to find out how various parties would propose to
deal with those issues.
(5) There is an inherent contradiction between (i) the apparent
requirement that a potential vendor respondent to the RFI
supply all of a specific list of information (the list under
"The IASA is seeking..." on pages 3 and 4 or its
near-equivalent in Appendix B) and presumably be committed to
it should the vendor choose to respond to an RFP and (ii) the
disclaimer in item (4) on page 5 that a non-response to the RFI
does not bar someone from responding to an RFP. While some of
the information requested in Appendix B are entirely
appropriate to an RFI response that is not binding on either
the IASA or the respondent, others, especially the requirement
to identify a specific candidate person for the Series Editor
if someone might later submit a proposal specifying that
position is a deterrent to getting useful responses.
It would be completely appropriate for an RFI to request a
discussion of the job description for the Series Editor that is
present in the RFC Editor Model document (except that the
description there is mostly hand-waving) or to discuss that
role more generally, and even to ask for comments on how that
position might effectively be filled, but that particular
requirement, and some of the others, potentially puts a
respondent at a disadvantage relative to an organization that
held that information more closely until it was ready to submit
an RFP response.
(6) In several places in the document, especially in the SOW
for the RFC Series Editor and Independent Submission Editor,
various actors are required to "work with" various other
actors. That language, in context, implies that no one is in
charge (or everyone is) and is the sort of thing that can lead
to non-performance justifed by considerable finger-pointing.
Other text seems to carry forward the problem of the RFC Editor
Model document in assigning responsibility with no authority.
In other cases, the final responsibility and authority seems to
lie with the IAB. But the IAB (unlike the IESG) is not a
management body (or has not been one since the late 1980s or
early 1990s) and is not chartered to hire or fire anyone (other
than its Chair). This is another reason why the issue raised
in (3) above is relevant.
(7) The SOW for the RFC Series Editor, point F.7, appears to
assign responsibility for April Fool's RFCs to the Series
Editor. Under RFC 4846, those RFCs are a special category of
Independent Submissions and hence should belong to the
Independent Submission Editor. Nothing I've seen in the RFC
Editor Model draft appears to contradict that assignment, so
this is either a mistake or an instance of the IASA changing
established policy on its own initiative.
(8) This document, in the respective SOWs, creates optional
Editorial Boards for both the RSE and the ISE. Those Boards
are optional and, if appointed, have members that serve purely
at the pleasure of the relevant Editor. At least for the ISE
function, that model is different from and contradicts the
carefully-worked-out model established in RFC 4846 and nothing
in the RFC Editor Model draft appears to override 4846 in that
regard. Again, this is either a mistake in the draft RFI or an
instance of the IASA changing established policy on its own
initiative.
(9) While I would expect this to be elaborated upon in
responses to the RFI, there are a number of places in which
various parties can direct the holders of one function or
another to do specific work that they may not have anticipated
on when they submitted bids or agreed to contracts. Unless the
RFP (and probably the RFI, given that you are asking for
commitments about funding models) anticipates contracts plus
additional tasks on a time and material basis (something that
would be very risky for the IASA/IETF), these have the
potential to be what are known elsewhere as "unfunded
mandates". If you expect useful responses to the RFI, you
should really provide enough information about how you
anticipate all of those provisions to be supported to permit
those responses (even if the response is to tell you what won't
work).
(10) The SOW for the Independent Submission Editor appears to
bind that function to the provisions of RFC 3932 or its
successor. This contradicts RFC 4846, which carefully avoided
binding the Independent Submission process to any output from
the IESG. Under 4846, the RFC Editor is required only to give
input from the IESG appropriate consideration; the RFC Editor
is not "subject to its provisions". Both RFC 3932 and its
proposed successor are IESG documents, describing an IESG
procedure for conducting an IESG evaluation. They are not
provisions or instructions for the RFC Editor (or any of its
sub-functions). This is, again, either a mistake in the draft
RFI or an attempt by the IAOC to reverse existing and
carefully-considered and negotiated policy.
(11) Section A of the Independent Submission Editor SOW appears
to establish tasks or activities for which the ISE is
responsible (or for which the ISE must "ensure" that something
happens) which are dependent on timely and appropriate
responses from other bodies, including the IAB and IESG. It
was not clear from the RFC Editor Model draft how the ISE was
going to be able to do those things without authority to make
the IAB or IESG do anything (their members are not under
contract to the IASA). This draft RFI makes the requirements on
the ISE even stronger and the authority mechanism, if it were
possible, even more vague.
(12) RFC 4714 was a very controversial document that did not
achieve nearly the level of community review and consensus
associated with RFC 4844 and 4846. It reflects a somewhat
different attitude toward the role and independence of the RFC
Editor Function (in the aggregate) than the attitude reflected
in the two latter documents. Those who disliked it stopped
opposing its publication only when its scope was clearly
limited to what later became known as the IETF Stream (which is
exactly the role that RFC 4844, Section 5.2.1, assigns it). If
the RFI intends to use it more broadly, as the "Reference"
paragraphs of the Production Center and Publisher SOWs
suggests, we have another policy problem.
(13) The Production Center is committed to follow the
provisions of a Style Manual that does not exist today, is
unlikely to exist when the RFP goes out, and may become the
first task for the newly-appointed RFC Series Editor in January
2010. I hope the IAB has a plan about how that particular bit
of transition is going to be handled and that the plan has been
vetted by the IAOC. If not, this is another internal normative
dependency.
(14) Some of the details of the recent, and still unresolved,
discussion about the IPR policy and Contributions document
point out that the "careful negotiation; don't touch this
document" model may be the wrong one, or at least that the
model of what the "minimal formatting edits" constitute may
need work (see the short titles in the RFC 3978 headers for an
example). Are you sure you want to write that into to
Production Center SOW without some additional qualifications
about where the guidelines come from and how far they can go?
I hope the answer isn't supposed to be "Style Manual", because
those guidelines are a policy matter of some import.
(15) The whole Production Center SOW is too oriented toward the
IETF Stream, and the Standards substream in particular, with
the other streams left as loose ends.
(16) Production Center SOA, A.3, involves another controversy
in which the IESG has made rules without obvious community
consensus. Precisely what is meant by "validating the syntax"
(e.g., whether the syntax in a given document is required to
have a single root) is, itself, controversial and a matter of
policy. Expecting respondents to the RFI to comment on this is
inappropriate; expecting to write such a comment into an RFP or
contract without much more specificity would be a grave
disservice to the community.
(17) It is not clear what Production Center SOA, A.8, means, or
who can authorize/order such a step. Presumably it is at least
stream-dependent.
(18) Like recent drafts of the RFC Editor Model document, the
SOAs in this document do not reflect the many and varied
iteration paths that can and do occur in the present editing
process. I would be happy to see some of those loops
disappear, but I do not believe that eliminating them would be
consistent with high-quality output. In any event, they should
not be eliminated as an accidental side-effect of the design of
an RFI or RFP.
(19) It is not clear whether the working document archives to
be maintained by the publisher (source documents, tracking and
reviewing information, and other supporting materials) are
expected to be public and publicly accessible. This has been
another controversial issue in the community and the decision
is likely to have a cost impact. The decision involves policy
and should not be left to an accident or low-level
administrative process.
Thanks for letting me comment.
john
p.s. I'm copying the IETF list. Most of the above are
substantive issues and should no more be isolated to an obscure
mailing list than responses to a Last Call issued by the IESG.
--On Monday, January 05, 2009 8:55 -0800 IETF Administrative
Director <iad@xxxxxxxx> wrote:
> All;
>
> This is a reminder that 7 January is the last call opportunity
> to provide input to this Draft RFI before it is released for
> vendor response later in January.
>
> In 2009 the IETF Administrative Oversight Committee (IAOC)
> plans to issue a Request for Information (RFI) and a Request
> for Proposal (RFP) for the performance of the RFC Editor
> functions beginning in 2010. The incumbent has advised that
> they do not intend to respond to the RFP. At the request of
> the IAOC, the RFC Editor Selection Oversight Subcommittee is
> issuing a draft RFI for community comment. The draft is
> located at: http://iaoc.ietf.org/rfpsrfis.html
>
> The purpose of the RFI itself is to identify potential
> contractors to provide the RFC Editor services and to obtain
> feedback from contractors and the broader Internet community
> on the implementation of the new RFC services model.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf