[DNA] Comments on the DNA BCP draft

[Jari Arkko <jari.arkko@kolumbus.fi>]

Hi,

I read draft-narayanan-dna-bcp-00.txt on the plane on my
way here to San Diego. It looks like a good document! I do have
a few questions and comments, however:

* I don't understand the second paragraph of Section 4.1.2.
   It seems like you can assume your router is still alive and
   your address is good if you receive a packet from the Internet,
   destined to your address. But some other packet to some other
   address is not a guarantee of this.

* Section 4.3, what do you mean by "configuration procedures"?
   DHCP? Something else?

* Section 5.1, 4th paragraph. I would delete the sentence about
   SEND certificates not being present in the messages; they are not
   present but there's another message where they are. You should
   either say nothing about the certificates or explain where they
   they are carried.

* At the end of the same paragraph, I think you mean prefixes
   and not source addresses.

* Section 6 says that information from other protocol layers should
   not be trusted for other than hint purposes, because such information
   can come from an insecure protocol such as WEP. However, it seems
   that IP layer information can be insecure as well (e.g., no DHCP
   authentication or plain ND is used), so I'm not sure this argument
   is so good.

* Section 7.6, why does it matter whether an RA is a response to
   a specific RS or not?

* Section 7.6 says also that when SEND is in use, nonces can be
   relied upon to match requests and responses. This holds only
   for the case of responses sent to a unicast address; the inclusion
   of the Nonce in a multicast response is only a MAY in the SEND
   specification.

* Section 9.5 says that hosts should send an mld report swiftly
   after initiating DNA procedures. But wouldn't this be always
   necessary, so why is this only a "should"?

* Section 10.1 says that the size of packets increases dramatically
   if SEND is used. This is right, but note that the certificates
   transport is not always needed. It is initiated when it is needed.
   For instance, in a ping-pong situation you would never retrive
   new certificates.

Editorial:

* Section 4.1.2, s/receive incorrectly believe/incorrectly believe/

* s/MIPv6/Mobile IPv6/g

* Section 5.1, s/prefix supported by them/prefixes supported by them/

* Section 5.1, s/localization/location/

* Section 5.2, s/important/significant/ (same in Section 9.1)

* Section 5.2, s/proposes to reduce/allows the reduction of/

* Why does Section 8 have similar material to what was already
   discussed in Section 5.2? Could these be combined?

* Section 8.4, s/NONCE/nonce

* s/connexion/connection/

* s/secured neighbor discovery/secure neighbor discovery/