Subject: Fwd: IPv6 Policy Document Review - Call for comments

From: Bob Hinden <[email-masked]>
Date: Thu, 06 Jan 2000 09:47:35 -0800

Not sure everyone has seen this.

Bob

---------------------------------------------

>Date: Wed, 8 Dec 1999 10:48:39 +1000 (EST)
>From: Anne Lord <[email-masked]>
>X-Sender: anne@hadrian
>Reply-To: Anne Lord <[email-masked]>
>To: [email-masked], [email-masked]
>Subject: IPv6 Policy Document Review - Call for comments
>
>
>Dear Bob, Steve,
>
>In collaboration with the other RIRs, APNIC is about to issue
>the following 'Call for Comments' on the: Provisional IPv6
>Assignment and Allocation Policy Document - as this document
>is now scheduled for public review.
>
>The text of the announcement is appended to this email.
>However, in commencing this review, we would specifically welcome
>comments from you, and members of the IPng working group.
>In so doing, please feel free to distribute the text of this email to
>relevant parties.
>
>We look forward to hearing from you.
>
>Best wishes,
>
>
>Anne
>Manager, Member Services
>APNIC--
>
>
>***************************************************************************
>                         CALL FOR COMMENTS
>                         FIRST REVISION OF
>         "PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT"
>***************************************************************************
>
>On 28 May 1999, the three Regional Internet Registries (APNIC, ARIN, and
>RIPE NCC) made available a draft of the "Provisional IPv6 Assignment and
>Allocation Policy Document". Following feedback and review from the
>community, the document was amended and jointly released on 14 July 1999.
>(see http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html).
>
>The policies contained in that document are the result of a collaborative
>effort of the RIRs and their respective communities to provide a
>responsible, globally consistent framework for the management of IPv6
>address space. In July 1999, on the basis of that document, IANA made the
>first formal delegations of IPv6 address space to the RIRs.
>
>A formal review of the document was scheduled to start in October 1999, so
>that early experiences of IPv6 operation and administration could be fully
>evaluated and any necessary amendments made.
>
>APNIC now calls for comments to assist in this first review. We encourage
>you, as a member of the Internet community, to re-visit this document and
>we invite you to make any comments you feel would be constructive to the
>development of the next version.
>
>In particular, APNIC seeks your comments on the following sections of the
>document:
>
>* 4.2.3.2 Multihomed Sites
>
>This section was left unwritten in the first release, as there was
>insufficient experience to draw on in formulating a policy. We encourage
>any members of the community who have operational experience or interest in
>IPv6 and multi-homing to contribute suggestions for this section.
>
>* 4.2.8 Allocations to NLA Registries
>* 4.3.1 Assignments to End-users
>
>Review of these two sections is sought from members of the community who
>have relevant operational experience.
>
>* Definition of 'transit provider'
>
>A definition for the above term was not included in the current document.
>Comments and suggestions for an appropriate definition are encouraged.
>
>Finally, we also encourage you to consider the "IPv6 sub-TLA Request Form"
>  (http://www.apnic.net/apnic-bin/ipv6-subtla-request.pl) and provide any
>comments or suggestions for improvements.
>
>PLEASE SEND COMMENTS BY FRIDAY 21ST JANUARY 2000.
>
>Discussion will take place on the "ipv6-registry" mailing list. To
>subscribe to that list, send an email to <[email-masked]> with the
>words "subscribe ipv6-registry" in the body of the message. If you would
>prefer to make private comments, please contact Anne Lord <[email-masked]>.
>
>+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
>APNIC Secretariat                                 <[email-masked]>
>                                                      Tel: +61-7-3367-0490
>Asia Pacific Network Information Centre (APNIC) Ltd  Fax: +61-7-3367-0482
>Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia
>+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Tue, 25 Jan 2000 16:26:24 -0800

Anne et al,

Here are some comments on the Provisional IPv6 Assignment and Allocation
Policy Document from the co-chairs of the IPng and NGTrans Working Groups.
We very much appreciate your invitation for us to review the document.

Let us first note that we are delighted that the IPv6 address allocation
and assignment process has begun and seems to be functioning smoothly.
The establishment of such a process was a critical requirement for
production deployment of IPv6, and we would like to say thanks to you
and your colleagues in the RIRs for all the work you have done to get
the process up and running.

Let us also point out that these comments are not based on us being
customers of the allocation process -- we hope that those ISPs who have
been allocated IPv6 address space under the existing process will
separately comment on any difficulties they may have encountered or any
suggestions for improvement they might have.  Rather, these comments
are based on our knowledge of the design goals and technical
requirements of IPv6 addressing and our concerns about some potential
negative consequences of the current allocation policy.

Our primary concern with the current document is that it stresses
unnecessary address conservation in a number of places, and in ways
that are contrary to the intent of the protocol design.  Specifically:

    (1) The third paragraph of section 4.3.1, regarding dial-up lines,
	is apparently motivated by a desire to conserve address space.
	Unfortunately, it is ambiguous and contradictory, and depending
	on how it is interpreted, it could impose an unnecessary and
	potentially harmful constraint on IPv6 address allocation to
	customer sites.

	      o It is ambiguous because it seems to equate dial-up
		access with single-user access, while clearly those
		properties are distinct:  a single dial-up line may
		well serve multiple users.  And why is the number of
		users relevant to IP address allocation?  A single user
		with multiple IP devices requires more IP addresses
		than multiple users sharing a single device.

	      o It is contradictory because a dial-up customer (e.g., a
		residential or small-office customer) who has a need to
		create subnets is intended to receive a /48, according
		to the first paragraph of that section, and a longer
		prefix than /48, according to the third paragraph.
		
	      o It is unnecessary because the size of the public
		topology part of the IPv6 address was explicitly chosen
		to be far more than enough to hierarchically assign a
		unique TLA+NLA (i.e., a unique /48) to every enterprise
		and every household in the world, for the foreseeable
		future and beyond, regardless of their type of access
		technology.  We took into consideration the possibility
		that all dial-up users would one day migrate to always-
		on access, and we sized the public topology part of the
		IPv6 address accordingly.  Thus there is no need to
		share a /48 among multiple customers, whether they use
		dial-up access or not.

	      o It is potentially harmful because if ISPs interpret the
		policy to mean they should assign only a single /64 to
		each dial-up customer, given that at least some and
		possibly many dial-up customers will have a need to
		create subnets, we will almost certainly see one or both
		of the following harmful developments:

		      - subdivision of the customer's 64-bit interface
			ID field into a subnet ID field and a smaller
			interface ID field, which would defeat the IPv6
			goals of stateless address autoconfiguration and
			topologically-independent, globally-unique node
			identification that are achieved through the use
			of EUI-64-based interface IDs.

		      - deployment of IPv6 NAT devices to allow the
			customer to have multiple /64 subnets behind
			a single /64 allocation, which would defeat the
			IPv6 goal of having a single, global address
			space for all IPv6 devices.

	Therefore, we recommend that the third paragraph of section 4.3.1
	be deleted from the document, and that it be made clear to the
	RIRs and ISPs that it is perfectly legitimate and desirable that
	every end-user customer, including dial-up and residential
	customers, be assigned a static, unique /48 IPv6 address prefix.

    (2) The last paragraph of section 3.2, regarding address assignment
	to point-to-point links, also seems to be motivated by the desire
	to conserve address space.  The recommendation against ISPs
	assigning global, public addresses to routers' point-to-point
	interfaces is both unnecessary and inappropriate.

	      o It is unnecessary because it would have negligible impact
		on address space consumption if each ISP were to set aside
		one of its allocated NLA values (i.e., one /48), from
		which to assign global /64 prefixes to each of its point-
		to-point links.  The IPv6 address space is, by design, big
		enough to allow all Internet device interfaces, including
		those of ISPs' routers, to have globally-unique, publicly
		visible addresses.

	      o It is inappropriate because it is beyond the RIRs' mandate
		to determine that ISPs' router interfaces "do not require
		public address space".  An ISP might well choose to assign
		global addresses to its point-to-point interfaces, for
		example to permit inter-ISP traceroute to work properly,
		and the RIRs have no business interfering in that
		operational decision.

	Therefore, we recommend that the last paragraph of section 3.2
	be deleted.  (However, the parenthetical comment at the end of
	that paragraph, concerning the validity of all 1s and all 0s
	field values, should be retained somewhere, or be promoted to
	being a paragraph of its own).

    (3) Though the document does not explicitly say so, a number of
	readers have interpreted the description of the slow-start
	mechanism in section 4.2.4 to mean that an ISP will normally
	start with a /35 allocation and then, as its IPv6 customer
	base grows, be required to come back to its RIR for each
	additional bit of address space, i.e., first for the enclosing
	/34, then for the enclosing /33, and so on, up to the sub-TLA
	allocation of /29.  While that might be a reasonable approach
	if we were trying to force the ISPs to achieve maximal density
	of address usage, such aggressive address conservation is
	explicitly not a goal of the IPv6 allocation policy, and if it
	were in fact to be implemented that way, it would impose an
	unnecessary and undesirable burden on ISPs.  For example, while
	an ISP might reasonably do flat routing for its first 6500 NLAs
	(80% of the NLAs in the initial /35), if it expected to enjoy
	any significant further growth, the next sensible step would be
	for it to establish an internal hierarchy for its subsequent NLA
	assignments.  However, obtaining only a single bit of additional
	address space would not allow for any sort of long-term hierarchy
	to be established.  Instead, we suggest that a reasonable
	expectation for any ISP that appears at all likely to grow into a
	full sub-TLA, and eventually a TLA, should be that they go from
	a /35 initial allocation to a /29 full sub-TLA allocation in one
	step.  We do not believe this would be inconsistent with the
	purposes of slow start for IPv6 address allocation, which we
	understand to be:

	      o prevention of flagrant wastage or stockpiling of IPv6
		address space,

	      o arranging that ISPs with significantly fewer customers
		have longer prefixes than others, and

	      o forcing occasions for ISPs to receive guidance from
		their RIRs on acceptable address usage practices.

	Now perhaps our suggested approach is in fact what you have in
	mind -- we note that the document gives considerable (and
	sensible) flexibility for the RIRs to exercise their best
	judgement regarding how much additional space to grant.  If that
	is the intent (and we hope it is), we would prefer that that be
	made much more explicit in the policy document, so that any
	legitimate ISP with serious plans for a large IPv6 deployment
	can know that it will not be subjected to many small "baby-step"
	allocations that would complicate its planning and possibly
	force it to impose otherwise unnecessary renumbering events
	on its earlier customers.

	We also suggest that you consider changing the criteria so
	that existing top-level IPv4 ISPs who already have a large
	installed infrastructure and IPv4 customer base, and who
	presumably require less guidance on prudent address allocation
	practices, be able to obtain a full /29 sub-TLA to start, rather
	than being required to slow start from a /35.  Yes, that creates
	the risk of such an ISP obtaining a lot of IPv6 space and then
	never using it, but (a) the requirement that ISPs report their
	NLA allocations in a public database provides a separate
	mechanism for monitoring usage, and that could be used as input
	to a reclamation decision, should that become necessary, and
	(b) if existing large IPv4 ISPs fail to eventually acquire a
	significant number of IPv6 customers, that will almost certainly
	indicate an overall lack of demand for IPv6 service, in which
	case the issue of IPv6 address stockpiling will have become moot.

    (4) The very few words in the document regarding allocation of TLAs
	("If no further growth is possible within that sub-TLA range,
	the Regional IR may allocate a full TLA.", in section 4.2.5.1),
	when read in the context of the other, unnecessary address
	conservation requirements above, give the impression that the
	RIRs will be very reluctant to allocate actual TLAs.  In
	particular:

	      o Why does it say "...*may* allocate a full TLA", rather
		than "...*will* allocate a full TLA" (or "...*will
		normally* allocate a full TLA", to allow for exceptions)?

	      o What is the criterion for determining that "no further
		growth is possible" with a sub-TLA?  The only reference
		to determining when a piece of address space is "full"
		is in the section on sub-TLA allocation, section 4.2.5,
		in which there is an "at least 80% used" requirement.
		That is a reasonable threshold for determining when
		a flat address space, or a single field of a
		hierarchical address (such as the 13-bit NLA field in
		an initial /35 allocation, handled as a flat space),
		is near capacity, but it is unreasonable and unachievable
		in practice in a hierarchically-structured address space
		(such as the 19-bit NLA space in a full sub-TLA).

	We recommend that the criteria for obtaining a TLA be made more
	explicit, and we suggest that you consider a metric such as the
	"H ratio" defined in RFC 1715, which takes into account the
	significantly reduced density achievable in a hierarchical
	address space.  For example, specifying an H ratio of 0.26,
	which that RFC describes as "optimistic" based on past
	experience with other, similar address spaces, would yield a
	recommendation that an ISP be granted a TLA at the point that
	it has allocated about 87,000 NLA values to end-user customers
	and/or downstream ISPs.  Perhaps you could round that number down
	to 75,000 or up to 100,000 to come up with a simple rule for when
	an ISP could expect to acquire a TLA.

Our remaining comments, both substantive and editorial, are given below,
following quotations of the relevant text:

> ABSTRACT
>
> This document describes the registry system for distributing
> globally unique unicast IPv6 address space.

Append to the end of that sentence: "under format prefix 001, as defined
in RFC 2374", to make it clear that this policy does not necessarily
apply to any future global unicast space that might be created under
other format prefixes.

>                                               IPv6 address
> space is distributed in a hierarchical manner (as is IPv4
> address space), managed by the IANA and further delegated by
> the Regional Internet Registries (Regional IRs) as described
> in RFC 1881. In the case of IPv6, the Regional IRs allocate
> Top-Level Aggregation Identifiers (TLAs) to organizations,
> which, as TLA Registries, in turn allocate or assign address
> space to other Internet Service Providers (ISPs) and end
> users. ISPs then serve as Next Level Aggregation (NLA)
> Registries for their customers.

The use of the terms "TLA Registry" and "NLA Registry" above, and
throughout the document, are inconsistent and often counter-intuitive.
For example, the above paragraph uses:

      - "TLA Registry" to refer to an organization to whom a TLA value
	has been assigned, but

      - "NLA Registry" to refer to an organization that assigns NLA
	values to others.

We suggest that you consistently use:

      - TLA Registry only to refer to those organization that assign
	TLA and sub-TLA values, i.e., IANA, the RIRs, and  subordinate
	registries (like JPNIC), if any.

      - NLA Registry only to refer to those organizations that assign
	NLA values, i.e., ISPs and Exchanges, and their subordinate
	ISPs, if any.

      - SLA Registry only to refer to those organizations that assign
	SLA values, i.e., end-user customers (and ISPs, for their own
	infrastructure).

> 2 IPv6 ADDRESS SPACE AND THE INTERNET REGISTRY SYSTEM
>
> IPv6 unicast addresses are aggregatable with contiguous
> bit-wise masks used to define routable prefixes,...

The reference to "contiguous bit-wise masks" is obsolete and
inapplicable to IPv6.  In IPv6, prefixes are always specified by
length (number of bits), never by mask.

>...using a method similar to that used for IPv4 addresses under CIDR.

The method of aggregation is not just "similar" to that used for IPv4
under CIDR, it is the same.

> Internet. The Internet Registry system exists to ensure that
> IPv6 address space is managed in a globally consistent,
> fair, and responsible manner that minimizes wastage, and
> maximizes aggregation within the routing structure.

The goal is not to *minimize* wastage, nor is it to *maximize*
aggregation.  Rather, the goal is to *limit* wastage, and to achieve
*adequate* aggregation to meet the demands of stable, global routing.

> 2.1 The Internet Registry System Hierarchy
>
> The hierarchical Internet Registry system exists to enable
> the goals described in this document to be met. In the case
> of IPv6, this hierarchy consists of the following levels, as
> seen from the top down: IANA, Regional Internet Registries,
> TLA, NLA Registries, and end-sites.

Following our suggestion above for consistent usage of terms, remove
"TLA," from the last sentence above.  (IANA and the RIRs are the TLA
registries.)  And if you disagree with that, then at least add the word
"Registries" after "TLA", for grammatical consistency.

> 2.1.3 TLA Registries
>
> TLA Registries are established under the authority of the
> appropriate Regional IR to enable "custodianship" of a TLA
> or sub-TLA block of IPv6 addresses.

Following our terminology suggestion, this section would refer to NLA
registries having custodianship over blocks of NLAs (that fall under
specific TLA or sub-TLA values assigned by the RIRs), and the subsequent
(currently empty) section 2.1.4 would be deleted.

We would also like to see this same language about custodianship
applied to the RIRs themselves, so that it is made clear the RIRs are
also custodians, not owners, of the address space (blocks of TLAs and
sub-TLAs) allocated to them by IANA.

> 2.1.5 End-sites
> [to be written]

We assume the points to be made here are that:

	- end-site customers are not granted "ownership" of the
	  address space they are assigned.

	- end-site customers are responsible for assigning SLA IDs
	  (subnet numbers) and interface IDs to their own links and
	  nodes.

> 2.2.1 Uniqueness
>
> Each IPv6 unicast address must be globally unique.

After "unicast address", add the phrase "under format prefix 001",
because the statement above is not true of *all* IPv6 unicast addresses
(particularly site-local, link-local, and loopback unicast addresses).

> This is an absolute requirement for guaranteeing that every host
>on the Internet can be uniquely identified.

Change "host" to "node".  (In IPv6, the term "host" does not include
routers, whereas "node" includes all IPv6 devices, both hosts and
routers.)

> 2.2.2 Aggregation
>
> IPv6 addresses must be distributed in a hierarchical manner,

In several places in the document, the term "distribution" is used,
rather than "allocation" or "assignment".  If "distribution" has a
distinct meaning, or is meant to refer to the union of allocation and
assignment, please include it in the glossary at the end, with an
explanation of its meaning.

> permitting the aggregation of routing information and
> limiting the number of routing entries advertised into the
> Internet. This is necessary to ensure proper operation of
> Internet routing and to maximize the routing system's
> ability to meet the demands of both likely and unforeseeable
> future increases in both size and topological complexity. In
> IPv6, aggregation of external routes is the primary goal.

In that last sentence, change "the primary goal" to "a primary goal".
IPv6 has other primary goals, such as increasing the available address
space.

> This goal is motivated by the problems which arose in IPv4
> network addressing. IPv4 address allocations have not been
> sufficiently hierarchical to ensure efficient routing across
> the Internet. Inefficient use of classful allocations led to
> an excess of routing entries appearing in the default-free
> routing table.

Change "Inefficient use of classful allocations" to "Allocations of
non-hierarchical (classful) prefixes".  It was not the inefficiency of
classful allocation that led to large routing tables, but rather their
lack of sufficient hierarchy.

> Furthermore, increased complexity of network
> topologies led to IPv4 prefixes being announced many times
> via different routes.

The presence of this sentence, in the context of the paragraph in which
it appears, would seem to imply that a goal is to reduce the complexity
of network topologies, which is certainly not a goal of IPv6 addressing
or the allocation policy.

> 2.2.4 Registration
>
> Every assignment and allocation of IPv6 Internet address
> space must be registered in a publicly accessible database.
> This is necessary to ensure uniqueness and to provide
> information for Internet trouble shooting at all levels.

Add a hyphen to "trouble shooting".

> 3.2 Initial IPv6 Addressing Hierarchy
>
> ...
>
> All router interfaces are required to have at least one
> link-local unicast address or site-local address.

As we explained in our earlier comments, we recommend that the paragraph
containing this sentence be deleted.  However, in case you decline to
accept that recommendation, you should know that the above sentence is
not exactly right.  All router (and host) interfaces are required to
have at least one link-local unicast address.  *In addition*, they may
be assigned site-local and/or global unicast addresses.

> 4.1 IPv6 Addresses not to be considered property
>
> All allocations and assignments of IPv6 address space are
> made on the basis that the holder of the address space is
> not to be considered the "owner" of the address space, and
> that all such allocations and assignments always remain
> subject to the current policies and guidelines described in
> this document.

Change "all such allocations and assignments" to "all allocations and
assignments of addresses under format prefix 001".

Perhaps change "in this document" to "in the most recent version of
this document".

>                 Holders of address space may potentially be
> required, at some time in the future, to return their
> address space and renumber their networks in accordance with
> the consensus of the Internet community in ensuring that the
> goals of aggregation and efficiency continue to be met.

Perhaps change "that the goals of aggregation and efficiency be met" to
"that the technically and operationally necessary levels of aggregation
and efficiency be met".

> 4.2.1 General Criteria for Initial Sub-TLA Allocation
>
> Subject to sections 4.2.2, and 4.2.3, Regional IRs will only
> make an initial allocation of sub-TLA address space to
> organizations that meet criterion (a) AND at least one part
> of criterion (b), as follows:
>
>      a. The requesting organization's IPv6 network must
>      have exterior routing protocol peering
>      relationships with the IPv6 networks of at least
>      three other organizations that have a sub-TLA
>      allocated to them.

In criterion (a), change "sub-TLA" to "sub-TLA or TLA".

>
> AND either
>
>      b(i). The requesting organization must have
>      reassigned IPv6 addresses received from its
>      upstream provider or providers to 40 SLA customer
>      sites with routed networks connected by permanent
>      or semi-permanent links.

What's a semi-permanent link?

>
> OR
>
>      b(ii). The requesting organization must
>      demonstrate a clear intent to provide IPv6 service
>      within 12 months after receiving allocated address
>      space. This must be substantiated by such
>      documents as an engineering plan or deployment
>      plan.

So, what sort of organization would satisfy (a) AND b(ii)?  Any ISP
who could satisfy (a) would presumably already be providing IPv6
service, not just planning to do it.

>
> 4.2.2 Criteria for sub-TLA Allocations in Transitional
> "Bootstrap" Phase
>
> ...
>
>      a. The requesting organization's network must have
>      exterior routing protocol peering relationships
>      with at least three other public Autonomous
>      Systems in the default-free zone.

Make it clearer that you are talking about *IPv4* peering arrangements,
in this case.

>
> AND
>
>      b. The requesting organization must show that it
>      plans to provide production IPv6 service within 12
>      months after receiving allocated address space.
>      This must be substantiated by such documents as an
>      engineering plan or a deployment plan.
>
> AND either
>
>      c. The requesting organization must be an IPv4
>      transit provider and must show that it already has
>      issued IPv4 address space to 40 customer sites
>      that can meet the criteria for a /48 IPv6
>      assignment. In this case, the organization must
>      have an up-to-date routing policy registered in
>      one of the databases of the Internet Routing
>      Registry, which the Regional IR may verify by
>      checking the routing table information on one of
>      the public looking glass sites).
>
> OR
>
>      d. The requesting organization must demonstrate
>      that it has experience with IPv6 through active
>      participation in the 6bone project for at least
>      six months, during which time it operated a
>      pseudo-TLA (pTLA) for at least three months. The
>      Regional IRs may require documentation of
>      acceptable 6Bone routing policies and practice
>      from the requesting organization.

We understood that the 6bone pre-qualification process was to be
independent of the other bootstrap criteria, i.e. sufficient on it own.
It seems unlikely that many ISPs meeting criteria (a) would need to
rely on criterion (d), rather than (c).  The 6bone pre-qual was
supposed to allow bootstrapping of IPv6 providers who are *not*
established IPv4 providers, i.e., do not satisfy (a).

> 4.2.3.2 Multihomed Sites
> [to be written]

What needs to be said here is that end-user sites connected to multiple
ISPs are expected to receive an NLA assignment (i.e., a /48) from each
of those ISPs, and therefore, each of such an end-user's nodes may have
multiple, globally-unique addresses.  However, it should also be explicitly
said that nothing in this policy is intended to prevent or discourage a
multi-homed end-user site from negotiating with any number of ISPs
for the service of advertising and routing a /48 prefix obtained from
another ISP.

> 4.2.4 Size for Initial Allocation: "Slow-Start" Mechanism
>
> Regional IRs will adopt a "slow start" mechanism when making
> initial allocations of sub-TLA space to eligible
> organizations. By this mechanism, the initial allocation
> will allow 13 bits worth of NLA IDs to be used by the
> organization unless the requesting organization submits
> documentation to the Regional IR to justify an exception
> based on topological grounds. This initial allocation allows
> the organization to create a hierarchy within the allocation
> depending on their customer type (ISP or end-site) and the
> topology of their own network. For example, an organization
> may receive 8,192 SLAs (a /48 each).

In that last sentence, change "8,192 SLAs" to "8,192 NLAs".

> 4.2.6 Registering and Verifying Usage
>
> Each TLA Registry is responsible for the usage of the
> sub-TLA address space it receives...

Change "sub-TLA" to "sub-TLA or TLA".  (And we would prefer that these
be called NLA registries, because they register NLAs, not TLAs, as
discussed above.)

> Registered end-sites must be connected and reachable.

This is inconsistent with our recommendation that dial-up customers be
able to obtain a /48, just like any other customers, so if our
recommendation is accepted, this section will have to be reconsidered.

>                        ...Filtering holes should be negotiated
> by the Regional IR and the organization holding the
> addresses in question.

Explain what is meant by a "filtering hole".

>...If an end-site requests an additional SLA, the TLA Registry must
>send the request to the Regional IR for a second opinion.

That should be "If an end-site requests an additional *NLA*, the
*NLA* Registry must...".

> 4.2.7 Renumbering
>
> It is possible that circumstances could arise whereby
> sub-TLA address space becomes scarce. This could occur, for
> example, due to inefficient use of assigned address space,
> or to an increase in the number of organizations holding
> both TLA and sub-TLA space.

Change "inefficient" to "very inefficient".

> Regional IRs requiring a TLA Registry to renumber will allow
> that Registry at least 12 months to return the sub-TLA
> space. [Note that the granted renumbering time may depend on
> the prefix length returned. The draft document
> http://search.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-08.txt
> describes the issues involved in and methods used for
> renumbering IPv6 networks.]

Just for your information, the IPng working group has an effort underway
to produce a new document describing the renumbering process for a site,
which will be more appropriate to cite here, once it has been published.

> 4.4 Reclamation Methods/Conditions
>
> ...
>
> However, if the limit is reached and routing technology at
> that time is not able to support additional routing entries,
> Regional IRs will review all allocations made up to that
> point. In the course of this review, the Regional IRs may
> seek consensus of the Internet registry and engineering
> communities to set minimum acceptable usage rates or new
> criteria determining eligibility to hold sub-TLA space.
> Dependent upon such a consensus, the Regional IRs may revoke
> the sub-TLA allocations of any Registry not complying with
> those rates or criteria.

We wonder if you want to say "sub-TLA or TLA" in the two places above
where you refer only to "sub-TLA".

> During the period that routing technology is being
> investigated, the Regional IRs will continue allocating
> address space even if the number of "possible" routes are
> reached.

Change "are reached" to "is reached".

> 6.1 Allocation and Reverse Address Mapping
>
> ...
>
> For each IPv6 address block allocated by a Regional IR to a
> member or customer, the Regional IR must set up NS records
> in the appropriate sub-domain within the "ip6.int" domain.

Just for your information, it is very likely that the "ip6.int" domain
will be moved out of ".int" and into ".arpa".  We expect this to be
decided fairly soon, probably by Adelaide.

> 7. GLOSSARY
>
> Allocation - The provision of IP address space to ISPs that
> reassign their address space to customers.

Change "ISPs" to "ISPs or exchanges".

> End-user - An organization receiving reassignments of IPv6
> addresses exclusively for use in operational networks.

Why "reassignments" instead of "assignments"?

What is the point of using the phrase "operational networks"?  Is this in
contrast to experimental networks or non-operational networks?  If this is actually intended to mean "not for offering public transit service to other
organizations" or something like that, please say that.

> Public Topology - The collection of providers and exchanges
> who provide public Internet transit service.

Change "who" to "that".

> Site - A location, physical or virtual, with a network
> backbone connecting various network equipment and systems
> together. There is no limit to the physical size or scope of
> a site.

Insert the word "geographic" before "scope"?

> Unicast - An identifier for a single interface. A packet
> sent to a unicast address is delivered to the interface
> identified by that address. Note that the definition of an
> IPv4 host is different from an IPv6 identifier. One physical
> host may have many interfaces, and therefore many IPv6
> identifiers.

IPv4 and IPv6 are *not* different in the way that this confusing text
seems to suggest.  In both protocols, addresses identify interfaces,
not hosts, and in both kinds of addresses, the lowest-order field
identifies an interface within a net or subnet (even though it is
less precisely called the "host field" in IPv4).

>Comments and suggestions for an appropriate definition are encouraged.

We suggest that you *not* try to define that term, knowing what a slippery
slope that is.  We believe the  criteria for allocation specified by the
policy document (however it turns out after this review cycle) is, or
ought to be, sufficient to indicate who is eligible to be assigned a
sub-TLA or TLA value and who is not.

Thanks again for requesting our feedback, and we apologize for the lateness
and lengthiness of our response.  We would be happy to set up a meeting to
discuss any of these issues with you in person, if that would be helpful.

Steve Deering & Bob Hinden,
Co-Chairs, IPng Working Group

Alain Durand, Bob Fink & Tony Hain,
Co-Chairs, NGTrans Working Group