Subject: [tcpm] Publication request for draft-ietf-tcpm-experimental-options-02

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 7 Nov 2012 20:23:31 +0100

The TCPM working group requests publication of draft-ietf-tcpm-experimental-options-02 as Proposed Standard RFC.

The Document Shepherd is Michael Scharf <[email-masked]>.

The write-up is attached below.

Thanks

Michael (TCPM co-chair)

******************************

Writeup for draft-ietf-tcpm-experimental-options-02

(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 <[email-masked]>.
   The responsible Area Director is Wesley Eddy <[email-masked]>.

(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.