Eliot Lear wrote: > Tony Hain wrote: > > 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?
>From the operator perspective, the demand is for address space that is architecturally set aside as private use, locally controlled. That did not initially exist in IPv4, and history shows that people took whatever bit patterns looked interesting. > > > > > > > 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. But auditors are not running the RIR's. Are you inserting an explicit extra cost into the system to have a 3rd party auditor certify the requests to the RIR's? > > 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 > >>many > > network 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). That is because everyone has a different perspective on what their Yes vote meant while the No votes were very clear about why we need something to meet the operational requirements. As routing locators, it is not the IETF's role to tell network managers that they can't limit the domain of applicability where an address is valid for use. As an identifier, the IETF is in a position to say there will be no intentional duplication to cause ambiguity, which would create a domain of applicability for the identifier. Tony > > 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] --------------------------------------------------------------------
