Here are my comments on draft-ietf-ipv6-2461bis-09.txt. In general, I think
the document is ready for publication. Included below are a few substantive
comments that I would like to see addressed before publication, and some
editorial corrections/suggestions/comments.
- Ralph
-----
Substantive/editorial: I'm confused by the statements in section 3.2,
Supported Link Types: "Neighbor Discovery should be implemented
as described in this document." What is the intent of the
statement - advice about whether to implement or how to
implement? Under what circumstances would a node not implement
Neighbor Discovery as described in the document.
Substantive: From section 4.6, Option Formats:
Options should
be padded when necessary to ensure that they end on their natural 64-
bit boundaries.
How, exactly, is this padding encoded? And, why bother?
Substantive: The definition of the L bit, from the Prefix Information
option, includes:
When
not set the advertisement makes no statement about
on-link or off-link properties of the prefix.
This point about "no statement about on-link or
off-link..." is made other places, as well. I don't think
I see any indication of the consequences of this
definition; that is, what should the implementor be aware
of as a consequence of the lack of knowledge about whether
a prefix is on-link or off-link? If those consequences are
subtle, perhaps they should be explained?
Editorial/substantive: From section 5.1, Conceptual Data Structures:
Default Router List
- A list of routers to which packets may be sent.
Is it possible for a host to send packets to routers that
are not on the Default Router list?
Editorial: In the last paragraph of section 1,
s/Deering Richard/Deering, Richard/
Editorial suggestion: In the definition of "link MTU" (section 2.1),
s/piece/transmission unit/ (or some other similar term)
Editorial: In the definition of NBMA (section 2.2), s/it(e.g.,/it (e.g.,/
Editorial: In the definition of "Address Autoconfiguration" in section 3,
I'm guessing that "How nodes automatically configure..." was
changed to "Introduces the mechanisms needed in order to allow
nodes to automatically configure..." because the mechanism is
defined in RFC 2462. A citation of RFC 2462 might be in order
here.
Editorial: In the definitions of "Anycast addresses" and "Proxy
advertisements" in section 3, the phrases "non-Override
advertisements" and "non-Override Neighbor Advertisements"
are used before they are defined.
Editorial: Seems "autonomous address configuration" and "stateless
address configuration" (and some variants like "autonomous
address-configuration", "stateless address
autoconfiguration" and "address autoconfiguration") are
used interchangeably throughout the document; it would
improve clarity to pick one phrase and use it uniformly
throughout the document
Editorial: The definition for Prefix Information option in section 4.2
includes the text "specify the prefixes that are on-link
and/or are used for address autoconfiguration". Is it the
case that a Prefix Information option will only appear for
on-link and/or address autoconfiguration; i.e., at least
one of the L and A bits will always be set in Prefix
Information option?
Editorial: In the definition of MinRtrAdvInterval in 6.2.1,
s/.75 *MaxRtrAdvInterval/.75 * MaxRtrAdvInterval/
Editorial: In section 6.3.4, s/"on-link "/"on-link"/
Editorial suggestion: In Appendix E,
s/working. It merely/working; it merely/
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf