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] --------------------------------------------------------------------
