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

Hi Joe,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:touch@strayalpha.com]
Envoyé : lundi 19 août 2019 05:52
À : BOUCADAIR Mohamed TGI/OLN
Cc : Wes Eddy; tcpm IETF list
Objet : Re: [tcpm] New Version Notification for draft-ietf-tcpm-rfc793bis-14.txt

Hi, all,

RESERVED != UNASSIGNED
[Med] Sure. This is what the initial comment was about.

Unassigned means not currently assigned but that there’s a process in place for assignment, IMO.
[Med] The authoritative reference is https://tools.ietf.org/html/rfc8126#section-6/. That RFC says:

      Unassigned:  Not currently assigned, and available for assignment
            via documented procedures.  While it's generally clear that
            any values that are not registered are unassigned and
            available for assignment, it is sometimes useful to
            explicitly specify that situation.  Note that this is
            distinctly different from "Reserved".

Reserved means that they would be defined only by a change to the protocol spec itself, not merely by an assignment mechanism.
[Med] Again, the authoritative RFC says the following:

      Reserved:  Not assigned and not available for assignment.

            Reserved values are held for special uses, such as to extend

            the namespace when it becomes exhausted.  "Reserved" is also

            sometimes used to designate values that had been assigned

            but are no longer in use, keeping them set aside as long as

            other unassigned values are available.  Note that this is

            distinctly different from "Unassigned".

I would strongly suggest sticking with RESERVED, per the original doc.
[Med] These bits were assigned in the past (e.g., RFC3168) without having to edit a 793bis. Future RFCs can ask for a flag bit to be assigned.

I don’t think we’re in the business in this doc of changing the specs per se.
[Med] We are not changing the spec. We are clarifying the intent and aligning it with today’s IETF language. That’s straightforward, Joe. We are aligning the language with RFC2780 which says:

===
9.2 Reserved Bits in TCP Header

   The reserved bits in the TCP header are assigned following a
                                       ^^^^^^^^^^^^^^^^^^^^^^^^
    Standards Action process.
    ^^^^^^^^^^^^^^^^^^^^^^^^
====

Joe

On Jul 30, 2019, at 10:42 PM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> 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).

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:tcpm-bounces@ietf.org] 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:

internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>

To:

Wesley M. Eddy <wes@mti-systems.com><mailto:wes@mti-systems.com>, Wesley Eddy <wes@mti-systems.com><mailto:wes@mti-systems.com>

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
Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/
Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-14
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis
Diff: 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
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm