Subject: [tcpm] errata on RFC793

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 2 May 2012 03:51:21 -0700

Hello,

Michael, Pasi and I have checked the reported errata on RFC793 and the
below is the list of our current dispositions.
We've classified the errata based on the guideline in
http://www.ietf.org/iesg/statement/errata-processing.html
Please let us know if you have comments on these.

o http://www.rfc-editor.org/errata_search.php?eid=1567

   Status: Held for Document Update
   Type: Technical

   Technical clarification proposal on data on SYN segment.
   According to the errata, there is some ambiguity in RFC 793 regarding
data in SYNs.
   This might require changes beyond the suggested errata text, and thus we
believe
   this issue should be held for a document update or a separate RFC on
data in SYNs.

o http://www.rfc-editor.org/errata_search.php?eid=1568

   Status: Rejected
   Type: Technical

   Technical and editorial modification proposals on received packet
inspection sequence.
   This errata combines several different suggestions. Some of them repeat
updates of RFC 1122,
   some are subtle minor hints, and in some cases the errata does not
propose better phrasing.
   The errata cannot be accepted in this form. It might be worth to
consider individual aspects
   separately.

o http://www.rfc-editor.org/errata_search.php?eid=1569

   Status: Held for Document Update
   Type: Editorial

   Small editorial clarification proposal. But, we believe the original
texts are clear enough.

o http://www.rfc-editor.org/errata_search.php?eid=1570

   Status: Rejected
   Type: Editorial

   An editorial modification proposal that changes the meaning of the text
(plural to singular).
   We believe that the original text is not confusing and a change of the
meaning is not required.

o http://www.rfc-editor.org/errata_search.php?eid=1571

   Status: Held for Document Update
   Type: Technical

   Technical clarification proposals on sending MSS option with SYN.
   We believe that there is not much ambiguity in RFC 793 and RFC 1122 with
regard to
   this point, and thus an errata is not required.

Regards,
--
Yoshifumi

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 2 May 2012 12:53:42 -0700

Hi Joe,

Thanks for the comments. I think you are quite right if producing new RFCs
is our consensus.
But, I'm wondering rejecting by just potential needs is proper approach.

--
Yoshifumi

On Wed, May 2, 2012 at 10:44 AM, Joe Touch <[email-masked]> wrote:

> Hi, all,
>
> I'm not clear on the categories. "Rejected" means the erratum is
> incorrect. "Hold for document update" allows further scrutiny of the
> erratum, but appears to imply (IMO) some potential validity.
>
> My read of "Rejected" is more appropriate for the two errata indicated
> below - esp. given the indicated need for new RFCs on the specific issues.
>
> Joe
>
>
> On 5/2/2012 3:51 AM, Yoshifumi Nishida wrote:
>
>> Hello,
>>
>> http://www.ietf.org/iesg/**statement/errata-processing.**html<http://www.ietf.org/iesg/statement/errata-processing.html>
>> o http://www.rfc-editor.org/**errata_search.php?eid=1567<http://www.rfc-editor.org/errata_search.php?eid=1567>
>>
>>    According to the errata, there is some ambiguity in RFC 793
>> regarding data in SYNs.
>>    This might require changes beyond the suggested errata text, and
>> thus we believe
> ...
>  o http://www.rfc-editor.org/**errata_search.php?eid=1571<http://www.rfc-editor.org/errata_search.php?eid=1571>
>>
>>    We believe that there is not much ambiguity in RFC 793 and RFC 1122
>> with regard to

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 May 2012 13:53:19 -0700

Hi, all,

Joe

...

> this point, and thus an errata is not required.

---

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 May 2012 13:54:13 -0700

Hi, Yoshifumi,

On 5/2/2012 12:53 PM, Yoshifumi Nishida wrote:
> Hi Joe,
>
> Thanks for the comments. I think you are quite right if producing new
> RFCs is our consensus.

The process is a bit unclear on this. AFAICT, it seems to indicate that
items are "hold for document update" when that's the intended outcome -
a document update.

Since that's unlikely - esp. for the items found - putting things in
that category doesn't seem useful. Errata should not be a cache for
pending TCP clarifications that are intended for separate docs, IMO.

Joe

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 2 May 2012 23:21:34 +0200

Joe, 

> The process is a bit unclear on this. AFAICT, it seems to 
> indicate that items are "hold for document update" when 
> that's the intended outcome - a document update.
>
> Since that's unlikely - esp. for the items found - putting 
> things in that category doesn't seem useful. Errata should 
> not be a cache for pending TCP clarifications that are 
> intended for separate docs, IMO.

It would be important to get technical feedback on whether the erratas are really invalid. If an errata addresses a valid issue, even if it is minor, rejecting it might not be very useful neither.

The chairs had some discussion most notably regarding the advancement of SND.NXT in the first errata (http://www.rfc-editor.org/errata_search.php?eid=1567), and we'd be interested in additional insight on that. My personal understanding right now is that RFC 793 has not fully specified that case. But feel free to correct me - I might be wrong.

Michael

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 May 2012 06:49:11 -0700

Hi, Michael (et al.),

On 5/2/2012 2:21 PM, Scharf, Michael (Michael) wrote:
> It would be important to get technical feedback on whether the
> erratasare really invalid. If an errata addresses a valid issue,
 > even if it is minor, rejecting it might not be very useful neither.

The errata instructions here:
http://www.rfc-editor.org/status_type_desc.html
say that:

Held 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." - IESG statement on "IESG Processing of RFC Errata for the IETF 
Stream"

Rejected	"The erratum is in error, or proposes a change to the RFC that 
should be done by 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." - IESG statement on "IESG 
Processing of RFC Errata for the IETF Stream"

I think the SYN DATA issue and the other clearly falls into "Rejected" 
by these metrics. It's not merely a claim that the erratum is in error.

Given a second consideration, the MSS issue is probably a "Held for Doc 
Update" as originally proposed, though.

> The chairs had some discussion most notably regarding the
> advancementof SND.NXT in the first errata
> (http://www.rfc-editor.org/errata_search.php?eid=1567), and we'd be
> interested in additional insight on that. My personal understanding
> right now is that RFC 793 has not fully specified that case. But feel
> free to correct me - I might be wrong.

The error applies to more than the erratum notes.

I.e., the same omission happens during the OPEN call processing during a 
LISTEN state:

   OPEN Call
...
     LISTEN STATE

       If active and the foreign socket is specified, then change the
       connection from passive to active, select an ISS.  Send a SYN
       segment, set SND.UNA to ISS, SND.NXT to ISS+1.  Enter SYN-SENT
       state.  Data associated with SEND may be sent with SYN segment or
       queued for transmission after entering ESTABLISHED state.  The
                                                                 ^
[missing the update of SND.NXT]
       urgent bit if requested in the command must be sent with the data
       segments sent as a result of this command.  If there is no room to
       queue the request, respond with "error:  insufficient resources".
       If Foreign socket was not specified, then return "error:  foreign
       socket unspecified".

again on page 68:

         If SND.UNA > ISS (our SYN has been ACKed), change the connection
         state to ESTABLISHED, form an ACK segment

           <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

         and send it.  Data or controls which were queued for
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         transmission may be included.  If there are other controls or
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[missing all details of this step]
         text in the segment then continue processing at the sixth step
         below where the URG bit is checked, otherwise return.

In both of these additional cases, the details are omitted.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 03 May 2012 11:04:39 -0400

> Update" as originally proposed, though.

These look like the correct directions to take to me, and I am able
to update the notes to indicate the reasoning discussed here behind
the way we selected how to deal with them.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 May 2012 10:44:11 -0700

Hi, all,

Joe

...

---

From: Joe Touch <[email-masked]>
Date: Wed, 02 May 2012 13:15:50 -0700

Hi, Yoshifumi,

Joe

>
> --
> Yoshifumi
>
> On Wed, May 2, 2012 at 10:44 AM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi, all,
>
>     My read of "Rejected" is more appropriate for the two errata
>     indicated below - esp. given the indicated need for new RFCs on the
>     specific issues.
>
>     Joe
>
>
>         http://www.ietf.org/iesg/__statement/errata-processing.__html
>         <http://www.ietf.org/iesg/statement/errata-processing.html>
>         o http://www.rfc-editor.org/__errata_search.php?eid=1567
>         <http://www.rfc-editor.org/errata_search.php?eid=1567>
>
>         o http://www.rfc-editor.org/__errata_search.php?eid=1571
>         <http://www.rfc-editor.org/errata_search.php?eid=1571>
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 3 May 2012 22:17:01 +0200

Joe, 

> Given a second consideration, the MSS issue is probably a 
> "Held for Doc Update" as originally proposed, though.

Fine

> I.e., the same omission happens during the OPEN call 
> processing during a LISTEN state:
> 
>    OPEN Call
> ...
>      LISTEN STATE
> 
>    ^ [missing the update of SND.NXT]

Fixing this would apparently need an RFC. In that sense it might be fine to reject the errata as it is.

Thanks

Michael

PS: Sorry, I apparently made an error when approving some stale e-mails that got queued in mailman.