Alain, The current document does not enforce a business model (earlier versions did), but does set technical constraints. Personally I don't think it is possible to 'Provide mechanisms that prevent hoarding', so the requirement 'without any procedure for de-allocation' creates a problem once hoarding has been detected. I do not object to the current document as this specific issue will be resolved by an update once the system is in operation and practical experience exposes that flaw.
Recommending against all-zero's is not only a waste of time, it specifically directs people to the thing you are trying to avoid. There is nothing that a document can do to prevent a consultant from configuring all of his customers with the same prefix. He can run [RANDOM] once and use that everywhere, yet is in full compliance with the document. Even more of a problem, an equipment manufacturer could run [RANDOM] once and burn that value into every piece of equipment they ship. The best a document can do is highlight the issues raised by duplicate assignments, and provide a mechanism which solves them if used as directed. As much as some people want to, it is not the IETF's job to legislate operational behavior. The language in this document is appropriate and it should be published. Tony BTW: why wasn't draft-hain-templin-ipv6-localcomm-04.txt sent at the same time as the unique address & deprecation drafts? They are all dealing with the same issue. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alain > Durand > Sent: Friday, February 20, 2004 1:22 AM > To: Brian Haberman; Bob Hinden > Cc: The IESG; Margaret Wasserman; IPv6 Mailing List; Alain Durand; Thomas > Narten > Subject: Re: Request To Advance : "Unique Local IPv6 Unicast Addresses" > > Dears ADs, > > I found it very unfortunate that the chair decided to request to > advance this document > without answering two major issues I raised during the last call: > > - Permanent allocation is equivalent of selling address space, which is > very different from > the notion of stewardship that are now in place for any IP address > allocation today. > There are a number of legal questions not answered around this point. > More, this is imposing a business model to the entity that will be in > charge of the allocations, > and I believe that the IETF should refrain from imposing business > model. > > - The document does not contain any wording recommending against the > 'all zero' self allocation. > It merely say that: > "Locally assigned global IDs MUST be generated with a pseudo-random > algorithm consistent with [RANDOM].". However, it should be noted > that [RANDOM] > or RFC1750 does not contain any mandate, just provide ideas on how > to do things. > An 'all zero' self allocation would create the prefix FD00::/48 and > will be very tempting > to use by many. > This working group just spend more than a year to deprecate the site > local > fec0::/10 prefixes, just to reinvent it here. > > As the request to advance this document came from the Ipv6 wg chairs, > representing the wg, > it is my opinion that the IPv6 Working Groug has made an incorrect > technical choice which > places the quality and/or integrity of the Working Group's product(s) > in significant > jeopardy. > > As the request to advance this document has already been sent to you, > ADs, > this is my appeal to you to reject it and send it back to the working > group. > > - Alain. > > > > > > On Feb 18, 2004, at 5:22 PM, Brian Haberman wrote: > > > Margaret & Thomas, > > On behalf of the IPv6 working group, the chairs request the > > advancement of: > > > > Title : Unique Local IPv6 Unicast Addresses > > Author(s) : R. Hinden, B. Haberman > > Filename : draft-ietf-ipv6-unique-local-addr-03.txt > > Pages : 16 > > Date : 2004-2-13 > > > > as a Proposed Standard. The -02 version completed working group last > > call on 02/02/2004. This version addresses issues raised during the > > last call period. > > > > Regards, > > Brian & Bob > > IPv6 WG co-chairs > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [EMAIL PROTECTED] > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
