Please send substantive comments to the ipv6 mailing list, and minor editorial comments to the authors. This last call period will end on 5 November 2003.
I do not believe that this document is ready for Proposed Standard.
My comments (both as suggested text corrections and as more substantive comments on content) are as follows:
Section 3.2 -----------
"The centrally assigned global IDs have a much higher probability that they are unique"
The intent of the central assignment function is to ensure uniqueness. Therefore the wording should be:
"The centrally assigned global IDs are uniquely assigned"
Also:
"It is recommended that sites planning to use Local IPv6 addresses for extensive inter-site communication use a centrally assigned prefix as the possibility of any conflicts is lower."
should be re-worded as:
"It is recommended that sites planning to use Local IPv6 addresses for extensive inter-site communication use a centrally assigned prefix as there is no possibility of prefix assignment conflicts."
Section 3.2.1 -------------
"This to ensure that there is not any relationship between allocations and to help clarify that these prefixes are not intended to be routed globally."
Clumsy grammar and perhaps additional words are appropriate. Suggest change to:
"This to ensure that there is no relationship between allocations and to help clarify that these prefixes are not intended to be routed globally by eliminating aggregation possibilities."
Also:
"This is easiest to accomplish if there is a single source of the assignments."
and
"One time non-refundable allocation fee in the order of 10 Euros (at January 1, 2004 exchange rates) per allocation."
I question the validity of specifying a single source coupled with service fees in a document such as this. This appears to be creating regulatory issues of establishing a global monopoly coupled with price fixing. An alternate wording that may mitigate this to some extent is to change the second sentence to remove this item from requirements, and instead phrase this as a recommendation, namely:
"It is recommended that the registry operate using a service regime of a single service fee per allocation bearing in mind that the service should be accessible and affordable to small sites in all parts of the world."
Also:
"The reason for the one time 10 Euro charge for each prefix is to provide a barrier to any hoarding of the these allocations but at the same time keep the cost low enough to not create a barrier to anyone needing one. The charge is one time to eliminate the need for an ongoing relationship with the allocation authority. The charge is non-refundable in order to keep overhead low."
change to:
"The reason for the per-prefix allocation service fee is to allow the service to operate on a financially sustainable basis. A service fee also creates an externality of a barrier to any hoarding of the these allocations. The fee should be low enough to not create a barrier to anyone needing one. The charge is one time to eliminate the need for an ongoing relationship with the allocation authority. The charge is non- refundable as the allocation is irrevocable."
Also:
"It is escrowed to insure there are no duplicate allocations and in case it is needed in the future (e.g., to resolve duplicate allocation disputes).
add the case of a potential change in allocation registry operator. i.e.
"It is escrowed to insure there are no duplicate allocations and in case it is needed in the future (e.g., to resolve duplicate allocation disputes, or to support a change of central allocation registry operator).
Also:
"This document directs the IANA, in section 13.0, to delegate the FC00::/8 prefix to an allocation authority to allocate centrally assigned /48 prefixes consistent with the requirements defined in this section."
change requirements to requirements and recommendations
"This document directs the IANA, in section 13.0, to delegate the FC00::/8 prefix to an allocation authority to allocate centrally assigned /48 prefixes consistent with the requirements and recommendations listed in this section."
Section 3.3 -----------
"Rather, these prefixes are globally unique, and as such, their applicability exceeds the current site-local addresses."
Should the word "current" be used in this context? Perhaps:
"Rather, these prefixes are globally unique, and as such, their applicability exceeds the previously defined site-local addresses."
Section 7.0 -----------
It may be worth mentioning that DNS systems should be configured to prevent queries relating to such addresses to be passed into the public DNS system.
To quote the AS112 project home page: "Because most answers generated by the Internet's root name server system are negative, and many of those negative answers are in response to PTR queries for RFC1918 and other ambiguous addresses" (http://www.as112.net/)
Section 13.0 ------------
"This allocation authority shall comply with the requirements described in section 3.2 of this document, including in particular the charging of a modest one-time fee, with any profit being used for the public good in connection with the Internet."
It is noted that there are significant problems with this proposed approach to directions to IANA, particularly with the noted concept that this is a for-profit activity and IANA is, in effect, being directed to be in the position of selecting a global monopoly operator. The indeterminate nature of a fair, open and reasonable definition of "the public good" is also a problem in the context of these instructions to IANA. Some of the lessons learned from DNS administration over the past decade would indicate that this is not a sensible directive to pass to IANA, as it is unlikely to be reasonably implemented in this precise form.
Additional Comments --------------------
draft-huston-ipv6-local-use-comments-01.txt contains a number of additional comments that are not addressed in this draft. In particular, section 5 of that draft raises issues concerning
- the structure of an allocation fee being a form of monopoly rental. (a service fee would be more viable from a regulatory perspective) (section 5.1 of the comments draft)
- the recording of allocations (section 5.4 of the comments draft)
- reverse mapping of such addresses in ip6.arpa (section 5.5 of the comments draft)
regards,
Geoff Huston
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
