« Return to Thread: Erratum on RDDP Architecture RFC
Re: Erratum on RDDP Architecture RFC
by Lars Eggert-4
::
Rate this Message:
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 |
> +---------+------+------------+----------------+----------
> +-----------+
>
_______________________________________________
rddp mailing list
rddp@...
https://www.ietf.org/mailman/listinfo/rddp
> 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 |
> +---------+------+------------+----------------+----------
> +-----------+
>
_______________________________________________
rddp mailing list
rddp@...
https://www.ietf.org/mailman/listinfo/rddp
smime.p7s (3K) « Return to Thread: Erratum on RDDP Architecture RFC
| Free embeddable forum powered by Nabble | Forum Help |
