It looks good for me and look into my inline comments.
> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au
> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Greg Daley
> Sent: Tuesday, December 23, 2003 8:47 AM
> To: dna@eng.monash.edu.au
> Cc: Pekka.Nikander; greg.daley@eng.monash.edu.au
> Subject: [DNA-BOF] Revised WG Charter
>
>
> Hi,
>
> Here's the charter which Pekka and I put together
> after the last session.
>
> Please tell us what you think of the text
> (clarity/coverage) and work-items.
>
> Let's start a separate thread if there's need
> to discuss the location of DAD optimization work,
> though.
>
> Greg
>
> We'll remove the DAD specific sections
> if IPv6 WG take on the DAD optimizations.
> Of the text in the charter, only the second last
> paragraph and one of the dot-points refer to
> IPv6 DAD optimization (Indicated with question marks).
>
> Also, there are two deliverables tied to this topic.
>
> ---------------------------------
>
> 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
> stateful autoconfiguration procedures may take a
> fairly long time due to delays associated with
> Router Discovery and Duplicate Address Detection
> processes.
Is this working group treating on *stateful configuration*
within a scope of item ? Above sentence occurs a
ambiguousity. If considering, I think below sentence should be
added...
...multicast listener (MLD) stage [RFC2710], Dynamic Host
Configuration Protocol for IPv6 [RFC 3315].
If not considering, you should remove "stateful autoconfiguration"
from above sentence.
> 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.
Below is a individual thought.
The purpose of the DNA working group is to define
standard and BCP mechanisms (or protocol) that
allow.....
> 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.
As you know, IPv6 wg is working on RFC2461,2462-bis
and considering lots of issues to extend each protocol.
Don't we need to clarify what extensions are work items
in DNA and relationship between them ?
and what issues happens on RFC 3315 ? possibly is so
ambiguous for me...
> ?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].
In my opinion, *without* is not accurate. It is because we
have been working for optimized DAD not skiped DAD
against current DAD mechanism.
> The DNA WG will not provide explicit directions to
> implementors about datalink layer issues.
>
> 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
>
> Existing Link Layer Hints Catalogue (Info) Aug04
>
>
> ?IPv6 DAD Optimization Goals and
> ? Requirements (Info) Aug04
> ?
> ?IPv6 DAD Optimization (Standards Track) Dec04
>
Goals and Milestones:
=================
Feb 2004 ~ July : What happens during this period ?
Aug 2004: Submit Detecting Network Attachment in IPv6 as informational.
Aug 2004: Submit Best Current Practice for Detecting Network Attachment in IPv6 as BCP
Aug 2004: Submit Existing Link Layer Hints Catalogue as informational.
Aug 2004: Submit IPv6 DAD Optimization Glals and Requirements as informational.
Dec 2004: Submit IPv6 DAD Optimization as standard.
Dec 2004: Submit Detecting Network Attachment in IPv6 as standard.
Sep 2004: Close WG or Re-charter.
Regards
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics