Re: RFC Editor RFP Review Request

[Allison Mankin <[e-mail]>]

Hi, Ray, and all,

I read the SOW earlier to check that it matched with the
draft-mankin-pub-req-10 (output of techspec), but I've now
given a read to other matters in the RFP.  

If anyone wants to discuss points from this mail other than those
specifics to the RFP, I suppose we should do so on [e-mail].

1. Some wording under Independent Submissions is still a bit 
   confusing.  2.a. states the optional presentation of the document
   to the IESG for end-run evaluation while it is in the RFC Editor's
   initial review.  2.e states the mandatory presentation which is
   called for by RFC 2026.  2.a says see 2.e.  In a non-sequential
   reading, which is possible, 2.e does not sound mandatory.  But it
   is firmly required by RFC 2026.

   [And while I have this topic:  this is not because of power
    projection for anyone, but because the WGs' labors are heavily
    invested in RFCs as an end-product, and their charters and work
    need to be consulted by their AD]

   So I'd like to suggest that 2.e be changed a little bit:
 OLD:
     Submit document to IESG for review of
     conflicts or confusion with IETF process, end runs around working
     group activities, and obvious and significant harm to the Internet

 NEW:
     As required by RFC 2026, submit document to IESG for review of
     conflicts or confusion with IETF process, end runs around working
     group activities, and obvious and significant harm to the Internet

2.
>    g. Final Editing and Publication 
>       1) Edit and publish as for IETF community documents

This publication process is not identical to IETF community documents. 
IETF has a BCP (3932) which currently specifies differences, but we're in
some debate now (expressed during the Thursday plenary in Montreal)
about its full applicability to the independent submissions.  There
should be some statement in the SOW about how the differences, such as
a boilerplate stating the nature of the independent submissions, or
a specific type of identifier within the RFC series, will be further
resolved.  How about wording like:

NEW:
       1) Edit and publish with the same steps as IETF community
          documents but with clear indications that these belong to
          an independent series.  Specifics of these indications will
          be authorized by the appropriate IETF community parties.


> h. Coordination with Other Document Streams 
>   1) Coordination with and prioritization of other document streams is the 
>       prerogative of the IAB 


I'm assuming that h.1 is not intended to cover the document differentiation
issue, but in any event, it would not do it well.  The IESG and
the BCP-approving community hasn't finished discussing (by approving a changed
BCP) a view that the IAB is now arbiter of the IETF's public messaging on
independent RFCs.  Due to independent RFC's potential close involvement with
working group RFCs, there are reasons for WG folks to really think about this.
I don't think there's any intention to affect a standards-related issue by
placing language in the RFP/contract, but we should really watch that we do not.

Allison




_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf