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

Re: charter



> I think additional example must be added:

> 	IPv6 differs from IPv4 that its global routing table is small.

I don't follow. While it is a goal that IPv6 routing tables be
smaller,  this has to do with a lot of factors, including whether we
get a handle on multihoming. So I don't see how we can put that in the
charter. Also, if the statement were true, what implication does it
have for the charter or this group's work?

> > The WG will take on the following initial tasks:
> > 
> > Produce a document defining what site multihoming is, the requirements
> > for a multihoming solution (from both the end site and ISP
> > perspective).  This document will also include a taxonomy of different
> > ways that multihoming might be achieved.

> That task is acceptable only if it does not affect the last task.

Huh? The last task will most certainly be influenced by what we decide
are requirements.

> > The WG will also consider specific proposals to multihoming in IPv6
> > (both existing and new) and select a small number of them to work on
> > as formal WG items. Development of specific solutions will require
> > approval of the IESG (e.g., a recharter).

> We can technically discuss difference between multiple proposals.
> However, discussion on taxonomies with different proposals in
> minds is really unproductive.

What I would like to see is a broad discussion of possible approaches,
without ruling any of them out of scope. But discussing them doesn't
give the WG a green light to fully develop the approaches and do the
complete solution (at least not initially).  As discussion moves along
we will then want to start gravitating towards one or two or three
that seem the most promising. At that point, I think we need to decide
how best to go forward with the selected approaches. That may mean
rechartering, it may mean forming WG(s) in other areas, etc.

I do think it is is important that the WG formally decide which
approaches to work on (by comparing costs and benefits, how they meet
requirements, etc.) before going ahead with any one specific proposal.

Thomas