[Mobopts] New IRTF process for RG RFCs

[Rajeev Koodli <[e-mail]>]

Folks,

after considerable deliberation, we have a new process which I believe 
will bring a much-needed formal peer review process for RG documents. I 
feel this is very good for us, personally having brought it up many a 
time earlier, including during the IAB review of MobOpts in Paris. So, I 
am looking forward to it.

Please see the process description below. I hope it is encouraging to all!

Regards,

-Rajeev

ps: to begin with, I will act as the shepherd (see below).

...............................................................

- An RG decides to publish a document using the IRTF publication
     track. The RG performs a review for editorial and technical
     content.  The document should have a statement in the abstract
     identifying the document as the product of the RG and a paragraph
     in the first section describing the level of support for the
     document (e.g., "this document represents the consensus of the
     FOOBAR RG", "the views in this document were considered
     controversial by the FOOBAR RG but the RG reached a consensus that
     the document should still be published") and the breadth of review
     for the document.  I.e., was this document read by all the active
     contributors, 3 people, or folks who are not "in" the RG but are
     expert in the area?  It should also be very clear throughout the
     document that it is not an IETF product and is not a standard.  If
     an experimental protocol is described appropriate caveats need to
     be present.

   - Documents should have a shepherd.  This is a relatively new
     concept developed in the IETF to ensure that issues raised in the
     review and publication process (e.g., by the IESG and RFC Editor)
     are responded to in a timely manner.  The IETF shepherding process
     is described in draft-ietf-proto-wgchair-doc-shepherding-05.txt
     and should be adapted to the IRTF publication process as some
     items in the draft will not apply.

   - The sponsoring RG chair brings the document to the IRSG for
     publication.  The expectation is that the RG chair has already
     reviewed the draft thoroughly and considers it of publishable
     quality editorially and technically.  The RG should be copied on
     the mail message requesting IRSG review.

   - A (firm) eight-week IRSG review period follows after which a poll
     is taken.  Reviews should be similar to that for a conference
     paper.  Votes can be:

     = 'ready to publish' -- requires a thorough read and reasonably
       detailed review

     = 'not ready to publish' -- requires a thorough read, reasonably
        detailed review, and actionable comments.

     = 'no objection' -- I don't object if this document goes forward;
       I've read the document (perhaps quickly); I have some small
       comments which are not show stoppers; I don't have great
       expertise in the area.

     = 'request more time to review' -- a commitment to to provide a
       thorough review in a specified period of time.

     Reviews should be written to be public.  In particular, they
     should be sent to the submitted RG mailing list.  (We may need a
     tracker of some sort to collect reviews.)

     At least two other IRSG members (besides the one sponsoring the
     document) need to vote 'ready to publish' for the document to move
     forward.  Any vote of 'not ready to publish' will hold a documents
     progress until the comments are addressed.  The IRTF chair may
     choose to override 'not ready to publish' holds that, in the
     opinion of the chair, have received an adequate response.

   - The document is submitted to the RFC Editor who does not perform
     an ISR review.  The RFC Editor sends it to the IESG for an RFC3932
     review.  There are several reasons why the IESG may block a
     document, described in RFC3932 section 4.  (The document shepherd
     should be responsible for checking the IETF datatracker for IESG
     blocking and non-blocking comments and forward them to the RG.)

   - Rather than the disclaimers found in RFC3932, the IESG will
     instruct the RFC Editor to add the following disclaimer:

       "This RFC is a product of the Internet Research Task Force and
       is not a candidate for any level of Internet Standard.  The IRTF
       publishes the results of Internet-related research and
       development activities.  These results may not be suitable for
       deployment."

     For documents that specify a protocol or other technology, and
     that have been considered in the IETF at one time:

       "This RFC is a product of the Internet Research Task Force.  The
       content of this RFC was at one time considered by the IETF, and
       therefore it may resemble a current IETF work in progress or a
       published IETF work.  However, this is not an IETF document is
       not a candidate for any level of Internet Standard.  The IRTF
       publishes the results of Internet-related research and
       development activities.  These results may not be suitable for
       deployment."

    (These disclaimers will require approval by the IESG.)



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