Date: Wed, 14 Aug 2002 09:16:47 -0700 From: "Michel Py" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]>
| I might not have been clear, but the reason I support keeping the 'u' | bit is *not* because I want to use it as an excuse to keep the /64 | boundary, but because it makes little sense removing it as long as the | /64 boundary is there. You were clear enough, I understood that. Maybe I wasn't clear enough that the 'u' but is the worst part of the draft. It (or the part of it which pretends to be visible externally) is the thing which most needs to be deleted. I don't just want it gone in order that the 64 bit boundary can go, I want it gone because it is unimplementable nonsense, which doesn't belong in the doc. It just happens that after this goes, the sole motivation for keeping fixed /64 also goes, so it may as well be removed at the same time. | It appears to me that you are trying to modify the Addressing | Architecture doc in order to allow very minor optimizations. Forget the optimisations. What I want is for it to actually describe the addressing architecture. And not something which someone believes it would be nice if it was like, but without any reasoning. I think it was Thomas who said that we don't have to adjust our docs to allow for other people ignoring them, and doing broken things. And that's certainly right. An example was the "just send 8" SMTP argument, lots of people did that, and argued for adopting it - but it is easy to show how that is technically wrong. On the other hand, if lots of people are doing things one way, and there's no technical argument to show that it should be done a different way, then it really starts to look as if the only reason for not changing is stubbornness. | In weighing the pros and cons of removing the /64 hard boundary, my | opinion is that the savings that it would bring are not significant | enough compared to the potential operational annoyances. Name one operational annoyance? That is one that my use of /112 (or someone else's use of /126 or /127) inflicts upon you, assuming that you're not the other end of the link (if you are, it is your choice to participate, no-one is compelling you to use > /64). Just one. kre -------------------------------------------------------------------- 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] --------------------------------------------------------------------