"Michel Py" <[EMAIL PROTECTED]> writes: > > 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. Background: 3177 is a recommendation and represents current thinking. It is not an architectural statement. The /48 boundary is 100% policy. The RIRs have taken that input, and have largely accepted it. This is reflected in the current IPv6 allocation policies, which have been adopted by APNIC, ARIN and RIPE. E.g., see: http://www.arin.net/policy/ipv6_policy.html. IMO, we should declare victory and stop worrying about this. There is no need to for the IETF to make further statements about the /48 boundary at this time. I would also argue that it is wrong to try to push that boundary into an architecture or standards track document, as there is no technical implication on implementations. (Indeed, rather the opposite -- we take great steps to ensure that no implementation will incorrectly assume such a boundary exists and hard code it into the implementation.) > 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. I disagree. Per above, this is not architecture, it is policy. > 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. Per above, this is not part of the architecture. This is policy (and good policy, IMO). I do not think it is appropriate to hard wire this into our specifications. > > 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. Yes. Obsoleting 2374 is (from what I can tell) the point of this document. IMO, putting more into the document than needed to achieve just this is a distraction. > 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. The above could be read to suggest that this document is so important that no changes are appropriate at this point. I have hard time with that, given that we've needed this document for something like 2+ years, and it has been a mere 10 days since the -00 version appeared. One can get documents done quickly, so long as there is rapid discussion, iteration and convergence. Let me suggest we try this first. There is a time to surpress the urge for changes in a document, but it seems a little early to be there for this one. > 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. I see no need to tie this document with the already approved 2374bis. If a merge is needed, we can do that later. Thomas -------------------------------------------------------------------- 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] --------------------------------------------------------------------
