Thomas / Brian / Bob, >> Michel Py wrote: >> 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.
> Thomas Narten wrote: > 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. There is some truth to this, although this document was not the concern but draft-ietf-ipngwg-addr-arch-v3-11.txt going forward. It is even more urgent that we obsolete RFC2373 than 2374. Per some traffic on a RIPE list today, some people are still stuck with EUI-64 in their mind, this is not good. Since I don't recall this being discussed before, I made (possibly wrongly) the default assumption that the author's intentions were to do a pair of documents in the standard tracks that would be a one-for-one replacement of 2373/2374. To the extent that I could try to second-guess Pekka, I think that I am not the only one. Someone please debunk me if needed, but I have in the back of my mind that if addr-arch has not been published yet is because it's waiting for this document to ship. Hence the "importance". >> Michel Py wrote: >> 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. > Thomas Narten wrote: > 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. I am not proposing that we change this. All that I was trying to say is that I would have wished to give more importance to 3177, but if the consensus is that we have declared victory once and for all, so be it whether I like it or not. I have done my job reminding the list that although RFC3177 is policy, it still has some strong ties to architecture. I think that what I'm not happy about is that as an afterthought I would have preferred 3177 to be BCP. > 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, I would agree that it is wrong to push that boundary back into architecture, but I think we went one step too far from having it in the architecture to the point that we say "we don't know, we don't care and we don't even want to hear about it." > as there is no technical implication on implementations. There might be a need later. In MHAP, I have a hard /48 boundary for optimization purposes. I needs to be debated whether or not it's a good idea in that context, but I think that we should not totally close the door to going back to a thinking that might be a little harder on the boundary. > (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.) I agree for the basic IPv6 stack, but again there could be some future spin-offs. > 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. Mmmm. I still think that what Bob did trying to sneak in the documentation prefix was a good idea, since he also pulled it at the first sign of trouble. > Brian Carpenter wrote: > If the draft attempted to make a normative reference to 3177, > it would be a blunder. > .... > 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. Reluctantly settles for a footnote. > Bob Hinden wrote: > While I don't feel too strongly about that status of the document, > I share the belief that is important to send a "strong" message. > Perhaps classifying it as a BCP might be a good middle ground. I'm with Bob and Brian on the "strong" signal, a BCP would be a good way to reach consensus. 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] --------------------------------------------------------------------
