FYI - Re: IPv6 Policy Document Review
- Date: Mon, 31 Jan 2000 15:27:47 +0100
Dear colleagues,
Please see below comments the Co-Chairs of the IETF IPng Working
Group and the NGTrans Working Group sent concerning the IPv6 Policy
Document. Maybe this can be useful as input for the discussion at the
RIPE Meeting.
Kind Regards,
Mirjam Kuehne
RIPE NCC
---------- Forwarded message ----------
Date: Tue, 25 Jan 2000 16:26:24 -0800
To: Anne Lord anne@localhost, ipv6-registry@localhost
From: Steve Deering deering@localhost
Subject: Re: IPv6 Policy Document Review - Call for comments
Cc: ipng@localhost, ngtrans@localhost
Content-Type: text/plain; charset="us-ascii"
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).
Finally, in the Call for Comments for the policy document, you said:
>* 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.
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
|
you are here: RIPE -> RIPE Maillists > Archives
