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
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
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
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
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
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