Re: [DNA] DNA BCP Submission

[JinHyeock Choi <jinchoe@gmail.com>]

Dear Sathya

I looked through the BCP draft and here are my comments. 

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

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. 

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. 

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. 

Overall I would like the draft be more focused & organized. 

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock