Erik / ipv6 folk, > Erik Nordmark wrote: > RFC 2374 contained an IPv6 allocation structure that > included TLA (Top Level Aggregator) and NLA (Next > Level Aggregator) which is formally made historic by > this document. > The TLA/NLA scheme has been replaced by an coordinated > allocation policy defined by the Regional Internet > Registries [REF]. Part of the motivations for obsoleting > the TLA/NLA structure were technical, for instance there > was concerns that it was not the technically best > approach at this point in time on IPv6 deployment. > Another part of the motivation was that the issues of > how the IPv6 address space is managed is much more > related to policy and to the the stewardship of the IP > address space and routing table size that the RIRs have > been managing for IPv4. It is likely that the RIRs > policy will evolve as IPv6 deployment proceeds. > The IETF has provided technical input to the RIRs (for > example [RFC 3177]) that has been taken into account > when defining the policy.
I was re-reading your text, and I have additional comments. [disclaimer: I have stated before that it was fine by me, and this still holds. If consensus is reached on the text you proposed the doc should be shipped without further delays.] That being said, I have contradictory / ambiguous feelings about the omission of "SLA". Here's the contradiction: - On one side, since you explicitly kill TLA and NLA but not SLA, it is permitted to think that SLA is not completely dead, which suits me fine since my position is that although moving it to policy was a good idea, killing the notion of site boundary was not. - On the other side, if SLA is not dead it's not alive either, which makes it a zombie I guess. This is not good, and one of these nights, when the moon is full, it will rise from the grave like in Michael Jackson's "thriller" and come haunt us. Therefore, we have three options for SLA: 1. Don't change the text and keep it a zombie. 2. Kill it (which I don't like). 3. Spare it; the idea being that what we want to do is move it to policy but don't kill the notion that a site boundary exists. This is what RIRs call a "soft" or "semi-hard" boundary. Comments welcome. Michel. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
