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

["Greg Daley" <[e-mail]>]

Hi Jari, 

Thanks for the feedback.

> -----Original Message-----
> From: Jari Arkko [mailto:[e-mail]]
> Sent: Fri 10/23/2009 9:47 PM
> To: [e-mail]; Greg Daley
> Cc: [e-mail]; DNA
> Subject: comments on draft-ietf-dna-tentative
 
> 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?
>

I think either Informational, (or Experimental) but not Historic.
Standards track would have been nice, but a standard would need more interest, no?

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

The new draft is available at:

http://www.ietf.org/id/draft-ietf-dna-tentative-03.txt

> > 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.

RS requirements are currently a SHOULD, but RFC4429 allows use of RS with unicast
source while Optimistic, so long as SLLAO is not included (it would pollute the NCE
and not be discovered or overridden by an existing address owner).

(as an aside, Preferred and Deprecated addresses are still valid for ND, though.  There's no change in
behaviour between these two states in sending solicitations.  These are not the focus:
What is interesting is initial link attachment and sending solicitations in the first milliseconds after
attachment.  That initial query gains most from Optimistic state).


I have reorganized and augmented the text as follows:

-   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.


+   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.
+
+   Particularly, Tentative Options are premitted to be sent when
+   addressing state precludes sending the SLLAO, but a neighbour cache
+   entry will be created on a peer node [RFC4429].

Please note the (typo) premitted.  I will update along with any feedback 
if I get the chance today.


> > 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?

I have removed references to this section.



> > 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 ...

Thanks. Done.

> > 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.

Thanks. Done.

> > 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"?

Thanks for that.  The re-read stymied me too.

> > 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.

I'm not sure if there was a behaviour being alluded to which is no longer
in the document.

As a quick stab (it is 3:30 and my daughter is awake by 5...) I have
amended it to "Particular care is taken..."

I will think on it and resubmit by deadline if able.

> 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.

You are correct about the legacy behaviour.  

There is an appendix showing the behaviour of the devices upon reception,
which is largely one of:
a) Transmit to an existing valid NCE
b) NS to the original sender to create an NCE for the RA or NA response
c) Multicast response (where appropriate).


I have added the following paragraph to the end of the Introduction:

+   Operations in this document are safe with respect to existing nodes
+   that implement IPv6 Neighbor Discovery [RFC4861] and Stateless
+   Address Autoconfiguration.  Expected behaviours of legacy decives are
+   summarized in Appendix B.

Alas, another typo (decives).  


Sorry about the response's crudeness.  I saw your e-mail and wished to get
a submission in which implemented some of the points you made.


Sincerely,
Greg