Re: Erratum on RDDP Architecture RFC

--===============1783919139==
Content-Type: multipart/signed; boundary=Apple-Mail-41--666752934; micalg=sha1; protocol="application/pkcs7-signature"


--Apple-Mail-41--666752934
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

On 2008-12-10, at 3:49, [email protected] wrote:

> Lars,
>
> http://www.rfc-editor.org/errata_search.php?eid=136
>
> I believe the recommendation is to Approve the erratum as
> submitted, as the first function prototype clearly needs to
> be changed and is a potential source of confusion, BUT ...
>
> ... as part of the approval, please add a note that the
> "Additionally ..." commentary in the Notes is not part of
> the approval because the different types of the two "s"
> arguments make it clear that the arguments are distinct,
> and that  suffices, as these function prototypes are
> described as not intended for implementation usage.

I think I can remove that text entirely, if that's preferable?

Lars


>
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>> Behalf Of Lars Eggert
>> Sent: Wednesday, December 03, 2008 3:04 AM
>> To: Talpey, Thomas
>> Cc: [email protected]; Stephen Bailey; Black, David; [email protected]
>> Subject: Re: [rddp] Erratum on RDDP Architecture RFC
>>
>> 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-41--666752934
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
MBwGCSqGSIb3DQEJBTEPFw0wODEyMTAwODAwMzRaMCMGCSqGSIb3DQEJBDEWBBRObpP+A6T+Tx1p
4fKSzLUiS4eSSTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw
CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw
DQYJKoZIhvcNAQEBBQAEggEAj2ZWII4PMPrE6lWLPuRepHI/saudjQetKI+G5rD3HqVV3E+5uDSr
99POotH9LMcZ9D3uwxPEXwp3oHJumgnZ9gP4n6A/vwmvsFBPaGktxJM2EA5xmiXRTWwswLXubz2K
341CmF6JC/Sd3Xc3Qf72WZBab1WSBsPpW/HUggprLNtbjXQOq1BYjPDdXk6QIFYZEOlXz1NVTSig
lqim/wL3V4i2zLj61TRoc/p/cSmHxDMIKkEo/6vaKMCu+SSnCtgMGIKuJMXOM0K2RYQbr6BYVE7B
kmIYnb25WdSvbQHQZqgc+S/4C2tDommgh548RxIfDOquQW58Dw3qDAB+UupNDwAAAAAAAA==

--Apple-Mail-41--666752934--

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

--===============1783919139==--