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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf