--On Wednesday, 07 March, 2007 08:07 -0800 "Hallam-Baker,
Phillip" <pbaker(_at_)verisign(_dot_)com> wrote:
I agree with John's analysis of the constraints here.
[skipping the conjectures about US politics -- it is a much
longer discussion that isn't clearly suitable for the IETF list]
The ISPs face costs from bots on their nets, so there is a
direct cost benefit. I don't think that the game of charging
to eliminate caps would be viable for devices other than a
cable/dsl modem rented from the ISP. That approach would
introduce a harmful oppositional dynamic with the slashdot
crowd.
I would contend that such extra charges are in place now.
Whether one tries to get around it via public addresses, clever
NAT boxes, dynamic DNS, or otherwise, most of the ISPs in the
low-end market have terms and conditions of service that
prohibit "servers" and many prohibit long-lived connections.
Depending on the ISP, one may or may not be able to ignore those
constraints but, if one wants them removed, it typically
requires a shift from a "residential" to a "commercial" product.
And that shift is typically, modulo some support promises and
the like, essentially "same product, different (contractual)
blocks, higher price".
[ More speculation omitted without either agreeing or
disagreeing]
We agree at the requirements level here: peer to peer video
conferencing must work seamlessly. The difference is that I am
prepared to require the applications to make adjustments to
allow for the deployment of NAT while you appear to be
insisting on a particular means of achieving that requirement.
I am probably more agnostic on that subject than I appear. It
is true that I tend to be pessimistic about changes to deployed
applications that can't be "sold" in terms of clear value. I'm
also negative about changing the architecture to accommodate
short-term problems. As examples of the latter, I've been
resistant to changing (distinguished from adding more features
and capability to) the fundamentals of how email has worked for
30+ years in order to gain short-term advantages against
spammers. And, when I conclude that IPv6 is inevitable (unless
someone comes up with another scheme for global unique addresses
RSN), I get resistant to making architectural-level applications
changes that are justified on the basis of making the IPv4 space
behave better under scarcity. You haven't justified NATs on
that basis so, on a case-by-case evaluation of particular
applications and particular adjustments, we might even agree,
although I'd predict that I'd be more conservative about the
choices than you might be.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf