ietf
[Top] [All Lists]

Review of draft-ietf-ipv6-2461bis-09.txt

2006-12-04 06:36:25
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Review of draft-ietf-ipv6-2461bis-09.txt, Ralph Droms <=