Thomas Narten wrote: > > "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.
It's a very light reference to 3177. I think it's useful to make the point that the RIR policy and the IAB/IESG recommendation are consistent. It's a footnote though. > > 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.) Agreed, and the draft doesn't do that. > > > 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. I agree with Thomas, but the draft doesn't go there anyway. > > > 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. Correct. If the draft attempted to make a normative referennce to 3177, it would be a blunder. But it doesn't. > > > > 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. I really don't find that the text you are objecting to is a distraction. I think it makes the draft more comprehensible. But it's a judgement call, so I'd like some other people to comment. > > > 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. I assume you mean 2373bis. I don't see why a merge would be needed. We do need to delete the reference to 2374 in 2373bis, but that's editorial. Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
