Mailing List Archive

Michael, I guess I missed this when it was originally posted, but if you
could put some attribution around it, it would be more helpful.

--
Stan | Academ Consulting Services |internet: sob@academ.com
Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.
- - - - - - - - - - - - - - - - -

On Sun, 2 Jun 1996, Stan Barber wrote:

> Michael, I guess I missed this when it was originally posted, but if you
> could put some attribution around it, it would be more helpful.

Sorry, I should have clarified. It's something I haulled off of an ISP
discussion list and it appears that some of RIPE's activities may be
butting heads with Sprint's route filtering policies. Specifically, RIPE
is charging a fee to ISP's to get large blocks of IP addresses to allocate
to their customers and yet these blocks are smaller than what Sprint will
route.

I intentionally left out the attribution in case the individual concerned
was simply wrong due to not having done enough research.

I was kind of hoping that someone would pipe up and say that the
operations folks and the IP registres are now working closer and
coordinating their activities. Am I dreaming?....

Michael Dillon ISP & Internet Consulting
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com

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

At the NANOG meeting just past, Sprintlink made a presentation indicating that
they were altering their filtering policies over the course of this month
such that all networks 206 and above would be filtered at /19. They said this
was to be consistent with the new revision to RFC 1466 that is in the works.

[.Note to NANOG readers: please correct me if my notes on this was wrong, but
this is what I recorded.]


--
Stan | Academ Consulting Services |internet: sob@academ.com
Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.
- - - - - - - - - - - - - - - - -

Michael Dillon wrote:
> Sorry, I should have clarified. It's something I haulled off of an ISP
> discussion list and it appears that some of RIPE's activities may be
> butting heads with Sprint's route filtering policies. Specifically, RIPE
> is charging a fee to ISP's to get large blocks of IP addresses to allocate
> to their customers and yet these blocks are smaller than what Sprint will
> route.

Specifically RIPE are allocating /19s as their default allocation window
to local-IRs. They don't charge per block but they charge a yearly fee
for being a local-IR. Sprint in its wisdom is filtering those in 195/8
(great theory, but a bit problematic in practice when it can't agree with
one of the larger registries on what size to filter) with the result
there are now likely to be 50% more adverts (i.e. 2x/19 and an additional
/18 - /19 still necessary to get ANS to work as you can't put a /18
route object in the database).

> I was kind of hoping that someone would pipe up and say that the
> operations folks and the IP registres are now working closer and
> coordinating their activities. Am I dreaming?....

AFAIK Yes. But it would be great if not (I wasn't at NANOG so missed
the announcement).

Alex Bligh
Xara Networks


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

> Michael Dillon <michael@memra.com> writes:
> On Sun, 2 Jun 1996, Stan Barber wrote:
>
> ... appears that some of RIPE's activities may be
> butting heads with Sprint's route filtering policies.

As I have said in this forum before the address allocation policies RIPE
uses are in line with IANA's policies, RFC1466 and the current draft of
RFC1466's successor. The policies are published and regularly discussed
with ISPs in the appropriate fora such as RIPE meetings, NANOG, IETF etc.

The current policy is that the size of the *first* allocation to any new
local registry (ISP) is /19. Of course we will *place* such allocation
such that the possibility for future aggregation is maximised.

These policies are not subject to change based on routing policies set
by a single ISP or a small number of ISPs. Otherwise a single ISP would
in fact be setting the policies. Of course rough consenus among ISPs is
an entirely different matter; however this is not apparent on the
prefix length filtering issue.

> Specifically, RIPE
> is charging a fee to ISP's to get large blocks of IP addresses to allocate
> to their customers

We charge *everyone* for registration services. That is how it should
be. There is no reason why governments (read: taxpayers) should be
footing the bill.

> and yet these blocks are smaller than what Sprint will
> route.

*used to be* smaller. At NANOG Sprint announced that their filters will
be /19. This should be implemented "in the next couple of weeks". Also
most of the RIPE NCC's allocations are out of 193/8 and 194/8 which were
never filtered by Sprint.

> I was kind of hoping that someone would pipe up and say that the
> operations folks and the IP registres are now working closer and
> coordinating their activities. Am I dreaming?....

We are working quite closely together indeed.
But sometimes there is no rough consensus.

Daniel
RIPE NCC Manager
- - - - - - - - - - - - - - - - -

On Mon, 3 Jun 1996, Daniel Karrenberg wrote:

> > Specifically, RIPE
> > is charging a fee to ISP's to get large blocks of IP addresses to allocate
> > to their customers
>
> We charge *everyone* for registration services. That is how it should
> be. There is no reason why governments (read: taxpayers) should be
> footing the bill.

No quarrel with that, but the folks who pay those high fees kind of
expected that they were guaranteed to work on the global Internet. As you
pointed out, there really *IS* some co-operation between registries and
NSP's and the filtering isue really *IS* becoming more sane, i.e.
co-ordinated with registry activities. This is good news.

> We are working quite closely together indeed.
> But sometimes there is no rough consensus.

As long as the lines of communication are kept open rough consensus
usually finds a way to form itself even if not in the way people might
have first imagined it would form.

I started this thread because a European ISP could not find out from
either Sprint or his own upstream NSP or RIPE, why were these routes being
blocked and what could he do to unblock them. This points out to me that
there may still be some room for improvement in opening up avanues of
communication.

Thank you.

Michael Dillon ISP & Internet Consulting
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com

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

> "Alex.Bligh" <amb@xara.net> writes:
>
> Specifically RIPE are allocating /19s as their default allocation window
> to local-IRs. They don't charge per block but they charge a yearly fee
> for being a local-IR.

Nice to read something correct for a change. Thanks! ;-(

> Sprint in its wisdom is filtering those in 195/8
> (great theory, but a bit problematic in practice when it can't agree with
> one of the larger registries on what size to filter)

I happen to agree and Sprint happens to have changed their policy to one
that happens to be compatible with the NCC's allocation policy in the
meantime.

> with the result
> there are now likely to be 50% more adverts (i.e. 2x/19 and an additional
> /18 - /19 still necessary to get ANS to work as you can't put a /18
> route object in the database).

Yes you can! If you have a /18 allocation you should announce it as such
and put a /18 route object in the database. Can you be more specific
on why it did not work for you?


Daniel
- - - - - - - - - - - - - - - - -

> Michael Dillon <michael@memra.com> writes:
>
> No quarrel with that, but the folks who pay those high fees kind of
> expected that they were guaranteed to work on the global Internet.

Our documentation clearly tells them that this may be a wrong expectation
and also tells them where to complain. Now if people would read
documentation the world would be a better place .... ;-(

> I started this thread because a European ISP could not find out from
> either Sprint or his own upstream NSP or RIPE, why were these routes being
> blocked and what could he do to unblock them.

I am quite sure we point everyone with routing problems in the direction
of the ISP concerned. I realise that some find this not too helpful,
but what else can we do?

> This points out to me that
> there may still be some room for improvement in opening up avanues of
> communication.

Concrete suggestions are always welcome.

Daniel
- - - - - - - - - - - - - - - - -

Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:

> > with the result
> > there are now likely to be 50% more adverts (i.e. 2x/19 and an additional
> > /18 - /19 still necessary to get ANS to work as you can't put a /18
> > route object in the database).
>
> Yes you can! If you have a /18 allocation you should announce it as such
> and put a /18 route object in the database. Can you be more specific
> on why it did not work for you?

Sorry I wasn't clear. If you have a /19 allocated in the RIPE database then
for obvious reasons you have to put a /19 route (not a /18) route in the
RIPE database. To get ANS to accept this you have to announce a /19 route
for this. This got filtered by Sprint.

Before Sprint's (much welcomed - thanks Sean) change of heart, you could
get around this if you were the lower /19 in the block by also making
a /18 advert. As the other half of the /18 was unused normally, this
makes no difference to anyone except those in the /19 suddenly get
Sprint connectivity. Actually it was likely to be of benefit to
any future holder of the upper half of the /18 as that would have
been the only way they would have gained Sprint connectivity (effectively
the holder of the lower half gives them partial transit to the point
where the upper /19 advert hits the /18 route to Sprint). This possibly
slightly naughty but oh-so-tempting hack would have meant that European
local IRs were likely to announce a /18 and a lower /19, and an upper
/19 rather than just two /19s. So Sprint would see one /18 and get
suboptimal routing, everyone else would see 3 adverts rather than 2.

Hope that makes sense.

Anyway, all sorted out now Sprint have changed their policy. Glad
the world has seen sense (i.e. RIPE and Sprint have agreed on the
same size - whether it was /18 or /19 didn't matter to me, just
as long as it was consistent).

Alex Bligh
Xara Networks


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

In message <199606030827.JAA06158@diamond.xara.net>, "Alex.Bligh" writes:
> Michael Dillon wrote:
> > Sorry, I should have clarified. It's something I haulled off of an ISP
> > discussion list and it appears that some of RIPE's activities may be
> > butting heads with Sprint's route filtering policies. Specifically, RIPE
> > is charging a fee to ISP's to get large blocks of IP addresses to allocate
> > to their customers and yet these blocks are smaller than what Sprint will
> > route.
>
> Specifically RIPE are allocating /19s as their default allocation window
> to local-IRs. They don't charge per block but they charge a yearly fee
> for being a local-IR. Sprint in its wisdom is filtering those in 195/8
> (great theory, but a bit problematic in practice when it can't agree with
> one of the larger registries on what size to filter) with the result
> there are now likely to be 50% more adverts (i.e. 2x/19 and an additional
> /18 - /19 still necessary to get ANS to work as you can't put a /18
> route object in the database).

Since when can't you put a /18 in the database?

It sounds like what you are saying is you will be advertising 2 /19s
plus advertising a /18 that you won't be registering just to get the
traffic to come out of Sprint.

You can certainly register a /18 and the whole world would much rather
you advertised just the /18 and and not the /19s.

This sounds to me like some people don't know or care who the other
/19 belongs to and are just announcing the /18 for Sprint's sake. The
two /19s would be announced regardless of anything ANS does or
regardless of any registry issues. Is this the case?

Curtis
- - - - - - - - - - - - - - - - -

> "Alex.Bligh" <amb@Xara.Net> writes:
> Sorry I wasn't clear. If you have a /19 allocated in the RIPE database then
> for obvious reasons you have to put a /19 route (not a /18) route in the
> RIPE database. To get ANS to accept this you have to announce a /19 route
> for this. This got filtered by Sprint.

OK so far.

> Before Sprint's (much welcomed - thanks Sean) change of heart, you could
> get around this if you were the lower /19 in the block by also making
> a /18 advert. As the other half of the /18 was unused normally, this
> makes no difference to anyone except those in the /19 suddenly get
> Sprint connectivity.

Since this means announcing routes to address space not allocated to you
it is dubiuous to say the least.

> Actually it was likely to be of benefit to
> any future holder of the upper half of the /18 as that would have
> been the only way they would have gained Sprint connectivity (effectively
> the holder of the lower half gives them partial transit to the point
> where the upper /19 advert hits the /18 route to Sprint). This possibly
> slightly naughty but oh-so-tempting hack would have meant that European
> local IRs were likely to announce a /18 and a lower /19, and an upper
> /19 rather than just two /19s. So Sprint would see one /18 and get
> suboptimal routing, everyone else would see 3 adverts rather than 2.
>
> Hope that makes sense.

Technically I understand what you are saying.
Whether "it makes sense" is another matter.

> Anyway, all sorted out now Sprint have changed their policy. Glad
> the world has seen sense (i.e. RIPE and Sprint have agreed on the
> same size - whether it was /18 or /19 didn't matter to me, just
> as long as it was consistent).

Yes indeed.

Daniel
- - - - - - - - - - - - - - - - -

> It sounds like what you are saying is you will be advertising 2 /19s
> plus advertising a /18 that you won't be registering just to get the
> traffic to come out of Sprint.
>
> You can certainly register a /18 and the whole world would much rather
> you advertised just the /18 and and not the /19s.
>
> This sounds to me like some people don't know or care who the other
> /19 belongs to and are just announcing the /18 for Sprint's sake. The
> two /19s would be announced regardless of anything ANS does or
> regardless of any registry issues. Is this the case?

See my later mail. Of course it would be irresponsible to do this without
consent of the owner of the upper half of the /18, however most (all
that I've seen) of the /19s RIPE are currently assigning from 195
have been lower /19s with the upper half not used, so they can grow.
Please don't take what I wrote as a criticism of ANS - I've never had any
problem with ANS filtering as it's entirely predictable and worked
precisely in parallel with the registries, and the ANS NOC is admirably
helpful in sorting out any filtering problems. I was describing
a marginally unpleasant workaround to an otherwise intractable (sp?)
problem (RIPE and Sprint not agreeing on minimum block size) - and
AFAIK the only way to get /19s routed to Sprint when the other half isn't
in use in many cases (yes, I know about proxy aggregation etc.). I'd be the
first to say it isn't nice, but fortunately it's now (or will soon be)
unnecessary. My point was the fact RIPE and Sprint *didn't* agree
would actually encourage hacks like this and in some cases increase
the number of routes carried.

Alex Bligh
Xara Networks



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

>> > Specifically, RIPE
>> > is charging a fee to ISP's to get large blocks of IP addresses to allocate
>> > to their customers
>>
>> We charge *everyone* for registration services. That is how it should
>> be. There is no reason why governments (read: taxpayers) should be
>> footing the bill.
>
>No quarrel with that, but the folks who pay those high fees kind of
>expected that they were guaranteed to work on the global Internet. As you
>pointed out, there really *IS* some co-operation between registries and
>NSP's and the filtering isue really *IS* becoming more sane, i.e.
>co-ordinated with registry activities. This is good news.

No quarrel with that either, except for the bit about high fees.
RIPE NCC tariffs are quite moderate. With the help of market
buoyancy, they've been able to reduce them significantly year
on year. This year, most of the ISPs receiving service from
the RIPE NCC pay a charge of 1500 ecu (about $1800). The scale
of charges are agreed each September by the ISPs themselves as a
committee of NCC contributors.

Mike Norris

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

> We charge *everyone* for registration services. That is how it should
> be. There is no reason why governments (read: taxpayers) should be
> footing the bill.

This would be ok if there was a market for registry's.

The current Ripe approach seems to build a large byracrazy, with
lots and lots of paperworks, so you need more resources to process
the paperworks, does not really support the part of the Internet
we are where supposed to facilitate.

If there is a finite resource that needs to be managed, it should be
done in a fair way for all players, and right now i don't think
that's not the case if we look at the globe as a whole.

Fix the rules, open up more registrys wich all apply the same rules,
maybe someone needs to audit the registrys to make sure that things are
done correct, and have them compete on speed and effectiveness and cost.

--Peter
- - - - - - - - - - - - - - - - -

Peter,

[IEPG added as this isn't just a North American issue]

Executive summary: come to the PIARA and IRE BOFs at the Montreal
IETF.

>> We charge *everyone* for registration services. That is how it should
>> be. There is no reason why governments (read: taxpayers) should be
>> footing the bill.
>This would be ok if there was a market for registry's.

While I am generally a strong proponent of creating a market for
registry services, I will be honest and admit things just aren't set
up for the registries to compete yet.

>The current Ripe approach seems to build a large byracrazy, with
>lots and lots of paperworks, so you need more resources to process
>the paperworks, does not really support the part of the Internet
>we are where supposed to facilitate.

The existance of a bureaucracy and "lots and lots of paperworks" is
the direct result of what I consider the complete raving irrationality
of the current registry system. What would you propose the registries
do to meet the requirements of a) conserving address space, b)
conserving routing table space, and c) allocating the remaining free
pool of addresses in a "fair" fashion when we're constrained by
(arguably) obsolete policies put in place in the days when the
Internet was one big happy R&E community?

From my (admittedly biased) perspective, it would seem there are two
options:

A) The socalist approach
B) The capitalist approach

Right now, the registries use option A. Addresses are allocated "to
each according to need" and the regional registries that charge (APNIC
and RIPE-NCC) request "from each according to ability" (at least to
some extent). As a result, since the definition of "need" is hard to
pin down, a bureaucracy is created and (since there is no other
acceptible way of verifying needs and/or reducing the address
allocation rate), huge amounts of paperwork and oodles of tedious
forms are necessary to submit requests.

Every time someone (who me?) brings up option B, we go chasing merrily
down one or more of the following ratholes:

1) we need to conserve route table space, lets charge for that,
not addresses (irrelevant)
2) AT&T (or some other evil speculator) will buy up all the
address space (and ISPs are just going to sit idly by?)
3) if you charge, then poor organizations can't connect
to the Internet (so who's paying for their connectivity?)
4) you can't charge for addresses because they're just
numbers and have no value (tell that to the US Treasury)

Regardless of the validity of any of these ratholes, they are missing
the point -- without some OBJECTIVELY VERIFIABLE CRITERIA, the
registries must rely on people being honest and forthright about their
requirements. Money (e.g., a charge per address) has proven to be a
pretty effective objectively verifiable criteria to determine whether
someone *really* needs the address space they are requesting.

However, since option B is theo-politically infeasible for whatever
reason, you get option A, with increasingly draconian rules and ever
growing mountains of paperwork. Life is harsh.

>If there is a finite resource that needs to be managed, it should be
>done in a fair way for all players, and right now i don't think
>that's not the case if we look at the globe as a whole.

What is "fair"?

Is it fair early adopters have (mutliples of) /8s and will never need
to go through the registry hassle? Is it fair that the current
allocation policies are (statistically speaking) conserving address
space to the benefit of the large ISPs, most of which are in the US?
Would it be fairer if the registries allocated /14s (or /19s) to
everyone regardless of requirements? Should everyone who wants an IP
address be given one, regardless of what they'll use it for? Should
addresses only be given to ISPs?

The registries try to be "fair", from their perspective. Presumably,
the concern you are expressing here is that the regional registries
have implemented the various policies somewhat differently. I believe
this was a specific goal of RFC 1466 which created the multiple
registries in the first place. The registries are trying to
coordinate policies, but we're somewhat constrained by the different
communities we serve (e.g., what is considered a "small ISP" in the US
is likely to be larger than most of the ISPs in the AP region).

>Fix the rules,

Not to pick on you in particular, but I didn't see a lot of comment
from you or other people on the registry guidelines draft. Please
indicate what rules need to be fixed (I have my own set, but I'd like
to see other people's).

>open up more registrys wich all apply the same rules,

Applying all the same rules would tend to imply ignoring the
differences in the development in the Internet throughout the world.
Is this what people really want (honest question -- there are
arguments on both sides)?

Oh yeah, check out how many bits there are for registries in IPv6...

>maybe someone needs to audit the registrys to make sure that things
>are done correct,

Who and who would pay them?

>and have them compete on speed and effectiveness and cost.

I think we agree this should be the end goal. How do we get there?

For those who are interested in this gunk, there will be 2 BOFs at
the Montreal IETF:

Pricing of Internet Addresses and Route Advertisements (PIARA)

and

Internet Registry Evolution (IRE)

I'm sure both BOFs will be non-controversial and quite sedate. Stop
on by if you want to catch up on your sleep... :-).

Regards,
-drc

P.S. So which rathole are we going to go down this time? 30 quatloos
on rathole #4 (it's my favorite 'cause it's so silly (Hi Brian!)).
- - - - - - - - - - - - - - - - -

> 4) you can't charge for addresses because they're just
> numbers and have no value (tell that to the US Treasury)
...
> P.S. So which rathole are we going to go down this time? 30 quatloos
> on rathole #4 (it's my favorite 'cause it's so silly (Hi Brian!)).


Well, since you ask...

My view is still that charging for routing announcements is
necessary and sufficient - but as I've said before, I think
that registries should charge for their *services*, and
allocating an address block is a service. So I don't think
we're that far apart. See you in Montreal.

Brian
- - - - - - - - - - - - - - - - -

> >From my (admittedly biased) perspective, it would seem there are two
> options:
>
> A) The socalist approach
> B) The capitalist approach
>

The argument appears to be more well-rehearsed than that. In essence
it seems similar to the name-space argument. We have a scarce resource,
and must find ways of distributing it. Past experience has shown that
the free market approach is in general the least of all evils, but
it has some pathologies; these are well known in economics in general
not just in terms of internet politics. The main issue is that we
have a single supply (noone can go and set up another IP address space),
and the cost price is apparently zero. For instance:

> 1) we need to conserve route table space, lets charge for that,
> not addresses (irrelevant)

Specific case of peculiar non-linear cost curve complicated by the
fact that there has to be some economic disadvantage to poor
aggregation on a given amount of address space.

> 2) AT&T (or some other evil speculator) will buy up all the
> address space (and ISPs are just going to sit idly by?)

Specific case of monopolistic disfunctionality.

> 3) if you charge, then poor organizations can't connect
> to the Internet (so who's paying for their connectivity?)

Specific case of the merit good argument.

> 4) you can't charge for addresses because they're just
> numbers and have no value (tell that to the US Treasury)

Urmm... see the market for options and derivatives.

Historically the way to prevent such market disfunction has been
regulation of this sort. Which is exactly what Internic, RIPE, etc.
do. However, where regulation is different in different geographical
areas in what is effectively a global market place, it causes problems.
c.f. the telecoms industry.

Alex Bligh
Xara Networks





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

> "Alex.Bligh" <amb@xara.net> writes:
>
> Historically the way to prevent such market disfunction has been
> regulation of this sort. Which is exactly what Internic, RIPE, etc.
> do. However, where regulation is different in different geographical
> areas in what is effectively a global market place, it causes problems.
> c.f. the telecoms industry.

That is true and we work very hard to align all regional registries
to the extent possible. I see no major differences causingproblems at
the moment. If there are, please point them out.

randy Conrad has made the argument why there is a need for the
regional differences that do exist.


Daniel

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

Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote
>
> > "Alex.Bligh" <amb@xara.net> writes:
> >
> > Historically the way to prevent such market disfunction has been
> > regulation of this sort. Which is exactly what Internic, RIPE, etc.
> > do. However, where regulation is different in different geographical
> > areas in what is effectively a global market place, it causes problems.
> > c.f. the telecoms industry.
>
> That is true and we work very hard to align all regional registries
> to the extent possible. I see no major differences causingproblems at
> the moment. If there are, please point them out.
>
> randy Conrad has made the argument why there is a need for the
> regional differences that do exist.

I don't disagree with either of the above. I was not arguing against regional
registries, just that the problem is more widely known and understood than
in just the internet industry. There has been the potential for problems (viz.
the subject line) but AFAIK they've mostly been sorted by harmonizing
the differences. Where this hasn't happened yet (one area I have direct
experience of is namespace - .co.uk vs. .com for example), it has
started to distort the 'market'.

Alex Bligh
Xara Networks



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

>
> > "Alex.Bligh" <amb@xara.net> writes:
> >
> > Historically the way to prevent such market disfunction has been
> > regulation of this sort. Which is exactly what Internic, RIPE, etc.
> > do. However, where regulation is different in different geographical
> > areas in what is effectively a global market place, it causes problems.
> > c.f. the telecoms industry.
>
> That is true and we work very hard to align all regional registries
> to the extent possible. I see no major differences causingproblems at
> the moment. If there are, please point them out.

I agree. The regional registries meet several times a year as well
as keeping in close contact via email to coordinate our policies
as much as possible. We are aware of geographical differences and
try to make allowances for them as much as possible. I think the
majority of the problems with IP numbers pretty much transcend any
international boundaries.

Kim


>
>
> Daniel
>
>

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

> >From my (admittedly biased) perspective, it would seem there are two
> options:
>
> A) The socalist approach
> B) The capitalist approach
>
And, generally, I would have to say that for a resource such as IP addresses
and Internet registration services, option A is certainly better suited
to the task at hand.

> Right now, the registries use option A. Addresses are allocated "to
> each according to need" and the regional registries that charge (APNIC
> and RIPE-NCC) request "from each according to ability" (at least to
> some extent). As a result, since the definition of "need" is hard to
> pin down, a bureaucracy is created and (since there is no other
> acceptible way of verifying needs and/or reducing the address
> allocation rate), huge amounts of paperwork and oodles of tedious
> forms are necessary to submit requests.
>
Agreed. There should be an effort to streamline the process while still
recognizing that a certain amount of bureaucracy and forms goes with
the territory. It would, however, be nice if the various registries
could standardize on a user interface and make their modifications behind
the scenes. I just received an announcement from the InterNIC that they
have completely changed the form yet again. AAAARRRRRGGGGGGHHHH!!!
Oh, well, at least this time, I found out _BEFORE_ I submitted something.

> Every time someone (who me?) brings up option B, we go chasing merrily
> down one or more of the following ratholes:
>
> 1) we need to conserve route table space, lets charge for that,
> not addresses (irrelevant)

Not irrelevant. Highly relevant, but not the right solution to that
problem either.

> 2) AT&T (or some other evil speculator) will buy up all the
> address space (and ISPs are just going to sit idly by?)

Depending on the situation, it might be difficult for them to do anything
effective about it. It is a real danger, and could easily occur.

> 3) if you charge, then poor organizations can't connect
> to the Internet (so who's paying for their connectivity?)

For one thing, I am. I provide free connections to a number of small
non-profit organizations that have little or no money. Similarly, ConXioN
does the same, and plans to expand the amount of that we do, as we become
more profitable. Donating connectivity is easy. Donating NIC fees is
significantly less attractive. (Especially in the case of InterNIC, where
the level of service is low, the delays high, and the general attitude
less than helpful, it is very unpalatable to donate CASH to them).

> 4) you can't charge for addresses because they're just
> numbers and have no value (tell that to the US Treasury)
>
Gladly. The IRS opinion that they could "auction off" a domain name as an
asset is a clear cut example of the need for strong legislative relief to
the contrary. Unfortunately, we are dealing with a government that doesn't
even understand people, let alone the network we have built. This government
is so backwards that it attempted to regulate content on a federal level for
a network that is so thoroughly internation in nature that the concept is
absurd. In so doing, it completely ignored the supreme law which it is sworn
to uphold, the Constitution for the united States of America.

> Regardless of the validity of any of these ratholes, they are missing
> the point -- without some OBJECTIVELY VERIFIABLE CRITERIA, the
> registries must rely on people being honest and forthright about their
> requirements. Money (e.g., a charge per address) has proven to be a
> pretty effective objectively verifiable criteria to determine whether
> someone *really* needs the address space they are requesting.
>
Bull. Money has proven to be an effective weapon which allows the larger
to smash the smaller. The internet is a great equalizer right now. If
you apply this model to it, it will become the next great tool of domination
used by large corporations.

> However, since option B is theo-politically infeasible for whatever
> reason, you get option A, with increasingly draconian rules and ever
> growing mountains of paperwork. Life is harsh.
>
And on a balance, I will opt for the existing system.

> >If there is a finite resource that needs to be managed, it should be
> >done in a fair way for all players, and right now i don't think
> >that's not the case if we look at the globe as a whole.
>
> What is "fair"?
>
> Is it fair early adopters have (mutliples of) /8s and will never need
> to go through the registry hassle? Is it fair that the current
> allocation policies are (statistically speaking) conserving address
> space to the benefit of the large ISPs, most of which are in the US?
> Would it be fairer if the registries allocated /14s (or /19s) to
> everyone regardless of requirements? Should everyone who wants an IP
> address be given one, regardless of what they'll use it for? Should
> addresses only be given to ISPs?
>
Yes and no. However, that is certainly more "fair" than retroactively
charging them for what they already have. To lease address space to
people would require the lessor to "own" the address space. This is
not a good solution. Address space cannot be owned. The real solution
is to work as rapidly as possible to transform it from a finite resource
into an abundant resource. This can be done with a protocol change. The
design is already avaialble, and there are reference ports appearing for
a multitude of platforms. When this transition is well underway, the
issue of "limited" address space will be moot.

> The registries try to be "fair", from their perspective. Presumably,
> the concern you are expressing here is that the regional registries
> have implemented the various policies somewhat differently. I believe
> this was a specific goal of RFC 1466 which created the multiple
> registries in the first place. The registries are trying to
> coordinate policies, but we're somewhat constrained by the different
> communities we serve (e.g., what is considered a "small ISP" in the US
> is likely to be larger than most of the ISPs in the AP region).
>
True. However, the definition of small should be relatively irrelevant.
Everyone should be treated the same, regardless of size. If you have
a need for 8 class C's, then you need a /21. If you need 64, you need a /18.
If you need 256, you need a /16. Etc. Number of addresses needed and
rate of growth should be the primary parameters used to judge address
allocation. Size of the company relative to others is irrelevant.

> >Fix the rules,
>
> Not to pick on you in particular, but I didn't see a lot of comment
> from you or other people on the registry guidelines draft. Please
> indicate what rules need to be fixed (I have my own set, but I'd like
> to see other people's).
>
I have not read the draft yet, so am unable to comment.

> >open up more registrys wich all apply the same rules,
>
> Applying all the same rules would tend to imply ignoring the
> differences in the development in the Internet throughout the world.
> Is this what people really want (honest question -- there are
> arguments on both sides)?
>
Why would it imply ignoring the differences? Why can we not come up
with a standardized set of rules based on need (current and reasonable
projected) which can be applied fairly. Those differences should result
in different needs. If the rules are properly written, the differences
in input will result in different output and the output will always
be appropriate to the input. Realistically, I recognize that it won't
be perfect, but I bet we could hit 90% if we tried.

Also, and in my opinion more important that a consistent policy structure
between registries, is a unified standardized user interface. Figure out
what information you want/need from the users and put it all down. Ask
for it all, and stabilize the template. Recognize that you are going to
have to live with this template for many years to come, and put in place
a policy that any errors made in the design of this template are the
registries' problem that they are responsible for dealing with. Having
a new template design come out of InterNIC every time I go to register a domain
is getting really old.

> Oh yeah, check out how many bits there are for registries in IPv6...
>
> >maybe someone needs to audit the registrys to make sure that things
> >are done correct,
>
> Who and who would pay them?
>
I propose the ISOC and the IANA be jointly responsible for this process, and
it should be funded by the fees the registries are collecting.

> >and have them compete on speed and effectiveness and cost.
>
> I think we agree this should be the end goal. How do we get there?
>
> For those who are interested in this gunk, there will be 2 BOFs at
> the Montreal IETF:
>
> Pricing of Internet Addresses and Route Advertisements (PIARA)
>
> and
>
> Internet Registry Evolution (IRE)
>
> I'm sure both BOFs will be non-controversial and quite sedate. Stop
> on by if you want to catch up on your sleep... :-).
>
> Regards,
> -drc
>
> P.S. So which rathole are we going to go down this time? 30 quatloos
> on rathole #4 (it's my favorite 'cause it's so silly (Hi Brian!)).
>
It's not silly at all. All four of the "ratholes" you mentioned are legitimate
issues. Whether you choose to agree or not is a different issue.

Owen

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

> > A) The socalist approach
> > B) The capitalist approach

Without competition, the capitalist approach doesn't work well at all.

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

Owen,

> > >From my (admittedly biased) perspective, it would seem there are two
> > options:
> >
> > A) The socalist approach
> > B) The capitalist approach
> >
> And, generally, I would have to say that for a resource such as IP addresses
> and Internet registration services, option A is certainly better suited
> to the task at hand.

Why option A is "certainly better suited" ?

> > Every time someone (who me?) brings up option B, we go chasing merrily
> > down one or more of the following ratholes:
> >
> > 1) we need to conserve route table space, lets charge for that,
> > not addresses (irrelevant)
>
> Not irrelevant. Highly relevant, but not the right solution to that
> problem either.

Why this is not "the right solution" ?

>
> > 2) AT&T (or some other evil speculator) will buy up all the
> > address space (and ISPs are just going to sit idly by?)
>
> Depending on the situation, it might be difficult for them to do anything
> effective about it. It is a real danger, and could easily occur.

Why do you think this is "a real danger, and could easily occur" ?

Yakov.
- - - - - - - - - - - - - - - - -

Randy,

>
> >My view is still that charging for routing announcements is
> >necessary and sufficient -
>
> Sufficient for what?

Sufficient to give folks an incentive to use addresses that aggregate
for routing purposes. (This is carefully phrased *not* to be CIDR-specific.)
>
> >but as I've said before, I think that registries should charge for their
> >*services*, and allocating an address block is a service.
>
> What is the difference in the service charge for allocating
> a /8 compared to allocating a /24?
>
Indeed - I was debating whether to mention that in my previous mail.
I don't have a quick answer.

Brian
- - - - - - - - - - - - - - - - -