Re: [DNA-BOF] Revised WG Charter

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

Hi Jari, 

----- Original Message -----
From: Jari Arkko <jari.arkko@kolumbus.fi>
Date: Tuesday, December 23, 2003 6:34 pm
Subject: Re: [DNA-BOF] Revised WG Charter

> Hi Greg. The charter looks very good, thanks! A few nits
> inline:
> 
> > Detecting Network Attachment (DNA)
> > 
> > When an IP node detects or suspects that its
> > underlying link layer (L2) connectivity has or
> > may have undergone a change, it needs to check
> > whether its IP layer (L3) configuration and
> > connectivity are still valid or have changed.
> > In the case that the L3 connectivity has changed,
> > the node needs to reconfigure and may need to
> > initiate mobility procedures, such as sending
> > Mobile IP binding updates. Changes in an L2
> > connection do not necessarily mean that
> > there has been change in L3 connectivity.
> > 
> > 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, an L3 link is the
> > range where a given IP configuration is valid.
> > 
> > In IPv6, the IP layer configuration information
> > includes the set of valid unicast addresses[RFC2461],
> > the DAD status of the addresses[RFC2462], valid
> > routing prefixes[RFC2461], set of default
> > routers[RFC2461], multicast listener (MLD)
> > state[RFC2710].  The current IPv6 stateless and
> 
> Is this expected to be an exhaustive list or just
> some examples? RFC 2461 Neighbor Cache and Destination
> Cache should perhaps be included as well?

I think that it's hard to be exhaustive, but
in this case we missed a fairly important pair.

Thanks for that.


> > stateful autoconfiguration procedures may take a
> > fairly long time due to delays associated with
> > Router Discovery and Duplicate Address Detection
> > processes.
> > 
> > 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 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.
> > 
> > The purpose of the DNA working group is to define
> > standards track and BCP documents that allow hosts
> > to detect their IP layer configuration and
> > connectivity status quickly, and to propose some
> > optimization to the current specifications that
> > would allow a host to reconfigure its IPv6 layer
> > faster than today.
> > 
> > Initiation of link change detection procedures can
> > be achieved either through reception of messages at
> > the IP layer or through indications from other
> > layers.  The working group will produce a document
> > that contains a catalogue of the indications
> > available from a number of link layer technologies.
> > 
> > The working group will preduce a document explaining
> > how a node can make best use of the existing L2
> > and L3 information for detecting network attachment.
> > 
> > The working group will define a set extensions to the
> > current IPv6 configuration protocols [RFC2461, 2462,
> > possibly RFC3315] that allow the nodes to
> > discover whether L3 configuration or connectivity
> > may have changed more reliably and easily than today.
> > 
> > ?In order to detect network attachment, it is important
> > ?to be able to send and receive IP messages on the link,
> > ?even if the link has changed.
> > ?The DNA WG will develop a system which allows use of
> > ?an IPv6 addresses while determining if a link has
> > ?changed without the latency cost of the traditional
> > ?DAD [RFC2462].
> 
> This seems a bit unclear. Is the optimistic DAD procedure
> only allowed to be used for the probes related to DNA, but
> not for real traffic?

I think this is the second piece of feedback I've 
received from this. It's clearly not clear enough.

"...
?In order to detect network attachment, it is important
?to be able to send and receive IP messages on the link,
?even if the link has changed.
?The DNA WG will develop a system which allows use of
?an IPv6 addresses without the latency cost of the
?traditional DAD [RFC2462].
?Such a system may allow the transfer of user data while
?link-change detection and DAD procedures are in progress.
..."


> > The DNA WG will not provide explicit directions to
> > implementors about datalink layer issues.
> 
> I did not get this, but maybe its just me.

How about:

"The DNA WG will not define new procedures or APIs
related to datalink layers."


> > Goals:
> > 
> > * Document existing link layer (L2) information which is
> >       useful to start detecting network attachment.
> > 
> > * Specify a solution framework for detecting network
> >       attachment and L3 link change in IPv6 networks.
> > 
> > * Specify a set of extensions to the current IPv6
> >       protocols for detecting network attachment and
> >       L3 link change more reliably or more easily than
> >       today.
> > 
> > ?* Develop a DAD optimization protocol, independent of
> >       link layer (L2) technology.
> > 
> > 
> > ----------------------------------------
> > Deliverables:
> > 
> > 
> > Detecting Network Attachment in IPv6:
> >             Goals and Requirements  (Info)            Aug04
> > 
> > Best Current Practice for Detecting Network
> >           Attachment in IPv6        (BCP)             Aug04
> > 
> > Detecting Network Attachment in
> >           IPv6 Protocol             (Standards Track) Dec04
> 
> Hmm... I don't see a clear mapping between these three items
> and the two items from the goals list relating to IPv6 DNA.
> In the goals list, you talk about a framework and a set of
> extensions. Here, you talk about a requirements document,
> an "IPv6 as-is" DNA BCP, and the "extended IPv6" DNA RFC.
> 
> I think the deliverables list makes more sense than the
> framework approach.

I think that this is mainly a bad description of the 
documents above.

instead of the two dot points above, the goals should be:

"...
* Specify current practice for detecting network
   attachment and L3 link change in IPv6 networks.
 
* Define a protocol extension to for detecting network
   attachment and L3 link change in IPv6 networks 
   more reliably and easily.
..."

> Perhaps you should also change "goals and requirements" into
> "problem statement"? This might ensure that we don't spend
> a lot of time listing detailed requirements, which would be
> a waste of time, imho.

I think that it's easy enough to overspecify requirements,
but I'd like to have more than just a problem statement
from a documentation point of view.  

How about we drop the name "and requirements" from the 
charter, and see where it leads?..
 

Greg