Subject: [DNA] Confirming today's face-to-face meeting decisions

From: Pekka Nikander <[email-masked]>
Date: Mon, 08 Nov 2004 20:22:45 -0500

Folks,

We made a number of decisions in today's WG meeting, which
we need to confirm on the mailing list.  I'm trying to
summarise just the decisions here; the actual minutes will
come later (hopefully tomorrow).  If you don't agree with
the following decisions, of if you have comments or
questions, please don't hesitate to express your concerns.

1. Link-information draft

The feeling in the room was that the draft is not quite
ready.  It requires more work both in explaining its
applicability and with respect to some specific link
layer technologies, including 3GPP and 3GPP2.  With
regard to 802.16, we were informed that the .16 mobility
spec is not likely to be ready any soon, and therefore it
may not warrant to include it.  At San Diego people asked
for an 802.3 section, but so far nobody has volunteered
to write one.

As a conclusion, more work is needed on the draft.

2. BCP

The feeling of the room was that would be useful to have
two BCP documents, one targeted to host implementors and
the other one to people that configure networks and routers.

More work is needed to determine how to proceed in this area.

3. Solutions framework

We decided to adopt draft-jinchoi-dna-soln-frame-00.txt as
a working group document, with the intent of publishing
it as Information.  The idea is that the document provides
good information to the working group and to the community.
However, this adoption does not mean that the eventual
DNA solution must necessarily be based on this framework.
Right now the framework seems to provide a good starting
point, but our understanding may evolve.

It was left as an open question how fast to proceed with
the draft.  The chairs suggested of quickly proceeding to
a WG last call, but some other people thought that it
might be better to wait for the design team to come up
with at least some initial ideas before going forward.
I would encourage people to express their opinions on this.

4. Solutions work

The chairs proposed to set up a design team to work in the
solutions base.  The consensus in the room was favourable
to this.  The idea is that the design team would come up
with an initial design before the next IETF meeting, if
possible.

I'll announce the design team membership once it is set up.
In addition to those that we have currently in mind, it would
not hurt to have one more person that intends to implement
the design at the same time as the design team makes progress.

--Pekka Nikander

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 11 Nov 2004 04:05:15 +0900

Dear Pekka
  
Thanks for a summary. I think it adequately sums up the decisions 
of the meeting and is of much help. 

[omitted]
> As a conclusion, more work is needed on the draft.

ok. 
 
> More work is needed to determine how to proceed in this area.

ok. 
 
> point, but our understanding may evolve.

ok. 
 
> I would encourage people to express their opinions on this.

I am for a quick proceeding. 
 
> the design at the same time as the design team makes progress.

ok

Best Regards

JinHyeock

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Nov 2004 11:21:08 -0800

hi Pekka,

> I would encourage people to express their opinions on this.

I have a hard time understanding proceedingly quickly with
a solution framework document, when we dont have stable
solutions (atleast agreed to by the WG) in the WG.

the solution framework is bound to be different based on
which links are being used (cdma2000 make-before-break).
some links might only require fastRA and optDAD and dont
need link identifiers. some make-before-break links might
just require link identifiers.

Vijay

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 11 Nov 2004 07:39:17 +1100

> solutions (atleast agreed to by the WG) in the WG.

Hi Vijay,

	my point of view is that the solution framework should.
discuss the techniques available and the situations in which
they are suitable.  Actual link types would be used as examples
rather than trying to combine a canonical list of link types.

	That way, when someone decides to implement fast
network attachment on PhlogistonNet or whatever, they
can go to the informational and say yes: it needs this,
no: it doesn't need that, etc.

	Mind you, I haven't read the document in question 
lately, and I'm not there in DC, so this comment may be
rather irrelevant!

-----Nick in Melbourne

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Nov 2004 12:46:36 -0800

Nick 'Sharkey' Moore wrote:
> discuss the techniques available 

my point is have we agreed that we have some techniques
available?

Vijay

> and the situations in which

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 10 Nov 2004 16:03:09 -0500

> solutions (atleast agreed to by the WG) in the WG.

Maybe it is better to wait; I am open to both options.
Opinions, please!

I'm just trying to keep us making progress and not lag
too far behind our milestones; OTOH, it there is a reason
it is not that hard to update the milestones.

--Pekka

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Nov 2004 13:46:01 -0800

Pekka Nikander wrote:
  better to wait; I am open to both options.
> it is not that hard to update the milestones.

Seems like folks are confusing "framework" and "summary" or "overview".
A framework is the thing you build before you place things into it.
For instance, you build the supporting structure of a building before 
you place the wallboards.

I agree that we can't write a summary or overview document until we know 
what we end up with, but we should be able to write a framework document 
which provides the frame into which the puzzle pieces will fit.
If we can't do that, then we must be fumbling around in the dark.

So I'm confused why folks think we must wait.
    Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 10 Nov 2004 14:06:17 -0800

> So I'm confused why folks think we must wait.

the framework seems to recommend that we need a Link identifier
solution, fast RA, fast RS, optDAD and TSLLAO. it says with this
we have a good DNA solution.

that doesnt seem like a "supporting structure" to me.

maybe I dont understand whats in the framework document.

Vijay

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 11 Nov 2004 07:22:29 +0900

> that doesnt seem like a "supporting structure" to me.

Framework presents a few ideas on which we base 
DNA solutions, such as Link Identifier, RA optimized 
for DNA & Quick RA delivery. 

However, they are rather conceptual and even though 
the draft mentions a few current schemes as possible 
candidates, it was not out intention to recommend a 
specific scheme, such as FastRA, as a solution. 

Best Regards

JinHyeock

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Nov 2004 18:08:20 -0800

> maybe I dont understand whats in the framework document.

This discussion, about the content of the document, is what I'd like to 
see. Thanks.

The current content of the document captures (captured) the authors 
ideas when it was written. It probably makes sense to rephrase things as 
the desirable properties.
For instance, I think we know we want a solution which uses router 
advertisements so that one can find the configuration of the new link at 
the same time as detecting whether or not one has moved to a new link.

And given that we have two different styles to detect the link (an 
explicit link identifier, compared to what I would characterize as a 
cookie or a landmark, where the host asks "does this landmark still 
exist" without an explicit linkid) we should express the need based on 
the property that a host should be able to determine whether it is on 
the same link or not from receiving a single message.

   Erik