Re: [tcpm] Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-rfc793bis-25: (with DISCUSS and COMMENT)

[Wesley Eddy <[e-mail]>]

Hi Zahed, I'll get to your (and the rest of the IESG's) other comments 
later, but wanted to answer to your DISCUSS points more immediately.  
See below.

On 9/22/2021 4:46 PM, Zaheduzzaman Sarker via Datatracker wrote:
> * I found at least one reference that should be normative reference but they
> are not. Section 3.8.5 : describes --
>
>      TCP implementations MUST still include support for the urgent mechanism
>      (MUST-30). Details can be found in RFC 6093 [38]
>
>    This to ne makes RFC6093 a must to read and understand to deploy this
>    specification. Hence it should in the normative references.

I propose to change this to say "Details on how some TCP implementations 
interpret the urgent pointer can be found in RFC 6093 [38]."  I think 
that would be more of what we want to convey, since it has been done 
differently (and incompatibly), thus why we say that applications 
shouldn't rely on it!  I think this is the right thing to do rather than 
a normative reference, because our goal was to incorporate the normative 
parts of 6093 into this 793bis.

Does this sound okay to you?


> * (This perhaps more process thing than technical), me and Benjamin Kaduk
> discussed another issue regarding urgent pointer. This specification specifies -
>
>         Pointer indicates first non-urgent octet       | MUST-62|
>
>    RFC1011 rectifies RFC973 to -
>
>        The urgent pointer points to the
>           last octet of urgent data (not to the first octet of non-urgent
>           data).
>
>    So what does happen to RFC1011 rectification then when 793bis is not bis
>    anymore? Is this a known fact and there is conscious decision not to do
>    anything about it? or was this a unknown fact and that part of RFC1011 need
>    to be obsoleted (how?)?

RFC 6093 was written to solve all of this confusion :).  There is really 
nice explanation in 6093 that when implementations were surveyed, most 
were not following 1011 (and 1122's incorporation of that bit from 
1011).  The logic and situation is explained more in 6093, but the most 
relevant short passage I can quote that is clear on the current 
situation is:

    we hereby
    updateRFC 793  <https://datatracker.ietf.org/doc/html/rfc793>  [RFC0793  <https://datatracker.ietf.org/doc/html/rfc0793>],RFC 1011  <https://datatracker.ietf.org/doc/html/rfc1011>  [RFC1011  <https://datatracker.ietf.org/doc/html/rfc1011>], andRFC 1122  <https://datatracker.ietf.org/doc/html/rfc1122>  [RFC1122  <https://datatracker.ietf.org/doc/html/rfc1122>]
    such that "the urgent pointer points to the sequence number of the
    octet following the urgent data" (in segments with the URG control
    bit set), thus accommodating virtually all existing TCP
    implementations.

Hopefully that helps!