Re: Erratum on RDDP Architecture RFC

> -----Original Message-----
> From: rddp-bounces@... [mailto:rddp-bounces@...] On
> Behalf Of Lars Eggert
> Sent: Wednesday, December 03, 2008 3:04 AM
> To: Talpey, Thomas
> Cc: ah@...; Stephen Bailey; Black, David; rddp@...
> 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" <lars.eggert@...>
> > Date: October 14, 2008 17:07:09 GMT+03:00
> > To: <tsv-chairs@...>, "David Black" <black_david@...>
> > 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 |
> > +---------+------+------------+----------------+----------
> > +-----------+
> >
>