[tcpm] Publication request for draft-ietf-tcpm-tcpmss-04
"Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com> Wed, 09 May 2012 11:28 UTC
Return-Path: <michael.scharf@alcatel-lucent.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDFC21F8528; Wed, 9 May 2012 04:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.411
X-Spam-Level:
X-Spam-Status: No, score=-7.411 tagged_above=-999 required=5 tests=[AWL=-1.518, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sys7qMc-SHaO; Wed, 9 May 2012 04:28:23 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id C1D6F21F8523; Wed, 9 May 2012 04:28:22 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q49BQRLx019326 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 May 2012 13:28:17 +0200
Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 9 May 2012 13:28:09 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: "iesg-secretary@ietf.org" <iesg-secretary@ietf.org>, Wesley Eddy <wes@mti-systems.com>
Date: Wed, 09 May 2012 13:28:07 +0200
Thread-Topic: Publication request for draft-ietf-tcpm-tcpmss-04
Thread-Index: Ac0t1s5nzWVVdP7lTBeZzFp14LiDDg==
Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A9BB0C9@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "david.borman@quantum.com" <david.borman@quantum.com>
Subject: [tcpm] Publication request for draft-ietf-tcpm-tcpmss-04
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2012 11:28:24 -0000
The TCPM working group requests to publish draft-ietf-tcpm-tcpmss-04 as Informational RFC. The Document Shepherd is Michael Scharf <michael.scharf@alcatel-lucent.com>. The write-up is attached below. Thanks Michael (TCPM co-chair) ************************************************************************************* (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? The intended status is Informational, and this is indicated on the title page. The document clarifies statements in the current TCP standards-track specifications (most notably, RFC 1122) that are correct, but that lead to some confusion amongst implementors. The document also corrects two RFCs (879 and 2385, the latter is obsoleted by 5925), which contain wrong statements, but which are not part of the set of current TCP standards-track RFCs. Given that limited scope, Informational seems appropriate. (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 memo discusses what value to use with the TCP MSS option, and updates RFC 879 and RFC 2385. There has been some confusion as to what value should be filled in the TCP MSS option when using IP and TCP options. When calculating the value to put in the TCP MSS option, the MTU value SHOULD be decreased by only the size of the fixed IP and TCP headers, and SHOULD NOT be decreased to account for any possible IP or TCP options; conversely, the sender MUST reduce the TCP data length to account for any IP or TCP options that it is including in the packets that it sends. Working Group Summary This document was written to clarify statements in the TCP standards, given that implementors asked for better guidance of what is already known for many years. The document represents the consensus of the TCPM working group and addresses all feedback in the working group and during/after the last call. Document Quality This is a short document that can be summarized by a single sentence (in section 2). The rest of this document just explains the rationale of what is implied by the TCP standard documents. The MSS option is implemented in all known TCP stacks. It has been reported in the past that some implementations handled the MSS option differently. Due to the resulting risk of packet fragmentation it can be assumed that all modern TCP stacks comply to what the document clarifies. Personnel The Document Shepherd is Michael Scharf <michael.scharf@alcatel-lucent.com>. The Resposible Area Director is Wesley Eddy <wes@mti-systems.com>. (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 Shepherd has searched in the working group archives for comments received before, during, and after the working group last call. The Document Shepherd has reviewed the current version and he confirms that all known comments are addressed. The document is considered ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The issue and the document have been discussed in the working group several times. After these discussions and after the working group last call, some minor changes have been made to address comments from several contributors. Given that the document is short and just clarifies what has already been mandated by the TCP standards, this amount of review is considered sufficient for publication. The Document Shepherd was not active in the working group when the discussion of the document started, but he believes that there has always been strong consensus about the content of the document. (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 such review is required. (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. The Document Shepherd is not aware of any concerns. This is a straightforward document that provides useful guidance to implementors. It should be noted there has been some delay between completion of the working group last call and submission of the current version, due to other obligations of the author. (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. There are no known IPR issues with this draft. Given that this document just explains what is already required by RFC 1122 and described therein (although misunderstood by some implementors), IPR issues have not been discussed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures. (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 represents consensus of the TCPM working group. It can be assumed that everybody in the WG understands the document. The Document Shepherd believes that there has always been strong consensus on what is clarified by the document. The TCPM working group has discussed whether there is actually a need for this document at all, given that it just clarifies what is already implied by TCP standards. The document was finally written because implementors asked for a better explanation. The document has been reviewed by some few individuals in the TCPM working group, it has passed the WGLC, and it has been updated accordingly. (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.) There is no known discontent. (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. The draft passes ID nits without any errors or issues that would have to be fixed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal reviews are required. (13) Have all references within this document been identified as either normative or informative? Yes. The document classifies all references as informative. The document could have classified RFC 793 and RFC 1122 as normative, but it is self-contained since it surveys the key recommendations in RFC 793 and RFC 1122 in appendix A. (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. The document only references to published RFCs, and one e-mail from 1993 related to the topic. (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 updates RFC 879 and RFC 2385, which is mentioned on the title page and in the abstract. The introduction explains the rationale for the update. RFC 879 has no known state, and RFC 2385 is obsoleted by RFC 5925. The document explains what is implied by RFC 1122 (and RFC 793), and given that the the statements therein are correct, 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 document has no actions for IANA. (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 document has no actions for IANA. (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. There is no such content in the document.
- [tcpm] Publication request for draft-ietf-tcpm-tc… Scharf, Michael (Michael)