I am an assigned INT directorate reviewer for
draft-ietf-6man-rfc1981bis-03.txt. These comments were written
primarily for the benefit of the Internet Area Directors. Document
editors and shepherd(s) should treat these comments just like they
would treat comments from any other IETF contributors and resolve them
along with any other Last Call comments that have been received. For
more details on the INT Directorate, see
http://www.ietf.org/iesg/directorate.html.

This document appears to be Ready with Nits.


Add RFC 2119 to Reference and add corresponding boilerplate, probably
to the Terminology section.

Section 4, Page 6, next to last paragraph of Section 4: "should" -> "SHOULD"

Section 5.1, Page 7, 2nd sentence of next to last paragraph of Section
5.1: delete superfluous comma

Section 5.2, Page 7: just a wording suggestion: "must in fact
represent" -> "represents"

Section 5.2, Page 8: The indented Note about "security
classifications" strikes me as probably an archaism left over from
when it was the "US Department of Defense Internet". I suggest
replacing "security classifications" with "quality of service
markings" or the like. Security seems like one "quality" of service so
I believe the new wording I am suggesting is a superset of the old.

Section 5.2, Page 9: I am not entirely comfortable that earlier in the
document it says that a Packet Too Big reporting a next hop MTU less
than the IPv6 minimum link MTU should be discarded and that a node
MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum
link MTU but in the top paragraph on page 9 it talks in an
unrestricted way about reducing the PMTU based on Packet Too Big
message next hop size. I suggest, at the top of page 9: "uses the
value in the MTU field in the Packet Too Big message as a tentative
PMTU" -> "uses the value in the MTU field in the Packet Too Big
message, or the minimum IPv6 next hop MTU if that is larger, as a
tentative PMTU"

Section 5.3, Page 10, right after the indented Note: "must not" -> "MUST NOT"

Section 5.4, Page 10: "should not" -> "SHOULD NOT"

Section 5.4, Page 11, 1st paragraph: Expand "MSS" on first use; "must
not" -> "MUST NOT"

Section 5.4, Page 11, indented Note: in 1st paragraph "must not" ->
"MUST NOT"; in 2nd paragraph "must" -> "MUST"

Section 5.5, Page 12, 1st paragraph: "should" -> "SHOULD"

Section 5.5, Page 12, 3rd paragraph: "recommended" -> "RECOMMENDED"

Section 5.5, Page 12, 4th paragraph: If some NFS operations cannot be
fragmented, "should not" -> "MUST NOT"

Appendix B, 2nd sentence: "version that the change was made.:" ->
"version where the change was made."

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com