Subject: [tcpm] dispositioning of RFC 793 reported-errata

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 25 Jan 2011 12:24:27 -0600

Hello, we have several reported errata on RFC 793 which have been stalled in the "reported" state for quite some time, and need to be dispositioned as either:

 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.

There are ~20 of these, so I was thinking we could go through them
in 3 batches of ~7.  Here are some proposed dispositions (from me) for
the first 7 which your feedback would be useful on.  These only come
from my own review at the moment.

In the next several weeks, I'd like to ask the working group if there
is consensus on the proposed dispositions for each of these (please
copy the TCPM list with any comments you have):

1 - Errata ID 1496:
http://www.rfc-editor.org/errata_search.php?eid=1496

Accepted - note that RFC 1122 already fixes this

2 - Errata ID 1561:
http://www.rfc-editor.org/errata_search.php?eid=1561

Hold for Document Update - the state is very clearly
defined in the document (and diagram), so this change
seems to not be strictly necessary, and it expresses
something slightly different than the existing text,
though it is correct.

3 - Errata ID 1562:
http://www.rfc-editor.org/errata_search.php?eid=1562

Accepted - minor clarification

4 - Errata ID 1563:
http://www.rfc-editor.org/errata_search.php?eid=1563

Accepted - note, RFC 1122 already corrected this

5 - Errata ID 1564:
http://www.rfc-editor.org/errata_search.php?eid=1564

Accepted - minor clarification

6 - Errata ID 1565:
http://www.rfc-editor.org/errata_search.php?eid=1565

Hold for Document Update - the actual clarification
that might be included may be more complex than what
this errata suggests, and it does not seem to be
strictly necessary to clarify at the moment

7 - Errata ID 1566:
http://www.rfc-editor.org/errata_search.php?eid=1566

Rejected - this is "may" and does not produce incorrect
protocol behavior, so there is no reason to remove it.

Guidance:

   In order to help you determine the correct handling for the errata,
   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.

--
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Jan 2011 11:00:13 -0800

Hi, all,

Some commments below.

Joe

----------

On 1/25/2011 10:24 AM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] 
wrote:
...
> Accepted - note that RFC 1122 already fixes this

I'm not sure of the correct procedure here. RFC 1122 updates RFC 793. I 
don't think it's appropriate to include errata that merely point out 
those updates.

At best, HOLD FOR DOC UPDATE, but I prefer that such changes be just 
REJECTED.

> something slightly different than the existing text,

Agreed.

> Accepted - minor clarification

I disagree. The wording is very poor, at best. The point appears to be 
that the sequence number can increase due to data octets OR unique 
control segments (segments without data), AFAICT. The flag fields 
themselves are not counted per se, either individually or when repeated 
(again, AFAICT). E.g., the sequence number does not increase by two for 
a SYN-ACK (which has two flag bits).

This change should either be Rejected (as submitted) or edited to be clear.

> Accepted - note, RFC 1122 already corrected this

This should be separated into different reports.

The typographic errors should definitely be HOLD FOR DOCUMENT UPDATE; 
only the specific changes should be added.

For the rest, disagree - handle the rest as noted for eratta 1496.

> Accepted - minor clarification

Disagree - handle as noted for errata 1562.

> strictly necessary to clarify at the moment

Agreed.

> protocol behavior, so there is no reason to remove it.

Agreed.

---

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 25 Jan 2011 15:48:46 -0600

Thanks Joe, I buy your arguments, here are some additional comments:

>-----Original Message-----
>From: Joe Touch [mailto:[email-masked]]
>Sent: Tuesday, January 25, 2011 2:00 PM
>
> ...
>
>> 1 - Errata ID 1496:

Now that you mention it, there should be an additional IESG guideline
added to the list of errata-handling guidelines: For documents that
the RFC-Editor has already recorded as "Updated by" other documents,
if those updates correct or clarify the subject of the errata, then
the errata should be REJECTED.

>This change should either be Rejected (as submitted) or edited to be

I see your point; I could live with either a "reject" or "hold for
document update" since the point is that the SYN/FIN bits count.  The
errata as-written is not quite right, and accepting some fixed version
of it probably won't make any difference to implementers (since this is
sufficiently well-explained elsewhere).

>Disagree - handle as noted for errata 1562.

I now agree; both 1562 and 1564 should be treated the same, however that
consensus turns out.

--
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Jan 2011 13:58:04 -0800

Hi, Wes,

> the errata should be REJECTED.

Yup - that's a useful general guideline IMO.

> sufficiently well-explained elsewhere).

I think as-is it's more confusing than helpful. Are there procedures for 
editing the errata? Or should we just submit a more clear one (that we 
hold for doc update) and reject this?

Joe