Re: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size)

[Dmitry Kiselev dmitry@localhost]

Hi, Max!

On Tue, Sep 19, 2006 at 10:30:33PM +0400, Max Tulyev wrote:

> This story is about PA/LIR, where (again, in the theory) all is quite
> simply. No money -> closing contarct (as in terms of it) -> getting back
> IPs.
> 
> But. If there is PI space (and ASes not associated with LIR company) -
> there is also third party: end-user. He shouldn't  have any  troubles
> if  LIR goes out of business or  became  unlucky in it.
> 
> I have a large experience in providing PI/AS (even own a LIR with
> primary service is PI assignment i  ex-USSR).
> 
> My opinion is:
> 
> 1. PI is a GOOD thing.
> 1a. It stimulates small and medium business, providing Internet in
> regions with a lack of money. Yes, EUR2000 really can be a yearly
> turnover of small Internet company here.
> 1b. It conserves IP space (people do request as many space as they
> really need, not /21 "because it is given at LIR startup")
> 2. PI and AS SHOULD be billed in the regular basis (yearly, quarterly or
> so). This pervents dead IP space beeing locked.
> 3. There shoud be an mechanism (NOT mntner as it is now) to suspend and
> remove address space if there is no payments. Again, _not_ LIR's mntner
> in object.
> 4. There should be clear and simply mechanism ("what-to-do,
> step-by-step") how PI end-user can change LIR if something goes wrong
> (LIR is out of business, and even LIR goes mad).
> 4a. This mechanism should be quite easy and clear so anyone  can get rid
> in it in ten minutes, therefore  there should be something to stop user
> switching between LIRs looking where is cheaper (and in practice,
> killing the market by some inadequate players will do demping).
> 5. Of course, RIPE (LIR?) should check actuality of contact information
> of that kind of objects. Or if not really check - have an ability to
> suspend objects if this information is invalid (i.e. RIPE can't contact
> user with that information).
> 
> Yes, I think there should be "suspended" objects: not visible in the
> database (or visible with some flag, but not routeable - without route
> objects or so). These objects can be returned to life in some cases
> (user at least payed a bill, provided actual contacts or so) or wiped in
> some other cases.
> 
> Maybe, we should learn things from domain name registering systems.
> 
> If it is interesting, I can do something like presentation or policy
> draft? So it is a good topic to talk at the RIPE meeting anyway ;)



According to current IPv4 Address Policy PI address space should be
ASSIGNED to END USERS ONLY. ISP usually provide service for some
(or many) organizations, i.e. contact info for some ranges may be
very different. Although ISP is close to its customers they are
different companies - end-users in Policy terms. ISP with PI can't
create separate DB records and it is violate section 4.0 of Policy.
It is violate item 5 from Your opinion quoted above too. ;)

Since PA have no such disadvantages and have a good scale capability
it should be used by ISPs. PI is still good for small/medium
*enterprises* which large enough to do multihoming.


> > On Tue, 19 Sep 2006, Max Tulyev wrote:
> >
> >> Dmitry Kiselev wrote:
> >>> Max, how say that fees will be equal? As for me, PI/24+ASN should have
> >>> yearly fee acceptable for most small companies. If they really need it,
> >>> they will pay for it. Once payments stoped - resources returned and
> >>> ready to reassignment.
> >>
> >> Seems to be very reasonable. For example, as it was a long before.
> >
> > Once payment stops resources are not returned (as far as my example
> > shows below).  See:
> > http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.html
> >
> > for an example I've been tracking for 5 years now (company bankrupt).
> >
> > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt
> > shows the following still:
> > il.doarnet
> >     DoarNet Ltd.
> >
> >     19981211    212.77.128/19   ALLOCATED PA
> >
> > So in theory your idea sounds nice.  In practice it doesn't work.
> 
> -- 
> WBR,
> Max Tulyev (MT6561-RIPE, 2:463/253@localhost)

-- 
Dmitry Kiselev