Re: Next steps

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,
> 
> 
> 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
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.3
> 
> iQA/AwUBQM8sU6arNKXTPFCVEQJZGwCeOWUyZQA0swRE0h5XkuUt9O2NlD8An1uT
> q2LPtsVnkVvTLtmR78w3t0Xm
> =PiIQ
> -----END PGP SIGNATURE-----
> 
>