[dna] comments on draft-ietf-dna-tentative

[Jari Arkko <[e-mail]>]

Here are a few comments on this draft. Overall, this document is in 
reasonable shape, but contained a number of small errors.

Detailed comments:

First, which status would this document be published with? 
Historic/Informational as in the case of draft-ietf-dna-protocol? Or 
something else?

Second, the document needs to be re-submitted to the directories before 
I can enter it to the tracker.

> In a case where it is safe to send a Source Link-Layer Address
> Option, a host SHOULD NOT send a TO, since the message may be
> misinterpreted by legacy nodes.
>
> Importantly, a node MUST NOT send a Tentative Option in the same
> message where a Source Link-Layer Address Option is sent
> Any Router Solicitation from a Preferred, Deprecated or Optimistic
> address MAY be sent with a Tentative Option [RFC4429 <http://tools.ietf.org/html/rfc4429>].
>   

Aren't these two text excerpts in conflict with each other? RS typically 
includes a SLLA, so normally we would not be able to use a TO based on 
the rule in the earlier text. Also, if the source address is Preferred 
or Deprecated, an SLLA can be used and per the earlier rule, should not 
be used.

> An extension which allows Router Solicitations to be sent with a TO
> from the unspecified address is described in Appendix C <http://tools.ietf.org/html/draft-ietf-dna-tentative-02#appendix-C>.
>   

I understood from Greg that this has not been implemented. Does it make 
sense to remove it from the draft as well?

> For standardization, this document requires that the IANA allocate
> the Tentative Option for link-layer addressing (Section Section 2.1 <http://tools.ietf.org/html/draft-ietf-dna-tentative-02#section-2.1>)
> from the IPv6 Neighbour Discovery options for IPv6.
>   
This document asks the IANA to allocate ...

> Previous (older) experimental implementations have used the value
> 0x11 (17) for the Tentative Option, before the IPv6 Neighbour
> Discovery experimental range was defined [RFC4727 <http://tools.ietf.org/html/rfc4727>].
>   
This value does not appear to be free anymore, according to 
http://www.iana.org/assignments/icmpv6-parameters

I would suggest deleting this paragraph.

> The use of the Tentative Option in Neighbour and Router Solicitation
> messages acts in a similar manner to SLLAO, updating neighbour cache
> entries, in a way which causes packet transmission.
>   
?

Did you mean "affects the transmission of subsequent packets"?


> Particular care should be taken that transmission of messages
> complies with existing IPv6 Neighbour Discovery Procedures, so that
> unmodified hosts do not receive invalid messages.
>   
I'm not sure what you are asking for here.

Missing things: the document should clearly state somewhere how you deal 
with legacy nodes that do not implement this RFC. My understanding is 
that since unknown options are ignored, the resulting behaviour is 
equivalent to sending an ND message without SLLAO (which is the current 
behaviour with standard ND anyway). Correct?

Jari