Re: Last Call: RFC Editor Services Draft RFI

[Leslie Daigle <[e-mail]>]

Hi John,

As an individual who happens to find herself on the RFP subcommittee, 
I'd like to follow up a few points, below.

I have added [e-mail] to the cc line (having seen your 
follow up note) as it is my understanding that the intention was for 
that list to be publicly archived, and this gets to the attention of all 
of the members of the subcommittee.

John C Klensin wrote:
> 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.

Personally, I rather hope it's clear that the IAB doesn't make such 
delegations, but will leave the discussion of the RFC Model document for 
elsewhere.

   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.

It would be really useful to have a couple of examples of where you see 
this happening in the SOW.  There are places where we worked to make 
sure the IAB (or some entity) was in a loop, but I don't believe there 
was the intention of making the IAB critical path.  So, it would be 
helpful to know where you read it that way.

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

Again, the terminology is perhaps there to solve a different problem: 
as things become distributed, it is important to spell out who (people 
or entities) needs to be in the loop.  (I'm not saying it doesn't 
introduce issues, but we are going to have to find a balance to be clear 
  about expectations, even if it means abusive interpretations could put 
us in a bad place).

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

Well, I can't argue about the possibility of risk, but this is precisely 
the sort of mechanism that the IASA has been using in its contracts, for 
exactly the reason you suggest ("unfunded mandates" don't work).

  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.

While I won't comment either way about how well received 4714 was, I do 
agree that its use should be restricted to the IETF Stream.


Thanks,
Leslie.

> 
> (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 <[e-mail]> 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[e-mail]
-------------------------------------------------------------------
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf