RE: How long much advanced notice do ISPs need to deploy IPv6?
When the Internet changed from IPv4 to IPv6 how many days advance notice was needed?
The question is irrelevant, IMHO. And it is irrelevant because the presumption is that the adoption of IPv6 implies displacement of IPv4 in something amounting to a flag day. That's clearly not the case, there is no requirement for it. Displacement over time, perhaps. So, since there won't be a flag day, what does it matter other than being watercooler discussion and trolling? :) Thanks, Christian ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers." 117
Christian Kuhtz wrote:
So, since there won't be a flag day, ...
Maybe that's the point. The notion of Internet flag days has largely disappeared as the Internet's ubiquity and criticality have increased. There won't be flag days for IPv6, S(o)BGP, BGP-5, etc. So what's a company like Verisign to do when they want to substantially change the way the COM and NET zones work? (And is the answer different if they want to make these changes solely for their own financial gain?) If an incremental rollout isn't possible here, then folks end up in the fairly rare position of trying to figure out how to roll out a significant change that will affect the entire Internet at what will essentially be the flip of a switch. Clearly, "pulling a Verisign" and doing it without notifying anybody beforehand isn't the right way. But this alone doesn't make it much easier to decide what *is* the right way. -Terry
On Wed, Oct 22, 2003 at 12:16:08PM -0400, Terry Baranski wrote:
Christian Kuhtz wrote:
So, since there won't be a flag day, ...
Maybe that's the point. The notion of Internet flag days has largely disappeared as the Internet's ubiquity and criticality have increased. There won't be flag days for IPv6, S(o)BGP, BGP-5, etc.
This is why some providers (like Verio for example) have opted for the dual-stack v4, v6 approach. I expect to see a number of other providers move this path as well. There seems to be a lot of movement in the direction of everyone dumping their voice traffic on their internet backbones. I seem to recall seeing Sprint, Telus and other "traditional" telephony providers moving towards what some people call a "converged network". Transporting their voice traffic within IP or MPLS (using stuff like the juniper ccc and cisco equivalents). It's interesting to see the increased reliance on the internet as a network that can survive significant catastrophic events and still provide reliable communications (eg: sept 11, northeast-north-american power outage) for a large set of people. The success of people like Vonage and others in transporting services across the global IP backbones/networks clearly shows that the reliability of the network is sufficent for them to build a business case around it. When something new comes along (eg: bgp-5) there will always be that backward compatability until the edge networks upgrade. What used to be a few years lag for them to upgrade is now increasing as we've clearly seen happen in the software market (both for pc and routers.. how many people are still running win95 or ios 11.1 on their older, perfectly "good" hardware?) - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
The "RIGHT" way, absent a clear and compelling need to do it is DON'T. I will now clarify... In order to make such a change, the following criteria should be required prior to consideration: 1. There must be a clear and compelling reason for the change. Verisign's financial gain isn't a clear and compelling reason for the entire internet. Providing better directory assistance an innovative features might be, but... 2. There must be no alternative method for implementing the "clear and compelling" capability or service which could be implemented without such radical or abrupt change. 3. It must not pose any significant or demonstrable risk to existing infrastructure. If it meets these criteria, then, it should be proposed to the appropriate body and be discussed in the community. If there is general community support for moving forward, the community should be involved in developing the implementation schedule and details. During this process any further issues with cooperation or interoperation with existing services should be identified, discussed, tested, and mitigations developed where appropriate. In any case where the communty does not feel adequate mitigation exists, the proposal should be postponed until such time as these issues are resolved. Verisign's proposal might marginally meet 1. It definitely doesn't meet 2, and, it certainly doesn't meet 3. As such, we should simply not do it. Owen --On Wednesday, October 22, 2003 12:16:08 PM -0400 Terry Baranski <tbaranski@mail.com> wrote:
Christian Kuhtz wrote:
So, since there won't be a flag day, ...
Maybe that's the point. The notion of Internet flag days has largely disappeared as the Internet's ubiquity and criticality have increased. There won't be flag days for IPv6, S(o)BGP, BGP-5, etc.
So what's a company like Verisign to do when they want to substantially change the way the COM and NET zones work? (And is the answer different if they want to make these changes solely for their own financial gain?) If an incremental rollout isn't possible here, then folks end up in the fairly rare position of trying to figure out how to roll out a significant change that will affect the entire Internet at what will essentially be the flip of a switch. Clearly, "pulling a Verisign" and doing it without notifying anybody beforehand isn't the right way. But this alone doesn't make it much easier to decide what *is* the right way.
-Terry
At 12:26 PM 10/22/2003, Owen DeLong wrote:
The "RIGHT" way, absent a clear and compelling need to do it is DON'T.
I will now clarify...
In order to make such a change, the following criteria should be required prior to consideration:
1. There must be a clear and compelling reason for the change. Verisign's financial gain isn't a clear and compelling reason for the entire internet. Providing better directory assistance an innovative features might be, but...
Yes, but one point to consider on this: What happens to the wildcard in the event that the Registry is given to another party to manage when/if the current Verisign contract is terminated? Will the wildcard be left in place pointing to sitefinder? Will the new registry create another version of sitefinder? Will the users who have become used to seeing sitefinder now have to revert to seeing "Host Not Found" messages again?
2. There must be no alternative method for implementing the "clear and compelling" capability or service which could be implemented without such radical or abrupt change.
As was asked during the meeting, if the intent is to serve misdirected HTTP clients, why not simply create a browswer plug-in? This would perpetuate beyond a registry transfer, and work in all TLDs, not just the ones that Verisign happens to operate the registry for. -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless! \ Director, Engineering | @ @ | \ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\------------------------------------------------------ \ Wholesale Internet Services - http://www.megapop.net
--On Wednesday, October 22, 2003 12:49:39 PM -0500 Chris Parker <cparker@starnetusa.net> wrote:
At 12:26 PM 10/22/2003, Owen DeLong wrote:
The "RIGHT" way, absent a clear and compelling need to do it is DON'T.
I will now clarify...
In order to make such a change, the following criteria should be required prior to consideration:
1. There must be a clear and compelling reason for the change. Verisign's financial gain isn't a clear and compelling reason for the entire internet. Providing better directory assistance an innovative features might be, but...
Yes, but one point to consider on this: What happens to the wildcard in the event that the Registry is given to another party to manage when/if the current Verisign contract is terminated?
These are points specific to sitefinder which I believe either A: Further point to the lack of clear and compelling, or, B: should be considered after deciding whether such a change _SHOULD_ even be considered. I was proposing generic criteria by which it could be determined whether ANY such change should be made on the internet, not just DNS wildcards or sitefinder.
Will the wildcard be left in place pointing to sitefinder? Will the new registry create another version of sitefinder? Will the users who have become used to seeing sitefinder now have to revert to seeing "Host Not Found" messages again?
These are operational issues to be addressed in the subsequent implementation plan I discussed below.
2. There must be no alternative method for implementing the "clear and compelling" capability or service which could be implemented without such radical or abrupt change.
As was asked during the meeting, if the intent is to serve misdirected HTTP clients, why not simply create a browswer plug-in? This would perpetuate beyond a registry transfer, and work in all TLDs, not just the ones that Verisign happens to operate the registry for.
Right. This is why I don't believe that Sitefinder meets this generic test and SHOULD NOT be considered for implementation. The rest of my message said that sitefinder definitely did not meet test 2, or did you not read that far? Owen
participants (5)
-
Chris Parker -
Jared Mauch -
Kuhtz, Christian -
Owen DeLong -
Terry Baranski