Re: ownership, leasing, renumbering, and that draft

Yakov Rekhter <yakov@cisco.com> Wed, 23 August 1995 14:03 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12636; 23 Aug 95 10:03 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12632; 23 Aug 95 10:03 EDT
Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa10353; 23 Aug 95 10:03 EDT
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id WAA01134 for <cidrd@iepg.org>; Wed, 23 Aug 1995 22:58:27 +1000
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id FAA06966; Wed, 23 Aug 1995 05:57:59 -0700
Message-Id: <199508231257.FAA06966@hubbub.cisco.com>
To: Robert Elz <kre@munnari.oz.au>
cc: cidrd@iepg.org
Subject: Re: ownership, leasing, renumbering, and that draft
In-reply-to: Your message of "Tue, 22 Aug 95 18:30:43 +0900." <11745.809080243@munnari.OZ.AU>
Date: Wed, 23 Aug 1995 05:57:59 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yakov Rekhter <yakov@cisco.com>

Robert,

>First, on the question of what is the current state of play
>with regard to address assignments, and whether this draft is
>changing the state of the world, or merely making explicit
>something that was always there, but hidden ... clearly this
>is a change.   It may have never been expressly stated that
>numbers allocated were owned (what does it really mean to own
>a number anyway), it has however always been assumed (and
>practised) that a number once allocated remained with the
>organisation it was allocated to as long as that organisation
>desired to retain it.  That is, more precisely, that number
>would not be allocated to any other organisation.  There is a
>long established principle (of law) that permitting a state
>of affairs to remain long enough, and allowing others to rely
>on that, abrogates any right to claim otherwise.

I suggest we add the following (taken almost verbatim from your note):

     While it have never been expressly stated that allocated network
     numbers were owner, it has however always been assumed (and practiced)
     that a network number, once allocated, remained with the organization
     it was allocated to as long as that organization desires to retain it,
     and that the number would not be allocated to any other organization.


>Now this is not, of itself, an objection to the aim of the
>draft, but to the way it is written.  That is, if address
>leasing is decided to be the way the Internet needs to move,
>then that decision should be made in a frank and honest way.
>That is, the draft should simply say words like "Until now,
>addresses have been allocated in perpetuity, this cannot
>continue (for reasons explained), and consequently a change
>needs to be made.   This document makes that change".

We'll add the text as you suggested.

>Second, there exist words in the draft that exempt existing
>numbers from this scheme.  I have some comments on that.
>
>First, the most minor issue is existing "as of when", which has
>been asked before.  And answered as well.  This is not really
>important - it's a pick a date, and be done with it, though the
>draft should be more explicit about just when that date is,
>perhaps with words like "as of the publishing of this draft
>as an RFC".

"as of the publishing of this document as an RFC"

>What is relevant is what is the definition of "allocated" at
>that time, whatever it is.   If I go to my service provider a
>week or two after the operative date, and ask for a new number,
>and the service provider allocates it out of a block they
>obtained before the relevant date, is that an "already allocated"
>number or not?   If I have a number I have had allocated for years
>now (say one from the SRI NIC, to put it in perspective), but
>which hasn't been used for almost as many years, that is, it
>is not currently consuming any of the precious router table
>space, is that number exempt from renumbering should I decide
>to start using it again?
>
>For a draft attempting to set in place a major policy initiative
>this one is terribly lacking in detail.

How about along the lines that "if you're not connected and are now 
connecting, you should renumber" ?

>Next, on the same issue, are we guaranteed that existing
>numbers, however they are defined, as of the relevant date,
>will never need to be renumbered?    Who is in the position to
>make that guarantee?   Is the cidrd working group able to
>force providers to accept ancient old numbers and provide
>routing for them?   Since this doc is proposing means of
>keeping routing working, isn't it rather a cop out to simply
>ignore all the existing address allocations, as if they weren't
>a major (perhaps the major) part of the problem being faced?

As you may well know, there are no guarantees in the Internet --
just "best effort delivery" :-)

>Would it not be better, if leasing and renumbering is the
>solution to the world's routing problems, to simply make
>the policy apply to everyone - which avoids all of the above
>definition problems?   Of course it does rather raise the
>issue a little higher among those IETF people who get to
>decide on whether the draft should move forward or not, at the
>minute everyone taking any notice of this issue (or essentially
>all of them) can sit back "this doesn't affect me" and allow
>it to slide by - which wouldn't happen if all of those people
>were faced with renumbering.


We can't require renumbering of *already connected* sites,
as it would cause major operational disruptions. So, we
have to grandfather already connected sites. 

>On a related issue, every time a concern is expressed by someone,
>on how they would not be able to renumber, the standard answer
>is "this doesn't apply to you, only new allocations".  That is
>an inappropriate response.   True, it deals with the particular
>case raised, but fails to notice that these are just examples
>of situations that arise all the time.  New organisations, not
>yet connected, and not yet holding immutable numbers will find
>themselves in all of the same situations as those of us who
>are connected now, with all of the same problems we would face
>if forced to renumber.   When responding to those who object
>on this basis, the defenders of the draft should look beyond the
>immediate objection, and into the reasoning behind the
>objection, and explain how a new organisation, not yet
>connected, not yet with a number, and consequently not yet with
>the knowledge, even if with the means, to object, would avoid
>the problems posed by those who do now have a connection, but
>are being exempted from this draft.
>
>Then there is the qualification that private nets are not a
>concern of this draft, it applies only to "the Internet".
>At first glance that seems resaonable, people building their
>own private nets can use any numbers at all, right?   That
>is, those defined for the purpose in RFC1597 (or its successor
>when, and if, published), or simply any other numbers picked
>at random.

While address allocation for private internets is an important issue,
it is outside the scope of the document.  To avoid any confusion we'll
add few sentences to the document to *clearly* articulate that the
document is NOT about address allocation policies for private
internets.

>Yes, so it does - with one caveat, and that is that this draft
>doesn't change anything wrt those kinds of allocations (or non
>allocations).  Unfortunately, it does.  The problem relates to
>just who does address assignments.  If address assignments are
>now to be leases from providers, to whom does an organisation
>without a provider turn if they decide that they need a unique
>address?
>
>One of the standard rebuttals to this is "the Internet shouldn't
>be subsidising outsiders", and nor should it - the organisation
>requesting a number should be paying whatever costs are incurred
>in granting that request, however that certainly is a side
>issue that isn't relevant here.

As I mentioned above, address allocation for private internets
is *outside* the scope of this document. So, whether private
internets should or should not have globally unique addresses
is outside the scope of this document as well.

>If addresses are still to be available to outsiders, from
>somewhere, so they can have addresses that are known unique,
>and which they can use to build their own private (though
>possibly large) independant nets, and then interconnect with
>each other, then what is the relationship of those numbers
>and this draft?
>
>If the organisation, whatever it is, that granted these numbers
>finds that its original lease for its address block has expired,
>and that it cannot be renewed, what happens to the addresses
>it has allocated to unconnected third parties?   Is it really
>correct to claim that this draft does not apply to such cases?
>
>If the effect of this draft is that unique addresses are no
>longer to be available to non-Internet-connected organisations,
>then it should say so explicitly, and justify that decision.

Ditto.

>Recall, this is the IETF - the IETF makes standards for all
>users of the IP protocol suite, not just the connected Internet.
>Anything published with the IETF stamp of approval should be
>able to apply equally to all users of the IP protocols.

Nonsense. RFCs may have scope of applicability, and thus need
not apply to "all users of the IP protocols".

>And finally (I hope) for this message, the draft claims that
>an option for a site faced with renumbering is to decide not to
>do so, and accept limited connectivity instead.   Let's
>examine that option for a minute, and let's take the best
>possible case for this to apply.

"Address leasing" does not mean that at the end of a term the
lease it automatically revoked. In fact, the revocation procedures
form an essential part of the lease itself. Thus depending
on the lease "terms and conditions" it could be possible
to renew the lease. Moreover, it could be possible (subject to
"terms and conditions") to renew the lease even after a site
disconnects from the provider from whom the site leases its addresses.


Yakov.