Re: [Mobopts] New IRTF process for RG RFCs

["James Kempf" <[e-mail]>]

What is the IRSG?

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, February 22, 2006 5:09 PM
Subject: [Mobopts] New IRTF process for RG RFCs


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



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