From proto-team-bounces@ietf.org Tue Jul 03 04:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5dbs-0007SB-GA; Tue, 03 Jul 2007 04:19:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5dbr-0007S6-Kp for proto-team@ietf.org; Tue, 03 Jul 2007 04:19:43 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5dbA-00041Y-DE for proto-team@ietf.org; Tue, 03 Jul 2007 04:19:43 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l638Icfk010679 for ; Tue, 3 Jul 2007 11:18:58 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 11:18:30 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 11:18:30 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 11:18:30 +0300 Received: from [172.21.34.200] (esdhcp034200.research.nokia.com [172.21.34.200]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l638ITxW018232 for ; Tue, 3 Jul 2007 11:18:29 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) To: proto-team@ietf.org Message-Id: <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> References: <468767D7.7020603@uninett.no> From: Lars Eggert Date: Tue, 3 Jul 2007 11:18:23 +0300 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Jul 2007 08:18:30.0213 (UTC) FILETIME=[BD288F50:01C7BD4A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [proto-team] Fwd: Question for draft shepherd's questionnaire? X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1064682793==" Errors-To: proto-team-bounces@ietf.org --===============1064682793== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3--1014926755; protocol="application/pkcs7-signature" --Apple-Mail-3--1014926755 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI, there was a suggestion to add an item to the questionnaire. What do folks think? How are we maintaining the questionnaire? Should I start a rfc4858bis document? Begin forwarded message: > From: "ext Stig Venaas" > Date: July 1, 2007 11:37:43 GMT+03:00 > To: Lars Eggert > Cc: ext Ralph Droms , Jari Arkko > > Subject: Re: Question for draft shepherd's questionnaire? > > Lars Eggert wrote: >> On 2007-6-29, at 14:51, ext Ralph Droms wrote: >>> "Does this Internet Draft propose any extensions to the operation >>> or capabilities of any other protocols such as IPv6 (extension >>> headers), ICMP, Diameter, RADIUS, DNS or DHCP? Does this >>> Internet Draft require that IANA assign any protocol numbers that >>> require review by another individual or review body outside the >>> submitting working group?" >> We might consider adding a sentence to (1.c) on this issue. Maybe: >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective, >> e.g., security, operational complexity, someone familiar >> with >> AAA, internationalization, or XML? >> NEW: >> If the document extends or makes requirements on a protocol >> that originated in another WG or area, has that group >> reviewed that the document conforms to any established >> protocol >> maintenance process and that it does not conflict with >> chartered or planned work? > > Adding this would be great, > > Stig --Apple-Mail-3--1014926755 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA3MDMwODE4MjNaMCMGCSqGSIb3DQEJBDEWBBSQ93X6h+z1sVMC md5vfbL9CB6rjzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAUmS62wU1JJVw5f7cnHzf4bwGFfNjhzPrn/Seuw8l0YfDXu7KjIAi yNXcstpIFYpOAfA8CuJQ+L/8fbk6rGp3BoW+sDMca2wH6JjmcMa4Q19ROqPzEhcFQV7IPIp7qMxG 5n0Xkqu0g2lPQdC5g7WvWWTnT4wn8z/OVy86rcSbhuSKoaIVYfaEcZT746WmSkIjv3NT751imWQn 1OZKLHJKl7YaTToMhJ+dEmiB2bDongyFGsBgxcPEf4NHplhWUjMpG23YHTLhB8xP/eAErtLiFgOM ms6E7gM196WK39h7XZeBs9sNh0U6zC1jA4r/ygSHMkXAdBAtgf6Esr0JYr7qVAAAAAAAAA== --Apple-Mail-3--1014926755-- --===============1064682793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============1064682793==-- From proto-team-bounces@ietf.org Wed Jul 11 09:41:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cRi-0007QI-9G; Wed, 11 Jul 2007 09:41:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cRh-0007Ne-OM for proto-team@ietf.org; Wed, 11 Jul 2007 09:41:33 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8cRh-0000ia-7R for proto-team@ietf.org; Wed, 11 Jul 2007 09:41:33 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6BDeS94015653; Wed, 11 Jul 2007 16:40:56 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 16:40:44 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 16:40:44 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 16:40:43 +0300 Received: from [172.21.35.100] (esdhcp035100.research.nokia.com [172.21.35.100]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6BDefX3031596; Wed, 11 Jul 2007 16:40:41 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> References: <468767D7.7020603@uninett.no> <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> Message-Id: From: Lars Eggert Subject: Re: [proto-team] Fwd: Question for draft shepherd's questionnaire? Date: Wed, 11 Jul 2007 16:40:32 +0300 To: proto-team@ietf.org, Russ Housley , Jari Arkko X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Jul 2007 13:40:43.0723 (UTC) FILETIME=[142211B0:01C7C3C1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2103255600==" Errors-To: proto-team-bounces@ietf.org --===============2103255600== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-46--304397246; protocol="application/pkcs7-signature" --Apple-Mail-46--304397246 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-7-3, at 11:18, ext Lars Eggert wrote: > FYI, there was a suggestion to add an item to the questionnaire. > What do folks think? Any opinions on this addition? > How are we maintaining the questionnaire? Should I start a > rfc4858bis document? The questionnaire is currently in the RFC and on http:// tools.ietf.org/group/proto/home/ as http://www.ietf.org/IESG/content/Doc-Writeup.html and http://www.ietf.org/IESG/content/Indiv-Doc-Writeup.html I don't know where the second version comes from - the sponsoring guidelines? I also don't know who maintains these templates and how additions such as the above would be made. Do we edit those web pages? Do we issue an RFC4858bis? Do we turn the templates into an ION? Lars > Begin forwarded message: >> From: "ext Stig Venaas" >> Date: July 1, 2007 11:37:43 GMT+03:00 >> To: Lars Eggert >> Cc: ext Ralph Droms , Jari Arkko >> >> Subject: Re: Question for draft shepherd's questionnaire? >> >> Lars Eggert wrote: >>> On 2007-6-29, at 14:51, ext Ralph Droms wrote: >>>> "Does this Internet Draft propose any extensions to the >>>> operation or capabilities of any other protocols such as IPv6 >>>> (extension headers), ICMP, Diameter, RADIUS, DNS or DHCP? Does >>>> this Internet Draft require that IANA assign any protocol >>>> numbers that require review by another individual or review body >>>> outside the submitting working group?" >>> We might consider adding a sentence to (1.c) on this issue. Maybe: >>> (1.c) Does the Document Shepherd have concerns that the document >>> needs more review from a particular or broader >>> perspective, >>> e.g., security, operational complexity, someone >>> familiar with >>> AAA, internationalization, or XML? >>> NEW: >>> If the document extends or makes requirements on a >>> protocol >>> that originated in another WG or area, has that group >>> reviewed that the document conforms to any established >>> protocol >>> maintenance process and that it does not conflict with >>> chartered or planned work? >> >> Adding this would be great, >> >> Stig --Apple-Mail-46--304397246 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA3MTExMzQwMzNaMCMGCSqGSIb3DQEJBDEWBBRz7DgXAcnUg3gs LjrYN9REYJrE9TCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAt3ke2T3XV2A43mjG7IcYJklW/potxaGHD497/cOhAI2b4ACmvFlN phVzSLQBg7VYMcNL6y/2a0xMU2i23DTbmhfS6p2K0wC+MPRJ+B+txtUMvXYaqgWwhsi3FxncR5S7 o8+fUjzt15OypeBDIbpWNcWdqy4t8ijCcFo+DTHE/aq2KUqWt39qYlHFfQhBsY1okOwyHJJEx1i3 dBQo5YdadZ/Bdojj+QW/BCjbeEQHHYwuBQi+onyy32IS3yOcZqA18raLxcznDU4HV15W9spCnHGh qZsJ1IWTDHICEi0U8LUVvtNA/r/J9QolKBbawVvWMtK9EUnvngah5jqYslSU/QAAAAAAAA== --Apple-Mail-46--304397246-- --===============2103255600== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============2103255600==-- From proto-team-bounces@ietf.org Wed Jul 11 09:54:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cds-0008Tc-6t; Wed, 11 Jul 2007 09:54:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cdr-0008TW-HO for proto-team@ietf.org; Wed, 11 Jul 2007 09:54:07 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8cdr-0000ze-3D for proto-team@ietf.org; Wed, 11 Jul 2007 09:54:07 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6BDrt0J027236; Wed, 11 Jul 2007 16:54:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 16:53:55 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 16:53:46 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 16:53:46 +0300 Received: from [172.21.35.100] (esdhcp035100.research.nokia.com [172.21.35.100]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6BDrjjP009809; Wed, 11 Jul 2007 16:53:45 +0300 In-Reply-To: <4694E07C.8020402@piuha.net> References: <468767D7.7020603@uninett.no> <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> <4694E07C.8020402@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <87A87D88-3BFE-44ED-B354-7888A6AF953A@nokia.com> From: Lars Eggert Subject: Re: [proto-team] Fwd: Question for draft shepherd's questionnaire? Date: Wed, 11 Jul 2007 16:53:34 +0300 To: "ext Jari Arkko" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Jul 2007 13:53:46.0347 (UTC) FILETIME=[E69D03B0:01C7C3C2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Russ Housley , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1300873106==" Errors-To: proto-team-bounces@ietf.org --===============1300873106== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-48--303615314; protocol="application/pkcs7-signature" --Apple-Mail-48--303615314 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-7-11, at 16:51, ext Jari Arkko wrote: > My take would be to edit the web pages. Do this for a year or so, > and then publish a bis if you've collected enough change. Works for me. Now I just need to know how to get permission to edit the pages... > The second version comes from the sponsoring guidelines ION. Lars --Apple-Mail-48--303615314 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA3MTExMzUzMzVaMCMGCSqGSIb3DQEJBDEWBBTL7N642VaIi4BG id5E+tP2NtCG5jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAFRgV26YQIJsGs4nXfB+gGekL4U4TOxe2Q3B4RKJllmnCm8kFQKEo yKrDPnuJjejybMMr2mGxLvk+VqTG1pPnryyM93wdlBfz0DHhiJTbUKZKXAr1FyzedVPvVllHxKQy q4S0zhXG6DATn8YjXNlsHo7rZ4cgdoGO5rw1MWvcoV+i7re5HJMEktARa0uWz/bsuttm/d8pEiTO zDubnpHwZX2YTr5aF1tETeNdJHamv+kldU3CX+qFfqBtzs1XWOIYUCDqvIdJSLWz0CvzV3Oy5en3 AcqmnUB0PHsNZ22q64X4mgagYJqen1TB+jJKy8JiPOV7Fa6BzPdzph0ozpjLoQAAAAAAAA== --Apple-Mail-48--303615314-- --===============1300873106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============1300873106==-- From proto-team-bounces@ietf.org Wed Jul 11 10:51:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dX5-0004UZ-DH; Wed, 11 Jul 2007 10:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dX4-0004UU-BO for proto-team@ietf.org; Wed, 11 Jul 2007 10:51:10 -0400 Received: from [2001:698:9:31:214:22ff:fe21:bb] (helo=merlot.tools.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8dX3-0002G8-GH for proto-team@ietf.org; Wed, 11 Jul 2007 10:51:10 -0400 Received: from localhost ([127.0.0.1] helo=marsanne.levkowetz.com ident=henrik) by merlot.tools.ietf.org with esmtp (Exim 4.67) (envelope-from ) id 1I8dX1-00085j-QN; Wed, 11 Jul 2007 16:51:07 +0200 Message-ID: <4694EE59.3090905@levkowetz.com> Date: Wed, 11 Jul 2007 16:51:05 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Lars Eggert Subject: Re: [proto-team] Fwd: Question for draft shepherd's questionnaire? References: <468767D7.7020603@uninett.no> <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> In-Reply-To: X-Enigmail-Version: 0.95.2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: lars.eggert@nokia.com, proto-team@ietf.org, housley@vigilsec.com, jari.arkko@piuha.net, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on merlot.tools.ietf.org); SAEximRunCond expanded to false X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Jari Arkko , Russ Housley , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1421016378==" Errors-To: proto-team-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1421016378== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1CF267522A6A9EC13B21F272" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1CF267522A6A9EC13B21F272 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2007-07-11 15:40 Lars Eggert said the following: > On 2007-7-3, at 11:18, ext Lars Eggert wrote: >> FYI, there was a suggestion to add an item to the questionnaire. =20 >> What do folks think? >=20 > Any opinions on this addition? Umm - not a lot. The addition seems reasonable by itself, but at the same time I'm wary of the questionnaire becoming too long. At some point we should probably require that any suggestion of an addition is accompanied by a suggestion of what should be removed. I wish the legislative bodies of countries would have a similar rule -- it's unreasonable to have a body of active laws which you expect people to follow which is so large that nobody can grasp it. >> How are we maintaining the questionnaire? Should I start a =20 >> rfc4858bis document? >=20 > The questionnaire is currently in the RFC and on http://=20 > tools.ietf.org/group/proto/home/ as >=20 > http://www.ietf.org/IESG/content/Doc-Writeup.html > and > http://www.ietf.org/IESG/content/Indiv-Doc-Writeup.html >=20 > I don't know where the second version comes from - the sponsoring =20 > guidelines? I think yes, and I think Jari created the second one. > I also don't know who maintains these templates and how additions =20 > such as the above would be made. Do we edit those web pages? Do we =20 > issue an RFC4858bis? Do we turn the templates into an ION? An ION (or two?) seems like a good idea. Henrik > Lars >=20 >> Begin forwarded message: >>> From: "ext Stig Venaas" >>> Date: July 1, 2007 11:37:43 GMT+03:00 >>> To: Lars Eggert >>> Cc: ext Ralph Droms , Jari Arkko =20 >>> >>> Subject: Re: Question for draft shepherd's questionnaire? >>> >>> Lars Eggert wrote: >>>> On 2007-6-29, at 14:51, ext Ralph Droms wrote: >>>>> "Does this Internet Draft propose any extensions to the =20 >>>>> operation or capabilities of any other protocols such as IPv6 =20 >>>>> (extension headers), ICMP, Diameter, RADIUS, DNS or DHCP? Does =20 >>>>> this Internet Draft require that IANA assign any protocol =20 >>>>> numbers that require review by another individual or review body =20 >>>>> outside the submitting working group?" >>>> We might consider adding a sentence to (1.c) on this issue. Maybe: >>>> (1.c) Does the Document Shepherd have concerns that the document= >>>> needs more review from a particular or broader =20 >>>> perspective, >>>> e.g., security, operational complexity, someone =20 >>>> familiar with >>>> AAA, internationalization, or XML? >>>> NEW: >>>> If the document extends or makes requirements on a =20 >>>> protocol >>>> that originated in another WG or area, has that group >>>> reviewed that the document conforms to any established =20 >>>> protocol >>>> maintenance process and that it does not conflict with >>>> chartered or planned work? >>> Adding this would be great, >>> >>> Stig >>> >>> ---------------------------------------------------------------------= --- >>> >>> _______________________________________________ >>> proto-team mailing list >>> proto-team@ietf.org >>> https://www1.ietf.org/mailman/listinfo/proto-team --------------enig1CF267522A6A9EC13B21F272 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFGlO5aeVhrtTJkXCMRArDWAKDInoJwvGG3e3ittLfXKHRoVygBCQCeIPef OQweeGgI1yK34BQPQFo26TA= =GDV3 -----END PGP SIGNATURE----- --------------enig1CF267522A6A9EC13B21F272-- --===============1421016378== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============1421016378==-- From proto-team-bounces@ietf.org Wed Jul 11 11:34:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8eCX-0005wE-2o; Wed, 11 Jul 2007 11:34:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8eCV-0005vp-BW for proto-team@ietf.org; Wed, 11 Jul 2007 11:33:59 -0400 Received: from corvus.nsf.gov ([198.181.231.29]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8eCV-0003iv-1F for proto-team@ietf.org; Wed, 11 Jul 2007 11:33:59 -0400 Received: from nsf-fe-01.nsf.gov (HELO nsf-fe-01.ad.nsf.gov) ([128.150.4.151]) by corvus.nsf.gov with ESMTP; 11 Jul 2007 11:33:24 -0400 X-SBRS: None Received: from NSF-BE-03.ad.nsf.gov ([128.150.130.227]) by nsf-fe-01.ad.nsf.gov with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 11:33:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [proto-team] Fwd: Question for draft shepherd's questionnaire? Date: Wed, 11 Jul 2007 11:33:39 -0400 Message-ID: <3E387C1C64088E499E7BF0E86B0E1BF7F85BFD@NSF-BE-03.ad.nsf.gov> In-Reply-To: <4694EE59.3090905@levkowetz.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [proto-team] Fwd: Question for draft shepherd's questionnaire? Thread-Index: AcfDyv7231ACduidTFOGCF0zTZ1imgABKGRQ References: <468767D7.7020603@uninett.no> <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> <4694EE59.3090905@levkowetz.com> From: "Mankin, Allison J" To: "Henrik Levkowetz" , "Lars Eggert" X-OriginalArrivalTime: 11 Jul 2007 15:33:46.0404 (UTC) FILETIME=[DEED0E40:01C7C3D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Russ Housley , Jari Arkko , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org =20 Hi, I think we should not add to the questionnaire without a fairly high bar. But I also think that we should put out a quick redo of 4858 that says the questionnaire will be found as an ION, now that there's a pretty easy to find the ION repository. I have more to say on the content of Ralph's suggestion, but I've been writing something and deadlining on it...Gack. Allison -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Wednesday, July 11, 2007 10:51 AM To: Lars Eggert Cc: Jari Arkko; Russ Housley; proto-team@ietf.org Subject: Re: [proto-team] Fwd: Question for draft shepherd's questionnaire? On 2007-07-11 15:40 Lars Eggert said the following: > On 2007-7-3, at 11:18, ext Lars Eggert wrote: >> FYI, there was a suggestion to add an item to the questionnaire. =20 >> What do folks think? >=20 > Any opinions on this addition? Umm - not a lot. The addition seems reasonable by itself, but at the same time I'm wary of the questionnaire becoming too long. At some point we should probably require that any suggestion of an addition is accompanied by a suggestion of what should be removed. I wish the legislative bodies of countries would have a similar rule -- it's unreasonable to have a body of active laws which you expect people to follow which is so large that nobody can grasp it. >> How are we maintaining the questionnaire? Should I start a rfc4858bis >> document? >=20 > The questionnaire is currently in the RFC and on http://=20 > tools.ietf.org/group/proto/home/ as >=20 > http://www.ietf.org/IESG/content/Doc-Writeup.html > and > http://www.ietf.org/IESG/content/Indiv-Doc-Writeup.html >=20 > I don't know where the second version comes from - the sponsoring=20 > guidelines? I think yes, and I think Jari created the second one. > I also don't know who maintains these templates and how additions such > as the above would be made. Do we edit those web pages? Do we issue an > RFC4858bis? Do we turn the templates into an ION? An ION (or two?) seems like a good idea. Henrik > Lars >=20 >> Begin forwarded message: >>> From: "ext Stig Venaas" >>> Date: July 1, 2007 11:37:43 GMT+03:00 >>> To: Lars Eggert >>> Cc: ext Ralph Droms , Jari Arkko=20 >>> >>> Subject: Re: Question for draft shepherd's questionnaire? >>> >>> Lars Eggert wrote: >>>> On 2007-6-29, at 14:51, ext Ralph Droms wrote: >>>>> "Does this Internet Draft propose any extensions to the operation=20 >>>>> or capabilities of any other protocols such as IPv6 (extension=20 >>>>> headers), ICMP, Diameter, RADIUS, DNS or DHCP? Does this Internet >>>>> Draft require that IANA assign any protocol numbers that require=20 >>>>> review by another individual or review body outside the submitting >>>>> working group?" >>>> We might consider adding a sentence to (1.c) on this issue. Maybe: >>>> (1.c) Does the Document Shepherd have concerns that the document >>>> needs more review from a particular or broader=20 >>>> perspective, >>>> e.g., security, operational complexity, someone familiar=20 >>>> with >>>> AAA, internationalization, or XML? >>>> NEW: >>>> If the document extends or makes requirements on a=20 >>>> protocol >>>> that originated in another WG or area, has that group >>>> reviewed that the document conforms to any established=20 >>>> protocol >>>> maintenance process and that it does not conflict with >>>> chartered or planned work? >>> Adding this would be great, >>> >>> Stig >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> proto-team mailing list >>> proto-team@ietf.org >>> https://www1.ietf.org/mailman/listinfo/proto-team _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Thu Jul 12 03:47:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tOC-0005OX-IO; Thu, 12 Jul 2007 03:47:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8tOB-0005OP-FC for proto-team@ietf.org; Thu, 12 Jul 2007 03:47:03 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8tO7-000243-0c for proto-team@ietf.org; Thu, 12 Jul 2007 03:47:03 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6C7kt01026546; Thu, 12 Jul 2007 10:46:57 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 10:46:53 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 10:46:53 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 10:46:53 +0300 Received: from [172.21.34.172] (esdhcp034172.research.nokia.com [172.21.34.172]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6C7kolp014208; Thu, 12 Jul 2007 10:46:51 +0300 In-Reply-To: <3E387C1C64088E499E7BF0E86B0E1BF7F85BFD@NSF-BE-03.ad.nsf.gov> References: <468767D7.7020603@uninett.no> <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> <4694EE59.3090905@levkowetz.com> <3E387C1C64088E499E7BF0E86B0E1BF7F85BFD@NSF-BE-03.ad.nsf.gov> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <05D8CB2B-C98B-4822-A633-00C6E5C57AFC@nokia.com> From: Lars Eggert Subject: Re: [proto-team] Fwd: Question for draft shepherd's questionnaire? Date: Thu, 12 Jul 2007 10:46:50 +0300 To: "ext Mankin, Allison J" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jul 2007 07:46:53.0403 (UTC) FILETIME=[D04A12B0:01C7C458] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Russ Housley , Jari Arkko , Henrik Levkowetz , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0853880727==" Errors-To: proto-team-bounces@ietf.org --===============0853880727== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--239219391; protocol="application/pkcs7-signature" --Apple-Mail-2--239219391 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-7-11, at 18:33, ext Mankin, Allison J wrote: > I think we should not add to the questionnaire without a fairly high > bar. But I also think that we should put out a quick redo of 4858 > that > says the questionnaire will be found as an ION, now that there's a > pretty easy to find the ION repository. OK, that works for me. I'll start putting together a revised ID and an initial ION and will post it to the list later. > I have more to say on the content of Ralph's suggestion, but I've been > writing something and deadlining on it...Gack. OK. Lars --Apple-Mail-2--239219391 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA3MTIwNzQ2NTFaMCMGCSqGSIb3DQEJBDEWBBSJ1TRRSroLHAhc 5DpnENXROu8MFjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAu15mXlsDpRGo3Lx4+UHPYEqIE6rIs3KvRimu/iatxlxT/mujj7Rr DgtJQE+ZOKcxJXbDHx/jbtkM28DMq2YIlyQ6nQoRtAF2vIS+KDPuGUwmDRsb7zNAp08Ffl3joAa9 kj5Z75RkwtEPAlDAVYFjGyapQX+z5Egvu83p/kE21lwYnTWpu16UB/beU5APoIMwgmp7xj5ikWkK L4OUgJIvj8xq5UyN+m6JaUMAOsYpPbq/DSZTbGDac/85QbOOQ83p1AK76PG4Fqe54pEFxCleek0f zUbjoIkUT49gZdv0OeAPX+9OigCRT8dYytPGAPGp2VxBnbREZBlduguHIARHYgAAAAAAAA== --Apple-Mail-2--239219391-- --===============0853880727== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============0853880727==-- From proto-team-bounces@ietf.org Fri Jul 13 09:09:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Ktw-00007n-Ga; Fri, 13 Jul 2007 09:09:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Ktu-00007W-KY for proto-team@ietf.org; Fri, 13 Jul 2007 09:09:38 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Ktk-0006o6-Dy for proto-team@ietf.org; Fri, 13 Jul 2007 09:09:38 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6DD9MOJ004173; Fri, 13 Jul 2007 16:09:26 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 16:09:16 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 16:09:12 +0300 Received: from [172.21.35.97] (esdhcp03597.research.nokia.com [172.21.35.97]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6DD9Ajm029695; Fri, 13 Jul 2007 16:09:10 +0300 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <05D8CB2B-C98B-4822-A633-00C6E5C57AFC@nokia.com> References: <468767D7.7020603@uninett.no> <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> <4694EE59.3090905@levkowetz.com> <3E387C1C64088E499E7BF0E86B0E1BF7F85BFD@NSF-BE-03.ad.nsf.gov> <05D8CB2B-C98B-4822-A633-00C6E5C57AFC@nokia.com> Message-Id: From: Lars Eggert Subject: Re: [proto-team] Fwd: Question for draft shepherd's questionnaire? Date: Fri, 13 Jul 2007 16:09:09 +0300 To: "ext Mankin, Allison J" , Henrik Levkowetz , Jari Arkko , Russ Housley , proto-team@ietf.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Jul 2007 13:09:12.0457 (UTC) FILETIME=[01AD4790:01C7C54F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f78a477504af065c5dcd07c0a5a2b344 Cc: X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1850474862==" Errors-To: proto-team-bounces@ietf.org --===============1850474862== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-29--133480488; protocol="application/pkcs7-signature" --Apple-Mail-29--133480488 Content-Type: multipart/mixed; boundary=Apple-Mail-28--133480636 --Apple-Mail-28--133480636 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-7-12, at 10:46, Lars Eggert wrote: > OK, that works for me. I'll start putting together a revised ID and > an initial ION and will post it to the list later. Attached are a first cut at rfc4858bis together with a diff against RFC4858 as well as a draft of the ION that would contain the template for the shepherd write-up. Comments? Lars --Apple-Mail-28--133480636 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0644; name=draft-ietf-proto-rfc4858bis.txt Content-Disposition: attachment; filename=draft-ietf-proto-rfc4858bis.txt PROTO Team H. Levkowetz Internet-Draft Ericsson Obsoletes: 4858 (if approved) D. Meyer Intended status: Informational Cisco/University of Oregon Expires: January 14, 2008 L. Eggert Nokia A. Mankin July 13, 2007 Document Shepherding from Working Group Last Call to Publication draft-ietf-proto-rfc4858bis-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been Levkowetz, et al. Expires January 14, 2008 [Page 1] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Process Description . . . . . . . . . . . . . . . . . . . . . 4 3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 5 3.2. Document Shepherding during AD Evaluation . . . . . . . . 6 3.3. Document Shepherding during IESG Evaluation . . . . . . . 8 4. Shepherding the Document's IANA Actions . . . . . . . . . . . 11 5. Document Shepherding after IESG Approval . . . . . . . . . . . 12 6. When Not to Use the Document Shepherding Process . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Example Document Announcement Write-Ups . . . . . . . 15 A.1. Example Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 15 A.2. Example Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Levkowetz, et al. Expires January 14, 2008 [Page 2] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 1. Introduction Early in 2004, the IESG undertook several experiments aimed at evaluating whether any of the proposed changes to the IETF document flow process would yield qualitative improvements in document throughput and quality. One such experiment, referred to as the "PROTO process" or "PROTO" (because it was created by the "PROcess and TOols" or PROTO [PROTO] team), is a set of methodologies designed to involve working group chairs or secretaries more directly in their documents' approval life cycle. In particular, the PROTO team focused on improvements to the part of a document's life cycle that occurs after the working group and document editor have forwarded it to the IESG for publication. By the end of 2004, the IESG had evaluated the utility of the PROTO methodologies based on data obtained through several pilot projects that had run throughout the year, and subsequently decided to adopt the PROTO process for all documents and working groups. This document describes this process. The methodologies developed and piloted by the PROTO team focus on the working group chair or secretary as the primary Document Shepherd. The primary objective of this document shepherding process is to improve document-processing throughput and document quality by enabling a partnership between the Responsible Area Director and the Document Shepherd. In particular, this partnership has the explicit goal of enfranchising the Document Shepherd while at the same time offloading a specific part of the follow-up work that has traditionally been responsibility of the Responsible Area Director. The Responsible Area Director has tens or many tens of documents to follow, while the Document Shepherd has only a few at a time. Flowing the responsibility to the working group level can ensure more attention and more timely response. Consequently, the document shepherding process includes follow-up work during all document-processing stages after Working Group Last Call, i.e., during AD Evaluation of a document, during IESG Evaluation, and during post-approval processing by IANA and the RFC Editor. In these stages, it is the responsibility of the Document Shepherd to track and follow up on feedback received on a document from all relevant parties. The Document Shepherd is usually a chair of the working group that has produced the document. In consultation with the Responsible Area Director, the chairs may instead decide to appoint the working group secretary as the responsible Document Shepherd. Levkowetz, et al. Expires January 14, 2008 [Page 3] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 3. Process Description The document shepherding process consists of the following tasks: o Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested, as described in Section 3.1. o During AD Evaluation of the document by the Responsible Area Director, managing the discussion between the editors, the working group, and the Responsible Area Director, as described in Section 3.2. o During an IETF Last Call, if performed for the shepherded document, following up on community feedback and review comments. o During IESG Evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document, as described in Section 3.3. o Following up on IANA and RFC Editor requests as described in Section 4 and Section 5. The shepherd must keep the document moving forward, communicating about it with parties who review and comment on it. The shepherd must obtain the working group's consensus for any substantive proposed changes. The shepherd is the leader for the document and for the working group, and maintains a critical and technical perspective. In summary, the Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has done while responsible for the document in the working group. Before any document shepherding takes place, a single Document Shepherd MUST be identified for a document (he or she will be named in the Document Shepherd Write-Up) . Frequently, the chairs and the Responsible Area Director will decide that the working group will adopt the PROTO process for all their future documents. After that decision, the chairs, in consultation with the Responsible Area Director, decide on who should act as Document Shepherd for any given document. This is typically and by default one of the chairs of the Levkowetz, et al. Expires January 14, 2008 [Page 4] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 working group. In consultation with the Responsible Area Director, the chairs MAY also decide to appoint the working group secretary as Document Shepherd for a given document. The Document Shepherd SHOULD NOT be an editor of the shepherded document. It is intended that the Document Shepherd role be filled by one person during the entire shepherding process. However, situations may occur when the Document Shepherd role may be reassigned to different persons during the lifetime of a document. It is up to the chairs and Responsible Area Director to identify situations when this may become necessary, and then consult to appoint a new Document Shepherd. It is important to note that the document shepherding process only applies to documents that are the product of a working group. It does not apply to documents that originate elsewhere. Additionally, Section 6 discusses other instances in which the document shepherding process does not apply. 3.1. Document Shepherd Write-Up When a working group decides that a document is ready for submission to the IESG for publication, it is the task of the Document Shepherd to complete a "Document Shepherd Write-Up" for the document. There are two parts to this task. First, the Document Shepherd answers a number of questions to give the Responsible Area Director insight into the working group process that applied to this document. Note that while these questions may appear redundant in some cases, they are written to elicit information that the Responsible Area Director must be aware of (to this end, pointers to relevant entries in the WG archive are helpful). The goal here is to inform the Responsible Area Director about any issues that may have come up in IETF meetings, on the mailing list, or in private communication that they should be aware of prior to IESG Evaluation of the shepherded document. Any significant issues mentioned in the questionnaire will probably lead to a follow-up discussion with the Responsible Area Director. The second part of the task is to prepare the "Document Announcement Write-Up" that is input both to the ballot for the IESG telechat and to the eventual IETF-wide announcement message. Some examples of Document Announcement Write-Ups are included in Appendix A, and there are many more examples with subject lines such as "Protocol Action" and "Document Action" in the IETF-announce mailing list archive. Levkowetz, et al. Expires January 14, 2008 [Page 5] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 The template for the Document Shepherd Write-Up is not included in this document, because it is frequently modified to improve its usefulness and clarity. The current version of this template is available as an Internet Operational Note (ION) [RFC4693] named ion- doc-shepherd-writeup-wg-template.txt from the IESG section of the IETF web site [ION-TEMPLATE]. Document Shepherds SHOULD make sure their Write-Up follows the latest available template. The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal information that needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. The Document Shepherd Write-Up is entered into the ID Tracker [IDTRACKER] as a "Comment". The name and email address of the Document Shepherd are entered into the ID Tracker, currently as a "Brief Note" (this may change in the future). The email address of the Document Shepherd MUST also be added to the "State or Version Change Notice To" field (typically the email addresses of all working group chairs, authors, and the secretary will be added). Entering the name and email of the Document Shepherd into the ID Tracker is REQUIRED to ensure that he or she will be copied on the email exchange between the editors, chairs, the IESG, the IESG secretariat, IANA, and the RFC Editor during the review and approval process. There are still manual steps required for these parties to ensure that they include the Document Shepherd, but it is hoped that in the future, automated tools will ensure that Document Shepherds (and others) receive necessary communications. The contact information for the Document Shepherd is also important for the Gen-ART team [GEN-ART], area directorates, and other review teams, so they can know to whom to address reviews, in addition to the Responsible Area Director. 3.2. Document Shepherding during AD Evaluation The steps for document shepherding during AD Evaluation are as follows: Levkowetz, et al. Expires January 14, 2008 [Page 6] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 (2.a) The Responsible Area Director reads, evaluates, and comments on the document, as is the case when not using the document shepherding process. If the Responsible Area Director determines that the document is ready for IESG Evaluation, he or she indicates this to the Document Shepherd and the document shepherding process continues as described in Section 3.3. (2.b) If the Responsible Area Director has identified issues with a document that must be addressed before IESG Evaluation can commence, he or she sends a full evaluation to the Document Shepherd and SHOULD also enter the review into the ID Tracker. (2.c) The Document Shepherd reads the AD Evaluation comments, making very certain that all comments are understood, so that it is possible to follow up on them with the editors and working group. If there is some uncertainty as to what is requested, this SHOULD be resolved with the Responsible Area Director. (2.d) The Document Shepherd sends the AD Evaluation comments to the editors and to the working group mailing list, in order to have a permanent record of the comments. It is RECOMMENDED that the Document Shepherd solicit from the editors an estimate on when the required changes will be completed and a revised document can be expected. Working groups that use issue tracking SHOULD also record the issues (and eventually their resolution) in their issue tracker. (2.e) During the production of a revised document that addresses the AD Evaluation comments, it is RECOMMENDED that the editors keep a list showing how each comment was addressed and what the revised text is. It is RECOMMENDED that this list be forwarded to the Responsible Area Director together with the revised document. (2.f) In the event that the editors or working group disagrees with a comment raised by the Responsible Area Director or has previously considered and dismissed the issue, the Document Shepherd MUST resolve the issue with the Responsible Area Director before a revised document can be submitted. (2.g) The Document Shepherd iterates with the editors (and working group, if required) until all outstanding issues have been resolved and a revised document is available. At this point, the Document Shepherd notifies the Responsible Area Director and provides him or her with the revised document, the summary of issues, and the resulting text changes. Levkowetz, et al. Expires January 14, 2008 [Page 7] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 (2.h) The Responsible Area Director verifies that the issues he or she found during AD Evaluation are resolved in the revised version of the document by starting the process described in this section at step (2.a). (2.i) If the document underwent an IETF Last Call and the AD concludes that significant issues were raised during the Last Call, then steps (2.b) through (2.h) need to be applied addressing the Last Call issues. This requires the Responsible Area Director to present to the Document Shepherd those Last Call issues raised only to the IESG. 3.3. Document Shepherding during IESG Evaluation During IESG Evaluation of a document, ADs can bring forward two kinds of remarks about a document: DISCUSS items and COMMENT items. A DISCUSS blocks a document's approval process until it has been resolved; a COMMENT does not. This section details the steps that a Document Shepherd takes to resolve any DISCUSS and COMMENT items brought forward against a shepherded document during IESG Evaluation. Note that DISCUSS and COMMENT items are occasionally written in a manner that makes their intent unclear. In these cases, the Document Shepherd SHOULD start a discussion with the ADs who brought the items up to clarify their intent, keeping the Responsible Area Director informed. If this fails to clarify the intent, the Responsible Area Director may need to work towards a clarification inside the IESG. (3.a) Leading up to the IESG conference call, the Document Shepherd may see emails about the document from directorate reviewers on behalf of one or more ADs and also emailed copies of DISCUSS and COMMENT items entered into the ID Tracker. The Document Shepherd SHOULD immediately begin to work on resolving DISCUSS and COMMENT items with the ADs who have raised them, keeping the Responsible Area Director copied on the email exchange, so that he or she is able to support the activity during the conference call. When dealing with directorate reviews, the Document Shepherd MUST involve the ADs to whom these directorates report to ensure that these ADs consider the review comments that need resolving. (3.b) Immediately following the conference call, when the document changes state from the "IESG Evaluation" state to one of the states requiring Document Shepherd action, e.g., "IESG Evaluation: Revised ID Needed" or "IESG Evaluation: AD Followup", the Document Shepherd will receive email. A state of "AD Followup" typically signifies the Responsible Area Director's hope that a resolution may be possible through a Levkowetz, et al. Expires January 14, 2008 [Page 8] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 continued discussion or (more usually) through a small set of changes as "Notes to the RFC Editor". Note that there may be very exceptional cases when DISCUSS items are registered after an IESG conference call. In these cases, the AD who has raised the DISCUSS MUST notify the Document Shepherd about it. (The notification facility in the ID Tracker is very convenient for this purpose and also for the cases where the DISCUSS and COMMENT items are updated after they are partially resolved.) (3.c) The Document Shepherd then queries the ID Tracker to collect the remaining DISCUSS and COMMENT items raised against the document. The Document Shepherd analyzes these items and initializes contact with the ADs who have placed them. The Responsible Area Director MUST be copied on all correspondence related to active DISCUSS or COMMENT items. This does not place the Responsible Area Director in the critical path towards a resolution, but should keep him or her informed about the state of the discussion. +-------+ +-------+ +-------+ | (3.b) | -----------> | (3.c) | ------------> | (3.d) | +-------+ Comments +-------+ Comments +-------+ collected /|\ | understood | | | | Comments not fully understood | | (Further AD/Document Shepherd | | discussion required) +---+ (3.d) The Document Shepherd then coordinates the resolution of DISCUSS and COMMENT items and builds a consistent interpretation of the comments. This step is similar to much of the process described in Section 3.2. +-------+ +-------+ | (3.c) | ---------------> | (3.d) | +-------+ Consistent +-------+ /|\ interpretation | | | Further AD/Document Shepherd | | discussion required +--------------------------+ Levkowetz, et al. Expires January 14, 2008 [Page 9] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 (3.e) The Document Shepherd then communicates the DISCUSS and COMMENT items to the document editors and the working group, alerting them of any changes to the document that have accumulated during IESG processing, such as "Notes to the RFC Editor". If any changes will be substantive, the Document Shepherd, in consultation with the Responsible Area Director, as during other stages, MUST confirm working group consensus or sometimes even IETF consensus. (3.f) After the editors resolve the DISCUSS and COMMENT items, the Document Shepherd reviews the resulting new version of the document, which will be a revised document, a set of "Notes to the RFC Editor", or both, using his or her technical expertise to ensure that all raised DISCUSS and COMMENT issues have been resolved. Note that the Document Shepherd MAY also suggest resolutions to DISCUSS and COMMENT items, enter them into an issue tracker, or perform other steps to streamline the resolution of the evaluation comments. It is very important to resolve the comments in a timely way, while the discussion is current for everyone involved. (3.g) When the Document Shepherd is satisfied that the revised document addresses the evaluation comments, he or she communicates the resolution to the Responsible Area Director and the ADs that had raised the DISCUSS and COMMENT items. (3.h) Each AD who had raised a DISCUSS checks whether the communicated resolution addresses his or her items. If it does, the AD will clear the DISCUSS. If it does not, the AD notifies the Document Shepherd and adds information to the ID Tracker explaining why the DISCUSS was not resolved. The Document Shepherd informs the working group accordingly. (COMMENT items need not be checked and cleared, because they do not block the document, but ADs are encouraged to do so.) If a DISCUSS was not resolved to the satisfaction of the AD that has raised it or the Responsible Area Director, two possibilities exist: (a) The process returns to step (3.d), or (b) If no progress can be made on the resolution of the DISCUSS with the AD who has raised it, despite repeated clarifications and discussions, the Responsible Area Director should take over continued shepherding of the document. Such a situation may be indicative of larger Levkowetz, et al. Expires January 14, 2008 [Page 10] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 issues that the PROTO process was not designed to handle. Once the process above has cleared all DISCUSS items, document shepherding continues with step (3.i). (3.i) The Responsible Area Director moves the document to the "Approved - Announcement to be sent" state in the ID Tracker. If he or she deems the changes to the revised document significant, there may be a new WG Last Call, or possibly a new IETF Last Call. The document goes through a new full IESG Evaluation process if there is a new IETF Last Call. 4. Shepherding the Document's IANA Actions IETF working group documents often include considerations requiring actions by the IANA, such as creating a new registry or adding information to an existing registry, perhaps after consulting an IESG-appointed Expert. Sometimes the Document Shepherd must keep track of certain IANA actions to be completed by the IESG, such as ratifying the appointment of a designated Expert called for in the IANA Considerations. IANA-related processing may also include a specified type of Expert review, such as review of proposed MIME media types on the designated ietf-types mailing list. The IANA reviews IETF documents and requests responses at any or all of the following times: in response to IETF Last Call, during the IESG Evaluation review of the document, and at the time when the IANA performs actions in its web-based registry for the document, usually but not always after IESG approval of the document. More details of the IANA process and IETF interaction are found in [RFC2434]. At the time of this publication, RFC2434 is under revision [I-D.narten-iana-considerations-rfc2434bis] and the updates are and will be of value to the Document Shepherd. Note that the Document Shepherd MUST determine (by individual review and consultation with others) what is the most recent and the most applicable IANA information and guidance for his or her document, be it the overall guidance, or external documents in his or her area, or in other areas. An example of an external document is [RFC4020]. Whenever an IANA request comes, during whatever phase of the shepherding process, the requester from IANA MUST ensure that the Document Shepherd and the Responsible Area Director both receive the request. The Document Shepherd is responsible for responding as rapidly as possible. He or she should discuss requests that introduce any possible concerns with the working group. The Document Shepherd and the Responsible Area Director may decide in consultation Levkowetz, et al. Expires January 14, 2008 [Page 11] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 that an IANA request leads to a change that needs additional review or approval. In general, the Document Shepherd ensures that the IANA process completes, checks that the registry is correct and that the IANA Matrix (http://www.iana.org/numbers.html) is complete and consistent, and troubleshoots when all is not well. At the end of IANA processing, the Document Shepherd should be sure that the RFC Editor has acknowledged IANA conclusion, i.e., that the handoff has been made. In summary, the task of shepherding the IANA actions is often overlooked, but is as important to coordinate and manage as all the other document reviews the Document Shepherd has managed. As with those, the Document Shepherd contributes greatly to quality and timeliness of the document by effective and responsive shepherding of the IANA requests. 5. Document Shepherding after IESG Approval After the IESG Evaluation and resolution described in Section 3.3, the IESG approves the document, and the Responsible Area Director uses the ID Tracker to ask for any final changes to the Document Announcement Write-Up and for it to be issued. The Document Shepherd may have some edits for the Responsible Area Director, such as minor "Notes to the RFC Editor", and this is the time to consult and provide them. The IESG approval announcement goes to the general community and to the RFC Editor, and now the Document Shepherd (identified in the Announcement Write-Up) continues to shepherd the document through its technical publication. The RFC Editor currently makes a number of types of requests to the authors, Document Shepherd and Responsible Area Director. The Document Shepherd SHOULD lead in responding to the RFC Editor and shepherd the document during the post-approval period to its publication. The RFC Editor request types include: editorial queries about dangling or missing informative and normative citations (good shepherding should try to catch these earlier, but they happen); requests for the document source (e.g., XML or nroff); occasional technical comments; and copy-edits for review and close scrutiny by the authors (AUTH48). For the latter, the Document Shepherd SHOULD lead in checking that copy-edits have in no case affected a consensus wording of the working group that prepared the document, and SHOULD bring speed to this checking by multiple coauthors. The Document Shepherd also consults with the Responsible Area Director on Levkowetz, et al. Expires January 14, 2008 [Page 12] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 reviewing proposed post-approval changes to the document by any author. These may require Area Director approval, and they often need to be presented to the working group for consent if not a full consensus procedure. As in other phases of document shepherding, the Document Shepherd provides attentiveness and timeliness by serving as the informed representative of the document and helping its advancement and its integrity. 6. When Not to Use the Document Shepherding Process As mentioned in Section 3, the Document Shepherd SHOULD NOT be an editor of the shepherded document. If this cannot be avoided by making another working group chair or secretary the Document Shepherd, the document shepherding process SHOULD NOT be used. There are several other cases in which the document shepherding process SHOULD NOT be used. These include: 1. Cases where the Document Shepherd is the primary author or editor of a large percentage of the documents produced by the working group. 2. Cases where the Responsible Area Director expects communication difficulties with the Document Shepherd (either due to experience, strong views stated by the Document Shepherd, or other issues). 3. Cases where the working group itself is either very old, losing energy, or winding down (i.e., cases where it would not be productive to initiate new processes or procedures). Finally, note that other cases exist in which using the document shepherding process may not be productive. The final determination as to whether or not to use the document shepherding process is left to the Responsible Area Director. If the document shepherding process is not used, the Responsible Area Director acts as Document Shepherd, per the existing procedures of shepherding by Area Directors. 7. Security Considerations This document specifies a change to IETF document-processing procedures. As such, it neither raises nor considers protocol- specific security issues. Levkowetz, et al. Expires January 14, 2008 [Page 13] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 8. IANA Considerations This document creates no new requirements on IANA namespaces or other IANA requirements. 9. Acknowledgments This document is the product of the PROTO team, which includes the authors as well as Bill Fenner, Barbara Fuller, and Margaret Wasserman. Aaron Falk worked actively in PROTO until the start of 2006 and worked on earlier versions of the document. The Document Shepherd Write-Up originated in an idea by John Klensin. Thomas Narten and Margaret Wasserman implemented it for the entire Internet Area, and their template was the basis of the version used today. Colin Perkins wrote the original Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black wrote the original Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Both original announcements have been modified to reflect changes to the Document Announcement Write-Up template since they were written. Frank Ellermann and Olafur Gudmundsson have suggested improvements to the document during IETF Last Call. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [RFC4693] Alvestrand, H., "IETF Operational Notes", RFC 4693, October 2006. [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Levkowetz, et al. Expires January 14, 2008 [Page 14] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-06 (work in progress), March 2007. [IDTRACKER] "The IETF Internet-Draft Tracker", Web Application: https://datatracker.ietf.org/, 2002. [ION-TEMPLATE] "Document Shepherd Write-Up Template for Working Group Documents", Internet Operational Note (ION) ion-doc- shepherd-writeup-wg-template.txt, Web Page: http:// www.ietf.org/IESG/content/ions/ ion-doc-shepherd-writeup-wg-template.txt. [PROTO] "The IESG PROcess and TOols (PROTO) Team", Web Page: http://tools.ietf.org/group/proto/home/, 2004. [GEN-ART] "The General Area Review Team (GEN-ART)", Web Page: http://www.alvestrand.no/ietf/gen/review-guidelines.html, 2005. Appendix A. Example Document Announcement Write-Ups This appendix includes two examples of Document Announcement Write- Ups. Many more examples with Subject lines such as "Protocol Action" and "Document Action" can be found in the IETF-announce mailing list archive. Note that these examples follow the structure of the Document Announcement Write-Up in the Document Shepherd Write-Up template that was current when this document was written. The current version of this template is available as an Internet Operational Note (ION) [RFC4693] named ion-doc-shepherd-writeup-wg-template.txt from the IESG section of the IETF web site [ION-TEMPLATE]. Document Shepherds SHOULD make sure their Write-Up follows the latest available template. A.1. Example Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format Levkowetz, et al. Expires January 14, 2008 [Page 15] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 Technical Summary These documents define the RTP Payload format for MIDI (Musical Instrument Digital Interface), and additional guidelines on implementation specifically concerning the timing of reception and transmission for best performance in different applications. MIDI is a real-time media, which however is brittle to losses and errors. Therefore the RTP payload format defines recovery journals as a way of avoiding persistent audible errors, and discusses congestion control handling for these journals. The RTP payload for MIDI encodes the broad range of MIDI commands. The format is suitable for interactive applications (such as network musical performance) and content-delivery (such as file streaming). Working Group Summary There is consensus in the WG to publish these documents. Document Quality This RTP Payload format has been implemented during the development of the specification and successfully tested over an IP network between two remote sites, thus showing that the technical solution is successfully working. It has been reviewed by the MIDI Manufacturers Association and their comments have been addressed. Personnel Magnus Westerlund and Colin Perkins jointly shepherded this document. Allison Mankin reviewed the document for the IESG, including a careful review with the editor of the media types, in parallel with ietf-types list review requested on 2006-01-08, which raised no issues. A.2. Example Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel Technical Summary This document specifies the encapsulation of IPv6, IPv4 and ARP packets over Fibre Channel. This document also specifies the methods for forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document (when published as RFC) obsoletes RFC2625 Levkowetz, et al. Expires January 14, 2008 [Page 16] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 and RFC3831. Working Group Summary This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG. There is solid support for this document both in the WG and from T11. Document Quality This document replaces and consolidates two separate RFCs on IPv4 over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 3831). Most of its technical content is unchanged from those RFCs. The technical changes that have been made are primarily based on implementation experience. Personnel The protocol has been reviewed for the IESG by David L. Black (WG chair). Bert Wijnen has reviewed this document for the IESG. In addition, Brian Haberman has done a review for the INT Area as requested by WG-chair (David Black) via Margaret Wasserman. Authors' Addresses Henrik Levkowetz Torsgatan 71 Stockholm S-113 37 Sweden Phone: +46 708 32 16 08 Email: henrik@levkowetz.com David Meyer 1225 Kincaid St Eugene, OR 97403 USA Phone: +1 541 346 1747 Email: dmm@1-4-5.net Levkowetz, et al. Expires January 14, 2008 [Page 17] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +49 50 48 24461 Email: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/ Allison Mankin Phone: +1-301-728-7199 Email: mankin@psg.com URI: http://www.psg.com/~mankin Levkowetz, et al. Expires January 14, 2008 [Page 18] =0C Internet-Draft Document Shepherding to IESG Approval July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Levkowetz, et al. Expires January 14, 2008 [Page 19] =0C --Apple-Mail-28--133480636 Content-Transfer-Encoding: 7bit Content-Type: text/html; x-unix-mode=0644; name=draft-ietf-proto-rfc4858bis-from-rfc4858.diff.html Content-Disposition: attachment; filename=draft-ietf-proto-rfc4858bis-from-rfc4858.diff.html Diff: rfc4858.txt - draft-ietf-proto-rfc4858bis.txt
 rfc4858.txt   draft-ietf-proto-rfc4858bis.txt 
Network Working Group H. Levkowetz PROTO Team H. Levkowetz
Request for Comments: 4858 Ericsson Internet-Draft Ericsson
Category: Informational D. Meyer Obsoletes: 4858 (if approved) D. Meyer
Cisco/University of Oregon Intended status: Informational Cisco/University of Oregon
L. Eggert Expires: January 14, 2008 L. Eggert
Nokia Nokia
A. Mankin A. Mankin
July 13, 2007
Document Shepherding from Working Group Last Call to Publication Document Shepherding from Working Group Last Call to Publication
draft-ietf-proto-rfc4858bis-00
Status of This Memo Status of this Memo
This memo provides information for the Internet community. It does By submitting this Internet-Draft, each author represents that any
not specify an Internet standard of any kind. Distribution of this applicable patent or other IPR claims of which he or she is aware
memo is unlimited. have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes methodologies that have been designed to This document describes methodologies that have been designed to
improve and facilitate IETF document flow processing. It specifies a improve and facilitate IETF document flow processing. It specifies a
set of procedures under which a working group chair or secretary set of procedures under which a working group chair or secretary
skipping to change at page 2, line 11 skipping to change at page 2, line 14
submitted to the IESG for publication. Before this, the Area submitted to the IESG for publication. Before this, the Area
Director responsible for the working group has traditionally filled Director responsible for the working group has traditionally filled
the shepherding role. the shepherding role.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Process Description . . . . . . . . . . . . . . . . . . . . . 4 3. Process Description . . . . . . . . . . . . . . . . . . . . . 4
3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 5 3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 5
3.2. Document Shepherding during AD Evaluation . . . . . . . . 9 3.2. Document Shepherding during AD Evaluation . . . . . . . . 6
3.3. Document Shepherding during IESG Evaluation . . . . . . . 10 3.3. Document Shepherding during IESG Evaluation . . . . . . . 8
4. Shepherding the Document's IANA Actions . . . . . . . . . . . 13 4. Shepherding the Document's IANA Actions . . . . . . . . . . . 11
5. Document Shepherding after IESG Approval . . . . . . . . . . . 14 5. Document Shepherding after IESG Approval . . . . . . . . . . . 12
6. When Not to Use the Document Shepherding Process . . . . . . . 15 6. When Not to Use the Document Shepherding Process . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Example Document Announcement Write-Ups . . . . . . . 18 Appendix A. Example Document Announcement Write-Ups . . . . . . . 15
A.1. Example Document Announcement Write-Up for A.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 18 draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 15
A.2. Example Document Announcement Write-Up for A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19 draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
Early in 2004, the IESG undertook several experiments aimed at Early in 2004, the IESG undertook several experiments aimed at
evaluating whether any of the proposed changes to the IETF document evaluating whether any of the proposed changes to the IETF document
flow process would yield qualitative improvements in document flow process would yield qualitative improvements in document
throughput and quality. One such experiment, referred to as the throughput and quality. One such experiment, referred to as the
"PROTO process" or "PROTO" (because it was created by the "PROcess "PROTO process" or "PROTO" (because it was created by the "PROcess
and TOols" or PROTO [PROTO] team), is a set of methodologies designed and TOols" or PROTO [PROTO] team), is a set of methodologies designed
to involve working group chairs or secretaries more directly in their to involve working group chairs or secretaries more directly in their
skipping to change at page 5, line 29 skipping to change at page 5, line 30
Section 6 discusses other instances in which the document shepherding Section 6 discusses other instances in which the document shepherding
process does not apply. process does not apply.
3.1. Document Shepherd Write-Up 3.1. Document Shepherd Write-Up
When a working group decides that a document is ready for submission When a working group decides that a document is ready for submission
to the IESG for publication, it is the task of the Document Shepherd to the IESG for publication, it is the task of the Document Shepherd
to complete a "Document Shepherd Write-Up" for the document. to complete a "Document Shepherd Write-Up" for the document.
There are two parts to this task. First, the Document Shepherd There are two parts to this task. First, the Document Shepherd
answers questions (1.a) to (1.j) below to give the Responsible Area answers a number of questions to give the Responsible Area Director
Director insight into the working group process that applied to this insight into the working group process that applied to this document.
document. Note that while these questions may appear redundant in Note that while these questions may appear redundant in some cases,
some cases, they are written to elicit information that the they are written to elicit information that the Responsible Area
Responsible Area Director must be aware of (to this end, pointers to Director must be aware of (to this end, pointers to relevant entries
relevant entries in the WG archive are helpful). The goal here is to in the WG archive are helpful). The goal here is to inform the
inform the Responsible Area Director about any issues that may have Responsible Area Director about any issues that may have come up in
come up in IETF meetings, on the mailing list, or in private IETF meetings, on the mailing list, or in private communication that
communication that they should be aware of prior to IESG Evaluation they should be aware of prior to IESG Evaluation of the shepherded
of the shepherded document. Any significant issues mentioned in the document. Any significant issues mentioned in the questionnaire will
questionnaire will probably lead to a follow-up discussion with the probably lead to a follow-up discussion with the Responsible Area
Responsible Area Director. Director.
The second part of the task is to prepare the "Document Announcement The second part of the task is to prepare the "Document Announcement
Write-Up" that is input both to the ballot for the IESG telechat and Write-Up" that is input both to the ballot for the IESG telechat and
to the eventual IETF-wide announcement message. Item number (1.k) to the eventual IETF-wide announcement message.
describes the elements of the Document Announcement Write-Up.
Some examples of Document Announcement Write-Ups are included in Some examples of Document Announcement Write-Ups are included in
Appendix A, and there are many more examples with subject lines such Appendix A, and there are many more examples with subject lines such
as "Protocol Action" and "Document Action" in the IETF-announce as "Protocol Action" and "Document Action" in the IETF-announce
mailing list archive. mailing list archive.
The initial template for the Document Shepherd Write-Up is included The template for the Document Shepherd Write-Up is not included in
below, but changes are expected over time. The latest version of this document, because it is frequently modified to improve its
this template is available from the IESG section of the IETF web usefulness and clarity. The current version of this template is
site. available as an Internet Operational Note (ION) [RFC4693] named ion-
doc-shepherd-writeup-wg-template.txt from the IESG section of the
(1.a) Who is the Document Shepherd for this document? Has the IETF web site [ION-TEMPLATE]. Document Shepherds SHOULD make sure
Document Shepherd personally reviewed this version of the their Write-Up follows the latest available template.
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?
(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?
(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.
(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?
(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)
(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.
(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].
(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?
(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?
(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.
Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?
Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are <TO BE ADDED BY THE AD>.'
The Document Shepherd MUST send the Document Shepherd Write-Up to the The Document Shepherd MUST send the Document Shepherd Write-Up to the
Responsible Area Director and iesg-secretary@ietf.org together with Responsible Area Director and iesg-secretary@ietf.org together with
the request to publish the document. The Document Shepherd SHOULD the request to publish the document. The Document Shepherd SHOULD
also send the entire Document Shepherd Write-Up to the working group also send the entire Document Shepherd Write-Up to the working group
mailing list. If the Document Shepherd feels that information which mailing list. If the Document Shepherd feels that information which
may prove to be sensitive, may lead to possible appeals, or is may prove to be sensitive, may lead to possible appeals, or is
personal needs to be written up, it SHOULD be sent in direct email to personal information that needs to be written up, it SHOULD be sent
the Responsible Area Director, because the Document Shepherd Write-Up in direct email to the Responsible Area Director, because the
is published openly in the ID Tracker. Question (1.f) of the Document Shepherd Write-Up is published openly in the ID Tracker.
Write-Up covers any material of this nature and specifies this more
confidential handling.
The Document Shepherd Write-Up is entered into the ID Tracker The Document Shepherd Write-Up is entered into the ID Tracker
[IDTRACKER] as a "Comment". The name and email address of the [IDTRACKER] as a "Comment". The name and email address of the
Document Shepherd are entered into the ID Tracker, currently as a Document Shepherd are entered into the ID Tracker, currently as a
"Brief Note" (this may change in the future). The email address of "Brief Note" (this may change in the future). The email address of
the Document Shepherd MUST also be added to the "State or Version the Document Shepherd MUST also be added to the "State or Version
Change Notice To" field (typically the email addresses of all working Change Notice To" field (typically the email addresses of all working
group chairs, authors, and the secretary will be added). group chairs, authors, and the secretary will be added).
Entering the name and email of the Document Shepherd into the ID Entering the name and email of the Document Shepherd into the ID
skipping to change at page 13, line 44 skipping to change at page 11, line 36
media types on the designated ietf-types mailing list. media types on the designated ietf-types mailing list.
The IANA reviews IETF documents and requests responses at any or all The IANA reviews IETF documents and requests responses at any or all
of the following times: in response to IETF Last Call, during the of the following times: in response to IETF Last Call, during the
IESG Evaluation review of the document, and at the time when the IANA IESG Evaluation review of the document, and at the time when the IANA
performs actions in its web-based registry for the document, usually performs actions in its web-based registry for the document, usually
but not always after IESG approval of the document. More details of but not always after IESG approval of the document. More details of
the IANA process and IETF interaction are found in [RFC2434]. the IANA process and IETF interaction are found in [RFC2434].
At the time of this publication, RFC 2434 is under revision At the time of this publication, RFC 2434 is under revision
[RFC2434bis], and the updates are and will be of value to the [I-D.narten-iana-considerations-rfc2434bis] and the updates are and
Document Shepherd. Note that the Document Shepherd MUST determine will be of value to the Document Shepherd. Note that the Document
(by individual review and consultation with others) what is the most Shepherd MUST determine (by individual review and consultation with
recent and the most applicable IANA information and guidance for his others) what is the most recent and the most applicable IANA
or her document, be it the overall guidance, or external documents in information and guidance for his or her document, be it the overall
his or her area, or in other areas. An example of an external guidance, or external documents in his or her area, or in other
document is [RFC4020]. areas. An example of an external document is [RFC4020].
Whenever an IANA request comes, during whatever phase of the Whenever an IANA request comes, during whatever phase of the
shepherding process, the requester from IANA MUST ensure that the shepherding process, the requester from IANA MUST ensure that the
Document Shepherd and the Responsible Area Director both receive the Document Shepherd and the Responsible Area Director both receive the
request. The Document Shepherd is responsible for responding as request. The Document Shepherd is responsible for responding as
rapidly as possible. He or she should discuss requests that rapidly as possible. He or she should discuss requests that
introduce any possible concerns with the working group. The Document introduce any possible concerns with the working group. The Document
Shepherd and the Responsible Area Director may decide in consultation Shepherd and the Responsible Area Director may decide in consultation
that an IANA request leads to a change that needs additional review that an IANA request leads to a change that needs additional review
or approval. or approval.
skipping to change at page 17, line 14 skipping to change at page 14, line 41
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 10.2. Informative References
[RFC4693] Alvestrand, H., "IETF Operational Notes", RFC 4693,
October 2006.
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, Standards Track Code Points", BCP 100, RFC 4020,
February 2005. February 2005.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
an IANA Considerations Section in RFCs", BCP 26, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
RFC 2434, October 1998. October 1998.
[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards
Track Documents may Refer Normatively to Documents at a
Lower Level", BCP 97, RFC 3967, December 2004.
[RFC2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing [I-D.narten-iana-considerations-rfc2434bis]
an IANA Considerations Section in RFCs", Work in Narten, T. and H. Alvestrand, "Guidelines for Writing an
Progress, March 2007. IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-06 (work in
progress), March 2007.
[IDTRACKER] "The IETF Internet-Draft Tracker", Web [IDTRACKER]
"The IETF Internet-Draft Tracker", Web
Application: https://datatracker.ietf.org/, 2002. Application: https://datatracker.ietf.org/, 2002.
[ION-TEMPLATE]
"Document Shepherd Write-Up Template for Working Group
Documents", Internet Operational Note (ION) ion-doc-
shepherd-writeup-wg-template.txt, Web Page: http://
www.ietf.org/IESG/content/ions/
ion-doc-shepherd-writeup-wg-template.txt.
[PROTO] "The IESG PROcess and TOols (PROTO) Team", Web [PROTO] "The IESG PROcess and TOols (PROTO) Team", Web
Page: http://psg.com/~mrw/PROTO-Team, 2004. Page: http://tools.ietf.org/group/proto/home/, 2004.
[GEN-ART] "The General Area Review Team (GEN-ART)", Web Page: [GEN-ART] "The General Area Review Team (GEN-ART)", Web Page:
http://www.alvestrand.no/ietf/gen/ http://www.alvestrand.no/ietf/gen/review-guidelines.html,
review-guidelines.html, 2005. 2005.
Appendix A. Example Document Announcement Write-Ups Appendix A. Example Document Announcement Write-Ups
This appendix includes two examples of Document Announcement Write- This appendix includes two examples of Document Announcement Write-
Ups. Many more examples with Subject lines such as "Protocol Action" Ups. Many more examples with Subject lines such as "Protocol Action"
and "Document Action" can be found in the IETF-announce mailing list and "Document Action" can be found in the IETF-announce mailing list
archive. archive.
Note that these examples follow the structure of the Document
Announcement Write-Up in the Document Shepherd Write-Up template that
was current when this document was written. The current version of
this template is available as an Internet Operational Note (ION)
[RFC4693] named ion-doc-shepherd-writeup-wg-template.txt from the
IESG section of the IETF web site [ION-TEMPLATE]. Document Shepherds
SHOULD make sure their Write-Up follows the latest available
template.
A.1. Example Document Announcement Write-Up for A.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format draft-ietf-avt-rtp-midi-format
Technical Summary Technical Summary
These documents define the RTP Payload format for MIDI (Musical These documents define the RTP Payload format for MIDI (Musical
Instrument Digital Interface), and additional guidelines on Instrument Digital Interface), and additional guidelines on
implementation specifically concerning the timing of reception and implementation specifically concerning the timing of reception and
transmission for best performance in different applications. MIDI transmission for best performance in different applications. MIDI
is a real-time media, which however is brittle to losses and is a real-time media, which however is brittle to losses and
errors. Therefore the RTP payload format defines recovery errors. Therefore the RTP payload format defines recovery
journals as a way of avoiding persistent audible errors, and journals as a way of avoiding persistent audible errors, and
discusses congestion control handling for these journals. discusses congestion control handling for these journals.
skipping to change at page 20, line 13 skipping to change at page 17, line 36
requested by WG-chair (David Black) via Margaret Wasserman. requested by WG-chair (David Black) via Margaret Wasserman.
Authors' Addresses Authors' Addresses
Henrik Levkowetz Henrik Levkowetz
Torsgatan 71 Torsgatan 71
Stockholm S-113 37 Stockholm S-113 37
Sweden Sweden
Phone: +46 708 32 16 08 Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com Email: henrik@levkowetz.com
David Meyer David Meyer
1225 Kincaid St 1225 Kincaid St
Eugene, OR 97403 Eugene, OR 97403
USA USA
Phone: +1 541 346 1747 Phone: +1 541 346 1747
EMail: dmm@1-4-5.net Email: dmm@1-4-5.net
Lars Eggert Lars Eggert
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
Nokia Group 00045 Nokia Group 00045
Finland Finland
Phone: +49 50 48 24461 Phone: +49 50 48 24461
EMail: lars.eggert@nokia.com Email: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert URI: http://research.nokia.com/people/lars_eggert/
Allison Mankin Allison Mankin
Phone: +1-301-728-7199 Phone: +1-301-728-7199
EMail: mankin@psg.com Email: mankin@psg.com
URI: http://www.psg.com/~mankin URI: http://www.psg.com/~mankin
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
skipping to change at page 21, line 45 skipping to change at page 19, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 28 change blocks. 
185 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--Apple-Mail-28--133480636 Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-unix-mode=0644; name=ion-doc-shepherd-writeup-template.txt Content-Disposition: attachment; filename=ion-doc-shepherd-writeup-template.txt DRAFT ION: Document Shepherd Write-Up Template Status: To be Approved Name: ion-doc-shepherd-writeup-template Title: Document Shepherd Write-Up Template Date: July 13, 2007 To be Approved by: IESG Editor: Lars Eggert Abstract This Internet Operational Note (ION) contains the current revision of the template for Document Shepherd Write-Ups to be used with the document shepherding process described in [I-D.ietf-proto-rfc4858bis]. Document Shepherds should make sure that their write-ups follow the latest available revision of this template. 1. Document Shepherd Write-Up Template (1) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? (2) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (3) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? (4) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. (5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) (7) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? (8) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. (9) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? (10) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? (11) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. It contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? 2. References [I-D.ietf-proto-rfc4858bis] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, "Document Shepherding from Working Group Last Call to Publication", draft-ietf-proto-rfc4858bis-00 (work in progress), July 2007. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. Author's Address Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland Phone: +49 50 48 24461 Email: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert/ --Apple-Mail-28--133480636-- --Apple-Mail-29--133480488 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA3MTMxMzA5MTBaMCMGCSqGSIb3DQEJBDEWBBTnEGQSwBA0kL9j 0p3Fa5hsZSm+0jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAxvKfbUYGGjPgdh5ytO4IuLUQUtPp1Poyf+XVZQe6hX+JDe4gLaWb jIzxWGXTFwn68/NfHMmY40K1EKnTq5GJJG12rGnkDYTOHYQKZAl7g/XsGT6tltyumFCGYwOTKv+Q I5D6uMcKoPuyL+7RaEU28lfRkfKY0gmOKdocZlzU6aF/d6CHMUgwDeE+uKIQ8nmLYNEVYt5Q7TdM UXIdvY57bO4B5oww2YzzWfou0YGudr4RXqOKYzocw/rj816gudEQdnNBNxcaXLOwf47NUI6y03dO fBOCvzpn2tMg2MZZOScV9Z+JXOgO3A0o8WUA0KKkUTtHvj5r0xuJYx22i3YncQAAAAAAAA== --Apple-Mail-29--133480488-- --===============1850474862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============1850474862==-- From proto-team-bounces@ietf.org Mon Jul 16 08:41:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAPtS-0002Hp-Lm; Mon, 16 Jul 2007 08:41:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAPtR-0002Hf-Iz for proto-team@ietf.org; Mon, 16 Jul 2007 08:41:37 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAPtR-0004Gp-4q for proto-team@ietf.org; Mon, 16 Jul 2007 08:41:37 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6GCf90Y000798; Mon, 16 Jul 2007 15:41:11 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 15:40:31 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 15:40:32 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 15:40:31 +0300 Received: from [172.21.34.165] (esdhcp034165.research.nokia.com [172.21.34.165]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6GCeTgm028424; Mon, 16 Jul 2007 15:40:30 +0300 In-Reply-To: <469B6578.3010700@piuha.net> References: <468767D7.7020603@uninett.no> <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> <4694EE59.3090905@levkowetz.com> <3E387C1C64088E499E7BF0E86B0E1BF7F85BFD@NSF-BE-03.ad.nsf.gov> <05D8CB2B-C98B-4822-A633-00C6E5C57AFC@nokia.com> <469B6578.3010700@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [proto-team] Fwd: Question for draft shepherd's questionnaire? Date: Mon, 16 Jul 2007 15:40:26 +0300 To: "ext Jari Arkko" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Jul 2007 12:40:31.0341 (UTC) FILETIME=[7F0D11D0:01C7C7A6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Russ Housley , Henrik Levkowetz , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0919087710==" Errors-To: proto-team-bounces@ietf.org --===============0919087710== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-32-123996881; protocol="application/pkcs7-signature" --Apple-Mail-32-123996881 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-7-16, at 15:32, ext Jari Arkko wrote: > FYI -- wearing my document shepherd hat: I like the > web pages in http://www.ietf.org/IESG/content/ > because it makes copying & pasting very easy. > We already have the individual submission template > there too, even if for that we also have an ION. In other words: don't put the template into an ION, use the web page? Works for me. (But then I'd like to be able to modify that web page directly, without needing to corner someone that has write access there.) Lars --Apple-Mail-32-123996881 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA3MTYxMjQwMjdaMCMGCSqGSIb3DQEJBDEWBBRsXoTgv/+Y8vWq fmnO5OVQLtg18jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAe7NiWs6XPP0HMSIuxFUmZoHlu2z6KX7A1QPfwareh2Zjz1KE/XQD kyeROXaDcw/J8RHoHL7TI0cB+qCB998DbcBihq5Z30vMlwlIUVvPMrVr22D15l0zz/T8YR7H7Iqx u1csmBp0/ztCDWUCXzd4qAAz7gcY5TmFP+ZBwlceeifgN8Yo9Nm73uZsYROsWttw9XMwzgwv4aqK 9k3lUi0wBSXqdrWrgUrSnnx97uVwXnPi0GCDZgqrmUJSUfa+/y1f9Y3mKMNUouknfjBno9QcXKBl fD1b4NqPMtXheJrrqkXDtOygkIPPNmt+RD9DDrVlQS0Nu6gNlKmsDbJHsksDagAAAAAAAA== --Apple-Mail-32-123996881-- --===============0919087710== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============0919087710==-- From proto-team-bounces@ietf.org Mon Jul 16 15:53:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAWct-0003QS-Uu; Mon, 16 Jul 2007 15:52:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAWcs-0003KL-Fb for proto-team@ietf.org; Mon, 16 Jul 2007 15:52:58 -0400 Received: from aquila.nsf.gov ([198.181.231.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAWca-0001i2-Jg for proto-team@ietf.org; Mon, 16 Jul 2007 15:52:58 -0400 Received: from nsf-fe-02.nsf.gov (HELO nsf-fe-02.ad.nsf.gov) ([128.150.4.152]) by aquila.nsf.gov with ESMTP; 16 Jul 2007 15:52:08 -0400 X-SBRS: None Received: from NSF-BE-03.ad.nsf.gov ([128.150.130.227]) by nsf-fe-02.ad.nsf.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 15:52:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [proto-team] Fwd: Question for draft shepherd's questionnaire? Date: Mon, 16 Jul 2007 15:52:28 -0400 Message-ID: <3E387C1C64088E499E7BF0E86B0E1BF7F85C21@NSF-BE-03.ad.nsf.gov> In-Reply-To: <469B6E75.2030108@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [proto-team] Fwd: Question for draft shepherd's questionnaire? Thread-Index: AcfHqzyQPzPzGJ4zSA+YSS5fnMFY2wANko2g References: <468767D7.7020603@uninett.no> <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> <4694EE59.3090905@levkowetz.com> <3E387C1C64088E499E7BF0E86B0E1BF7F85BFD@NSF-BE-03.ad.nsf.gov> <05D8CB2B-C98B-4822-A633-00C6E5C57AFC@nokia.com> <469B6578.3010700@piuha.net> <469B6E75.2030108@piuha.net> From: "Mankin, Allison J" To: "Jari Arkko" , "Lars Eggert" X-OriginalArrivalTime: 16 Jul 2007 19:52:29.0382 (UTC) FILETIME=[D7684660:01C7C7E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Russ Housley , Henrik Levkowetz , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: proto-team-bounces@ietf.org =20 Jari, Where do the WG Chairs find the information? We need both the Ads and the Chairs to find the questionnaire, both easily. The Chairs have fewer educational and reinforcement mechanisms than the Ads - the Ads have their calls, their IESG Chair, the secretariat, lots of ways to be helped in finding a consistent copy of the questionnaire, and they aren't even the ones who have to fill it out! As a further consideration, the WG Chairs (and the IETF participants) need the questionnaire to stay consistent, because it needs to be applied to all the documents the same way. If the questionnaire is maintained in several places, it will become inconsistent (when I was AD we had experience with several resources like this). =20 So, I believe it would be best for the questionnaire to have the same availability and maintenance situation as id-nits - that is now an ION and I believe that Ads, Chairs and IETFers all know how to find it and work with it. What do you think of my considerations about this? Allison -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Monday, July 16, 2007 9:11 AM To: Lars Eggert Cc: Mankin, Allison J; Henrik Levkowetz; Russ Housley; proto-team@ietf.org Subject: Re: [proto-team] Fwd: Question for draft shepherd's questionnaire? > In other words: don't put the template into an ION, use the web page? Yes. Or at least not only in an ION... > Works for me. > > (But then I'd like to be able to modify that web page directly,=20 > without needing to corner someone that has write access there.) The approvals and modification process is a separate issue from how this looks to the end user. If you want, we could still require that the web page is not updated unless the ION or the RFC is. Or we could update the web page as is needed, by some designated responsible person. The IESG web page access should be available to whoever AD wants to figure out how to do it... I have not yet. I suspect this needs subversion usage, and I have not used it before. Jari _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team From proto-team-bounces@ietf.org Wed Jul 18 02:11:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB2kY-0002gP-ON; Wed, 18 Jul 2007 02:11:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB2kX-0002gB-Up for proto-team@ietf.org; Wed, 18 Jul 2007 02:11:02 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IB2kW-00057d-F3 for proto-team@ietf.org; Wed, 18 Jul 2007 02:11:01 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6I6ANOQ011523; Wed, 18 Jul 2007 09:10:55 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:09:55 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 09:09:54 +0300 Received: from [172.21.34.135] (esdhcp034135.research.nokia.com [172.21.34.135]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6I69qER008126; Wed, 18 Jul 2007 09:09:52 +0300 In-Reply-To: <200707180218.l6I2IWaf019033@mgw-mx03.nokia.com> References: <468767D7.7020603@uninett.no> <410A74D2-C452-47E5-952A-C41F9B107777@nokia.com> <4694EE59.3090905@levkowetz.com> <3E387C1C64088E499E7BF0E86B0E1BF7F85BFD@NSF-BE-03.ad.nsf.gov> <05D8CB2B-C98B-4822-A633-00C6E5C57AFC@nokia.com> <469B6578.3010700@piuha.net> <469B6E75.2030108@piuha.net> <3E387C1C64088E499E7BF0E86B0E1BF7F85C21@NSF-BE-03.ad.nsf.gov> <200707180218.l6I2IWaf019033@mgw-mx03.nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [proto-team] Fwd: Question for draft shepherd's questionnaire? Date: Wed, 18 Jul 2007 09:09:46 +0300 To: ext Russ Housley X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Jul 2007 06:09:54.0967 (UTC) FILETIME=[42B5B270:01C7C902] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Jari Arkko , Henrik Levkowetz , proto-team@ietf.org X-BeenThere: proto-team@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Process and Tools Team List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1419209480==" Errors-To: proto-team-bounces@ietf.org --===============1419209480== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-15-273356106; protocol="application/pkcs7-signature" --Apple-Mail-15-273356106 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-7-18, at 0:10, ext Russ Housley wrote: > I thought we changed the RFC right before approval to include a > URL. Did that not happen? We didn't have a URL then. The document says: The initial template for the Document Shepherd Write-Up is included below, but changes are expected over time. The latest version of this template is available from the IESG section of the IETF web site. Lars --Apple-Mail-15-273356106 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA3MTgwNjA5NDZaMCMGCSqGSIb3DQEJBDEWBBSwO2gMHRt1CbgB NZwXMOlt32+6NjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAFCq25P92yvrvGmguw91mq2w6Oe4vydyo/hLKpVwxRlP5zZImlSSM HxTecWSn4v55P1Ye04v/sbK4Yu2wU8PplSazGtZwObHi6wby9TPyiTY3VnPNS1uusmSWqGjqLyO3 Dp0E4vj1jvkPqFKMLR+hxfwW8kuiExqA9VCnieJzytDewy01cp1YTiLXa+w8KLVU726NUOnVHyV1 xjytXRFbQcaVYvrAhYG32ADIHQkUSPQCbWBGgjyOSDErSu6r1R0fuppGl3pgwOxlDlK983rGiRe+ 42J4C8xFRg+LU5wiIKcuufike9VOnMVbexTZwsbNGeOoWfOW6R6NNzyFQtBcpwAAAAAAAA== --Apple-Mail-15-273356106-- --===============1419209480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ proto-team mailing list proto-team@ietf.org https://www1.ietf.org/mailman/listinfo/proto-team --===============1419209480==--