Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt

From: Joe Touch <[email-masked]>
Date: Sun, 18 Aug 2019 20:51:34 -0700

Hi, all,

RESERVED != UNASSIGNED

Unassigned means not currently assigned but that there’s a process in place for assignment, IMO.

Reserved means that they would be defined only by a change to the protocol spec itself, not merely by an assignment mechanism.

I would strongly suggest sticking with RESERVED, per the original doc. I don’t think we’re in the business in this doc of changing the specs per se.

Joe

> On Jul 30, 2019, at 10:42 PM, [email-masked] wrote:
> 
> Hi Wes,
>  
> Your suggestion on reserved bits works for me. Thanks.
>  
> As we are there are, I suggest to add a second action asking IANA to move the (orphan) TCP flag registry to be a sub-registry under the global “Transmission Control Protocol (TCP) Parameters” (https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml <https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml>).
>  
> Also, add to the draft a reminder that “reserved bits” are assigned following Standard Action as per Section 9.2 of RFC 2780.
>  
> Cheers,
> Med
>  
> De : tcpm [mailto:[email-masked] <mailto:[email-masked]>] De la part de Wesley Eddy
> Envoyé : mardi 30 juillet 2019 19:57
> À : tcpm IETF list
> Objet : [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt
>  
> Hello, this incorporates some small cleanups that accumulated prior to the IETF meeting, as well as some of the feedback received since then on the mailing list.
> 
> A couple specific things not yet done (because it doesn't look like we converged on the list yet):
> 
> - Did not yet change reserved bits to "unassigned" (nor indicate them in the IANA considerations section).  Rod Grimes has a good point about these being very commonly referred to as "the reserved bits" in other places.  I'm thinking we could add a note to say that in IANA terms they're "Unassigned" to add the clarity that Mohamed is advocating, but not change the name?
> 
> - Did not yet move section 2.1.
> 
> - Did not yet remove the note about my confusion on MUST vs SHOULD regarding reporting of excessive retransmissions in RFC 1122 (will confirm on the mailing list the "no change" proposal that was suggested at the meeting)
> 
> 
> 
> -------- Forwarded Message -------- 
> Subject: 
> New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt
> Date: 
> Tue, 30 Jul 2019 10:47:08 -0700
> From: 
> [email-masked] <mailto:[email-masked]>
> To: 
> Wesley M. Eddy <[email-masked]> <mailto:[email-masked]>, Wesley Eddy <[email-masked]> <mailto:[email-masked]>
> 
> 
> 
> A new version of I-D, draft-ietf-tcpm-rfc793bis-14.txt
> has been successfully submitted by Wesley M. Eddy and posted to the
> IETF repository.
> 
> Name: draft-ietf-tcpm-rfc793bis
> Revision: 14
> Title: Transmission Control Protocol Specification
> Document date: 2019-07-30
> Group: tcpm
> Pages: 104
> URL: https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc793bis-14.txt <https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc793bis-14.txt>
> Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ <https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/>
> Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14 <https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14>
> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis>
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-14 <https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-14>
> 
> Abstract:
> This document specifies the Internet's Transmission Control Protocol
> (TCP). TCP is an important transport layer protocol in the Internet
> stack, and has continuously evolved over decades of use and growth of
> the Internet. Over this time, a number of changes have been made to
> TCP as it was specified in RFC 793, though these have only been
> documented in a piecemeal fashion. This document collects and brings
> those changes together with the protocol specification from RFC 793.
> This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429,
> 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122,
> and should be considered as a replacement for the portions of that
> document dealing with TCP requirements. It updates RFC 5961 due to a
> small clarification in reset handling while in the SYN-RECEIVED
> state.
> 
> RFC EDITOR NOTE: If approved for publication as an RFC, this should
> be marked additionally as "STD: 7" and replace RFC 793 in that role.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> _______________________________________________
> tcpm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>