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

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

>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

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

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related honor.cybertrust.com Links hipsec-rg Request more information about Pantek

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:
  • '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
Do you need more help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software:
Learn more about Pantek's Technical Support offerings
Place an order for 24/7/365 Technical Support here
Learn more about Pantek, who we are, and what we do
Chat with a Live Operator
Related honor.cybertrust.com Links
hipsec-rg
Request more information about Pantek
     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.

  ---