On 6/10/15, 2:32 AM, "Lorenzo Colitti" <lore...@colitti.com> wrote:
>I'd be happy to work with people on an Internet draft or other >standard to define a minimum value for N, but I fear that it may not >possible to gain consensus on that. WG] No, I think that the document you need to write is the one that explains why a mobile device needs multiple addresses, and make some suggestions about the best way to support that. Your earlier response detailing those vs how they do it in IPv4 today was the first a lot of us have heard of that, because we're not in mobile device development and don't necessarily understand the secret sauce involved. This is especially true for your mention of things like WiFi calling, and all of the other things that aren't tethering or 464xlat, since neither of those are as universally agreed-upon as "must have" on things like enterprise networks. I'm sure there are also use cases we haven't thought of yet, so I'm not trying to turn this into a debate about which use cases are valid, just observing that you might get more traction with the others. >Asking for more addresses when the user tries to enable features such as >tethering, waiting for the network to reply, and disabling the features if >the network does not provide the necessary addresses does not seem like it >would provide a good user experience. WG] Nor does not having IPv6 at all, and being stuck behind multiple layers of NAT, but for some reason you seem ok with that, which confuses me greatly. The amount of collective time wasted arguing this is likely more than enough to come up with cool ways to optimize the ask/wait/enable function so that it doesn't translate to a bad user experience, and few things on a mobile device are instantaneous anyway, so let's stop acting like it's an unsolvable problem. Thanks, Wes Anything below this line has been added by my company’s mail server, I have no control over it. ---------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
