There are some historic 'lessons learned' included here, but the real issue is meeting the expectations of the network managers who are currently using IPv4 logic. That is not to say we don't want them to change, but we can't assume they will even be willing to consider something that has a radically different architecture.
I think we differ on what "radical" is. Besides, the architectural change is there in IPv6 today- you count networks not hosts. This is merely a matter of taking advantage of it, right?
You appear to assume that it is possible or desirable to expose the internal use of previous allocations, to show that some derivative of the HD ratio has been met to justify more space.
No, I certainly don't think it's desirable. Indeed what I'm saying is that auditors already need to know the financial state of affairs within a company, and they are already sworn to secrecy. This same mechanism could be expanded to cover the total allocation required. It's not that hard for a NOC to document, and in particular for IPv6 it really is a very simple counting exercise. The justification is MUCH simpler for IPv6 than it is for IPv4.
It also appears you are looking at this
from the perspective of managing allocations internal to the local network. The requirement was targeting the cost of maintaining an external central registry, and specifically at the cost aversion of small organizations, not large ones.
Well, even with the above wording I still don't really understand what registry you're talking about. How does this differ from the in-addr function that a NOC (even a small one) must support? I don't know what you mean by registry (internal or external).
1. "limited range" -- in particular, what is the semantic difference between these and SLs?
From a routing perspective, nothing. SL meets the requirements for manynetwork managers (it just doesn't meet the puritanical expectations of the IETF elite). From the identifier perspective, these are unambiguous.
How so? How about a diff in small words I can understand? As it stands I feel as though we're going to relive history yet again by looking at an obfuscated rehash of what we just rejected. No, I will not regurgitate the entire argument against SLs (y'all can thank me now).
Eliot
-------------------------------------------------------------------- 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] --------------------------------------------------------------------
