Re: [tcpm] Francesca Palombini's No Objection on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

[Wesley Eddy <[e-mail]>]

Sorry for the very slow response, but I think all questions are answered 
below.  Thanks for your comments and patience.


On 9/22/2021 5:19 PM, Francesca Palombini via Datatracker wrote:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-tcpm-rfc793bis-25: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for the work on this document. I only have minor comments, and some
> questions.
>
> I have divided comments into "minor" (including the questions) and "nits".
> Neither require replies strictly speaking, please feel free to address as you
> see fit. I will appreciate answers to my questions, to improve my
> understanding. If any clarification comes out of it, I hope it will help
> improve the document.
>
> Francesca
>
> ## minor
>
> 1. -----
>
> Figure 1
>
> FP: The figure's capture is "TCP Header Format", but Options and Data are
> included as well.

Yeah, that is true it's really the header format within the context of a 
full segment.  The options are part of the header, but including the 
data makes it a full segment.  I can add a quick note about that in the 
working copy.


> 2. -----
>
> Figure 2
>
> FP: For consistency, I would have kept the same style as in Figure 1.
> Additionally, the IPv4 fields below do not have their size explicitly
> specified, so using the same type of formatting as in Figure 1 would help, IMO.

That makes sense.  This was just retaining the way 793 originally showed it.


>
> 3. -----
>
>         0
>         0 1 2 3 4 5 6 7
>        +-+-+-+-+-+-+-+-+
>        |       0       |
>        +-+-+-+-+-+-+-+-+
>
> FP: More of a question than a comment: how come this change, compared to RFC
> 793? Any particular reason, or was it only for readability?

This was just part of making the format descriptions readable by 
tooling, conforming to: 
https://datatracker.ietf.org/doc/html/draft-mcquistin-augmented-ascii-diagrams


>
> 4. -----
>
> FP: This is surely me missing something but, in section 3.5 I see:
>
>     4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED
>
>     5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED
>
> which is followed by:
>
>     Note that the sequence number of the segment in line 5 is the same as
>     in line 4 because the ACK does not occupy sequence number space (if
>     it did, we would wind up ACKing ACKs!).
>
> However, later on, in Figure 13:
>
>     2.  (Close)                                              (Close)
>         FIN-WAIT-1  --> <SEQ=100><ACK=300><CTL=FIN,ACK>  ... FIN-WAIT-1
>                     <-- <SEQ=300><ACK=100><CTL=FIN,ACK>  <--
>                     ... <SEQ=100><ACK=300><CTL=FIN,ACK>  -->
>
>     3.  CLOSING     --> <SEQ=101><ACK=301><CTL=ACK>      ... CLOSING
>                     <-- <SEQ=301><ACK=101><CTL=ACK>      <--
>                     ... <SEQ=101><ACK=301><CTL=ACK>      -->
>
> I am confused why in this case, in line 3, ACK does in fact occupy sequence
> number space. What am I missing?

In line 3 if the sequence number was 100, that would be a retransmission 
of the FIN, rather than just an ACK that covers the other side's FIN 
(300).  There's no data in the segment, so the sequence number is just 
meaningful for validation.


>
> ## nit
>
> 5. -----
>
>     Initial Sequence Number Selection
>
> FP: I assume this (and following) was not numbered to keep it as close as
> possible to the original RFC, is that right? For readability, I would suggest
> numbering these subsections.

Yes, this was originally an attempt to stay close to the original 
formatting.  A number of other IESG comments remarked similarly to your 
comment, and in the working copy, these subsections all have proper 
numbers now.