At 01:22 AM 2/20/2004, Alain Durand wrote:
Dears ADs,
Since the appeal process starts with the working group chairs, we are responding as such.
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:
Before forwarding the document to the IESG we reviewed the discussion of all issues raised during the w.g. last call and concluded that the current draft resolved issues where there was a consensus to make changes. There were many significant changes (e.g., removing the requirement to charge for the central allocations, etc.). We did not see that there was any consensus to make the changes you requested.
- 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.
We believe that the current draft is very clear that it is not imposing a business model. It clearly states a set of requirements for how these
prefixes should be allocated. Earlier versions of the draft may have had that issue, but based on comments received during the working group
last call, this text was changed. In addition there were a number of
comments from Geoff Huston on the business model issue that led to
changes in earlier versions of the draft.
We do not agree that permanent address allocations as called for in this
draft is the same as selling address space. We also note that there are
other types of IPv6 addresses that are allocated in similar manner. This includes link-local addresses, site-local addresses (currently
being deprecated), multicast addresses, and NSAP addresses. There are
similar blocks of addresses in IPv4.
The Unique Local Addresses defined in the draft meet a clearly defined need that has been discussed at great length in the working group. The
permanency of these addresses is an important part of the requirements. They are by definition different from how other global IPv6 unicast
addresses are allocated and managed. This is why they were defined
in the first place.
- 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.
When you raised this issue on the mailing list the subsequent discussion
indicated that the document was very clear on what was required (i.e., what MUST be done as you quote above) and that there wasn't any reason
to provide a list of exceptions to this. Quoting from Christian
Huitema's email dated Wed, 28 Jan 2004:
"The draft already says that we MUST assign these numbers exactly one
way. Why on earth would we need to enumerate the 25 ways that should
not be used?"You logic seems to be that we are reinventing site-local addresses because we only describe what someone MUST do and do not describe how to
turn this back into site-local addresses. We believe your suggestion would have the opposite effect from what you desire. Also, if someone
wants to use site-locals, they can just ignore the deprecation document and keep using them. Why would they need to bother to use this prefix.
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.
For the reasons stated above, we do not agree that our action was incorrect and deny your appeal.
Regards, Brian Haberman and Bob Hinden IPv6 Working Group Chairs
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
