Requirement document last call (let's focus!)

["Christian Huitema" <huitema@windows.microsoft.com>]

> | This sounds exactly like a description of mobility, and exactly like
> | a description of multihoming. I don't think we should be scared of
> | common solutions (which is not the same as saying MIPv6 is the
> | solution for multihoming).
> 
> Remember that this WG is charterd to solve SITE multihoming,
> rather than host multihoming.   If the former, which implies
> simultaneous connectivity and/or migration for a collection of
> hosts from a few to a vast number, can be done using the mechanisms
> of the latter (e.g. multi-addressed hosts, MIP6), that's fine and
> dandy.  However, first, the charter documents need to be pushed
> along the standards track, as discussed in SLC.

Seconded!

Let's first achieve the goal of the current charter, which is to publish the requirement document. And let's not try to tailor the requirement to a specific solution: this is the known way to not make progress.

Could someone summarize the actual modifications to the requirement document that surfaced during this last call? I seem to recall the following:

1) Tony Hain sent several detailed comments, one of which generated a strong debate, i.e. his objection to a part of section 3.1.2 that stated that "a site MUST be able to distribute ... outbound traffic between multiple transit providers," arguing that this was a site policy matter. I personally don't agree with Tony, and believe the solution must enable the site to balance traffic, and must also enable the site to not do so if it chooses.

2) I pointed out that different classes of solutions have different scaling properties, which implies that the solution for multi-homing my home network to cable and DSL may not be the same as the solution for multi-homing Microsoft's network. Don't know whether that should be part of the requirement document.

3) The discussion on renumbering and EID pointed out the need to add a requirement that "the solution shall not depend on instant updating of the domain name system", or if you prefer that "the solution should be compatible with the observed dynamics of the current DNS system."

4) Naïve implementations of EID and MIPv6 tend to introduce a dependency on a name server or a home agent, i.e. another point of failure. If people want to pursue this path, we should make sure they do it the smart way, i.e. do not introduce a dependency on another system beside the site-exit router and the multiple providers. That may be worth spelling out in a requirement.

Do you agree that this is a fair summary of the discussion on the requirements draft? I yes, we should maybe have a short editing pass, and then proceed towards publication of the requirements and rechartering of this group.

-- Christian Huitema