Re: [DNA] DNA BCP Submission

[Sathya Narayanan <sathya@research.panasonic.com>]

Dear JinHyeock -

Thanks for your comment. Please find my responses inline.

>First, about DNA definition, there seems a difference  
>between goals & BCP drafts. 
>
>in BCP Abstract, you wrote
>
>"Detecting Network Attachment is a set of strategies for
>determining configuration validity in wireless or rapidly changing
>environments."
>
>whereas goals draft said
>
>"The process by which a host collects the appropriate information and
>detects the identity of its currently attached link to ascertains the 
>validity of its IP configuration, is called Detecting Network 
>Attachment (DNA)." 
>
>In goals, DNA is supposed to detect the identity of currently attached 
>link to verify all the configuration at a stroke. In BCP draft, DNA is 
>supposed to verify configurations one by one. 
>  
>
I understand, we will change the definition part to match with goals 
draft. But, this also brings up the question
that was raised before - should the BCP be restricted in scope by the 
goals document. I don't
think so. So, in the abstract we will include something like " This 
document details best current practice for
using Neighbor Discovery procedures to  Detect Network Attachment in 
IPv6 hosts  and other supporting
procedure to verify relevant configurations".

>I don't think it's wise to confuse what DNA is supposed to accomplish
>as above.  
>
>Second, if you recommend DNA to verify configuraitons separately,
>instead of link identity detection, I would like you to clearly pinpoint 
>what configurations DNA is supposed to verify. 
>
>In DNA point of view, IMO, it seems to sufficient to verify 
>1) (paritical) reachability of existing default routers
>2) validity of exisitng IP addresses
>  
>
We have mentioned these two configurations, in sections 4, 5 & 6 
basically focuses on these two
verifications as the heart of DNA procedures.

>If you think that DNA needs to verify other configurations, clearly 
>enumerate them. Then we can discuss about them.
>
>Right now, it's difficult for me to grasp what configurations you 
>suggest DNA would verify.
>  
>
OK - I guess I understand the confusion - Its the title of the section 5 
- "Validity of current
configurations".  From the section description you can see we are only 
thinking about the current
IP address and the current default router address. But, point well 
taken. We will enumerate them
in -02.

>For example, I can't see why DNA needs to keen about reachability 
>confirmation. I agree that Reachability confirmaiton is crucial for
>Internet connectivity but so does DAD, which we decided to rule
>out from DNA. 
>  
>
You seem to be contradicting yourself. You mentioned 'reachability of 
existing default routers' as one
of the verifications above. Please clarify.

Ofcourse, we don't have to do everything required for Internet 
connectivity, but I think reachability confiirmation
is crucial to DNA - any form of link-identification used for DNA is 
going to be derived from the default router - so
assuming network attachment to be succesful without verifying 
reachability to the default router doesn't make sense
 - while I can understand DAD to be a step after network attachment 
before Internet connectivity becomes active.

>Third, it would be helpful if you present why, right now, it's difficult 
>to verify a specific configuration and how we can overcome the 
>difficulties. 
>
>For example, to verify the (partial) reachability of existing default 
>routers, two difficulties come into my mind. 
>
>1) How to confirm (partial) reachability with link-local address
>Because router address is link-local scope, a host can't be
>sure that it's default router is still (partially) reachable, even if 
>a reply from the same link-local address arrives. 
>
>2) How to quickly detects unreachability 
>It will take substantial time to detect something is not there. 
>NUD will take 3 secs but BCP draft just says that it may be 
>better to reduce the number of NS/ NA exchange as belows.  
>
>" However, if the host has indication that the link may
>have changed, this delay may be reduced without significant damage
>for the network by reducing the number of retries." 
>
>Moreover, if we reduce the number to one, it still will take 1 sec. 
>
>If you present how we can solve the above two under RFC 2461, it 
>would be of help. 
>  
>
I would like to talk with you about these two comments - lets discuss 
this at IETF61.

>Overall I would like the draft be more focused & organized. 
>  
>
Two parallel responses:
1) The way we look at the draft right now is - upto section 6 is focused 
DNA BCP - with some
additional information in section 5 and 6 - from section 7 to 11 are 
additional information for some
specific topics/issues - and section 12 is the security considerations. 
We do believe the text in there right now
is all needed in the BCP.

2) If you could be more specific it will be very useful. We went through 
couple of iterations re-organizing the
draft and removing some text since -00. If you could point to sections 
which you think are redundant or
out-of-focus, or, if you could suggest some form of re-orgnaization, it 
will be great.

Once again, thanks for your comments.

with regards,
Sathya