Re: Erratum on RDDP Architecture RFC

--===============1259539346==
Content-Type: multipart/signed; boundary=Apple-Mail-118-876140004; micalg=sha1; protocol="application/pkcs7-signature"


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

On 2008-12-2, at 22:24, Talpey, Thomas wrote:
> The first should in any case be executed. Has the RFC editor been  
> waiting
> for some confirmation from the Working Group or authors on #136? We  
> would
> be happy to give the latter, if so.

The errata process has changed now such that the IESG (= your AD) is  
responsible for accepting, rejecting or holding erratas for a document  
update. (After checking with the authors, chairs or the WG.)

Please indicate which of the three you recommend to happen for each  
errata. I'm attaching my original email to the chairs below, which has  
more details FYI.

Lars

Begin forwarded message:
> From: "ext Lars Eggert" <[email protected]>
> Date: October 14, 2008 17:07:09 GMT+03:00
> To: <[email protected]>, "David Black" <[email protected]>
> Subject: errata processing for TSV area RFCs
>
> Hi,
>
> attached to this email you'll find a list of all errata that have been
> reported on documents produced by the transport area, or on documents
> that are otherwise related to the transport area (documents that pre-
> date the current IETF structure or individual submissions).
>
> I'd like to ask the chairs of the WGs that produced the respective
> documents to please lead the effort to determine whether each listed
> errata is valid or not. Here's the process you should follow:
>
> (1) Make note of the "id" for each errata posted against one of your
> WG documents
>
> (2) Go to http://www.rfc-editor.org/errata_search.php?eid=XXX where
> XXX is that errata ID
>
> (3) Copy the results of that page in to an email to the document
> authors and ask them to comment on the validity of the errata. CC your
> ADs. You may also CC the WG list if you feel that broader community
> input would be helpful and/or if the original authors are
> unresponsive. Give them a deadline of a two weeks or so.
>
> (4) The purpose of this discussion is to determine that (a) the
> indicated errata type (technical/editorial) is correct, and (b) to
> decide how the errata should be handled. For the latter, there are
> three options:
>
>    o Approved - The erratum is appropriate under the criteria below  
> and
>      should be available to implementors or people deploying the RFC.
>
>    o Rejected - The erratum is in error, or proposes a change to the
>      RFC that should be done my publishing a new RFC that replaces the
>      current RFC. In the latter case, if the change is to be
>      considered for future updates of the document, it should be
>      proposed using channels other than the errata process, such as a
>      WG mailing list.
>
>    o Hold for Document Update - The erratum is not a necessary update
>      to the RFC. However, any future update of the document might
>      consider this erratum, and determine whether it is correct and
>      merits including in the update.
>
> (5) After that deadline, judge the consensus on the errata, and
> conclude the discussion phase by sending an email summarizing your
> decision to the recipients of the original email. CC your ADs. The ADs
> will then update the posted errata in the RFC Editor's database.
>
> In order to help you determine the correct handling for the errata in
> step (4), the IESG has come up with a few guidelines:
>
>    1. Only errors that could cause implementation or deployment
>    problems or significant confusion should be Approved.
>
>    2. Things that are clearly wrong but could not cause an
>    implementation or deployment problem should be Hold for Document
>    Update.
>
>    3. Errata on obsolete RFCs should be treated the same as errata on
>    RFCs that are not obsolete where there is strong evidence that
>    some people are still making use of the related technology.
>
>    4. Trivial grammar corrections should be Hold for Document Update.
>
>    5. Typographical errors which would not cause any confusions to
>    implementation or deployments should be Hold for Document Update.
>
>    6. Changes which are simply stylistic issues or simply make things
>    read better should be Hold for Document Update.
>
>    7. Changes that modify the working of a protocol to something that
>    might be different from the intended consensus when the document
>    was approved should be either Hold for Document Update or
>    Rejected. Deciding between these two depends on judgment.
>    Changes that are clearly modifications to the intended consensus,
>    or involve large textual changes, should be Rejected. In unclear
>    situations, small changes can be Hold for Document Update.
>
>    8. Changes that modify the working of a process, such as changing  
> an
>    IANA registration procedure, to something that might be different
>    from the intended consensus when the document was approved should
>    be Rejected.
>
> Also note that you should involve your AD at any time when you feel
> the discussion would benefit from this.
>
> All that said, below are our current errata, for your processing
> pleasure. Please contact Magnus and me if you have any questions about
> this process.
>
> Lars
>
> PS: It'd be great if we managed to process some of these by  
> Minneapolis!
>
> PPS: In the future, we'll forward newly posted erratas directly to the
> appropriate WG chairs. The procedure for processing these is the same
> as above. (Save this email.)
>
>
> Documents coming out of a former or current TSV WG:
> +---------+------+-------------+-----------------+-------- 
> +-----------+
> | doc-id  | id   | submit_date | submitter_name  | wg     |  
> type      |
> +---------+------+-------------+-----------------+-------- 
> +-----------+
> | RFC5128 | 1403 | 2008-03-31  | Alfred Hoenes   | behave |  
> Editorial |
> | RFC5135 | 1318 | 2008-02-14  | Alfred Hoenes   | behave |  
> Editorial |
> | RFC5135 | 1319 | 2008-02-14  | Alfred Hoenes   | behave |  
> Technical |
> | RFC5135 | 1320 | 2008-02-14  | Alfred Hoenes   | behave |  
> Technical |
> | RFC4171 |  175 | 2006-06-23  | Hannes Reinecke | ips    |  
> Editorial |
> | RFC4173 |  174 | 2005-10-17  | Alfred Hoenes   | ips    |  
> Editorial |
> | RFC4544 |   61 | 2006-07-04  | Alfred Hoenes   | ips    |  
> Technical |
> | RFC4545 |   60 | 2006-06-29  | Alfred Hoenes   | ips    |  
> Technical |
> | RFC4939 | 1026 | 2007-09-14  | Alfred Hoenes   | ips    |  
> Technical |
> | RFC4506 |   76 | 2006-05-24  | Alfred Hoenes   | nfsv4  |  
> Editorial |
> | RFC4230 |  976 | 2007-05-16  | Alfred Hoenes   | nsis   |  
> Technical |
> | RFC4230 |  977 | 2007-05-16  | Alfred Hoenes   | nsis   |  
> Technical |
> | RFC4296 |  136 | 2006-01-06  | Alfred Hoenes   | rddp   |  
> Technical |
> | RFC5044 | 1427 | 2008-05-21  | Zem Green       | rddp   |  
> Editorial |
> | RFC3926 |  698 | 2004-11-10  | Alfred Hoenes   | rmt    |  
> Technical |
> | RFC3816 |  737 | 2005-02-23  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4995 | 1256 | 2008-01-11  | Alfred Hoenes   | rohc   |  
> Editorial |
> | RFC4995 | 1257 | 2008-01-11  | Alfred Hoenes   | rohc   |  
> Editorial |
> | RFC4996 | 1288 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1289 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1290 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Editorial |
> | RFC4996 | 1291 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1292 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1293 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1294 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1295 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1296 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Editorial |
> | RFC4996 | 1297 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1298 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1299 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4996 | 1300 | 2008-01-21  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC5225 | 1421 | 2008-05-13  | Alfred Hoenes   | rohc   |  
> Technical |
> | RFC4804 |  972 | 2007-05-16  | Alfred Hoenes   | tsvwg  |  
> Editorial |
> | RFC4820 |  897 | 2007-04-09  | Alfred Hoenes   | tsvwg  |  
> Technical |
> | RFC4895 |  995 | 2007-09-27  | Frank Ellermann | tsvwg  |  
> Editorial |
> +---------+------+-------------+-----------------+-------- 
> +-----------+
>
> Documents otherwise related to these current TSV WGs:
> +---------+------+------------+----------------+---------- 
> +-----------+
> | doc-id  | id   | date       | submitter_name | wg       |  
> type      |
> +---------+------+------------+----------------+---------- 
> +-----------+
> | RFC0793 |  784 | 2006-09-22 | Ian D. Allen   | tcpm     |  
> Technical |
> | RFC0793 | 1283 | 2008-01-14 | Pei-chun Cheng | tcpm     |  
> Editorial |
> | RFC0793 | 1496 | 2008-08-27 | Yin Shuming    | tcpm     |  
> Technical |
> | RFC0951 |  569 | 2006-02-18 | "Yin Shuming"  | tsvwg?   |  
> Technical |
> | RFC2347 | 1258 | 2008-01-13 | Edwin Groothuis| tsvwg?   |  
> Technical |
> | RFC2544 |  422 | 2006-11-05 | Al Morton      | ippm?    |  
> Editorial |
> | RFC2544 | 1484 | 2008-08-08 | Nikolai Malykh | ippm?    |  
> Editorial |
> | RFC2544 | 1488 | 2008-08-15 | Nikolai Malykh | ippm?    |  
> Editorial |
> | RFC2544 | 1490 | 2008-08-19 | Nikolai Malykh | ippm?    |  
> Editorial |
> | RFC2597 |  413 | 2005-05-24 | Bud            | tsvwg    |  
> Editorial |
> | RFC2663 | 1432 | 2008-05-29 | Harald Hubich  | behave   |  
> Technical |
> | RFC2679 |  398 | 2002-11-18 | Andrew Main    | ippm     |  
> Technical |
> | RFC2680 | 1528 | 2008-09-24 | Wenxia Dong    | ippm     |  
> Editorial |
> | RFC2681 |  397 | 2002-11-18 | Andrew Main    | ippm     |  
> Technical |
> | RFC2861 | 1303 | 2008-01-23 | Sally Floyd    | tcpm     |  
> Editorial |
> | RFC2988 | 1308 | 2008-02-05 | Michael Scharf | tcpm     |  
> Editorial |
> | RFC3331 | 1425 | 2008-05-16 | Alfred Hoenes  | tsvwg?   |  
> Technical |
> | RFC3331 | 1426 | 2008-05-16 | Alfred Hoenes  | tsvwg?   |  
> Technical |
> | RFC4380 |  107 | 2006-03-16 | Alfred Hoenes  | behave?  |  
> Technical |
> | RFC4410 |   97 | 2006-08-14 | Alfred Hoenes  | rmt?     |  
> Technical |
> +---------+------+------------+----------------+---------- 
> +-----------+
>

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw
ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz
OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy
dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W
571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0
6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs
VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY
ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV
HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF
AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb
6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d
ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ
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
SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB
MBwGCSqGSIb3DQEJBTEPFw0wODEyMDMwODA0MDNaMCMGCSqGSIb3DQEJBDEWBBSEpYAzDj7IHeRb
zGrYzAyZC4OWADCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw
DQYJKoZIhvcNAQEBBQAEggEAKQsjPuZhIOhOHfJPvn0lB6pCT1c1FfAMv9Cjrn5wycBav46QEFQk
1QIQe5gAR9fD8GFEjhzq7vqNX/xd/oxKhOetTslJbWq3CrhXw4k1sc+8muzlJ/zfkNHutLL/+cLM
Y4RrgvLG3ec2X1Wx+5MwRFcjE21e8ssvEa4xCF5jqA1Zl9jaGcZi9Qr7PZg/MbrM3KZvNz7An8Pm
nwfH1pj1/KJGPnIGaPNy6Mjd99WjhLhkv+53vWbAqNeCHEn/bzggt0Oval7hsx4+YHNU+nkdpFaW
C13SfBrVRZZorri8KmOX9+WL+5qZsm+oEu790ky+p2kRgIGaukFHl3/HGzdhlAAAAAAAAA==

--Apple-Mail-118-876140004--

--===============1259539346==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
rddp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rddp

--===============1259539346==--