Re: [DNA-BOF] Draft charter now online

[JinHyeock Choi <athene@sait.samsung.co.kr>]

Hi Greg
 
I think we need more clarification on a few points. Kindly find my 
in line comments. 
  
> I think that we have to be careful to distinguish between
> the ability to send datagrams, and the configuration
> being available in order to do so.
> 
> If we arrive on the same IP subnet which we have been
> previously attached to (maybe a momentary disconnection),
> then we already have enough configuration to transmit
> to hosts within the link.  Additionally we already have
> authentication configuration which allows us to transfer
> data off the link.
> (Although there are some difficult cases where not
> all hosts on the subnet are reachable in from
> another link-instance which is part of that subnet....)
> 
> 
> In the case where we arrive on a new link-instance,
> but we are unaware of the subnet to which we are attached,
> we may not have valid global addresses, validated link-local
> addresses or the capability to send data off the link.
> 
> I believe that our task is to determine that we've
> arrived on a new link, with a new IP subnet so that
> other processes can undertake the configuration.

I agree that our task is to determine that we've arrived on a new link, 
with a new IP subnet. But I think that it is also the task of DNA to 
gather some information (to receive a suitable RA from a router), 
in case the node actually has arrived on a new IP subnet.  

This is the example which, I hope, will clarify my point. 

Assume a node arrives at a new link and receives a RA with Link Identifier 
Option. If that link identifier differs from the current link identifier, the node 
can detect movement. But the RA may not contain enough information 
to configure new default router. In this case, I think it's DNA job to get a 
proper RA.  

> This means (for example) that if we don't need to
> configure the host's global address in DNA, then we
> leave it to the subsystem which is responsible for
> that (be it DHCPv6 or SAA).  I'd guess the same applies
> to Authentication for off-link data transfer.
> 
> So I guess we have IP connectivity (the ability to
> send and receive datagrams on the link, which I have been
> calling Network Attachment) and IP configuration,
> which entails appropriate Authentication, Addressing,
> and Routing for the subnet.
> My hunch is that the IP connectivity event (the network
> attachment) comes when the wire is plugged into the host,
> or the link-layer authentication is completed.

It seems that we have ambiguity in terminology here. I think 
what you mean by IP connectivity (Network Attachment) is not 
what I mean by IP connection or IP Network Attachment 
(On Spncer's suggestion). 

As I wrote on your suggestion, there are two attachments, 
Datalink Attachment and Network Attachment.  IMHO, when link-layer 
authentication is completed, Datalink Attachment occurs, not 
Network Attachment.    
  
I hope we clarify this, lest there should be confusion. 

> I'd guess that link-local communications in some form
> are available by the end of the attachment detection phase
> (although if RFC-2462 DAD or IPv4 is being used, this may
> not be using a link-local unicast address...).
> 
> I'm not sure if this is the agreed viewpoint, but
> one that I've been working with. (Tell me if it's not right).
> 
> Please indicate if we need to revise this, because
> we'll need to provide enough information in the charter
> to make sure people don't confuse our purposes.

I hope we understand clearly what it means a node has network 
attachment. 

Best regards

JinHyeock