[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA-BOF] IETF 57 DNA BoF session summary



Hi JinHyeock,

JinHyeock Choi wrote:
> Dear Greg
> 
> Thanks for the nice job both during the meeting and afterwards. 
> I guess we had a successful BoF and DNA is on the good track 
> to WG. 

Maybe, we still have to get a charter... :)

> Your meeting summary is good. It presents all the decisions we 
> made correctly and the necessary action points clearly. 
> 
> But I don't find any action point about DAD. Or does AP4 include
> DAD work?

I think that the decisions to include DAD in the charter
mean that we'll have to describe what work is to be done on
DAD optimization.  I didn't want to pre-empt the dicussion
by defining what work is to be done in action points...

We can get onto that soon.

Action Point 4 is to get a document which defines the delays
in MIPv6 handover, but is not necessarily a product of this
group.  In fact, I think it was mentioned that this would
be submitted to the MIP6 group (but obviously would be
useful here).

This goes some way toward determining what needs to be done
from a MIPv6 handover perspective, and may help to
justify a particular piece of work within DNA.

> And I think it will be useful if we have a document which clarifying 
> basic definitions of DNA. For example, 1) What does it mean that 
> a node is attached to a network? 2) What should a node check to 
> detect attachments? 
 >
> With clear definitions in hands, we can avoid unproductive confusion 
> and unnecessary arguments.    
> 

I agree.

This has been mentioned before the BoF, but not
during it.  It may make review of documents
much simpler if we have a common terminology.

I hope that the chartered work items would include
such a document.

> Kindly find my in line comments. 
> 
> 
>>AP1. Develop a WG charter for Detecting Network Attachment.
>>      AP owner <GD>
>>      Target Date: BoF LC to be completed by late August.
>>
>>AP5. Discuss whether cataloguing L2 Hints is useful
>>      (consensus call?)
>>      AP owner:     <TBA, initially GD>
>>      Target date:  mid August
> 
> 
> You put AP5 after AP1. Is this on intention? :-)

Sorry, I thought I'd re-order the issues, but failed
to renumber them.

> 
>>AP2. Link Localv4/DHCPv4 interaction clarification
>>      AP owner:     <GD, Zerconf, DHC WG Chairs>
>>      Target date:  to completed before mid August
>>
>>AP3. Link Localv4/DHCPv4 issues and guidelines document
>>      (informational?)
>>      AP owner:     <TBA, not discussed> (suggested by TN/BA)
>>      Target date:  to completed before mid August
>>
>>AP4. Mobile IPv6 Handover Delays Description Document
>>      AP owner:     <TBA, initially GD> (suggested by TN)
>>      Target date:  mid-late August
> 
> 
> Basically MIPv6 Handover Delay consists of 1) MD Delay, 2) DAD Delay 
> and 3) Signaling(BU/ BA) Delay. Will this document deal with all three 
> delays? I think 'Signaling Delay' is out of DNA scope. 
>
> And how about divide this AP like below
> 
> AP4.1 MD Delay in Mobile IPv6 Handover Description Document
> AP4.2 DAD Delay in Mobile IPv6 Handover Description Document
>  
> In two short documents, I think we can finish this AP more easily. We 
> can combine them later, if necessary. 

There's value in having some form of problem statement
for each of these issues (though not just in
Mobile IPv6).  The specific document which was described
was for an overview of these issues to be submitted to MIP6.

There is value in this even if it is not one of DNA's
work products.

For the problem statements, I think that we need to define
a list of documents required, and a charter.  This wouldn't
be reliant on the document for MIP6, necessarily.
I'll try to start this discussion soon.

> 
>>AP6. Establish Liaison with IEEE ECSG
>>      (? Not agreed, depends on L2 Hints in WG)
>>      AP owner:     <TBA, intially GD>
>>      Target date:  end of September
> 
>  
> Another thanks for good job and I hope we will have a WG at Minneapolis. 
> 

If we have a charter, then that's a good start.

Greg