Shared Use of Experimental TCP Options
draft-ietf-tcpm-experimental-options-06

[Ballot comment]
Based on the recent update to the document, I'm moving this to a No Objection.  I don't really think that the document has fully addressed the points raised here, but given the state of the consensus on this question in the working group, I'm afraid I'm not going to get much more movement, so I'll take what I can get.

Former DISCUSS:
I don't think it adds value to have the ExID be of variable length.  It's highly implausible that there could be 64k TCP experiments in the reasonable lifetime of this policy, particularly now that the code space is being managed by the IANA.  Two bytes in the TCP header is a lot, and alignment of 4-byte integers is easy to fix.  I think that using a 4-byte ExID runs a real risk of overflowing the available space in the TCP header in real-world circumstances.

[Ballot comment]
I have not decided whether to recommend the publication of this document yet. I want to hear the discussion on the IESG telechat first.

[Ballot comment]
A quick roll through the narrative minutes from 2012-12-20 make it look like the previous IESG has had a rollicking good time with this draft. I look forward to the telechat ...

[Ballot comment]
A quick roll through the narrative minutes from 2012-12-20 make it look like the previous IESG has had a rollicking good time with this draft. I look forward to the telechat ...

Are we in http://www.ietf.org/iesg/statement/discuss-criteria.html Section 3.3 territory on this one? I'm not sure from the discussion that I can see.

[Ballot comment]
This is a significant improvement over the version that I previously reviewed.

Although significant steps have been taken to improve the document, the risk of collision due to unregistered use or registration of a collision is still acknowledged. I would find this less objectionable in an Informational or Experimental document, but in a Standards Track document I find it difficult to accept anything other than required registration (which may be confidential to IANA) to ensure the absence of a collision.

[Ballot discuss]
I don't think it adds value to have the ExID be of variable length.  It's highly implausible that there could be 64k TCP experiments in the reasonable lifetime of this policy, particularly now that the code space is being managed by the IANA.  Two bytes in the TCP header is a lot, and alignment of 4-byte integers is easy to fix.  I think that using a 4-byte ExID runs a real risk of overflowing the available space in the TCP header in real-world circumstances.

I realize that I may be stepping in it here by making this observation, because I know that the compromise of doing an IANA registry was not popular in TCPM.  Nevertheless I feel compelled to request that the authors consider that, now that this compromise has been reached, it's pointless to maintain support for 4-byte ExIDs.  That is, I ask the authors to change the specification to make the ExID explicitly two bytes.

Please feel free to point me at the post-IESG-review discussion where this was decided to be unnecessary, rather than reiterating the arguments, if you have pointers to it.  I wasn't able to find this in reviewing the history, but the discussion got rather long, so I may have missed it.

[Ballot comment]
In light of the more recent drafts, I'm fine with logging my position as no objection.

I'm not sure that I interpret 3692 quite as strongly as Adrian's discuss does. while there is certainly a temptation to squat on experimental code points due to the size of the space, the potential for less pollution of the registered code point range seems like it has fewer consequences then what is otherwise expected to continue to happen.

[Ballot comment]
Hi Joe,

Thanks for your effort on this draft.
I'll clear my DISCUSS now.
The draft improved a lot during our discussion.
Discussing with Martin and Wes during the IETF last week, we concluded that it would be appropriate to restart the ballot on this draft. Indeed, IMHO, the draft improved so much that I believe that some IESG members might clear their ABSTAIN ... which is always a preferred outcome if possible.

Regards, Benoit

[Ballot discuss]
Thanks for working on my previous DISCUSS. The draft goes in the right direction IMHO.
I still find the draft confusing in three ways.

1.
>> All protocols using the TCP experimental option codepoints (253,
    254) SHOULD use ExIDs as described in this document.

Isn't a MUST, at least for the 16-bit?
For a Standards Track document, I believe it must be a MUST.
I mean: if I use this spec, I MUST register the 16-bit with IANA, while the magic number is whatever-I-want
Correct?  Where do I see "I MUST register the 16-bit with IANA"?
If you keep a SHOULD, in which case can we omit this?
Or, are you opening the door for the people who plans on not using this standard (which doesn't help anybody)?
The point is that we want to know whether all the experiments in the network support this future RFC.
If there is a MUST in that RFC, we can conclude that we will not have collisions
If there is a SHOULD in that RFC, we can't conclude anything...

2.
In the IANA considerations section:
Known overlapping uses -  whether of the first-come portion or the entire value - should also be listed and highlighted as collisions.

Why would someone pick up an 16-bit entry which is taken already?
Therefore, why don't you want to mandate that collisions in the first 16 bit are not possible?
We discuss experiment here. If a 16-bit entry is taken, we just take another one, register it, and that's it.
The experiment code shouldn't be too hard to change, right?
Note: I don't object the magic number. If you you want to keep it, fine.

3.
Much of my confusion comes, I guess, from the terminology.
Just 3 examples, but there are more.
Example 1:
      >> All protocols using the TCP experimental option codepoints (253,
      254) SHOULD use ExIDs as described in this document.
Don't you want to say:
      >> All protocols using the TCP experimental option codepoints (253,
      254) MUST use TCP Experimental Option with a 16-bit ExID as described in this document.
      >> All protocols using the TCP experimental option codepoints (253,
      254) MAY use TCP Experimental Option with a 32-bit ExID as described in this document.
Example 2:
In the sentence below, shouldn't you replace ExID by "magic number (part of the ExID)"
   
      The ExID helps reduce the
      probability of a collision of independent experimental uses of the
      same option codepoint, both for those who follow this document
      (using registered ExIDs) and those who do not (squatters who either
      ignore this extension or do not register their ExIDs).
Example 3:
      False positives occur where the ExID of one experiment matches the
      value of an option that does not use ExIDs or if two experiments
      select the same ExID.
Don't you want to say:
      False positives occur where the ExID of one experiment matches the
      value of an option that does not use ExIDs or if two experiments
      select the same magic number.

Regards, Benoit

[Ballot discuss]
Thanks for working on my previous DISCUSS. The draft goes in the right direction IMHO.
I still find the draft confusing in three ways.

    1.
      >> All protocols using the TCP experimental option codepoints (253,
      254) SHOULD use ExIDs as described in this document.

    Isn't a MUST, at least for the 16-bit?
    For a Standards Track document, I believe it must be a MUST.
    I mean: if I use this spec, I MUST register the 16-bit with IANA, while the magic number is whatever-I-want
    Correct?  Where do I see "I MUST register the 16-bit with IANA"?
    If you keep a SHOULD, in which case can we omit this?
    Or, are you opening the door for the people who plans on not using this standard (which doesn't help anybody)?
    The point is that we want to know whether all the experiments in the network support this future RFC.
    If there is a MUST in that RFC, we can conclude that we will not have collisions
    If there is a SHOULD in that RFC, we can't conclude anything...

    2.
    In the IANA considerations section
      Known overlapping uses -
      whether of the first-come portion or the entire value - should also
      be listed and highlighted as collisions.

    Why would someone pick up an 16-bit entry which is taken already?
    Therefore, why don't you want to mandate that collisions in the first 16 bit are not possible?
    We discuss experiment here. If a 16-bit entry is taken, we just take another one, register it, and that's it.
    The experiment code shouldn't be too hard to change, right?
    Note: I don't object the magic number. If you you want to keep it, fine.

    3.
    Much of my confusion comes, I guess, from the terminology.
    Just 3 examples, but there are more.
    Example 1:
      >> All protocols using the TCP experimental option codepoints (253,
      254) SHOULD use ExIDs as described in this document.
    Don't you want to say:
      >> All protocols using the TCP experimental option codepoints (253,
      254) MUST use TCP Experimental Option with a 16-bit ExID as described in this document.
      >> All protocols using the TCP experimental option codepoints (253,
      254) MAY use TCP Experimental Option with a 32-bit ExID as described in this document.
    Example 2:
    In the sentence below, shouldn't you replace ExID by "magic number (part of the ExID)"
   
      The ExID helps reduce the
      probability of a collision of independent experimental uses of the
      same option codepoint, both for those who follow this document
      (using registered ExIDs) and those who do not (squatters who either
      ignore this extension or do not register their ExIDs).
    Example 3:
      False positives occur where the ExID of one experiment matches the
      value of an option that does not use ExIDs or if two experiments
      select the same ExID.
    Don't you want to say:
      False positives occur where the ExID of one experiment matches the
      value of an option that does not use ExIDs or if two experiments
      select the same magic number.

[Ballot comment]
I think the changes in -04 are a fine compromise, providing an FCFS registry for those willing to use it, and giving advice for dealing with situation when the registry isn't used.  Thanks very much to the authors and the working group for sorting this out!

[Ballot discuss]
Updated after some discussion, including response from the authors:

I don't understand why an IANA-administered First Come First Served [RFC5226}
registry for magic numbers isn't preferable to an ad hoc "use more bits to make
collisions less likely" thing.  The shepherd writeup says that "it has been
recommended that magic numbers are posted for information to the TCPM mailing
list, and this mechanism has already been used by all known users of this
specification."  Where has that been suggested?  Not in the document.  It
doesn't seem like a good idea to have a mailing list re-implement something
that IANA already does well.

Particularly relevant excerpts from Joe Touch's responses:
> The issue I recall was that:
>
>        - such a registry requires coordination with IANA, which some
>        parties don't want to participate in for preliminary work;
>        once that work is coded, it often becomes too late
>
>        this is how numerous TCP option codepoints have been
>        squatted upon in the past
>
>        - such a registry publicly permanently announces the use of
>        the codepoint
>
>        some parties want a de-conflict mechanism that is autonomous,
>        transient, and private, until such time as they decide to
>        make it public
...
> some developers of experimental
> options don't want to advertise the fact that this is what they're doing by
> putting their info in a (implicitly permanent) registry.
...
> The mailing list is for informal, voluntary coordination. Some designers
> will still use these magic numbers without that coordination.

It's sad that people are often reluctant to use IANA registries, but it's a fact that they are, and that sometimes the damage caused by use of unregistered codepoints is sufficient to move us to work around that problem.  I also understand the desire, sometimes, to play around in private before making things public.  And, given other recent discussions: this does represent "running code".

I'm holding this DISCUSS along with the others, while the document is updated to explain the issues and options, and why other mechanisms aren't acceptable in this situation.

[Ballot discuss]
Also from DHCP: RFC 3925, which uses enterprise numbers to disambiguate a shared DHCP option code.  Has the use of enterprise numbers been considered TCP experimental options?

Allowing the experimental options to be used without the magic numbers later in a TCP session sounds like a really bad idea.  How do checksums help?  Does it depend on the experimental option code not being shared among different option protocols in a single session?

[Ballot discuss]
Reading the draft, my first reaction was: "you're not solving anything since you might still have collisions".
As I don't want to go in the way of the WG with a strong consensus on this doc, so maybe I should ABSTAIN?

After thinking some more about it, my second reaction was exactly the same as Barry' DISCUSS: "I don't understand why an IANA-administered First Come First Served [RFC5226} registry for magic numbers isn't preferable to an ad hoc "use more bits to make collisions less likely" thing.". So I was tempted to file the same "I don't understand" DISCUSS as Barry.

Then, I read the numerous email exchanges on this document. Joe justified that the different approaches (IANA FCFS, OUI based) are actually no better solutions. And I was kind of convinced. So what is really missing in this document is the analysis of the other solutions, and the justification of why they're not good enough. I really believe that this is required, so I'll file a DISCUSS

Let me cut/paste a few things that could be good topics to be included in the draft:
- An OUI presumes a centralized authority that assigns those IDs. The whole point of this draft is to allow self-assignment and avoid the need to use any organized registry.
- Regarding FCFS:

    - such a registry requires coordination with IANA, which some
    parties don't want to participate in for preliminary work;
    once that work is coded, it often becomes too late

    this is how numerous TCP option codepoints have been
    squatted upon in the past

    - such a registry publicly permanently announces the use of
    the codepoint

    some parties want a de-conflict mechanism that is autonomous,
    transient, and private, until such time as they decide to
    make it public
- etc...

[Ballot discuss]
I don't understand why an IANA-administered First Come First Served [RFC5226} registry for magic numbers isn't preferable to an ad hoc "use more bits to make collisions less likely" thing.  The shepherd writeup says that "t has been recommended that magic numbers are posted for information to the TCPM mailing list, and this mechanism has already been used by all known users of this specification."  Where has that been suggested?  Not in the document.  It doesn't seem like a good idea to have a mailing list re-implement something that IANA already does well.

Update: To be clear, here, this is a "discuss" position, asking for discussion.  I haven't been involved in the discussion of why this approach is the one being taken... I'd like to understand that, and why this approach is better than a very-lightweight, open-to-all IANA registry.  And I do understand that the lack of any coordination in this area is currently a significant problem that needs to be fixed.

[Ballot comment]
I have concerns that we are standardizing a sub-optimal approach based on the assumption of non-collision of identifiers, when it seems likely that we could have standardize a solution based on truly unique identifiers.

Given that this is to support experiments why does it need to be a standard rather than an Informational or an Experimental RFC?

[Ballot discuss]
I don't understand why an IANA-administered First Come First Served [RFC5226} registry for magic numbers isn't preferable to an ad hoc "use more bits to make collisions less likely" thing.  The shepherd writeup says that "t has been recommended that magic numbers are posted for information to the TCPM mailing list, and this mechanism has already been used by all known users of this specification."  Where has that been suggested?  Not in the document.  It doesn't seem like a good idea to have a mailing list re-implement something that IANA already does well.

[Ballot comment]
Note that you have 3692 transposed as 3962! I find this symptomatic :-(

---

I am Abstaining on this document.  I understand it as a pragmatic
extension of the experimental codepoint space, but I believe that
RFC 3692 (sic) is deliberately precise about the value of limiting the
experimental space and gives good reasons.  I cannot support this
document going against the philosophy of 3692, and I think it would
have been far better to encourage the use of non-experimental options
and possibly make it easier to register non-experimental options.

However, I do not believe I should block the pragmatic solution in this
document that clearly has consensus support.

[Ballot comment]
I am surprised that the "magic number" is not defined to be an OUI + (char)Type , if necessary on a newly allocated option number. That would ensure uniqueness, be a fixed length and only take one additional byte.

[Ballot discuss]
I may be missing something obvious here, but I am sure someone will set me straight if I am...

How can the size of the magic number within the TCP option be variable?  That is effectively what is happening when the document states: "The magic number SHOULD be 32 bits, but MAY be either longer or shorter".  To put this into an example, let's suppose we have a TCP option that looks like this:

    | 0xFE | 0x06 | 0xDE | 0xAD | 0xBE | 0xEF |

If I support this magic number approach, am I forced to do multiple value comparisons to determine if I recognize a magic number that may be 8-, 16-, or 24-bits long?  Or is there an expectation that when a document is published using this approach the magic number will be vetted against existing magic numbers to ensure these high-order overlaps do not cause confusion?  While the idea of making this field variable length is noble, the structure is too simplistic to minimize failure modes.

I would propose that this field needs to be a fixed length to ensure correct comparisons by receiving nodes.

[Ballot comment]

- typo @ end p2: "and in are"

- section 5, the last "MUST NOT" is a bit surprising - what if
the experimental option were turned on by via a sockopt but
the assigned option were turned on by the kernel - maybe this
ought to be a SHOULD NOT? (just a suggestion, no need to
respond if you're happy with it as-is)

IANA has reviewed draft-ietf-tcpm-experimental-options-03, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Shared Use of Experimental TCP Options) to Proposed Standard


The IESG has received a request from the TCP Maintenance and Minor
Extensions WG (tcpm) to consider the following document:
- 'Shared Use of Experimental TCP Options'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-12-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes how the experimental TCP option codepoints
  can support concurrent use through the use of a magic number. This
  mechanism avoids the need for a coordinated registry and is
  backward-compatible with currently known uses. It is recommended for
  all new TCP options that use these codepoints.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tcpm-experimental-options/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

    This document is requested for publication as Proposed Standard,
    as indicated on the title page.
   
    Early individual versions of the document were heading towards
    Informational status, but community feedback suggested that
    a target status of Proposed Standard would be more appropriate,
    given that the protocol specification is expected to be used
    by running applications. The document was accepted by the TCPM
    working group as a standards track document. There was a brief
    discussion whether the status could be BCP, but the document
    contains a technical protocol specification that could be updated
    in future. In summary, Proposed Standard seems the proper type.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

    This document describes how TCP option codepoints can support
    concurrent experiments using a magic number field. It extends
    the option structure for experimental codepoints (253, 254) with
    a magic number, which is used to differentiate different experiments.
    This mechanism avoids the need for a coordinated registry, and is
    backward-compatible with currently known uses. It is recommended for
    all new experimental RFCs that require TCP option codepoints.

Working Group Summary

  The document was accepted by the TCPM working group with support
  from a significant number of participants. It was discussed in
  several meetings and on the mailing list. Given that the mechanism
  proposed by the document is technically simple, the TCPM discussion
  mainly focused on process questions and a clear description of
  the normative parts of the document. There was only one clarification
  question during the working group last call. In summary, it
  is strong consensus in the TCPM working group that the document
  describes the best solution to deal with shared use of experimental
  TCP option codepoints.

Document Quality

  Several implementations of experimental protocols have already
  documented the use of the magic numbers as specified in this document.
  The document is a short and technically straightforward and does not
  require extensive technical review.

Personnel

  The document sheperd is Michael Scharf .
  The responsible Area Director is Wesley Eddy .


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document sheperd has reviewed the latest version of the document,
  as well as previous versions. He has also reviewed the single last call
  comment, which did not require a document update. The document is
  therefore considered ready for publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

  No.
 

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.
 

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  In the document, the characters ">>" preceding an indented line(s)
  indicates a compliance requirement statement using the key words
  listed above. This convention aids reviewers in quickly identifying
  or finding the explicit compliance requirements of this RFC.
 
  A reader of the document was apparently confused by that markers,
  probably because he skipped Section 2, where this notation is
  explained. The document sheperd believes that it is up to the RFC
  editor to decide whether to use those markers in the final RFC text,
  and possibly to remove them.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

    Yes. The author has confirmed that he is not aware of any IPR.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

    No IPR disclosure has been filed.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

    The document was reviewed and explicitly supported by multiple
    key contributors to the TCPM working group. There was no
    objection. The chairs therefore conclude that there is strong
    working group consensus that this document should be published.
    In addition, first implementions of new experimental protocols
    already use the mechanism. This confirms that the mechanism is
    accepted by the TCP implementation community.
   
    The document explicitly allows use of existing, accepted
    IETF processes to obtain a dedicated TCP option codepoint
    for a new protocol. Feedback in the TCPM working group indicates
    that this process continues to make sense in selected cases
    for experimental protocols (a recent example is MPTCP), possibly
    after careful analysis. Such cases are in line with what this
    document describes.
   
    As mentioned in the document, certain TCP options are known to be
    used by protocols without or with only limited involvment of the
    IETF and, most notably, the TCPM working group. This document
    enables a much simpler use of the existing experimental
    codepoints for such protocols. It remains to be seen whether
    unauthorized use of TCP option codepoints in deployed code will
    migrate towards the mechanism specified in this document. Users
    of unauthorized TCP option codepoints are often silent in the
    TCPM working group.
   

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

    No issues found in the document.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

    No such formal reviews are required.


(13) Have all references within this document been identified as
either normative or informative?

    Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    No. All normative references are published.
   

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    No.
   

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  The document does not change the status of any existing RFC. It
  describes an additional mechanism to facilitate shared use of
  the codepoints definied in RFC 4727. But given that RFC 4727 is
  not modified, no update is required.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The key objective of this document is to enable experimental use
  of TCP options without any new IANA registry. The TCPM working
  group has discussed use of IANA registries for the experimental
  magic numbers and concluded that a mechanism with less
  overhead would be preferable. It is expected that sufficiently
  stable protocols will request a dedicated TCP option codepoint
  via the existing IETF process (e. g., Standard Track document or
  IESG action) and use the existing IANA registry. For other protocols,
  it is difficult to track the actual use of magic numbers.
  Therefore, the document permits experiments to use an experimental
  magic number without IANA involvement.
 
  It is suggested that Internet Drafts documenting an experimental
  procotol specify the magic number in their document. Given that
  the value is not managed by IANA, such documentation
  can be anywhere in a draft, i. e., it does not have to
  be in the IANA section. It is up to the experiment to use
  a magic number with low risk of collissions. It has been
  recommended that magic numbers are posted for information to
  the TCPM mailing list, and this mechanism has already been
  used by all known users of this specification. It is expected
  that the collision probability for experiments resulting from
  that process is extremely small. Protocols can be expected to
  migrate to a dedicated TCP option codepoint managed by the existing
  IANA process prior to Internet-scale deployment.
 
  In summary, this document does inherently not require any
  IANA actions.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The objective of this document is to avoid new IANA registries,
  because it is impossible to track the use of TCP extensions
  used by certain experiments. The existing IANA registry for TCP
  option codepoints is not affected by this document, since the
  process for allocating a dedicated TCP option codepoint does
  not change.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The document does not contain such sections.