Keith,
I certainly agree that it's challenging to attack the generalized version. However, if you try to solve each version of this problem separately, the result will be even more complex, less workable, and less realistic than if you try to look at it from a broader view. There's a strong potential for those different solutions to collide with one another.
Indeed. And I want to remind everyone that this charter is only about _problem definition_ and _documentation of existing solutions_, not about development of new solutions. The scope at this stage needs to be large, even if we later find out that we need to or can develop a specific extension of, say, DHCP. At that point the group can focus on a narrow aspect, or perhaps even be moved to existing WGs. But we are not in that stage yet.
Or to put it another way, if you define a solution to a narrow version of the problem, it might not actually solve anything in the real world, and the WG's work will have been wasted. And from the POV of the application, or the transport layer, it really doesn't matter much _why_ the host (or peer) has multiple addresses - it still has to deal with them. As for whether "attacking this in full generality is well beyond what we can manage": Based on previous work that I have done in this area, I suspect that this is exactly the case. Which is why I think that it should be reasonable for the WG to look at the problem and come back and say "we haven't identified a good solution to this problem, and the best practices that we can recommend are to minimize the cases where a host or app has to deal with multiple addresses for itself or its peers". Of course, a better result would be for the WG to say "we recommend that the use of multiple addresses per host be limited to these specific cases, and avoided in other cases"... along with specific recommendations for networks, stacks, APIs, applications, etc. I think that this kind of output would be the most useful that the WG could produce. But it won't be able to produce a reasonable output if it looks at the problem through a narrow aperture.
Yes.
(Maybe this should really be in IRTF?)
I think the proposed scope fits very nicely to IETF: we are documenting what the problem is and what various real-world implementations have done about it.
(If we later decide that the real-world techniques are lacking and want to develop a magical solution that solves this problem in all situations, then it is probably a good idea to start a research project... but we are not there yet.)
Jari _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf