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

[Zaheduzzaman Sarker <[e-mail]>]

Hi Wes,

Thanks for the prompt response. We discussed the points in yesterday’s telechat. See my response reflecting the discussion below --

On 2021-09-23, 00:28, "Wesley Eddy" <[e-mail]<mailto:[e-mail]>> wrote:


Hi Zahed, I'll get to your (and the rest of the IESG's) other comments later,

NO problem at all.

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?

With your modified test, this still sounds normative. As we are not deprecating the use of urgent mechanism and it is MUST to support any details to support that is still normative. One alternative would be to bring the related parts of 6093 to the 793bis and be explicit about the warning ( different and incompatible), this fits to intention you describes also perhaps fits better to the fact that 793bis is obsoleting 6093.





* (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

   update RFC 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>], and RFC 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!

Feels like 793bis then should update 1011 as well, as it does to 1122.



BR

Zahed