Re: Erratum on RDDP Architecture RFC

That is indeed preferable.

Thanks,
--David 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Lars Eggert
> Sent: Wednesday, December 10, 2008 3:01 AM
> To: Black, David
> Cc: [email protected]; [email protected]; 
> [email protected]; [email protected]
> Subject: Re: [rddp] Erratum on RDDP Architecture RFC
> 
> 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 |
> >>> +---------+------+------------+----------------+----------
> >>> +-----------+
> >>>
> >>
> 
>