My primary concern is and always has been support for sites that "bump into one another" from time to time, which can happen as result of site mobility and/or temporal links between sites (e.g., VPNs, leased lines, range-restricted wireless links, etc.) Also to support sites that are intermittently connected to and/or frequently change provider points of attachment. Site multi-homing is clearly another area of prime concern expressed by others.
As can be seen from the IETF 56 meeting minutes, I stated a position closest to Bob's option B) below and in fact abstained from the balloting when the question was called on the list while stating my reasons for doing so. But, after significant further study, I can see no way in which the current site-local specification satisfies any of the above requirements and can in fact only see trouble down the road if site-locals emerge in wide scale deployment. So, I am now of the opinion that option A) below provides the most workable alternative.
Fred
[EMAIL PROTECTED]
P.S. This is not to say we should stop working on solutions for such "active" sites; only that the solutions should be worked independently of site-local deprectaion.
Bob Hinden wrote:
A) Deprecate Site-Local addresses independently from having an alternative solution available. This would mean that the working group should treat the deprecation, and requirements and solution documents outlined above independently from each other. If there was no consensus on an alternative a replacement would not happen.
B) Deprecate Site-Local addresses at the same time as a alternative solution is agreed to. This would mean advancing both documents at the same time and making them include normative references to each other to insure that they were published at the same time. This would result in the deprecation only happening if a consensus was reached on an alternative.
C) Deprecate Site-Local addresses after an alternative is defined, standardized, and in operational practice. This would mean not advancing a deprecation document until there was operational evidence that the alternative was working and shown to be an improvement over Site-Local addresses.
Note: In the above choices "Deprecate Site-Local addresses" means publishing an RFC that does the formal deprecation.
Please respond to the list with your preference, or if there is an alternative approach that is an improvement from the ones I outlined. I hope that many of you will respond.
Thanks, Bob
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
