RE: draft-hubbard-registry-guidelines-03.txt

JohnM <JohnM@competitive.com> Mon, 29 July 1996 15:11 UTC

Received: from ietf.org by ietf.org id aa04629; 29 Jul 96 11:11 EDT
Received: from cnri by ietf.org id aa04625; 29 Jul 96 11:11 EDT
Received: from ietf.org by CNRI.Reston.VA.US id aa05774; 29 Jul 96 11:11 EDT
Received: from ietf.org by ietf.org id aa04616; 29 Jul 96 11:11 EDT
Received: from cnri by ietf.org id aa04603; 29 Jul 96 11:11 EDT
Received: from callc2.competitive.com by CNRI.Reston.VA.US id aa05768; 29 Jul 96 11:11 EDT
Received: by callc2.competitive.com with Microsoft Exchange (IMC 4.0.838.14) id <01BB7D3E.5E475C80@callc2.competitive.com>; Mon, 29 Jul 1996 11:09:10 -0400
Message-ID: <c=US%a=_%p=Competitive_Comp%l=CALLC2-960729150850Z-315@callc2.competitive.com>
X-Orig-Sender: iesg-request@ietf.org
Sender: ietf-archive-request@ietf.org
From: JohnM <JohnM@competitive.com>
To: "'davidc@APNIC.NET'" <davidc@apnic.net>, "'dfk@RIPE.NET'" <dfk@ripe.net>, "'kimh@internic.net'" <kimh@internic.net>, "'markk@internic.net'" <markk@internic.net>, "'Postel@ISI.EDU'" <Postel@isi.edu>, 'Jim Browning' <jfbb@atmnet.net>
Cc: 'CIDRD List' <cidrd@iepg.org>, 'IESG' <iesg@CNRI.Reston.VA.US>, 'IETF' <ietf@CNRI.Reston.VA.US>
Subject: RE: draft-hubbard-registry-guidelines-03.txt
Date: Mon, 29 Jul 1996 11:08:50 -0400
Return-Receipt-To: <JohnM@Competitive.Com>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

It seems as if there is quite a bit of political wrangling over IP
addresses and how they should be doled out and administered.

Consider the Internet-draft that would allow all IP addresses to be
created and used dynamically.  Addresses would be created primarily by
using global positioning (latitude-longitude-altitude) information
coupled with MAC  addresses (network interface card manufacturer/serial
numbers).

The draft is in the IETF internet draft area and is entitled 

"draft-mangione-ipv6-gps-alt-00.txt"

Wouldn't it make IP address management simpler?

>----------
>From: 	Jim Browning[SMTP:jfbb@atmnet.net]
>Sent: 	Saturday, July 20, 1996 8:42 PM
>To: 	'davidc@APNIC.NET';; 'dfk@RIPE.NET';; 'kimh@internic.net';;
>'markk@internic.net';; 'Postel@ISI.EDU';
>Cc: 	'CIDRD List'; 'IESG'; 'IETF'
>Subject: 	draft-hubbard-registry-guidelines-03.txt
>
>As reflected in the minutes of the CIDRD WG meeting in Montreal, the
>IESG 
>has requested additional comments on the referenced draft.  To the
>extent 
>that this message reiterates comments I made about the earlier draft, I
>
>apologize for the redundancies, however if they are included here, it
>is 
>because my earlier comments still apply:
>
>
>>                             1. Introduction
>>
>>
>> Internet address space is distributed according to the following
>> three goals:
>>
>> 1) Conservation: Fair distribution of globally unique Internet address
>> space according to the operational needs of the end-users and Internet
>> Service Providers operating networks using this address space.
>> Prevention of stockpiling in order to maximize the lifetime of the
>> Internet address space.
>
>The reference to "Fair distribution" should be removed from the 
>Conservation paragraph because it is out of context.  Fair Distribution
>and 
>Conservation are both important goals, but they are not the *same*
>goals. 
> In fact, the two often conflict.  I recommend that they be split into 
>separate goals by adding the following:
>
>    4) Fair Distribution: Allocation of IP addresses according to the 
>operational needs of end-users, fairly and objectively determined.
>
>> It is in the interest of the Internet community as a whole that the
>> above goals be pursued.  However it should be noted that
>> "Conservation" and "Routability" are often conflicting goals.  All
>> the above goals may sometimes be in conflict with the interests of
>> individual end-users or Internet service providers.  Careful analysis
>> and judgement is necessary in each individual case to find an
>> appropriate compromise.
>
>Compromise is not an appropriate goal.  It presumes that there will be
>a 
>negotiation, and that the end result will be the allocation of an
>address 
>block smaller than requested, but larger than initially offered.  As 
>opposed to 'judgment and compromise'', the goal should be "the
>consistent 
>application of objective criteria", which will result in a correct and 
>supportable decision.  Compromises, while they give something to each
>party 
>in a negotiation, rarely result in the best decision.
>
>> IANA
>>
>> The Internet Assigned Numbers Authority has authority over all number
>> spaces used in the Internet.  This includes Internet Address Space. IANA
>> allocates parts of the Internet address space to regional IRs according
>> to its established needs.
>
>The source of IANA's authority should be referenced: 
><draft-ietf-poised95-ietf-orgs-03.txt>, or another more definitive 
>reference if there is one.
>
>
>> Regional IRs
>>
>> Regional IRs are established under the authority of the IANA.  This
>> requires consensus within the Internet community of the region.  A con-
>> sensus of Internet Service Providers in that region may be necessary to
>> fulfill that role.
>
>The process for establishing these IRs should be clearly defined, as
>should 
>the mechanisms for evaluating whether the distribution goals outlined
>in 
>this draft are being met.
>
>> The specific duties of the regional IRs include coordination and
>> representation of all local IRs in its respective regions.
>
>The duties of the IRs should include meeting the distribution
>objectives 
>and ensuring that local IRs meet them as well.
>
>
>> Local IRs
>>
>> Local IRs are established under the authority of the regional IR and
>> IANA.  These local registries have the same role and responsibility as
>> the regional registries within its designated geographical areas.  These
>> areas are usually of national dimensions.
>
>Just as with the IRs, The process for establishing Local IRs should be 
>clearly defined, as should the mechanisms for evaluating whether the 
>distribution goals outlined in this draft are being met at the local
>level.
>
>>
>>                         2.  Allocation Framework
>>
>> 2.1  Guidelines for Internet Service Providers (ISPs)
>[snip]
>> ISPs who exchange routing information with other ISPs at multiple loca-
>> tions and operate without default routing may request space directly
>> from the regional registry in its geographical area.
>
>Many multi-homed ISPs, with peering agreements in place, choose to
>maintain 
>a default route as well.  I see no reason why this draft should
>prohibit 
>such an ISP from obtaining a direct allocation of addresses when other 
>factors indicate that it is appropriate.
>
>[snip]
>> To facilitate hierarchical addressing, implemented using Classless
>> Inter-Domain Routing (CIDR), all other ISPs should request address space
>> directly from its upstream provider.  ISPs only request address space
>> directly from regional registries if their immediate requirement, when
>> satisfied with a contiguous block allocation, has a reasonable probabil-
>> ity of being routable on the Internet, and they meet one or more of the
>> following conditions.
>>
>>        a)  the ISP is directly connected to a major routing exchange
>>            (for purposes of this document, a major routing exchange
>>             is defined as a neutral layer 2 exchange point connecting
>>             four or more unrelated ISPs.)
>
>The issue of physical connectivity should not be a concern of this
>draft. 
> Many people believe that the future will see an increased reliance on 
>regional exchanges (which may or may not fit the above definition) and 
>private exchange/peering agreements which do not occur at an exchange 
>point.  Several major NSPs have begun taking the private exchange
>(between 
>only two providers) approach in order to reduce congestion at the NAPs.
>
> There is no reason these efforts should be discouraged through IP 
>allocation policy. The issue is whether there is a valid need for 
>addresses, and this has little to do with where networks are exchanging
>
>traffic.
>
>>        b)  the ISP is multi-homed, that is, it has more than one
>>            simultaneous connection to the global Internet and no
>>            connection is favored over the other
>
>I don't understand why favoring one connection over another should be a
>
>factor.  I also fail to see how this can be objectively determined. 
>Does 
>this mean that if an ISP is multi-homed with two connections of the
>same 
>speed to two different NSPs, but she pads her AS path for one of them
>so 
>route traffic is carried on a preferred (for whatever reason) path,
>that 
>she can not obtain a direct allocation of addresses?  I think this
>approach 
>prevents the application of objective criteria.
>
>> The following are the IP allocation guidelines for ISPs:
>[snip]
>> 4.     IP addresses are allocated to ISPs using a slow-start
>>        procedure.  New ISPs will receive a minimal amount based
>>        on immediate requirement.  Thereafter,  allocated blocks may be
>>        increased based on utilization verification supplied to the
>>        regional registry.  The parent registries are responsible for
>>        determining appropriate initial and subsequent allocations.
>>        Additional address allocations will provide enough address space
>>        to enable the ISP to assign addresses for three months
>>        without requesting additional address space from its parent
>>        registry.  Please note that projected customer base has little
>>        impact on the address allocations made by the parent registries.
>>        Initial allocation will not be based on any current or future
>>        routing restrictions but on demonstrated requirements.
>
>There is an apparent conflict between this paragraph and later (Section
>3) 
>paragraphs which reference a one-year period which will be taken into 
>account, and that there needs to be only 50% utilization in the first
>year.
>
>[snip]
>>  6.    Regional registries may set a maximum limit on assignment sizes
>>        such that a second opinion of the regional registry is required.
>
>This appears to be discussing the internal mechanics of a registry, but
>
>only with respect to one detail.  If the draft is going to define *how*
>a 
>registry meets the distribution goals, then there are a whole host of
>other 
>details that need to be specified.  I suggest either deleting this 
>paragraph, or restating it so that it addresses obtaining additional 
>opinions from regional registries parent registry.
>
>[snip]
>>                         3. Assignment Framework
>>
>> An assignment is the delegation of authority over a block of IP
>> addresses to an end enterprise.   The end enterprise will use addresses
>> from an assignment internally only; it will not sub-delegate those
>> addresses.  This section discusses some of the issues involved in
>> assignments and the framework behind the assignment of addresses.
>>
>> In order for the Internet to scale using existing technologies, use of
>> regional registry services should be limited to the assignment of IP
>> addresses for organizations meeting one or more of the following condi-
>> tions:
>>
>>       a)  the organization has no intention of connecting to
>>           the Internet-either now or in the future-but it still
>>           requires a globally unique IP address.  The organization
>>           should consider using reserved addresses from RFC1918.
>>           If it is determined this is not possible, they can be
>>           issued unique (if not Internet routable) IP addresses.
>>
>>       b)  the organization is multi-homed with no favored connection.
>>
>>       c)  the organization's actual requirement for IP space is
>>           very large, for example, the network prefix required to
>>           cover the request is of length /18 or shorter.
>
>If I am reading section 3 correctly (the wording could be clearer), it
>is 
>differentiating between end users who want to obtain addresses from a 
>registry, and ISPs who want to obtain addresses from a registry.  Why
>the 
>distinction?  Why should an end user with a large (/18 or shorter) 
>requirement be allowed to obtain addresses from a registry, when an ISP
>
>with a similar size requirement must also meet other criteria (NAP 
>connection, multi-homing, etc.).  If there are to be different criteria
>
>based upon whether a requester will be assigning addresses to other 
>entities, I would think the criteria should be less confining for the
>ISP, 
>as the size of her address space is more likely to increase in the
>future, 
>and she is more likely to end up with a NAP connection and/or be 
>multi-homed.
>
>This revision is much improved, although I believe there are
>substantive 
>issues (e.g., how registries are established) which must still be
>addresses 
><NPI>.  I appreciate the effort put forth by its authors, and the 
>opportunity to provide additional comments.
>--
>Jim Browning <jfbb@ATMnet.net>;
>619/643-1802   Fax 619/643-1801
>
>
>