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

--Apple-Mail-11--455332256
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi, Tom,

On Feb 24, 2006, at 21:27, Henderson, Thomas R wrote:
>
> 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.

great, thanks!

Aaron, I have one suggestion on the process described below; overall,  
it's IMO very sensible.

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

If the IRSG takes on a more executive role, I think the members need  
to be identified a bit more explicitly. The IRTF web site just says  
"IRSG membership includes the IRTF Chair, the chairs of the various  
Research Group and possibly other individuals ("members at large")  
from the research community."

While I can click through the RGs to find the chairs, that doesn't  
tell me if there are currently any "members at large". Something  
equivalent to http://www.ietf.org/IESGmems.html may be good.

>    - 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.)
>
>    - The document enters the RFC Editor queue at the same priority as
>      IETF documents.
>
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg@honor.cybertrust.com
> http://honor.cybertrust.com/mailman/listinfo/hipsec-rg

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--Apple-Mail-11--455332256
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw
ggKJoAMCAQICAw9TWTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE4MTAyOTU2WhcNMDYwODE4MTAyOTU2WjBgMQ8wDQYDVQQE
EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN
AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA2gsuG8tAmM6U2ESsQjhcijJSq6oDG2c+KvvXJ/xcJXbSIOY8IInezIP0DP41H0gxwHNv
AyOuwM6nh0r2wOhzdr77GlKXiij0LoFOpurScPKsC9KTykGAfZtAuCnWIRdDo67Urcw1e306yYgK
xF1UzYwGamLalPjejQTRcjLPIbzM4c7fUN/sxmpkpzT2p6OCJDyPhBfSaZWtv3UEoKF+xssNYzOF
DRCTHcLc3iXgF7z7J0ud8maUAadfb/25Gm7tJHzBOEonMPkHx2N8Ci0qNce0MMH/LVOVQlNO5kYJ
vUJiT0du7LAo/hf8tq3luZrh/Cwc/313x6oKYVuHDBllrQIDAQABo2IwYDAqBgUrZQEEAQQhMB8C
AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l
dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAovojiq8758E/78nMS
vNvD4359F8XAICzWbhz6cXJaGzv1FJoQcV/RY1x6CQZDt9PqiPiqyQX+xLvqicmEURbGU5+aiWj2
usovQXd+Ts8Doj3tbjk35nD7Etc8a2+Y9fQRUS6spzgJr0fcq2FMYbDnOtf71Bn77KgckoUbIszu
mTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1
bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT
G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl
ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa
LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq
VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud
HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls
Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs
Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf
qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa
9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G
CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy
ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT
FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq
hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw
NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx
EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO
ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI
hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT
wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z
9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY
LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD
VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy
ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz
MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0
QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9
3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR
piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB
KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
aW5nIENBAgMPU1kwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDYwMjI3MTcxNzA1WjAjBgkqhkiG9w0BCQQxFgQUWh0sjWPAAsdIAmefmk9k
FPNtlAkwgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu
LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg
THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu
bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq
hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl
bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD
VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw
JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA
BIIBANDDeAXvc8a2/oLJKatfRwO5or7TORMylWzhJvTjopWgV0ds/xcqqkoZvstWVyNvlmqVCOB/
Xm4UkyhF62AFoWd3CZKCAFJMpVPVA7Q+14zRoVQr9YE45/teB9RRujz0D0h7vFVTpNjKSB/LkSw6
G3SO7IZqoj3MRLmuLbHC+X1soz9D/rQqyUSZT9ZzTpE8ujLGaUSfwx8LRjkwBjZMxeDgdGsrlYnL
nBKpQljhHzEbPui1ybMz3QZi4i2buAl5hDR50JgFeMPBDxDcz/vaLTydUNRx2VT8rqfkhERv7fqo
zxypSTMqnq0e4AbNsRa49BSaDaKhlMx+8fVnhgt28E4AAAAAAAA=

--Apple-Mail-11--455332256--