TCP Options and Maximum Segment Size (MSS)
draft-ietf-tcpm-tcpmss-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-06-19
|
05 | Samuel Weiler | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Klaas Wierenga. |
2012-06-12
|
05 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-06-11
|
05 | (System) | IANA Action state changed to No IC |
2012-06-11
|
05 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-06-11
|
05 | Amy Vezza | IESG has approved the document |
2012-06-11
|
05 | Amy Vezza | Closed "Approve" ballot |
2012-06-11
|
05 | Amy Vezza | Ballot approval text was generated |
2012-06-07
|
05 | Wesley Eddy | State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2012-06-07
|
05 | David Borman | New version available: draft-ietf-tcpm-tcpmss-05.txt |
2012-06-07
|
04 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2012-06-06
|
04 | Benoît Claise | [Ballot comment] I don't understand what we gain by having this statement: Additional clarification was sent to the TCP Large Windows mailing list … [Ballot comment] I don't understand what we gain by having this statement: Additional clarification was sent to the TCP Large Windows mailing list in 1993 [Borman93]. The goal can't be to acknowledge the person who posted the email, as this is the author ;-) And it's even confusing. Should I review this email on the top of the document. This can't be, right? Note: that's the first time I see, part of a RFC, a reference to a specific email in the archive Regards, Benoit. |
2012-06-06
|
04 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-06-06
|
04 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-06-06
|
04 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-06-05
|
04 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-06-05
|
04 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-06-05
|
04 | Sean Turner | [Ballot comment] Just a reminder to publish a version that incorporates changes agreed to as part of the secdir review. |
2012-06-05
|
04 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-06-05
|
04 | Barry Leiba | [Ballot comment] Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: In addition to Adrian's … [Ballot comment] Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: In addition to Adrian's comment... -- 8 -- At least RFC 879 and RFC 2385 should be normative references here. It's kind of hard to imagine how this can Update those, and not cite them normatively. (Don't make the mistake of thinking that Informational documents don't have normative references.) |
2012-06-05
|
04 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-06-04
|
04 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-06-04
|
04 | Martin Stiemerling | [Ballot comment] The abstracts seems to be rather short in order to give hints to a reader, i.e., it would be good to the part … [Ballot comment] The abstracts seems to be rather short in order to give hints to a reader, i.e., it would be good to the part of IP options and TCP MSS from the into. |
2012-06-04
|
04 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2012-06-02
|
04 | Adrian Farrel | [Ballot comment] I am surprised about the perceived need to update an obsoleted RFC, but if folk really want to do it, I think they … [Ballot comment] I am surprised about the perceived need to update an obsoleted RFC, but if folk really want to do it, I think they should make it very clear in this document that RFC 2385 has been obsoleted by RFC 5925 so that readers understand that using RFC 2385 with the correction documented here is not the preferred approach. --- Would a reference to RFC 6151 help? |
2012-06-02
|
04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-06-01
|
04 | Russ Housley | [Ballot comment] Please consider the editorial comments in the Gen-ART Review by Martin Thomson on 24-May-2012. Please find the review here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07452.html |
2012-06-01
|
04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-05-31
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to Martin Thomson |
2012-05-31
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to Martin Thomson |
2012-05-31
|
04 | Brian Haberman | [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman |
2012-05-31
|
04 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2012-05-30
|
04 | Wesley Eddy | Placed on agenda for telechat - 2012-06-07 |
2012-05-30
|
04 | Wesley Eddy | Ballot has been issued |
2012-05-30
|
04 | Wesley Eddy | [Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy |
2012-05-30
|
04 | Wesley Eddy | Ballot writeup was changed |
2012-05-30
|
04 | Wesley Eddy | Created "Approve" ballot |
2012-05-30
|
04 | Wesley Eddy | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-05-30
|
04 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-05-24
|
04 | Martin Thomson | Request for Last Call review by GENART Completed. Reviewer: Martin Thomson. |
2012-05-18
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2012-05-18
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Klaas Wierenga |
2012-05-17
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Martin Thomson |
2012-05-17
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Martin Thomson |
2012-05-17
|
04 | Pearl Liang | IANA understands that, upon approval of this document, there are no IANA Actions that need completion. |
2012-05-16
|
04 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (TCP Options and MSS) to Informational … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (TCP Options and MSS) to Informational RFC The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Options and MSS' as Informational RFC 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-05-30. 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 memo discusses what value to use with the TCP MSS option, and updates RFC 879 and RFC 2385. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcpmss/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcpmss/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-05-16
|
04 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-05-16
|
04 | Amy Vezza | Last call announcement was changed |
2012-05-15
|
04 | Wesley Eddy | Last call was requested |
2012-05-15
|
04 | Wesley Eddy | Last call announcement was generated |
2012-05-15
|
04 | Wesley Eddy | Ballot approval text was generated |
2012-05-15
|
04 | Wesley Eddy | Ballot writeup was generated |
2012-05-15
|
04 | Wesley Eddy | State changed to Last Call Requested from AD Evaluation |
2012-05-14
|
04 | Wesley Eddy | State changed to AD Evaluation from Publication Requested |
2012-05-09
|
04 | Amy Vezza | (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? … (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 . The Resposible 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 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. |
2012-05-09
|
04 | Amy Vezza | Note added 'The Document Shepherd is Michael Scharf (michael.scharf@alcatel-lucent.com).' |
2012-05-09
|
04 | Amy Vezza | Intended Status changed to Informational |
2012-05-09
|
04 | Amy Vezza | IESG process started in state Publication Requested |
2012-03-29
|
04 | David Borman | New version available: draft-ietf-tcpm-tcpmss-04.txt |
2010-09-26
|
03 | (System) | Document has expired |
2010-03-25
|
03 | (System) | New version available: draft-ietf-tcpm-tcpmss-03.txt |
2009-07-13
|
02 | (System) | New version available: draft-ietf-tcpm-tcpmss-02.txt |
2009-07-13
|
01 | (System) | New version available: draft-ietf-tcpm-tcpmss-01.txt |
2009-03-04
|
00 | (System) | New version available: draft-ietf-tcpm-tcpmss-00.txt |