I agree with Michel. Although Thomas is logically correct, I think that including section 2.0 and putting this on standards track is a necessary signal to ensure that TLAs are really understood to be dead.
I also think the explicit reference to 2000::/3 is useful. It's the only space currently being allocated. Brian Michel Py wrote: > > Thomas / Bob / Heikki, > > > Thomas Narten wrote: > > [the introduction] > > As the above doesn't really have a lot of detail, some more > > explanation would be good. > > Mumble. I have not said anything before not to delay the process, but > since it appears we're not going to have a no-brainer anyway, indeed > some more explanation would be good. > > > For example, I still see people occasionally make statements > > about how IPv6 address allocation will enforce some sort of > > strict heirarchy (this comes from reading 2374, which this > > one is obsoleting). Explicitly explaining why that thinking > > is no longer in vogue would seem useful. > > As detailed below, a distinction must be made between the TLA/SLA > situation on one side and the SLA on another. > > > If Section 2.0 is removed, there is nothing in the document that > > needs to be on standards track. > > I strongly disagree on this point and I think there is: some text and a > reference to RFC3177, and there's nothing in addr-arch-v3-11.txt. > > Rationale: We moved three hard boundaries from architecture to policy, > the TLA, NLA and SLA. It was clear that the multi-tiered structure of > service providers was a matter of allocation and not of architecture, so > the TLAs became LIRs, the way they allocate space to lower tiers is none > of the IETF's business and all the RIR's. > > This reasoning is not valid for the SLA boundary though, because > although we removed the notion, the block of addresses assigned to an > organization will still define the site boundary in most situations. The > site boundary has deep consequences on architecture and scope. > > Indeed, TLAs and SLAs are gone and this is the RIR's business that we > don't want to deal with. However, while the SLA is gone, the site > boundary remains and this still is our business by the RIR's reading: > > > [ripe-267: http://www.ripe.net/ripe/docs/ipv6policy.html] > > 5.4. Assignment > > LIRs must make IPv6 assignments in accordance with the > > following provisions. > > 5.4.1. Assignment address space size Assignments are to be made in > > accordance with the existing guidelines [RFC3177, RIRs-on-48], > > which are summarized here as: > > /48 in the general case, except for very large subscribers > > /64 when it is known that one and only one subnet is needed by design > > /128 when it is absolutely known that one and only one device is > > connecting. > > In short: the bottom line is that the site boundary is now defined by > RFC3177, which is what the RIRs call a semi-hard boundary. Given the > intricate relations with architecture and scope, I don't see how a > reference to it could be left out of the standards track. > > > Indeed, given that none of section 2 is new, it all restates > > stuff on addr-arch, I don't think even this document should go > > on standards track. Having this document be info, and obsoleting > > 2473 would work just fine process wise. > > > Heikki Vatiainen wrote: > > If RFC 2374 will become historic, should draft-ietf-ipngwg-addr- > > arch-v3-11.txt be revised a bit so that it no longer refers to > > RFC 2374? Or is it already too late? > > On paper, it's not a bad idea, but we would need to recall addr-arch to > do that, go over last call again. We might have to revisit the /64 hard > boundary, the "u" bit and the site-local thing again (for the, what? 6th > time?) and possibly have to deal with more appeals. It is urgent to > obsolete 2374. > > Thomas, I can't argue with any of your other points, but you might want > to include the need to wrap this up soon in the equation. I have not > contributed what is in this message before because I did not want to > delay the process, and that stuff still can wait, IMHO. > > For the sake of having RFCs reasonably in sync with reality, can't we > ship two documents on the standards track now and obsolete both of them > in the next iteration of addr-arch that would be a single doc? The > architecture will continue to evolve, but we need to set a milestone > from time to time. > > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
