[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [DNA-BOF] Revised WG Charter
Hello
Please see my inline comments.
> -----Original Message-----
> From: Greg Daley [mailto:greg.daley@eng.monash.edu.au]
> Sent: Tuesday, December 23, 2003 12:30 PM
> To: Soohong Daniel Park
> Cc: dna@eng.monash.edu.au; 'Pekka.Nikander'
> Subject: Re: [DNA-BOF] Revised WG Charter
>
>
> Hi Daniel,
>
> It's good to see so much useful input.
>
> Soohong Daniel Park wrote:
> > 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.
>
> Certainly {stateful|stateless} address configuration is
> part of the IP layer configuration, but DHCP is more than
> that (containing application layer configuration as well).
>
> I'd guess that we'll have to focus just on Layer 3 issues,
> to keep the task managable.
>
> so perhaps this is the way to phrase the above paragraph:
>
> "...
>
> In IPv6, the IP layer configuration information
> includes the set of valid unicast addresses[RFC2462,
> RFC3315], 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.
>
> ..."
>
> This pre-introduces both DHC and SAA before we talk about
> autoconfiguration.
>
> (note the change from 2461 to 2462 in the first point).
>
> Is this reasonable?
better than before IMHO.
>
> >> 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.....
>
> BCPs aren't explicitly protocols. They are definitions
> of how existing protocols are used.
>
> "standards track" has an explicit meaning within IETF
> which should remain here. Certainly we will develop
> documents, but I hope we end up defining standards...
>
> I suppose it depends on whether you think the IETF
> is a standards or document development organization... :)
>
> Does anyone else have a preference here (for mechanisms/
> procedures/documents)?
>
> I think it reads OK with the existing text (given the
> particular meaning of standards track and BCP).
I do not have a hard argument to this meaning of
"define standards track and BCP documents" at the moments
but I would like to see more obvious words than now.
> >> 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 ?
>
> Not really, we're mainly defining new procedures, or
> new semantic interpretations of existing features.
> The scope of the RFC246[12]bis updates are to clear
> up ambiguity in the draft standards.
>
> No new function is being introduced in the IPv6 updates
> (AFAIK).
>
> > and what issues happens on RFC 3315 ? possibly is so
> > ambiguous for me...
>
>
> RFC 3315 is DHCPv6. I don't think that we're explicitly
> going to define DHC parameters, but it may become obvious
> that additions are needed to DHCP discovery capabilities
> (through IPv6 Router Discovery, for example).
>
> I'm pretty sure that any protocol additions or modifications
> will be reviewed or developed (even last called) in the group
> which owns the original document, if it's appropriate.
>
> At this stage, I'm not sure if DNA needs to use DHCPv6 at all.
> I'd prefer not to pre-define a solution in the charter though.
I'd prefer to discuss only problem statement for DHCPv6 when
a client performs stateful address configuration as informational.
No need to propose any solutions IMHO.
Thought ?
> >> ?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.
>
> I think the issue is not without DAD, but without the cost
> of traditional DAD.
> Is there a better way to say this?
>
> >> 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 ?
>
> We develop the documents within the group, and get them
> reviewed.
>
> I think that it may be hard to get a good discussion of
> the documents without assuming that an IETF meeting will
> pass.
>
> Maybe we can get some of them done before August, but
> I think there's no reason to set goals which are
> uniformly out of reach from the start.
>
> > 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.
> >
>
> I think some of the dates and syntax are incorrect on
> these.
>
> I'll still keep the question marks for the DAD items
>
> How about this:
If we think DAD is a DNA procedure, then it must be discussed here.
But if not, I don't have a specific opinion.
Regards
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics