[DNA] DNA in IPv6 Goals 04 I-D

[JinHyeock Choi <jinchoe@gmail.com>]

Dear DNA WG
 
We discussed with Thomas to address his discuss and believe 
that we have reached an understanding. 
 
We reflected IESG review, both discuss & comments, to update 
the draft and the current version is available at 
 
http://www.diffeo.com/drafts/draft-ietf-dna-goals-04.txt
 
Aside editorials, these are the main changes. 
 
1st, reflecting Thomas' comment, we have changed the title to 
 
Goals of Detecting Network Attachment in IPv6
 
2nd, reflecting Spencer's comment, we have changed 
 
    In practice, the host doesn't know which of its addresses are valid
    on the newly attached link.  The host knows neither if its existing
    default router is on this link, nor whether its neighbor cache
    entries are valid.  
 
to 
 
   In practice, the host doesn't know which of its addresses are valid
   on the newly attached link.  It also doesn't know whether its
   existing default router is on this link nor if its neighbor cache
   entries are valid. 
 
3rd, reflecting Spencer's comment, we have changed 
 
     ...................................On the other hand, the host
has full Internet
   connectivity only when it is able to exchange packets with arbitrary
   destinations.
 
to
   ......................On the other hand, the host has Internet connectivity
   only when it is able to exchange packets with off-link destinations.
 
4th, reflecting Thomas' comment, we have changed 
 
.............Third, Router Discovery may take too long and result in
   service disruption.
 
to
   .......................................Third, the current Router Discovery
   specification specifies that routers wait a random delay of 0-.5
   seconds prior to responding with a solicited RA.  This delay can be
   significant and may result in service disruption. 
 
5th, reflecting Thomas & Pekka's comment, we have changed  
 
   Before a host sends an initial solicitation, it SHOULD delay the
   transmission for a random amount of time between 0 and
   MAX_RTR_SOLICITATION_DELAY (1 second).  Furthermore, any Router
   Advertisement sent in response to a Router Solicitation MUST be
   delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5
   seconds).
 
to 
 
   According to RFC 2461 [1]:
 
   -  before a host sends an initial solicitation, it SHOULD delay the
      transmission for a random amount of time between 0 and
      MAX_RTR_SOLICITATION_DELAY (1 second).
 
   -  Furthermore, any Router Advertisement sent in response to a Router
      Solicitation MUST be delayed by a random time between 0 and
      MAX_RA_DELAY_TIME (0.5 seconds).
 
6th, reflecting Thomas & Spencer's comment, we have changed
 
    G2 When upper-layer protocol sessions are being supported, DNA
       schemes should detect the identity of an attached link with
       minimal latency lest there should be service disruption.
 
to
  
  G2 DNA schemes should detect the identity of an attached link with
      minimal latency lest there should be service disruption.
 
We put 'upper-layer' part to underline the necessity of a fast DNA 
procedure. However, it seems that the part is not so much illuminating 
as confusing. So we have removed the part all together. 
 
7th, reflecting Pekka's comment, we have changed 
 
    Because DNA schemes are based on Neighbor Discovery, its trust models
    and threats are similar to the ones presented in RFC 3756 [6].
 
to 
 
   DNA Process is intimately related to Neighbor Discovery protocol [1]
   and its trust model and threats have much in common with the ones
   presented in RFC 3756 [5]. 
 
8th, reflecting Bert Wijnen's comment, we have removed all un-cited refs. 
 
Kindly give your opinion whether everything is all right. 
 
Best Regards
 
JinHyeock