TCP Options and Maximum Segment Size (MSS)
draft-ietf-tcpm-tcpmss-05

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

[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.)

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

[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?

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.

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