Subject: Re: [tcpm] WGLC for 793bis - REVIEW NEEDED

From: Wesley Eddy <[email-masked]>
Date: Tue, 13 Oct 2020 15:41:08 -0400

On 9/25/2020 9:52 AM, [email-masked] wrote:
> Hi all,
>
> Wes already addressed my comments in previous versions of the spec.
>
> Please find some edits/nits/comments:
>
> * pdf:https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-tcpm-rfc793bis-18-rev%20Med.pdf  
> * doc:https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-tcpm-rfc793bis-18-rev%20Med.docx  
>
> The document is almost ready to move forward.
>
> Many thanks to Wes for carrying this important work.

Thank you for the detailed comments and corrections.  I've finished 
working through your suggested changes and had alternate suggestions on 
a small number of them below.  The remainder are mostly verbatim going 
into my working copy for the next draft revision, with the exception of 
some differences in reference styles from XML2RFC that are probably more 
of an RFC Editor decision on how to properly cite anyways.

(1) On adding:

"Multipath considerations are out of scope. The reader may refer to [RFC 
8684]."

How about instead mentioning this later on instead, where we mention 
congestion control and high-performance extensions, and saying 
"Multipath considerations for TCP are specified separately in [RFC 8684]."

(2)  I like your suggestion of abbreviating three-way handshake to 
"3WHC".  Before I abbreviate this in a number of places, I wanted to 
give the list a chance to push back in the event that there's any 
concern about new acronyms.

(3) You raised a question on the text:

"""

There MUST (MUST-33) be a way for the application to learn how much 
urgent data remains to be read from the connection, or at least to 
determine whether or not more urgent data
remains to be read.

"""

Asking "This is local to the implem.  Why the normative language is 
used?".    This comes from 1122, and I think the intention is that when 
an application is choosing to use the urgent mechanism and is signaled 
that there is urgent data, it also needs to be able to figure out when 
it's read through all of the urgent data and can go back to it's 
non-urgent mode of handling input.

---

From: <[email-masked]>
Date: Wed, 14 Oct 2020 07:19:23 +0000

Hi Wes, 

(1) looks good to me. 

For (3), you may consider tweaking the text so that the reco is on the TCP implem, not the application. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de Wesley Eddy
> Envoyé : mardi 13 octobre 2020 21:41
> À : [email-masked]
> Objet : Re: [tcpm] WGLC for 793bis - REVIEW NEEDED
> 
> > *
> > pdf:https://github.com/boucadair/IETF-Drafts-
> Reviews/blob/master/draft
> > -ietf-tcpm-rfc793bis-18-rev%20Med.pdf
> > *
> > doc:https://github.com/boucadair/IETF-Drafts-
> Reviews/raw/master/draft-
> > ietf-tcpm-rfc793bis-18-rev%20Med.docx
> >
> working through your suggested changes and had alternate suggestions
> on a small number of them below.  The remainder are mostly verbatim
> going into my working copy for the next draft revision, with the
> exception of some differences in reference styles from XML2RFC that
> are probably more of an RFC Editor decision on how to properly cite
> anyways.
> 
> 
> (1) On adding:
> 
> "Multipath considerations are out of scope. The reader may refer to
> [RFC 8684]."
> 
> determine whether or not more urgent data remains to be read.
> 
> """
> 
> used?".    This comes from 1122, and I think the intention is that
> when an application is choosing to use the urgent mechanism and is
> signaled that there is urgent data, it also needs to be able to
> figure out when it's read through all of the urgent data and can go
> back to it's non-urgent mode of handling input.
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 14 Oct 2020 17:17:09 -0400

> For (3), you may consider tweaking the text so that the reco is on the TCP implem, not the application.

That makes sense.  In the working copy, I've changed the beginning of 
the sentence from:

to:

The TCP implementation MUST (MUST-33) provide a way for the application to
...

I think that addresses your point.

---

From: Joseph Touch <[email-masked]>
Date: Thu, 15 Oct 2020 18:09:25 -0700

Hi, all,

> On Oct 13, 2020, at 12:41 PM, Wesley Eddy <[email-masked]> wrote:
> ...
> (2)  I like your suggestion of abbreviating three-way handshake to "3WHC". 

Did you mean the more common “3WHS”?

If not, what does the C stand for?

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 15 Oct 2020 21:48:57 -0400

> Did you mean the more common “3WHS”?

Yes, I mistyped.  Sorry!