Thanks Mark for stating that.
It would really be helpful if this type of text is included in the
description/charter.
The lack of of this information in the recently distributed material caused
several immediate allergic reactions...
regards, kiwin
On 6/30/2011 2:57 AM, Mark Townsley wrote:
I think the consensus we had in the past BoFs and discussion in and around this
topic can be summed up as stating that homenet deliverables will:
- coexist with (existing) IPv4 protocols, devices, applications, etc.
- operate in a (future) IPv6-only home network in the absence of IPv4
- be IP-agnostic whenever possible
In other words, anything we do for the IPv6 homenet cannot actively break
what's already running on IPv4. Also, trying to define what the IPv4 home
network should be has long reached a point of diminishing returns given the
effort in doing so coupled with our ability to significantly affect what's
already deployed. There's still hope we can help direct IPv6, as such that is
homenet's primary focus. However, when we can define something that is needed
for IPv6 in a way that is also useful for IPv4 without making significant
concessions, we should go ahead and do so.
- Mark
On Jun 30, 2011, at 9:25 AM, Mikael Abrahamsson wrote:
On Thu, 30 Jun 2011, Fernando Gont wrote:
My point was that, except for the mechanism for PD, I don't see a substantial
difference here that would e.g. prevent this from being developed for IPv4 (in
addition to IPv6). -- Yes, I know we need to deploy IPv6... but I don't think
you can expect people to get rid of their *working* IPv4 devices... (i.e., not
sure why any of this functionality should be v6-only)
Chaining NAT boxes already work. I also feel that we shouldn't put in a lot of
work to develop IPv4 further, that focus should be put on IPv6.
I think this deserves a problem statement that clearly describes what we expect
to be able to do (but currently can't), etc. And, if this is meant to be
v6-only, state why v4 is excluded -- unless we're happy to have people connect
their IPv4-devices, and see that they cannot communicate anymore.
IPv4 should be excluded because it's a dead end, and we all know it. We're just
disagreeing when it's going to die and how.
--
Mikael Abrahamsson email: swmike(_at_)swm(_dot_)pp(_dot_)se
_______________________________________________
homegate mailing list
homegate(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/homegate
_______________________________________________
homegate mailing list
homegate(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/homegate
--
Stephen [kiwin] Palm Ph.D. E:
palm(_at_)kiwin(_dot_)com
Senior Technical Director T: +1-949-926-PALM
Broadcom Broadband Communications Group F: +1-949-926-7256
Irvine, California W: http://www.kiwin.com
Secondary email accounts: stephenpalm(_at_)alumni(_dot_)uci(_dot_)edu
palm(_at_)broadcom(_dot_)com
s(_dot_)palm(_at_)ieee(_dot_)org palm(_at_)itu(_dot_)ch
spalm(_at_)cs(_dot_)cmu(_dot_)edu
palm(_at_)ics(_dot_)t(_dot_)u-tokyo(_dot_)ac(_dot_)jp
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf