[rfc-i] Request for Clarification of RFI review points

John C Klensin john+rfc at jck.com
Fri Jan 9 14:39:38 PST 2009

--On Friday, January 09, 2009 16:23 -0500 Ray Pelletier
<rpelletier at isoc.org> wrote:

> John,
> Thanks for your review of the draft RFI.  Some questions arose
> during the review of all the comments and would appreciate
> some clarity or examples.  In compiling this list I may have
> overlooked 1 or 2 others and may ask your indulgence for more
> counsel.

Ray, as a preface which you might deduce from my recent note to
the IETF list about the Trust IRP proposal, when I look at a
legal document (including this pre-contractual one) that does
not seem to accurately reflect plausible principles and the
IETF's best interests, I have three reactions that get stronger
or weaker depending on how much I've had to deal with similar
documents recently.  Those reactions are more or less at peak
right now, so apologies in advance if they are appropriate:

	(1) Why is the IETF expected to spend time analyzing and
	resolving these problems when one major purpose of the
	IASA was to let the IETF express principles and then let
	others sort out language and get it right?
	(2) How much longer do we need to put up with it?
	(3) When we get tired of it, is there any practical way
	to say "no, enough" other than to revise BCP 101 out of

I've got a very short available workday right now due to some
personal reasons.   You, the IAOC, and the Trustees are
essentially deciding that I should spend all of the available
IETF time on these matters and none of it on technical work.  I
don't think that is a good tradeoff for the IETF.

> 1. Could you provide some clarity on this point?
> f. (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.
> How could/should this be reflected in the RPC SOW?

Your mean "RFI SOW", I trust.  I believe that the language
should be muted or removed until and unless the community sorts
this out, with neither "IESG makes rules, applies them, and then
announces them" or "IESG bullies RFC Editor function into
behaving in certain ways lest they run into contractual
problems" constituting "sorting out".   All you really need to
say is that, under conditions to be determined by the IETF, the
Production House and Publisher may be asked to process a
document unchanged or with changes restricted to in areas not
specified by the community as unchangeable.  You don't add to
the workload of the Production House by telling them to not edit
all or part of some documents.  I believe that, if the IESG ever
makes that sort of request/demand again, they should be required
to specify what do not want edited, but that is an IETF problem,
not an RFC Editor one.

As a comment on the RFI itself, I would expect a Production
House and/or Series Editor that took organizational pride in its
work to ask to include an explicit statement in any document the
IESG told them to _not_ edit.  

I mention the IESG above _only_ because it is the only body that
has so far asserted the authority to make a "don't change this"

> 2. It would seen that Reference to  4846 makes this ok.  Is
> this sufficient?
> f. (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.

It would be lots better if you inserted a normative reference to
4846 and make it clear that the RFI only provides an outline and
that the details in 4846 are authoritative.    You don't do that
now, 4846 isn't even listed in the Reference section at the top
of the ISE SOW.   By contrast, 4714 _is_ referenced there, and
4714, as Leslie and I have both pointed out, is relevant _only_
to the IETF Stream.

Beyond that, no.  Just as 3932 was carefully written to be sure
it was an IESG document, describing IESG activities and actions,
but not binding anyone who was not subject to IESG authority,
4846 was carefully written to not require the IAB or IESG, much
less various RFC Editor functions that you now propose to
separate, to do anything.  It just describes how documents are
passed to those bodies and what actions those bodies might take
that the RFC Editor will pay attention to.  Under the present
model, if the RFC Editor passes a document to the IESG or IAB
and they do not respond in a timely fashion, the RFC Editor has
considerable discretion to either prod them or go ahead without
a response.  As I read the ISE SOW, the ISE can be held
contractually responsible, or at least negatively evaluated, if
a document is passed to the IESG, the IAB, or some other piece
of the RFC Editor structure and that entity does not respond in
a timely and competent way.

> 3. Don't see the conflict - why do you think that's true?
> h. (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.

Sigh.   Suppose I'm a potential proposer (presumably for more
than one of the roles/ SOWs) and that I think I could convince
Bob Braden or Mike Padlipsky to act as series editor,
independent of their current employment.  I mention those names
because I can't imagine either of them being wiling to do it but
also because each one would bring considerable credentials and
experience to the model (although each might dispute that about
the other... sorry, Bob).   I would expect that either name
would vastly strengthen my proposal, at least for any proposal
evaluation process that was familiar with IETF/NWG history and
competent.  But why would I want to give the names away --
either directly to potential competitors or to an RFI process
that I couldn't be assured wouldn't leak -- as part of an RFI
response.   I would probably be much better off saving that
information for a final proposal, giving my competitors no
information in advance or warning and, in particular, no
motivation to construct an argument in their proposals about why
having someone whose history with the publication and editing
process goes back to the dawn of the ARPANET would be a bad idea.

If my choices are "respond to the RFI" or "keep that information
private until I have to submit a final bit", I'm likely to
either choose the latter or to choose the latter and find a
surrogate to submit any comments I might have on the RFI itself
(and to do it via Appendix A).   Such surrogates reduce the
information available to the IAOC.

A different way to say this is that asking someone to commit a
name --as distinct from a clear set of perceived required
qualifications --on the RFI is roughly equivalent to asking them
to quote a price.  The information you need in the RFI response
is comments about cost structures and job qualifications, not
dollar amounts or people's names.

> 4. Where are the things you are referencing here?
> j. (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).

Most of the list was fairly obvious to me when I read the RFI.
It is troubling to me that neither you nor Leslie, as presumed
members of the drafting group, have not spotted them.  If you
get tried of waiting for me, look for sentences containing "may
be directed by", think through the implications of the IAB being
able to change the job description of the RFC Series Editor
mid-contract (see RSE SOW, Section 3) and a requirement to
"participate in and support" unspecified and unbounded
experiments (RSE SOW, Section I and Production Center SOW,
Section A.9(b)), and any place where one entity is required to
do work --work for which it is responsible for timely and
efficient output-- based on tools supplied by others that may
not turn up or may not be adequate.

That is _not_ a comprehensive list, just several examples.

> 5. Where are we deleting something here?
> l. (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.

You aren't deleting anything.   The "RFC Editor Model" is
incomplete and insufficient on these issues.  On at least one
occasion, the IAB Chair defended the omission of that material
from the Editor Model on the grounds that it would make things
too complex and hard to follow and that the IAOC would sort out
any details needed to write clear contracts and actually make
things work.  That effectively transfers doing the work of
explaining those loops to potential bidders to the RFI and RFP
and leaves it to you, the IAOC, and any drafting committees you
might have, to complete the descriptions and get them right.
If you don't want to assume that burden, take it up with the IAB
(for the record, I don't believe the IAB has the authority to
delegate that non-administrative matter to the IAOC, with this
particular set of omissions being a symptom of the pragmatic
part of the problem).


More information about the rfc-interest mailing list