Re: [DNA-BOF] Modified Charter available.

[Gregory Daley <Greg.Daley@eng.monash.edu.au>]

Hi JinHyeock,

----- Original Message -----
From: JinHyeock Choi <athene@sait.samsung.co.kr>
Date: Thursday, January 8, 2004 8:17 pm
Subject: Re: [DNA-BOF] Modified Charter available.

> Dear Greg
> 
> Thanks for your update. Kindly find my in line comments. 
> 
> [omitted]
> > Please tell me if there are any other issues.
> 
> I guess that DNA WG will work on IPv6 only, right? It seems 
> that we only have to settle the 'DAD issue'. Any progress there? 

We're still working on it.

I've passed the charter to the ADs for further comment.

> [omitted]
> > For the purposes of detecting network attachment, an
> > L3 link is defined by the range within which IP
> > packets may be sent without resorting to forwarding.
> > In other words, a link is the range where a given IP
> > configuration is valid.
> 
> '(L3) link', 'L2 link' and 'IP Subnet' are related but not 
> identical. 
> If we use the term 'link' carelessly, I am afraid there may be 
> a confusion. I wish we clarify the terminology.     

Indeed.

I think that the best thing for the charter is that
it is internally consistent and explains its own use
of terms (which this paragraph aims to do).

This doesn't bind us to using these terms in our
documents.


> [omitted]
> > In some wireless technologies, the link layer state
> > and events may not be accurate and unambiguous from
> > the IP point of view. For example, a host may be able
> > to see a base station but still be unable to deliver
> 
> What do you mean by 'a host may be able to see a base
> station'? See in in IP layer or Link layer? Does this mean 
> a host can receive a L2 frame from a base station but not 
> IP packets? 

There may be a pilot signal on another band, or 
beacon frames transmitted at a different rate, which
are able to be received by the host (or transmitted to 
the base station) at the link layer.
In certain circumstances, this may also occur on
the network layer (for example with multicast messages
being transmitted differently to unicast).

> > or receive IP packets within the link. Similarily, a
> > hardware indication that a radio link is up does not
> > necessarily mean that all link layer configuration,
> > such as authentication or virtual LAN connectivity
> > has been completed.
> 
> I still have problem to see the tie between the above and DNA
> work. Do we need the above? 
> 
> And in the below, what is the difference between 'change 
> detection' 
> and 'IP layer connectivity testing'?  
> 
> 'Therefore detecting network attachment requires not only 
> change detection but IP layer connectivity testing.'

IP layer connectivity testing may be any L3 or above
bidirectional confirmation of reachability (for example NS/NA).

Change detection is noticing that the IP configuration
on a link has changed, and that the host's ip address,
routes, MLD groups or other data need updating.
(as mentioned in the charter paragraphs 1,2,3).

Both of these components (as was discussed on the list)
are required for reliable Detection of network attachment.

> [omitted]
> > The working group will produce a document explaining
> > how a node can make best use of the existing L2 and
> > L3 information for detecting network attachment.
> 
> Actually I prefer the expression in below in other mail. 
> 
> "...
> The working group will define best current practice
> for nodes making use of existing L3 and L2 information
> for detecting network attachment.
> ..."

I think I missed integrating this into the list of
changes.

I'll see whather I can pass on the change on to the ADs.

> [omitted].
> > The DNA WG will not define new procedures or APIs
> > related to link layers.
> 
> Does the above mean DNA will not work on any procedures 
> which is related to link layer? Does the above exclude a DNA 
> solution relying on link-layer support, for example link-layer 
> hint? Above seems unnecessary to me. 

It's not going to preclude use of link hints to start 
DNA, but I don't think we'll be recommending how link
hints are generated, received or processed.  Particularly,
we won't be telling other standards bodies what to implement.

This is primarily so that people who see talk about link hints
don't get worried we'll be going beyond the IETF's mandated
work areas.

Thanks for your comments,

Greg