[Fwd: Re: [Mobopts] New IRTF process for RG RFCs]
Rajeev Koodli <rajeev@iprg.nokia.com> Sat, 11 March 2006 00:31 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHs0m-0001Rx-Th; Fri, 10 Mar 2006 19:31:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHs0m-0001Rs-AP for mobopts@irtf.org; Fri, 10 Mar 2006 19:31:12 -0500
Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHs0l-0006Zk-QI for mobopts@irtf.org; Fri, 10 Mar 2006 19:31:12 -0500
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k2ANqYg03646 for <mobopts@irtf.org>; Fri, 10 Mar 2006 15:52:34 -0800
X-mProtect: <200603102352> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.18.141.49, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdNOHOxb; Fri, 10 Mar 2006 15:52:32 PST
Message-ID: <44121A3B.8090900@iprg.nokia.com>
Date: Fri, 10 Mar 2006 16:30:51 -0800
From: Rajeev Koodli <rajeev@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "mobopts@irtf.org" <mobopts@irtf.org>
Subject: [Fwd: Re: [Mobopts] New IRTF process for RG RFCs]
Content-Type: multipart/mixed; boundary="------------010205010400010507090707"
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Errors-To: mobopts-bounces@irtf.org
Thanks Greg. I guess I forgot to do Reply All. -Rajeev
--- Begin Message ---Hi Jim, James Kempf wrote: > What is the IRSG? IRSG is RG chairs, IRTF chair and some members invited by the IRTF chair. -Rajeev > > jak > > ----- Original Message ----- From: "Rajeev Koodli" <rajeev@iprg.nokia.com> > To: <mobopts@irtf.org> > 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 >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts >> > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts--- End Message ---
_______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts
- [Mobopts] New IRTF process for RG RFCs Rajeev Koodli
- [Mobopts] Randomness from Wi-Fi background noise Pars Mutaf
- Re: [Mobopts] New IRTF process for RG RFCs James Kempf
- Re: [Mobopts] New IRTF process for RG RFCs Greg Daley
- [Fwd: Re: [Mobopts] New IRTF process for RG RFCs] Rajeev Koodli