[dna] Comments on draft-ietf-dna-tentative-04

[Erik Nordmark <[e-mail]>]

I read this document as well, and I have some editorial comments to make 
it more clear.

FWIW I found this paragraph hard to understand:
    The proposed IPv6 Duplicate Address Detection (DAD) Optimization
    "Optimistic DAD" defines a set of recoverable procedures which allow
    a node to make use of an address before DAD completes.  Essentially,
    Optimistic DAD forbids usage of certain Neighbour Discovery options
    which could pollute active neighbour cache entries, while an address
    is tentative.
It reads as as if the name of this proposal/document is "Optimistic 
DAD", but
that is a reference to RFC 4429, right? That is an RFC and not just 
something
that is proposed. Is the intent to say:
    The "Optimistic DAD" protocol [RFC4429]
    defines a set of recoverable procedures which allow
    a node to make use of an address before DAD completes.
    Optimistic DAD forbids usage of certain Neighbour Discovery options
    which could pollute active neighbour cache entries, while an address
    is tentative.


I'd suggest replacing:
      Length         The length of the option (including the type and
                     length fields) in units of 8 octets.
With:
       Length         8-bit unsigned integer.  The length of the option
                      (including the type and length fields) in units of
                      8 octets.  The value 0 is invalid.  Nodes MUST
                      silently discard an ND packet that contains an
                      option with length zero.

In section 2.2 we have
    The differing neighbour cache entry MUST NOT be affected by the
    reception of the Tentative Option.  This ensures that tentative
    addresses are unable to modify legitimate neighbour cache entries.
Thus this MUST NOT mean that a NCE can not be created? Or does 
"differing" imply that only the MUST NOT only talks about the case when 
a NCE already exists for the Source IPv6 address? The preceeding 
sentence already says the latter, so we don't need to repeat it with 
more difficult to understand wording.

Nit: "unable to" in passive voice reads a bit oddly. Can we say "cannot be
added" instead?

Then we have
    For these messages, no Neighbour Cache entry may be created, although
    response messages may be directed to a particular unicast address.
which is more words but less clarity. The document needs to explicitly 
say, for the case when no NCE exists for the Source IPv6 address, 
whether or not an NCE can be created based on the TO option.

Section 4 answers that question, but I still think section 2.2 should be 
made more concise.

Section 4.1 has this
    In the case that a cache entry is unable to be created or updated due
    to existence of a conflicting neighbour cache entry, it MUST NOT
    update the neighbour cache entry.
which reads as a tautology; if must not be updated, in the case that it 
wasn't updated. I suspect there there might be a desire to say
	When a node receives a ND message with a TO option, and a
	Neighbor Cache entry already exists with a different link-layer
	address than what is in the TO option, then the receiver MUST NOT
	perform any changes to the Neighbor Cache.
Basically not only must not the address be updated, but the state etc 
must not
be updated either. Was that the intended meaning of the text?

I suspect section 4.1 can be made more clear with less use of passive voice.
Also, section 4.1 and 4.2 seems to have overlapping text. Should 4.1 
just be about message validation, and 4.2 the processing of a received 
NS/RS with TO?

Finally two non-editorial questions:
Is an implementation allowed to use the TO option to send a reply to a 
NS or RS in the case that a differing NCE exists? The document doesn't 
talk about that and it might be a useful optimization in some cases.

Is an implementation allowed to include TO in NS/RS messages that have 
an unspecified source address?
The second question is answered in an appendix. That constraint should 
be made part of the main text.

    Erik