[Hipsec-rg] IRSG review of draft-irtf-hiprg-nat-01.txt

[[e-mail] (Henderson, Thomas R)]

All,
Aaron Falk has initiated a new process to handle IRTF documents.  I've
attached the details below, which will be published someday in an
internet draft.

We have volunteered draft-irtf-hiprg-nat-01.txt as one of the first of
three IRTF documents to undergo this process.  I have agreed to serve as
shepherd of this document.  Aaron is now soliciting two IRSG volunteers
to review this draft's readiness to publish.  Upon agreement or
successful comment resolution, the following disclaimer will be added:
       "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."
and the document will enter the RFC editor's queue at the same priority
as an IETF WG draft.

>From the RG perspective, I don't think anything needs to be done at this
time-- the results of this process will be discussed on the list, and
the RG has already agreed to the following statement at the end of the
Introduction:
   "This memo was discussed and modified in the Host Identity Protocol
   Research Group and represents a consensus view of the research group
   at the time of its submission for publication."

Tom

Below is Aaron Falk's proposal
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

As you assuredly know, RG drafts are treated like independent
submissions by the RFC Editor.  Some members of the community are
dissatisfied with the process which includes the following steps:

   - The RFC Editor performs independent submission review (ISR) for
     editorial acceptability and may request the authors revise the
     document before publishing.

   - The IESG performs a review (to avoid standards process
     end-arounds) and inserts a disclaimer (see RFC3932).

   - Independent submissions are delayed by lower priority treatment as
     they move through the RFC Editor's queue.

As I see it, there are three aspects of RG document publication that
are on the table:

   - ISR review
   - RFC publication priority
   - the RFC3932 blurb

Here is my proposal:

I propose we use the process for IETF-sponsored individual submissions
(sometimes called AD-sponsored individual submissions) as a model for
IRTF document handling.  From time to time, individuals will approach
a member of the IESG to publish a document that is not the product of
an IETF working group.  These documents do not receive RFC3932
disclaimers, do not receive low priority treatment by the RFC Editor,
and do not experience ISR review.  However, they do receive a thorough
review by the IESG.  For non-standards documents (yes, there are rare
cases of non-wg standards documents), the sponsoring AD gives the
document a thorough review, sometimes requiring expert reviews or
IETF-wide last calls, if the topic seems to warrant broad review.  The
bottom line is that a set of experienced, responsible folks give the
document a thorough review before publishing it as an "IETF product".

Using this as a model, I suggest we adapt this process to the IRTF as
follows.  The RFC Editor has reviewed the procedure below and fully
supports it.

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

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

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

     =3D '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.

     =3D '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.)

   - The document enters the RFC Editor queue at the same priority as
     IETF documents.