Re: [tcpm] Please review 793bis!

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Rodney W. Grimes [mailto:[e-mail]]
> Envoyé : mardi 30 juillet 2019 15:10
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Rodney W. Grimes; Wesley Eddy; [e-mail]
> Objet : Re: [tcpm] Please review 793bis!
> 
> Hello Med,
> Replied inline, trying to get this style, so pardon any
> mistakes I may be making.
> 
> Regards,
> Rod
> 
> > Hi Rodney,
> >
> > Please see iline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De?: Rodney W. Grimes [mailto:[e-mail]]
> > > Envoy??: lundi 29 juillet 2019 22:36
> > > ??: Wesley Eddy
> > > Cc?: [e-mail]; BOUCADAIR Mohamed TGI/OLN
> > > Objet?: Re: [tcpm] Please review 793bis!
> > >
> > > > Many thanks for your comments; my thoughts are below:
> > > >
> > > > On 7/29/2019 5:35 AM, [e-mail] wrote:
> > > > > Hi all,
> > > > >
> > > > > Please find below some very minor comments to enhance the
> readability
> > > of the document:
> > > > >
> > > > > * Consider moving Section 2.1 to be listed under Section 3.
> 
>  [RWG] If infact the author "moves" section 2.1 to be under 3
> in the draft in effect 2.1 would either go away, or become
> something different.
> 
> > > >
> > > > Either way is fine with me; does anyone have strong preference? The
> > > > section numbering is closer to the original 793 numbering currently,
> and
> > > > this would probably bump that, but that is a very trivial concern.
> > >
> > > I would counter that section renumbering breaks all external
> > > references to this document by section number and should probably
> > > be avoided at all cost.
> > >
> > > As an example if someone wrote someplace "See section 2.1 of rfc793",
> > > that reference would be broken, other than the new document is called
> > > rfc793bis, that may be lost on the seeker of the information.
> >
> > [Med] Hmm, there is no such 2.1 in RFC793:
> 
>  [RWG] Perhaps another cup of coffee?  :-)

[Med] I meant there is no "such" text in 793. See below ...

> 
> > RFC793
> >
> > 1.  INTRODUCTION ..................................................... 1
> >
> >   1.1  Motivation .................................................... 1
> >   1.2  Scope ......................................................... 2
> >   1.3  About This Document ........................................... 2
> >   1.4  Interfaces .................................................... 3
> >   1.5  Operation ..................................................... 3
> >
> > 2.  PHILOSOPHY ....................................................... 7
> >
> >   2.1  Elements of the Internetwork System ........................... 7
> 
>  [RWG] This does look to be a section 2.1 to me, did you miss it?

[Med] No. The new text in 2.1 of 793bis has nothing to do with this one. If you used to cite that section from 793, then that citation will be broken when RFC793bis will be published. 

> 
> >   2.2  Model of Operation ............................................ 7
> >   2.3  The Host Environment .......................................... 8
> >   2.4  Interfaces .................................................... 9
> >   2.5  Relation to Other Protocols ................................... 9
> >   2.6  Reliable Communication ........................................ 9
> >   2.7  Connection Establishment and Clearing ........................ 10
> >   2.8  Data Communication ........................................... 12
> >   2.9  Precedence and Security ...................................... 13
> >   2.10 Robustness Principle ......................................... 13
> >
> > 3.  FUNCTIONAL SPECIFICATION ........................................ 15
> >
> >
> > RFC793bis
> >
> >    1.  Purpose and Scope . . . . . . . . . . . . . . . . . . . . . .   3
> >    2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
> >      2.1.  Key TCP Concepts  . . . . . . . . . . . . . . . . . . . .   5
> >    3.  Functional Specification  . . . . . . . . . . . . . . . . . .   5
> >
> > I think that Wes tried to preserve the overall structure of Section 3.
> 
>  [RWG] I am concerned about historical references to this document in
> such things as code, text books, and other RFC's, but without solid
> evidence to that effect I have little ground to stand on.

[Med] Your concern is a valid one. There is a trade-off out there: readability vs. how to easily identify changes.

> 
> On the other hand I should further investigate:
> ./sys/netinet/tcp_fsm.h: * Per RFC793, September, 1981.
> ./sys/netinet/tcp_input.c:    "Follow RFC793 instead of RFC5961 criteria
> for accepting SYN packets");
> ./sys/netinet/tcp_input.c:    "Follow RFC793 instead of RFC5961 criteria
> for accepting RST packets");
> ./sys/netinet/tcp_input.c:               * is equivalent to the smoothing
> algorithm in rfc793 with
> ./sys/netinet/tcp_input.c:               * equivalent to rfc793 smoothing
> with an alpha of .75
> ./sys/netinet/tcp_input.c:               * rfc793's wired-in beta.
> ./sys/netinet/tcp_syncache.c:    * See RFC 793 page 65, section SEGMENT
> ARRIVES.
> ./sys/netinet/tcp_syncache.c:    * RFC 793 page 37:
> 
> I do understand that the document name is changing, but how to make
> it clear to a person reading the code above and pulling up 793bis that
> they
> should be looking to 793 is unclear to me at this point in time.
> 
> Is it possible to use the datatracker to see the changes
> from rfc793 to rfc793bis?

[Med] I'm afraid the diff provided by the datatracker is not helpful: https://www.ietf.org/rfcdiff?url1=rfc793&url2=draft-ietf-tcpm-rfc793bis-13. 

> 
> What about a section on "what has changed, added, and/or removed",

[Med] There is already one: Please refer to https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-4   

> usually when a specification evolves over time there is a history
> section that itemizes the changes.  This may be asking for far too
> much in this case though.
> 
> > >
> > > A search of the RFCs for section references to 793 could be attempted.
> > >
> > > > > * Rsrvd - Reserved:  s/Reserved/Unassigned. This is to be aligned
> with
> > > https://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a
> > > special meaning: "Reserved:  Not assigned and not available for
> > > assignment.")
> > > >
> > > > Thanks; I'll have to look at this in all cases and make sure we "do
> the
> > > > right thing".? I hadn't really been aware of 8126.
> > >
> > > Though I am new here and may be wrong on this,
> > > 8126 is about IANA considerations and should, if I am
> > > reading it correctly, only be apply to text in the IANA
> > > consideration section of an RFC and not to the whole
> > > body of it.
> >
> > [Med] It will be weird to use "Reserved" in the main text and
> "Unassigned" in the IANA section. Following RFC8126 would be my favorite
> here.
> 
>  [RWG] Have it read "Unassigned" in the spec that has almost 40
> years of running code that call it rsrvd is of equal
> concern from an implementers standpoint.  Any attempt
> to back port RFC8126 language into the prior 8000 RFC's seems
> difficult.

[Med] The name of the field can be maintained as it is. No need to change it to "UUUU". The change will be in the main text, e.g.,:

OLD: 

   Rsrvd - Reserved:  4 bits

     Reserved for future use.  Must be zero in generated segments and
     must be ignored in received segments, if corresponding future
     features are unimplemented by the sending or receiving host.

NEW:

   Rsrvd - Unassigned:  4 bits

     Not assigned, and available for assignment.  MUST be zero in generated segments and
     MUST be ignored in received segments, if corresponding future
     features are unimplemented by the sending or receiving host.

And in the IANA section:

NEW:
  New flags bits can be assigned via Standards Action [RFC8126].


> 
> Should RFC8126 apply to any RFC prior to it unless
> explicitly stated in the header of RFC8126?  Or is it the
> fact that chrnologically RFC793bis is after 8126 that should
> be applied here.  That would require one to have a date order
> of issue index to the rfcs?

[Med] Given that there are pending IANA actions to fix the tcp flags registry, RFC8126 language should be followed.

> 
> >
> > >
> > > I especially do not like the definition of
> > > Reserved as stated in 8126, that is more than reserved,
> > > it is immutable.  But that is for the topic of another
> > > draft.
> > >
> > > >
> > > > > * Add a pointer to the "TCP Header Flags" registry:
> > > https://www.iana.org/assignments/tcp-header-flags/tcp-header-
> flags.xhtml
> > > > >
> > > > > * Add an IANA action to update the above registry to include all
> TCP
> > > flags, not only those in 3168. Also, the description text in that page
> > > should be reworked, IMHO. Unassigned bits should also be indicated as
> such
> > > in that page.
> > > > >
> > > > > I would like to have those referenced in that page rather than
> having
> > > documents requiring access to these bits to duplicate the effort: see
> for
> > > example  RFC8519 (look for "reserved" and "flags" in Page 33).
> > > >
> > > > Good point.? 3168 created the registry, but then didn't fully
> populate
> > > > it with the bits that 793 had defined.
> > >
> > > This is probably of historical cause, 793 being a very early RFC.
> > > It would be wrong of 3168 to populate anything
> >
> > [Med] There is nothing wrong with another RFC than 793 to create and
> initialize the flags registry.
> 
>  [RWG] I think it would be incorrect to do so, it would surely mess up
> the presentation of information in the:
> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
> page which has back references to the RFC that had the IANA consideration.
> 
> If rfc3168 had populated say the SYN code point, the reference at IANA
> would
> be to rfc3168 and yet in that RFC I would find little information on
> the definition of the SYN flag.

[Med] The reference clause of the SYN in such case will need to point to RFC793, not RFC3168. This is straightforward.  

> 
> >
> > > other than 3168 bits, but I see 793bis as populating
> > > the other bits of TCP as a proper and needed update.
> >
> > [Med] Hence the need to fix the registry rather than leaving it
> incomplete.
>  [RWG] We fully agree on that

[Med] Great! Thanks.

> 
> >
> > >
> > > > > * Position titles right after figure #, e.g.,
> > > > >
> > > > > OLD:
> > > > >
> > > > >                                 TCP Header Format
> > > > >
> > > > >               Note that one tick mark represents one bit position.
> > > > >
> > > > >                                   Figure 1
> > > > >
> > > > > NEW:
> > > > >
> > > > >               Note that one tick mark represents one bit position.
> > > > >
> > > > >                                   Figure 1: TCP Header Format
> > > >
> > > > Also a good idea ... I will make this change, unless anyone shouts.
> > > >
> > > >
> > > > > * Introduce some notations used in the document (and a pointer to
> > > Appendix B), e.g.,
> > > > >
> > > > >       The window size MUST be treated as an unsigned number, or
> else
> > > > >       large window sizes will appear like negative windows and TCP
> > > will
> > > > >       now work (MUST-1) .  It is RECOMMENDED that implementations
> will
> > > > >                ^^^^^^^^
> > > > >       reserve 32-bit fields for the send and receive window sizes
> in
> > > the
> > > > >       connection record and do all window computations with 32
> bits
> > > (REC-
> > > > >
> > > ^^^^
> > > > >       1 ).
> > > > >
> > > > > Idem for SHLD-, etc.
> > > >
> > > > Good point.? It seems like explaining this in the introduction will
> > > work.
> > > >
> > > >
> > > > > * Section 3.1
> > > > >
> > > > > OLD:
> > > > >
> > > > >       The checksum also covers a pseudo header conceptually
> prefixed
> > > to
> > > > >       the TCP header.  The pseudo header is 96 bits for IPv4 and
> 320
> > > bits
> > > > >       for IPv6.  For IPv4, this pseudo header contains the Source
> > > > >       Address, the Destination Address, the Protocol, and TCP
> length.
> > > > >
> > > > > NEW:
> > > > >       The checksum also covers a pseudo header conceptually
> prefixed
> > > to
> > > > >       the TCP header.  The pseudo header is 96 bits for IPv4 and
> 320
> > > bits
> > > > >       for IPv6.  For IPv4, this pseudo header contains the Source
> > > > >       Address, the Destination Address, the Protocol (PTCL), and
> TCP
> > > length.
> > > > >                                                      ^^^^^^
> > > > >
> > > > > * Section 3.1: Add missing figure legend, e.g.,
> > > > >
> > > > >                     +--------+--------+--------+--------+
> > > > >                     |           Source Address          |
> > > > >                     +--------+--------+--------+--------+
> > > > >                     |         Destination Address       |
> > > > >                     +--------+--------+--------+--------+
> > > > >                     |  zero  |  PTCL  |    TCP Length   |
> > > > >                     +--------+--------+--------+--------+
> > > > >
> > > > > * Section 3.3:
> > > > >
> > > > > OLD:
> > > > >   The synchronization requires each side to send it's own initial
> > > > >
> > > > > NEW:
> > > > >   The synchronization requires each side to send its own initial
> > > >
> > > > Many thanks; all of the above suggestions look good to me.
> > >
> > > Indeed.
> > >
> > > > _______________________________________________
> > > > tcpm mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/tcpm
> > >
> > > --
> > > Rod Grimes
> > > [e-mail]
> 
> --
> Rod Grimes
> [e-mail]