Subject: Next steps

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 15 Jun 2004 19:05:19 +0200

All,

During the interim Multi6 WG meeting in Santa Monica, the group
tried to come up with a classification of the proposals made so far
based on the classes used in Geoff Huston's
draft-huston-multi6-architectures-01.txt. During the interim meeting,
this classification was discussed and to some extent reordered. Below
you will find the outcome that we agreed on in the room:

A. Addressing based
	 * draft-kurtis-multihoming-longprefix-00.txt
	 draft-savola-multi6-asn-pi-01.txt
	 draft-ohta-multihomed-isps-00.txt
	 draft-toyama-multi6-operational-site-multihoming-00.txt
	 draft-ohira-assign-select-e2e-multihome-01.txt
	 draft-van-beijnum-multi6-isp-int-aggr-01.txt
	 * draft-van-beijnum-multi6-2pi1a-00.txt
	 draft-ohira-multi6-multilink-auto-prefix-assign-00.txt
	 draft-teraoka-multi6-lin6-00.txt

B. "Intermediate systems"

	* draft-bagnulo-multi6-mhexthdr-00.txt
	draft-py-multi6-mhtp-01.txt

C. Hostbased
	 draft-huitema-multi6-experiment-00.txt
	 draft-huitema-multi6-hosts-03.txt

D. Tunnels

E. Transport
	 draft-coene-sctp-multihome-04.txt
	 draft-coene-multi6-sctp-00.txt
	 draft-arifumi-multi6-tlc-fm-00.txt
	 draft-ohta-e2e-multihoming-05.txt
	 draft-ohta-multi6-8plus8-00.txt
	
F. Wedgelayer 3.5 / Fat IP
	draft-nordmark-multi6-cb64-00.txt
	draft-nordmark-multi6-noid-01.txt
	* draft-nordmark-multi6-sim-01.txt
	draft-ylitalo-multi6-wimp-00.txt
	draft-crocker-mast-proposal-01.txt
	draft-nikander-multi6-hip-00.txt
	draft-van-beijnum-multi6-odt-00.txt

G. Components
	 draft-de-launois-multi6-naros-00.txt	
	 draft-crocker-celp-00.txt

The drafts that are preceded with a "*" where withdrawn during the
interim meeting by their authors. The chairs now would like to proceed
with trying to limit the numer of classes of proposed solutions still
on the table and try and judge the support for each class. Based on
the discussions during the interim meeting it appears that there is no
or limited support for the solutions in class A, so we would like to
remove this class of solutions. The same goes for class B. As for
class C, we would like to move the hostbased approach into the
Components class (which we will explain below). As for the tunnels
class, the only proposal that we could come up with that would fit
would be Jerooen Massar's draft-massar-v6ops-ayiya-00.txt, which is
not a complete multihoming solution. We therefore propose to add this
to the components class. As for transport, we judge that although
there is some support for some of the solutions in the transport
class, it does seeem to be in the minority. This then leaves us with the
F class. The chairs would like to encourage the authors of drafts in
this category to work together to try and combine their ideas and if
possible come up with a common proposal. We _might_ appoint a
document editor for this class to help with the work and make sure we
make progress.

As for the components class, this is a class of proposals that do
contain interesting ideas that might be worth studying further, but
that we believe do not constitute a full solution to the multihoming
problem in their own.

The chairs hope that by using this approach, we would have few enough
proposals by the November IETF to start discussion on a final
proposal and singling out of a proposal to move further (i.e. 
recharter).

The chairs feel there was consensus in the room for this approach,
and would now like to find out if people on the list disagree. We
aim to produce a final agreed categorisation and list of next steps
within two weeks, so please send your comments now.

Kurtis & Brian

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Jun 2004 16:14:53 -0400

>within two weeks, so please send your comments now.

I agree with the overall approach.  The categorization looks about 
right to me, and I think that pursuing a combined proposal based on 
the drafts in category F makes sense.

Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jun 2004 13:41:29 +0200

There's only been one (positive) comment on this message so far.

Now that the draft minutes are out, we would like to verify
that there is indeed consensus on the list for this approach:

- of course, finish our 4 chartered deliverable documents

- focus on combining/consolidating the "Wedgelayer 3.5 / Fat IP"
   class of solution directions (noting that we are not actually
   chartered to write a solution specification);

- continue individual work on items in the "Components" class,
   as potential building blocks.

Support or objections within a week, please.

  Brian
  co-chair

Kurt Erik Lindqvist wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 	All,
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.3
> 
> iQA/AwUBQM8sU6arNKXTPFCVEQJZGwCeOWUyZQA0swRE0h5XkuUt9O2NlD8An1uT
> q2LPtsVnkVvTLtmR78w3t0Xm
> =PiIQ
> -----END PGP SIGNATURE-----
> 
>

---

From: Michael Lambert <[email-masked]>
Date: Tue, 29 Jun 2004 10:09:35 -0400

The following all appear to be expired drafts (at least they are not 
current in the IETF ID repository):

>      draft-ohira-assign-select-e2e-multihome-01.txt  (and -02 as well)

Do the authors have plans to revise and resubmit?

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jun 2004 17:17:34 +0200

That isn't the plan, unless the authors choose to do so, but some
of these drafts fit into the wedge layer or components class,
so I would expect those to be updated or morphed.

      Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jun 2004 11:28:53 -0700 (PDT)

> Do the authors have plans to revise and resubmit?

I'm working on filling in some missing aspects of the signaling protocol
in NOID, to make sure this piece is complete. (I received comments
way back about it being underspecified for instance when both ends
initiate establishing state at the same time and taring down the state).

I view this not as "pushing" for noid as a proposal, but instead making
sure we have a worked out signaling protocol as a component that could
be applied elsewhere.

  Erik