Hi Dave.
The current draft charter prompts some basic questions:
Having now read through this thread...
1. What does "This solution should work whether or not the peer site
supports the shim6 protocol" mean in the draft charter and how can
it succeed?
I would assume that it means you can't require everyone else to also
implement shim6 in order to have working communication. I.e., if a
peer doesn't implement shim6, one falls back to standard IPv6, warts
and all.
2. Why is shim6 limited to IPv6? What is it about the problem space
and/or the solution space that is required to exclude IPv4?
I think it is pretty obvious that IPv6 has some aspects that IPv4
doesn't have, and these may make it easier to come up with a solution.
Having said that, I doubt anyone would be so foolish to say if there
is an approach that happens to work for IPv4 too, we're not allowed to
use it. :-)
Another way of looking at it is that if the shim6 work is successful,
we'll know a whole lot more about the problem space and the various
issues involved in coming up with a solution. At that point, doing an
IPv4 solution would presumably be a lot easier (read also: won't take
nearly as long as the shim6 work did), because there is existing work
to leverage. I think it is perfectly fine to delay working on an IPv4
approach (if it turns out to be possible/desirable) until a lot more
of the base work has been done here. At that point, it would make
sense to re-evaluate whether doing an IPv4 effort still makes sense
(whether in this WG or a separate one).
I believe that adding some sort of requirement that we also look at
solving the problem for IPv4 in this WG (at this time) would not
actually help either effort and is likely to be counterproductive.
3. What happens to shim6 if it must operate through a NAT?
This is a good question, but one that I don't think we should get hung
up on in terms of a requirement that shim6 work in the presence of
NATs. What I think the WG should do is (as it's doing its normal work)
is to keep in mind the NAT question and try to avoid breaking NAT as
it develops its protocols. But requiring that things work through a
NAT raises the bar significantly, I suspect, in terms of the
complexity of the solution. I'd prefer making the decision about
whether NATs can be accomodated when we get to the specific
engineering tradeoffs of one approach vs. another and see the
implications of one choice over another.
Adding "works through NATs" as a hard requirement strikes me as
another potential brick in the "add so many conflicting/hard
requirements as to make finding a solution impossible".