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

Ray Pelletier rpelletier at isoc.org
Fri Jan 9 13:23:59 PST 2009


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

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?

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.

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.

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


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.





More information about the rfc-interest mailing list