From owen at delong.com  Wed Oct  1 00:55:13 2003
From: owen at delong.com (Owen DeLong)
Date: Tue, 30 Sep 2003 21:55:13 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the
 Africa Portion of the ARIN Region
In-Reply-To: <web-1781374@multicasttech.com>
References: <web-1781374@multicasttech.com>
Message-ID: <2147483647.1064958913@dhcp157-204.corp.tellme.com>

Leo/Marshall,
	There are more significant differences from what you are expecting
from 2002-3 and what it delivers.

	2002-3 provides for ASSIGNMENT _ONLY_.  I still think it is worth
	passing 2002-3, but, it will _NOT_ help ISPs, because ISPs need
	ALLOCATIONS, not ASSIGNMENTS.

	2003-15 provides for ASSIGNMENTS _AND_ ALLOCATIONS, but, ONLY
	for sub-saharan Africa.  it does absolutely nothing for North
	American ISPs other than confirm the belief that the policy process
	is not worth their limited resources.  However, if 2003-15 were
	amended to be ARIN-WIDE policy, it would be worth while for
	smaller ISPs.  Passing 2002-3 will NOT hinder passing 2003-15 as
	a global policy.  Passing 2003-15 _WILL_ probably hinder
	getting a global /22 allocation policy.

Owen



From calvin at orange-tree.alt.za  Wed Oct  1 01:26:45 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 01 Oct 2003 07:26:45 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
	Africa Portion of the ARIN Region
In-Reply-To: <20031001005559.GA88615@ussenterprise.ufp.org>
References: <Pine.GSO.4.44.0309291103460.8405-100000@paixhost.pch.net>
	 <LPENICNLCKCKPNDPFKBACEIBEHAA.William@zanet.co.za>
	 <E1A4Rc3-0006vZ-DQ@ran.psg.com>
	 <LPENICNLCKCKPNDPFKBAKEHPEHAA.William@zanet.co.za>
	 <20031001005559.GA88615@ussenterprise.ufp.org>
Message-ID: <1064986004.8397.10.camel@pear.orange-tree.alt.za>

Leo,

On Wed, 2003-10-01 at 02:55, Leo Bicknell wrote:

<SNIP>

> In a message written on Wed, Oct 01, 2003 at 01:47:07AM +0200, William Stucke wrote:
> > Africans, and AfriNIC members, are unanimous in supporting 2003-15. I
> > haven't heard a single African refuse to support 2002-3. I'm happy to record
> > my support for 2002-3 hereby, but do rather wonder why it's taken so long to
> > get through the system. I haven't heard a convincing argument that
> > supporting one will harm the other. Why, oh why, do (some few vocal) North
> > Americans refuse to support 2003-15?
> 
> I support 2002-3.  Actually, I supported several versions before
> it, and to this day think it should be both allocation and assignment.
> I believe you'll find a strong history of me supporting those
> efforts.
> 
> Part of what bothers me here is that 6 or 12 months ago when 2002-3
> discussion was going on I don't recall many (or any, really) of the
> "Africa People" who have been supporting 2003-15 stepping up to
> voice their support.  There were proposals for a policy that did
> exactly what African's seem to want, and the 2002-3 proposal (which
> seems to not include assignments and allocations as desired), and
> yet no one came forward to help.
> 
> Now that we're getting some traction on 2002-3, we're sidetracked
> by this Africa proposal.  At least two people have responded on
> list when I asked them to support 2002-3 instead (or Owen asked,
> as amended) that they felt 2003-15 had a better chance of passing,
> so they just wanted the local policy.  My inference was that they
> felt 2002-3 would be defeated because the "big bad backbones" in
> the US would never let it happen here, but they might be indifferent
> enough to let Africa get away with it.

<SNIP>

As someone who has no knowledge of the North American networking scene,
I'd be hard pressed to support or go against anything proposed for that
region. I'd prefer those people to sort out their stuff in a way that
suits them. In fact, it would be extremely arrogant and rude of me to
adopt any other line.
The converse if course, applies.

--Calvin

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------


From bs at lantic.net  Wed Oct  1 03:53:03 2003
From: bs at lantic.net (Byron Sorgdrager)
Date: Wed, 1 Oct 2003 09:53:03 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the Africa Portion of the ARIN Region
In-Reply-To: <2147483647.1064958913@dhcp157-204.corp.tellme.com>
References: <web-1781374@multicasttech.com> <2147483647.1064958913@dhcp157-204.corp.tellme.com>
Message-ID: <200310010953.03585.bs@lantic.net>

I must mention that this list does get some major traffic, and I wish that the 
AfriNIC mailing list would be this busy... but hey...

Correct me if I'm wrong, but the 2003-15 proposal is only trying to change the 
CRITERIA for allocations/assignments, NOT the allocations/assignments 
themselves.

>From my perspective, it's simple why I support the proposal :

I have a few hundred thousand dialups, with loads of server hosting 
(co-location) as well as dedicated (leased line) clients.

I have been given 2 x /26's and 2 x /24's - considering the amount of clients 
I have, there's no way in hell I can give them connectivity without NAT.

NAT as we know, breaks certain things (especially SSL connections that check 
concurrency for security reasons). We have had so many complaints by users 
who cannot perform the things they need to (incoming connections into a NAT'd 
network being the number 1 reason why people complain/cancel)

I cannot get more IP's from my upstream, as I have to buy more bandwidth to 
get more IP's. I don't need bandwidth (extremely expensive) - I need IP's !!

Now knowing that the amount of IP's I am currently using (all the RFC1918's) I 
can get a few blocks from ARIN, however other ISP's in the Southern part of 
Africa, are not as "lucky"....

To make the process easier, proposal 2003-15 was introduced. Now if some 
people want to apply the CRITERIA change to the whole ARIN region, fine, do 
so, just please don't delay the proposal because of changes (amendments), as 
African ISP's are NOT having an easy time giving customers service, due to 
restrictions imposed on us.

PS: Thanks for giving us the oppertunity to try and change things to help 
African ISP's grow !

Byron Sorgdrager

-- 
Every word is like an unnecessary stain on silence and nothingness.
                -- Beckett




************************************************************
Scanned by @lantic IS Virus Control Service
This message was scanned for viruses and dangerous content.
@lantic Internet Services (Pty) Ltd. - http://www.lantic.net
eScan for Windows-based PCs - http://www.escan.co.za
************************************************************



From mury at goldengate.net  Wed Oct  1 04:02:19 2003
From: mury at goldengate.net (Mury)
Date: Wed, 1 Oct 2003 03:02:19 -0500 (CDT)
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
In-Reply-To: <LPENICNLCKCKPNDPFKBAEEIAEHAA.William@zanet.co.za>
Message-ID: <Pine.BSI.4.44.0310010259050.17920-100000@dew.goldengate.net>


Just wondering...

If the problem lies with these monopolies not giving IPs to their
downstream customers, why are they going to cooperate and route IPs
allocated from ARIN?  If all these arguments are true, why won't they just
have a "non-assigned routing fee?"

I don't see the difference.  If they think they can suck more money out of
their customers won't they do it whether they have assigned their
customers IPs or whether they have to route their customer's ARIN
allocated blocks?

Thanks.

Mury

On Wed, 1 Oct 2003, William Stucke wrote:

> Jon Lewis asked: -
>
> > Why are the monopoly incumbent carriers so reluctant to assign additional
> IPs when their customers have used up what they have?
>
> I'm not a monopoly incumbent Telco, so I can't speak for them, but I can
> take a guess: -
>
> It's because they're MONOPOLY INCUMBENTS, and the mindset of this particular
> animal simply doesn't understand the concept of competition.
>
> 1	They believe that giving an inch to their "customers" will allow the
> latter to wriggle out of their sticky and blood-red claws.
>
> 2	Why shouldn't they be? They can do what they like ... and don't talk about
> Regulators. There isn't a Government in Africa that I'm aware of that hasn't
> made damned sure that their Regulator (if one even exists) is tightly bound
> in terms of what it can and can't do. Telecommunications laws don't talk
> about IP addresses, they just say "Thou shalt connect anywhere via the
> incumbent, ONLY"
>
> A number of very important concepts are diametrically opposed when
> considering circuit-switched type telecommunications versus packet-switched
> type IP networks. Indeed the mindsets are so different that many people have
> difficulty grasping that a difference even exists .. but this is rather off
> topic. The Telecommunications laws are all written based on the former, and
> have real trouble dealing with the latter.
>
> The number of times that I've heard Telkom SA people equate the terms "core
> network / router" and "Telephone Exchange"  ...
>
> Regards,
>
> William Stucke
> ZAnet Internet Services (Pty) Ltd
> +27 11 465 0700
> William at zanet.co.za
>
> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of
> jlewis at lewis.org
> Sent: 30 September 2003 23:34
> To: Bill Woodcock
> Cc: William Stucke; ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for
> the Africa Portion of the ARIN Region
>
>
> On Mon, 29 Sep 2003, Bill Woodcock wrote:
>
> >       On Wed, 24 Sep 2003, William Stucke wrote:
> >     > In most of the 53 countries in Africa, ISPs don't
> >     > have a choice of from whom they get service, nor how it is carried.
> They are
> >     > obliged to use the monopoly incumbent, or go to jail. Some of those
> monopoly
> >     > Telcos are VERY reluctant to assign IP addresses - e.g. Kenya.
> >
> > This is an important factor for Americans to consider carefully before
> > rushing to judgement in this issue.  One of the _really fundamental_
> > assumptions Americans make, upon which the whole policy framework in
> > America is founded, is that customers can vote with their feet.  That is,
> > if a customer doesn't like the policies of an upstream provider
> > ($500/month for an additional IP address, or whatever), they can simply
> > switch providers, and give their money to someone more reasonable.  That
> > logic is simply not applicable in the African regulatory context, and that
> > fundamental difference informs this whole debate.  So, American ARIN
>
> Why are the monopoly incumbent carriers so reluctant to assign additional
> IPs when their customers have used up what they have?  If it's simply to
> extort more money from them, is there any reason to believe giving them
> portable space is going to make a difference?  "oh...you want to do BGP
> now?...well, that's going to be an extra $X/month per IP you announce to
> us."
>
> Now this sounds like a[n attempted] technical solution to a non-technical
> problem.
>
> ----------------------------------------------------------------------
>  Jon Lewis *jlewis at lewis.org*|  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.504 / Virus Database: 302 - Release Date: 2003/07/24
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.504 / Virus Database: 302 - Release Date: 2003/07/24
>



From mury at goldengate.net  Wed Oct  1 04:04:58 2003
From: mury at goldengate.net (Mury)
Date: Wed, 1 Oct 2003 03:04:58 -0500 (CDT)
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
In-Reply-To: <20031001005559.GA88615@ussenterprise.ufp.org>
Message-ID: <Pine.BSI.4.44.0310010304350.17920-100000@dew.goldengate.net>


Well said.

> I support 2002-3.  Actually, I supported several versions before
> it, and to this day think it should be both allocation and assignment.
> I believe you'll find a strong history of me supporting those
> efforts.
>
> Part of what bothers me here is that 6 or 12 months ago when 2002-3
> discussion was going on I don't recall many (or any, really) of the
> "Africa People" who have been supporting 2003-15 stepping up to
> voice their support.  There were proposals for a policy that did
> exactly what African's seem to want, and the 2002-3 proposal (which
> seems to not include assignments and allocations as desired), and
> yet no one came forward to help.
>
> Now that we're getting some traction on 2002-3, we're sidetracked
> by this Africa proposal.  At least two people have responded on
> list when I asked them to support 2002-3 instead (or Owen asked,
> as amended) that they felt 2003-15 had a better chance of passing,
> so they just wanted the local policy.  My inference was that they
> felt 2002-3 would be defeated because the "big bad backbones" in
> the US would never let it happen here, but they might be indifferent
> enough to let Africa get away with it.
>
> Indeed, that is somewhat my worry as well.  It is possible that
> 2003-15 would pass, and that people would use it passing to support
> defeating 2002-3.  I can think of a half dozen excuses (some of
> which have already been posted on the list) that might be used to
> support that line of thinking.
>
> There is a real problem that having both proposals in the system
> will split the vote.  I think the discussion here only supports
> that conclusion.  Clearly people have strong opinions one way or
> the other, and I see no clear majority.  The only way to win is to
> not split the vote, joining up and outvoting the "big bad backbones".
>
> Now, if we're going to join forces, it's going to be behind 2002-3,
> or a new proposal that is global, and includes allocations and
> assignments.  We're not going to join forces behind 2003-15, because
> it applies only to Africa, so for the people who've been working
> to get this in the US for some time now that would do absolutely
> no good.
>
> It is for this reason I would ask the African contingent to withdraw
> 2003-15, and either support 2002-3, or if having both types of
> membership is important draft a new proposal that is global and has
> both assignments and allocations.
>
> As long as we have both we're going to get bogged down in the
> global-vs-local us-vrs-africa big-bad-backbone-vrs-small-nice-guy
> wars and never win.  There are some valid opinions and some invalid
> opinions on both sides in each of those discussions, let's just avoid
> them, work together, and get something that actually helps _all_
> of us.
>
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>



From leo at ripe.net  Wed Oct  1 04:23:26 2003
From: leo at ripe.net (leo vegoda)
Date: Wed, 1 Oct 2003 10:23:26 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <LPENICNLCKCKPNDPFKBAKEHPEHAA.William@zanet.co.za>
References: <E1A4Rc3-0006vZ-DQ@ran.psg.com>
 <LPENICNLCKCKPNDPFKBAKEHPEHAA.William@zanet.co.za>
Message-ID: <JFGxMKH+7oe$EwV$@ripe.net>

William Stucke <William at zanet.co.za> wrote:

[...]

>In addition, in terms of "inter-registry policy coordination", RIPE
>currently makes /22 allocations for their "Micro Members" and only requires
>a demonstrated need for a /22, I believe. AfriNIC intends doing the same.
>Why is ARIN out of step?

That's not quite accurate.

We do not have a "Micro Member" billing category. Information on the 
RIPE NCC's 2004 charging scheme is available on our web site at:

    <http://ripe.net/ripe/draft-documents/charging2004-aoa03.html>

We also have a document that describes the default and minimum 
allocation size for each /8 block we've received from the IANA. It shows 
that our minimum assignment size is /29.

    <http://ripe.net/ripe/docs/smallest-alloc-sizes.html>

Regards,

-- 
leo vegoda
RIPE NCC
Registration Services Manager


From calvin at orange-tree.alt.za  Wed Oct  1 04:49:22 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 01 Oct 2003 10:49:22 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
	Africa Portion of the ARIN Region
In-Reply-To: <20030930201709.GA76967@ussenterprise.ufp.org>
References: 	 <OF51E62AC7.36E8CC27-ON80256DAC.00342FDC-80256DAC.003708E1@radianz.com>
	 <20030930201709.GA76967@ussenterprise.ufp.org>
Message-ID: <1064998162.7357.10.camel@calvin.coza.net.za>

On Tue, 2003-09-30 at 22:17, Leo Bicknell wrote:
> In a message written on Thu, Sep 25, 2003 at 11:01:07AM +0100, Michael.Dillon at radianz.com wrote:
> > I'm beginning to wonder if we are being dragged into some
> > internal Afrinic politics here. The transition plan for
> > Afrinic is that in February 2004, i.e. 3 months after the
> > ARIN meeting, they plan to process IP requests themselves
> > using ARIN and/or RIPE only for a 2nd opinion.
> 
> Do others believe this date?  I ask because if we do, doesn't it
> make this more or less a moot point?  It seems to me the quickest
> we could expect this policy to be in place (assuming it was rubber
> stamped by all involved) is around the first of the year.  If this
> date is good, that means this policy might help for 1-2 months.

I think the date is optimistic - my feeling (and its just that) is
towards the end of next year.

What I am sure about is that we have passed a point of no return, and we
have something that everyone can support (or that everyone is equally
unhappy with :) ).
Remember, AfriNIC has to merge 3 different allocation policies, deal in
more languages than I've seen elsewhere and take care of all the other
things Randy alluded to in a previous e-mail.

regards

--Calvin

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------



From William at zanet.co.za  Wed Oct  1 05:00:18 2003
From: William at zanet.co.za (William Stucke)
Date: Wed, 1 Oct 2003 11:00:18 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the Africa Portion of the ARIN Region
In-Reply-To: <2147483647.1064958913@dhcp157-204.corp.tellme.com>
Message-ID: <LPENICNLCKCKPNDPFKBAGEILEHAA.William@zanet.co.za>

Owen (and others) have said words along the lines of: -

>  I am inclined to believe it would be good for *Southern Africa*

Just to be strictly accurate, AfriNIC consists of six sub-regions: -

North Africa
East Africa
West Africa
Central Africa
Southern Africa
Indian Ocean

The ARIN area includes *ALL* of these except for North Africa and Indian
Ocean. That's why we use the term "sub-Saharan Africa", rather than
"Southern Africa" ;-)

Regards,

William Stucke
ZAnet Internet Services (Pty) Ltd
+27 11 465 0700
William at zanet.co.za

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.504 / Virus Database: 302 - Release Date: 2003/07/24



From abz at frogfoot.net  Wed Oct  1 05:14:37 2003
From: abz at frogfoot.net (Abraham van der Merwe)
Date: Wed, 1 Oct 2003 11:14:37 +0200
Subject: [ppml] Policy Proposal 2003-15 - question on multi-homing issue
In-Reply-To: <004601c3878d$05cd3960$e3df2799@wcomnet.com>
References: <004601c3878d$05cd3960$e3df2799@wcomnet.com>
Message-ID: <20031001091437.GB1105@oasis.frogfoot.net>

Hi Dawn                                          >@2003.09.30_21:57:04_+0200

> Just to note - I'm not opposed to this proposal but have a question that I
> do not see
> answered as of yet.
> 
> Why exactly does an ISP in southern Africa HAVE to have portable IP address
> space
> to be multi-homed? I understand the cost issues, I understand that there are
> political
> issues. I'm wondering if there is a technical issue? If so, can someone
> please state
> exactly what it is?

Simply because the upstream providers refuse to advertise each other's
address space.

-- 

Regards
 Abraham

The reward for working hard is more hard work.

___________________________________________________
 Abraham vd Merwe - Frogfoot Networks CC
 9 Kinnaird Court, 33 Main Street, Newlands, 7700
 Phone: +27 21 686 1665 Cell: +27 82 565 4451
 Http: http://www.frogfoot.net/ Email: abz at frogfoot.net



From William at zanet.co.za  Wed Oct  1 05:26:15 2003
From: William at zanet.co.za (William Stucke)
Date: Wed, 1 Oct 2003 11:26:15 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the Africa Portion of the ARIN Region
In-Reply-To: <5.2.0.9.0.20030930221333.0231da68@200.40.228.66>
Message-ID: <LPENICNLCKCKPNDPFKBAGEINEHAA.William@zanet.co.za>

Raul said: -

> This comparison is very incomplete.

I know. I said: -

>Adapted from ...

;-) I also gave the reference so that people could get the full story for
themselves - which isn't quite true either, because RIPE will assign as
small as a /29, as per Leo Vegoda's email.

Nevertheless, I think that you will agree that ARIN's policies are the most
restrictive of the four RIRs, in the sense of restricting the smaller ISP.

Regards,

William Stucke
ZAnet Internet Services (Pty) Ltd
+27 11 465 0700
William at zanet.co.za

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.504 / Virus Database: 302 - Release Date: 2003/07/24



From William at zanet.co.za  Wed Oct  1 05:20:31 2003
From: William at zanet.co.za (William Stucke)
Date: Wed, 1 Oct 2003 11:20:31 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <20031001005559.GA88615@ussenterprise.ufp.org>
Message-ID: <LPENICNLCKCKPNDPFKBAGEIMEHAA.William@zanet.co.za>

Leo Bicknell said: -

> Part of what bothers me here is that 6 or 12 months ago when 2002-3
discussion was going on I don't recall many (or any, really) of the
"Africa People" who have been supporting 2003-15 stepping up to
voice their support.

The answer to that is very simple. I, for one, hadn't heard of this list,
and wasn't aware that there was a possible method for me to influence ARIN
policy. That changed two weeks ago, when we held the AfriNIC session at
iWeek, which included an ARIN meeting.

> There is a real problem that having both proposals in the system
will split the vote.

Really? I know very little about ARIN politics, but I had no idea it was a
"one horse race" where only *ONE* proposal may be accepted at a time. If
that's not the case, then the issue of "splitting the vote" doesn't arise.

> Now, if we're going to join forces, it's going to be behind 2002-3,
or a new proposal that is global, and includes allocations and
assignments.

My understanding of 2002-3 is that it does NOT include both allocations AND
assignments, so it still doesn't do what you want.

Owen DeLong asked: -

> However, is there an AfriNIC discussion list equivalent to PPML?

Yes. It's called AfriNIC-Discuss. That's how many of us heard about the PPML
list. See attached notification. (Are attachments allowed on this list?)

Regards,

William Stucke
ZAnet Internet Services (Pty) Ltd
+27 11 465 0700
William at zanet.co.za

-----Original Message-----
From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Leo
Bicknell
Sent: 01 October 2003 02:56
To: ppml at arin.net
Subject: Re: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for
the Africa Portion of the ARIN Region


In a message written on Wed, Oct 01, 2003 at 01:02:52AM +0200, William
Stucke wrote:
> RIR		MIN SIZE	ELIGIBILITY
> APNIC		/20		/22
> RIPE		/20		/22
> LACNIC	/20		/22
> ARIN		/20		/20
>
> In addition, in terms of "inter-registry policy coordination", RIPE
> currently makes /22 allocations for their "Micro Members" and only
requires
> a demonstrated need for a /22, I believe. AfriNIC intends doing the same.
> Why is ARIN out of step?

I've never thought to ask the question before, but I agree 100% that
ARIN is out of step, and wonder why.

In a message written on Wed, Oct 01, 2003 at 01:47:07AM +0200, William
Stucke wrote:
> Africans, and AfriNIC members, are unanimous in supporting 2003-15. I
> haven't heard a single African refuse to support 2002-3. I'm happy to
record
> my support for 2002-3 hereby, but do rather wonder why it's taken so long
to
> get through the system. I haven't heard a convincing argument that
> supporting one will harm the other. Why, oh why, do (some few vocal) North
> Americans refuse to support 2003-15?

I support 2002-3.  Actually, I supported several versions before
it, and to this day think it should be both allocation and assignment.
I believe you'll find a strong history of me supporting those
efforts.

Part of what bothers me here is that 6 or 12 months ago when 2002-3
discussion was going on I don't recall many (or any, really) of the
"Africa People" who have been supporting 2003-15 stepping up to
voice their support.  There were proposals for a policy that did
exactly what African's seem to want, and the 2002-3 proposal (which
seems to not include assignments and allocations as desired), and
yet no one came forward to help.

Now that we're getting some traction on 2002-3, we're sidetracked
by this Africa proposal.  At least two people have responded on
list when I asked them to support 2002-3 instead (or Owen asked,
as amended) that they felt 2003-15 had a better chance of passing,
so they just wanted the local policy.  My inference was that they
felt 2002-3 would be defeated because the "big bad backbones" in
the US would never let it happen here, but they might be indifferent
enough to let Africa get away with it.

Indeed, that is somewhat my worry as well.  It is possible that
2003-15 would pass, and that people would use it passing to support
defeating 2002-3.  I can think of a half dozen excuses (some of
which have already been posted on the list) that might be used to
support that line of thinking.

There is a real problem that having both proposals in the system
will split the vote.  I think the discussion here only supports
that conclusion.  Clearly people have strong opinions one way or
the other, and I see no clear majority.  The only way to win is to
not split the vote, joining up and outvoting the "big bad backbones".

Now, if we're going to join forces, it's going to be behind 2002-3,
or a new proposal that is global, and includes allocations and
assignments.  We're not going to join forces behind 2003-15, because
it applies only to Africa, so for the people who've been working
to get this in the US for some time now that would do absolutely
no good.

It is for this reason I would ask the African contingent to withdraw
2003-15, and either support 2002-3, or if having both types of
membership is important draft a new proposal that is global and has
both assignments and allocations.

As long as we have both we're going to get bogged down in the
global-vs-local us-vrs-africa big-bad-backbone-vrs-small-nice-guy
wars and never win.  There are some valid opinions and some invalid
opinions on both sides in each of those discussions, let's just avoid
them, work together, and get something that actually helps _all_
of us.

--
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.504 / Virus Database: 302 - Release Date: 2003/07/24
-------------- next part --------------
An embedded message was scrubbed...
From: "Theo Kramer" <theo at flame.co.za>
Subject: [Fwd: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy forthe Africa Portion of the ARIN Region]
Date: Tue, 23 Sep 2003 12:20:37 +0200
Size: 7048
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031001/d240c600/attachment.eml>

From theo at uniforum.org.za  Wed Oct  1 06:15:27 2003
From: theo at uniforum.org.za (Theo Kramer)
Date: 01 Oct 2003 12:15:27 +0200
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <OF8EED57F9.8A2E43B7-ON80256DB1.00504E97-80256DB1.00529FAC@radianz.com>
References: 	 <OF8EED57F9.8A2E43B7-ON80256DB1.00504E97-80256DB1.00529FAC@radianz.com>
Message-ID: <1065003327.3862.139.camel@josh>

On Tue, 2003-09-30 at 17:02, Michael.Dillon at radianz.com wrote:
<snip>
> Acceptance:
> By doing this we are supporting Afrinic as an independent organization 
> that is able to make its own policy decisions for its own members. I 
> believe this is the only reasonable choice for ARIN members and it's not 
> based on the contents of the policy but on the fact that it is a policy 
> for Africans that was made by Africans. I don't believe that it sets any 
> precedent for so-called sub-regions because this policy is actually about 
> uniting the regions of a continent, not about subdividing. Internal North 
> American issues are irrelevant to 2003-15. This is a unique situation that 
> will not happen again and an opportunity for us to make a gesture of 
> goodwill towards the ISPs in southern African countries.
> 
> We have plenty of proposed policy changes to discuss that do have very 
> real impacts on our organizations and we've spent too much effort already 
> on 2003-15. Let's move on, rubberstamp the Afrinic proposal, and focus 
> most of our energy on the North American issues that really matter.

Thank you Michael.

Regards
Theo



From rosi at uunet.co.za  Wed Oct  1 06:24:00 2003
From: rosi at uunet.co.za (Rosi)
Date: Wed, 1 Oct 2003 12:24:00 +0200 (SAST)
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
In-Reply-To: <Pine.BSI.4.44.0310010259050.17920-100000@dew.goldengate.net> from "Mury" at Oct 01, 2003 03:02:19 AM
Message-ID: <20031001102401.2974476335@mud.noc.uunet.co.za>

> If the problem lies with these monopolies not giving IPs to their
> downstream customers, why are they going to cooperate and route IPs
> allocated from ARIN?  If all these arguments are true, why won't they just
> have a "non-assigned routing fee?"

hi,

As one of the largest ISPs in South Africa and Southern Africa, we do
not have any problems giving downstreams as many IPs as they need.

Also, we do not charge for IP address space.

Our conditions are that customers must be connected through us,
and that they must justify their need for address space with a
network plan and future estimate plans.  We can and have currently 
assigned anything from /29s to /19s to customers.

I am amazed at what I am seeing on the list that so many folks here
in South Africa are having huge difficulties in getting the address
space that they need from upstreams.

I suspect, and this is my personal opinion, that there may be *some*
incompetency involved with the ip-admin dept of certain ISPs who refuse
to give their downstreams sufficient address space because they themselves
may not know how to wade through the bureacracy of ARIN to get sufficient
space for current and future needs or simply don't understand how assignments 
of address space is supposed to work or how to plan for it.  But that
probably doesn't account for everybody.

I would ask some very pointed questions of such an upstream as to exactly 
why there is a problem assigning more space and why they haven't applied
for sufficient space from ARIN. 

I am also outraged (but not surprised) that ISPs here are charging 
anything other than nominal processing fees for address space.

There is a grey line here between admin fees and selling address space.

Charging an admin fee is fine.  But selling address space would be fraud,
as you are not allowed to sell what you don't own - and while I'm unclear
as to whether address space belongs to ICANN, the RIRs or nobody, it
certainly does not belong to any ISPs in Africa, but from the way some
of them are acting it looks like they seem to think it does!

We also have no problem routing address space that customers have from
other ISPs in situations of multi-homing, providing the space is large
enough to be practically routable and that the other ISP is happy with
us routing it.  We have several customers who multi-home with our
biggest competitors and we have very amicable agreements with our competitors
to route each other's address space for such customers.

regards,
Rosi


From gregm at datapro.co.za  Wed Oct  1 06:28:39 2003
From: gregm at datapro.co.za (Gregory Massel)
Date: Wed, 1 Oct 2003 12:28:39 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for th e Africa Portion of the ARIN Region
In-Reply-To: <20031001005559.GA88615@ussenterprise.ufp.org>
References: <20031001005559.GA88615@ussenterprise.ufp.org>
Message-ID: <200310011228.39616.gregm@datapro.co.za>

> Part of what bothers me here is that 6 or 12 months ago when 2002-3
> discussion was going on I don't recall many (or any, really) of the
> "Africa People" who have been supporting 2003-15 stepping up to
> voice their support.  There were proposals for a policy that did
> exactly what African's seem to want, and the 2002-3 proposal (which
> seems to not include assignments and allocations as desired), and
> yet no one came forward to help.

Leo, maybe I'm misreading you, but the impression I get is that you're saying 
you're concerned to support "Africa People" because they were not vocal 
earlier in the year.

I think you may be overlooking the fact that until recently very few "Africa 
People" were aware of the ARIN public policy mailing list, 2002-3, etc. I, 
for example, only joined it a few weeks ago and at the time posted messages 
to a few popular African networking lists to create awareness of the PPML.

I have not yet seen a single posting from any one of the "Africa People" 
rejecting 2002-3, although I have seen quite a number supporting it.

> felt 2002-3 would be defeated because the "big bad backbones" in
> the US would never let it happen here, but they might be indifferent
> enough to let Africa get away with it.

It's not about indifference. There are different issues at stake. Both 
proposals have merit, but for different reasons.

> that conclusion.  Clearly people have strong opinions one way or
> the other, and I see no clear majority.  The only way to win is to
> not split the vote, joining up and outvoting the "big bad backbones".

What you're talking about here, is obtaining consensus.

Just a hypothetical question for you...

If both 2002-3 and 2003-15 were passed, who would be unhappy? (aside from 
possibly the "big bad backbones")

So if were talking about standing united, then it means we all have to give 
and take a bit. The best compromise I've seen to date is that we all stand 
united in support of both 2002-3 and 2003-15. This is the only win-win 
situation for all that does not involve the excessive delays that amending 
either or both policies would introduce.

If you tell Africans to dump or amend 2003-15 or North Americans to dump or 
amend 2002-3, then you'll struggle to get a united stance. Supporting both 
simultaneously is the only compromise that benefits all.

-Greg



From woody at pch.net  Wed Oct  1 06:25:19 2003
From: woody at pch.net (Bill Woodcock)
Date: Wed, 1 Oct 2003 03:25:19 -0700 (PDT)
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
In-Reply-To: <Pine.BSI.4.44.0310010259050.17920-100000@dew.goldengate.net>
Message-ID: <Pine.GSO.4.44.0310010323530.11780-100000@paixhost.pch.net>

      On Wed, 1 Oct 2003, Mury wrote:
    > If the problem lies with these monopolies not giving IPs to their
    > downstream customers, why are they going to cooperate and route IPs
    > allocated from ARIN?

Again, nobody asks them to cooperate.  ISPs simply tunnel through them,
and announce the prefixes to transit providers in other locations where
market forces make them more cooperative.

                                -Bill




From rosi at uunet.co.za  Wed Oct  1 06:46:09 2003
From: rosi at uunet.co.za (Rosi)
Date: Wed, 1 Oct 2003 12:46:09 +0200 (SAST)
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <LPENICNLCKCKPNDPFKBAGEIMEHAA.William@zanet.co.za> from "William Stucke" at Oct 01, 2003 11:20:31 AM
Message-ID: <20031001104609.AAC8D76335@mud.noc.uunet.co.za>

> discussion was going on I don't recall many (or any, really) of the
> "Africa People" who have been supporting 2003-15 stepping up to
> voice their support.
> 
> The answer to that is very simple. I, for one, hadn't heard of this list,
> and wasn't aware that there was a possible method for me to influence ARIN
> policy. That changed two weeks ago, when we held the AfriNIC session at

Yeah, ditto.

....so I joined and *bada-bing* all the usual suspects here too!...

*wave to William, Calvin, Theo, Byron, Rob, Ant, Greg, & the rest of the gang*

it's like a za flash crowd  :)

Rosi


From theo at uniforum.org.za  Wed Oct  1 08:11:21 2003
From: theo at uniforum.org.za (Theo Kramer)
Date: 01 Oct 2003 14:11:21 +0200
Subject: [ppml] AfriNIC Support Document for ARIN Policy Proposal 2003-15...
In-Reply-To: <E1A4QnG-0005Qf-NT@ran.psg.com>
References: <004601c3878d$05cd3960$e3df2799@wcomnet.com>
	 <E1A4QnG-0005Qf-NT@ran.psg.com>
Message-ID: <1065010281.3862.163.camel@josh>

... is available at http://www.afrinic.org/afrinic_support_2003_15.pdf

Regards
Theo



From randy at psg.com  Wed Oct  1 09:57:45 2003
From: randy at psg.com (Randy Bush)
Date: Wed, 1 Oct 2003 06:57:45 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
References: <LPENICNLCKCKPNDPFKBAEEIAEHAA.William@zanet.co.za>
	<Pine.BSI.4.44.0310010259050.17920-100000@dew.goldengate.net>
Message-ID: <E1A4hUA-0005Kt-7P@ran.psg.com>

> If the problem lies with these monopolies not giving IPs to their
> downstream customers, why are they going to cooperate and route IPs
> allocated from ARIN?

unfortunately, in the past, this has turned out to be a serious
problem with techno-colonialist and monopoly upstreams in africa.
it would be really nice if we could figure out a way to attack
this issue from the top downward, i.e., find a way in process or
policy to 'encourage' them to route the space.

randy



From bicknell at ufp.org  Wed Oct  1 10:13:03 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 1 Oct 2003 10:13:03 -0400
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the Africa Portion of the ARIN Region
In-Reply-To: <200310011228.39616.gregm@datapro.co.za> <LPENICNLCKCKPNDPFKBAGEIMEHAA.William@zanet.co.za> <2147483647.1064958913@dhcp157-204.corp.tellme.com>
References: <20031001005559.GA88615@ussenterprise.ufp.org> <200310011228.39616.gregm@datapro.co.za> <20031001005559.GA88615@ussenterprise.ufp.org> <LPENICNLCKCKPNDPFKBAGEIMEHAA.William@zanet.co.za> <web-1781374@multicasttech.com> <2147483647.1064958913@dhcp157-204.corp.tellme.com>
Message-ID: <20031001141303.GA14561@ussenterprise.ufp.org>


A few issues I want to address.

In a message written on Tue, Sep 30, 2003 at 09:55:13PM -0700, Owen DeLong wrote:
> 	2002-3 provides for ASSIGNMENT _ONLY_.  I still think it is worth
> 	passing 2002-3, but, it will _NOT_ help ISPs, because ISPs need
> 	ALLOCATIONS, not ASSIGNMENTS.

I agree this is an important difference.  As such, I want to make sure
my position is very clear.

We need to move both assignments and allocations to a /22 (and
actually I think /24, but I'll leave that for another day).  Given
the process to get things passed, I believe the fastest way to do
that now is pass 2002-3, and introduce a new proposal to extend to
allocations and pass that later.

To that end, I see that African ISP's could "bend" the rules in one of
two scenarios:

Get a assignment, but treat it as an allocation, and "ugprade" it
to an allocation later (I believe there is already a process to
turn an assignment into an allocation without renumbering) when the
new proposal passes.

Get an assignment, but treat it as an allocation, and in a few
months have it automatically become an allocation when trasferred
to AfriNIC.

I agree that's not 100% the letter of the law, but I think it's
workable, and given the choices we have not a bad way to go.

In a message written on Wed, Oct 01, 2003 at 11:20:31AM +0200, William Stucke wrote:
> > There is a real problem that having both proposals in the system
> will split the vote.
> 
> Really? I know very little about ARIN politics, but I had no idea it was a
> "one horse race" where only *ONE* proposal may be accepted at a time. If
> that's not the case, then the issue of "splitting the vote" doesn't arise.

In theory, the proposals are voted on independantly.  That said,
before people vote on them they view all the proposals together and
decide what they like.  We've already seen on this list people show
a desire to support one, or the other, but not both.  That alone
is evidence to me that the two proposals split some part of the
vote.

Will it be significant or not, I cannot say.  That's why I advocate we
team up, worse case it makes no difference, best case it lets us
overcome the split vote.

In a message written on Wed, Oct 01, 2003 at 12:28:39PM +0200, Gregory Massel wrote:
> Leo, maybe I'm misreading you, but the impression I get is that you're saying 
> you're concerned to support "Africa People" because they were not vocal 
> earlier in the year.

No, that is not the reason at all.  The reason is that I fear they
are derailing an existing process to get 2002-3 passed.  The fact
that they were not vocal as an issue by itself has little meaning
to me, but the fact that they didn't take the time to look that
there was existing discussion and proposals that would do what they
want in the process already before introducing their own does concern
me.

> I think you may be overlooking the fact that until recently very few "Africa 
> People" were aware of the ARIN public policy mailing list, 2002-3, etc. I, 
> for example, only joined it a few weeks ago and at the time posted messages 
> to a few popular African networking lists to create awareness of the PPML.

I can understand that, as I joined myself not all that long ago.
However, participating on a mailing list and introducing a policy
are two different things.  Before you introduce a policy you need
to do more research and make sure you're not stepping on other toes.
That seems to have not been done.  Moreover, some people here who
have indicated they have "participated" (to what degree I don't
know) in the AfriNIC meetings/proposals are long time list members,
who clearly didn't step up and point out efforts were already going
on to fix this problem.

> I have not yet seen a single posting from any one of the "Africa People" 
> rejecting 2002-3, although I have seen quite a number supporting it.

No one has rejected it as bad, a few have refused to support it though,
prefering their own amendment.

> So if were talking about standing united, then it means we all have to give 
> and take a bit. The best compromise I've seen to date is that we all stand 
> united in support of both 2002-3 and 2003-15. This is the only win-win 
> situation for all that does not involve the excessive delays that amending 
> either or both policies would introduce.

With both we still have the potential to have split votes.  Thus I
consider having both (fully supported) is risker than having just one.
Also, on a side note to the concensus talk, I still have a problem with
region specific policy, particularly when global policy is also on the
table.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031001/0157c5ed/attachment.sig>

From randy at psg.com  Wed Oct  1 10:14:14 2003
From: randy at psg.com (Randy Bush)
Date: Wed, 1 Oct 2003 07:14:14 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
References: <Pine.BSI.4.44.0310010259050.17920-100000@dew.goldengate.net>
	<Pine.GSO.4.44.0310010323530.11780-100000@paixhost.pch.net>
Message-ID: <E1A4hk6-0005pI-Ur@ran.psg.com>

> Return-path: <owner-ppml at arin.net>
> Again, nobody asks them to cooperate.  ISPs simply tunnel through them,
> and announce the prefixes to transit providers in other locations where
> market forces make them more cooperative.

do not build real networks on flaky hacks



From lee.howard at mci.com  Wed Oct  1 12:23:59 2003
From: lee.howard at mci.com (Lee Howard)
Date: Wed, 1 Oct 2003 12:23:59 -0400 (EDT)
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the
 Africa Portion of the ARIN Region
In-Reply-To: <LPENICNLCKCKPNDPFKBAGEILEHAA.William@zanet.co.za>
Message-ID: <Pine.GSO.4.20.0310011209410.29774-100000@sun222-31.corp.us.uu.net>

On Wed, 1 Oct 2003, William Stucke wrote:

> Date: Wed, 01 Oct 2003 11:00:18 +0200
> From: William Stucke <William at zanet.co.za>
> To: ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for 
>     the Africa Portion of the ARIN Region
> 
> Owen (and others) have said words along the lines of: -
> 
> >  I am inclined to believe it would be good for *Southern Africa*
> 
> Just to be strictly accurate, AfriNIC consists of six sub-regions: -
> 
> North Africa
> East Africa
> West Africa
> Central Africa
> Southern Africa
> Indian Ocean
> 
> The ARIN area includes *ALL* of these except for North Africa and Indian
> Ocean. That's why we use the term "sub-Saharan Africa", rather than
> "Southern Africa" ;-)

To be strictly accurate, ARIN covers "sub-equatorial Africa" not
"sub-Saharan Africa."
http://ww2.arin.net/library/internet_info/index.html

Cameroon, to take one random example, is sub-Saharan but super-equatorial.
Therefore, it is in the RIPE region, and we won't be having an ARIN
Public Policy meeting there.
http://ww2.arin.net/library/internet_info/RIPEcountries.htm
or .../ARINcountries.htm

By the way, kudos to the ARIN staff for making it pretty easy for me
to find whatever I'm looking for on the ARIN web site.  Whether it's
Bylaws, financial reports, or countries ARIN supports, I haven't spent
more than two minutes looking for information, and I appreciate it.


> William Stucke
> ZAnet Internet Services (Pty) Ltd


Lee




From owen at delong.com  Wed Oct  1 12:45:51 2003
From: owen at delong.com (Owen DeLong)
Date: Wed, 01 Oct 2003 09:45:51 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
In-Reply-To: <1064986004.8397.10.camel@pear.orange-tree.alt.za>
References: <Pine.GSO.4.44.0309291103460.8405-100000@paixhost.pch.net>	
 <LPENICNLCKCKPNDPFKBACEIBEHAA.William@zanet.co.za>	
 <E1A4Rc3-0006vZ-DQ@ran.psg.com>	
 <LPENICNLCKCKPNDPFKBAKEHPEHAA.William@zanet.co.za>	
 <20031001005559.GA88615@ussenterprise.ufp.org>
 <1064986004.8397.10.camel@pear.orange-tree.alt.za>
Message-ID: <2147483647.1065001551@imac-en0.delong.sj.ca.us>

> As someone who has no knowledge of the North American networking scene,
> I'd be hard pressed to support or go against anything proposed for that
> region. I'd prefer those people to sort out their stuff in a way that
> suits them. In fact, it would be extremely arrogant and rude of me to
> adopt any other line.
> The converse if course, applies.
>

Right... since 2002-3 will affect sub-saharan Africa, decide on it based
on whether you think it is a positive of negative effect for sub-saharan
Africa or all of ARIN.  You can decide that.

The point Leo and I are making is that it is one thing for us to weigh
in and/or make policy for ARIN as a single region which we are a part of.
In that case, we have a stake in the process, and, we are representing
our views of what should be for something we are part of.

It is arrogant and presumptuous for us to attempt to dictate policy for
an area we are not part of.  It is even worse for us to vote in favor
of something we think is needed where we are, but, only to give it
to someone else at the exclusion of the area we are actually in.

For us to vote in favor of 2003-15 in it's current form would be equivalant
to handing our neighbor a band-aid while we continue to bleed, since we
think our neighbor might have a bigger cut the bandaid won't actually
handle.

Owen



From jonathan at ods.co.za  Wed Oct  1 13:21:19 2003
From: jonathan at ods.co.za (Jonathan Lydall)
Date: Wed, 1 Oct 2003 19:21:19 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <Pine.BSI.4.44.0310010304350.17920-100000@dew.goldengate.net>
Message-ID: <002801c38840$6dcb9990$0564a8c0@jon>

I was under the under the impression that each policy is "independent"
to each other, it's not like we are voting for a president, where we are
voting for one or the other? Can we not vote yes or no for both
policies? Surely then each policy will either be accepted or rejected by
their own merits or faults?

I acknowledge the frustration of other other list members pushing for
2003-03, however it is evident that a deadlock exists  or did exist and
hence the reason it has been going for a long time. Infact, the reason
Sub-Saharan African's have submitted their own independent policy
proposal is precisely because of this reason.

In regard to upstream providers, it goes without saying that they like
the way things are, the way that smaller ISPs can only change upstream
providers if they are willing to do massive IP address changes to all
their clients. Certainly they would be happy enough if things stayed the
way they are, however, they are certainly not opposing 2003-15, and a
couple of them are even for it, which implies that as a group we stand
together, to do what is best for the end user, and most importantly,
making people who have actually obtained internet at high expense, to
have made solid investment, which will not require time eating tasks
such as IP address renumbering.

While our Telecom is monopolistic, our upstream ISPs are not, and a
company like the one I work for definitely needs the ability to be able
to change upstream ISPs without the need of having to inconvenience
clients of ours who have mail servers or do web/application hosting and
especially DNS hosting. The ISP I work for would also greatly benefit by
plugging into our local up and running INX point, something where an ASN
for BGP would be incredibly useful.

Now, if I was only one of a few ISPs in this position I would understand
that it would shrugged off because it's the little guy whining, but the
majority of ISPs in this country are in a very similar position. We need
the smaller allocation / requirements so that we can meet the needs of
our clients, and provide what is best for them. By making action on our
side easier in the event of a problem, we can serve our clients better
by not interupting them.

The biggest drive is the INX points, with smaller requirements, the
relative number of ISPs connecting to these points will be huge, our INX
point will grow, making a lot more bandwidth available internal to our
country. 2003-15 will act aa highly effective catalyst to growth, and
more importantly, reliabilty of the internet where I live.

"Scale of economy" is the primary phrase here. Yes, while in a place
like North America, there may be a lot more ISPs than in Africa which
could also do with a policy like 2003-15, they may (I say may, because I
cannot truly say what the situation is like there), relatively speaking,
be the little guys. Where I live, by our standards, its not the "little
guy" who has current ARIN policy in their way, it is businesses which
are no longer considered start ups, have gotten over the hurdle of
starting out, and are here to stay.

We submitted this proposal, independently, because we are a united
region, all excited with the recent increase in growth of the internet
in our region, and very excited for the not so distant day when AfriNIC
starts allocating out IP addresses for itself. While we cannot ignore or
forget the rest of our collegues under the ARIN region, our part of the
region is different to them. You cannot ignore the significant number of
increases to mailing list form our region, and we are now hearing th
voice of other members on this list.

Now, I encourage all the recent additions to mailing list (myself
included) from the Sub-saharan region to carry on pushing for this goal
we've set out to achieve, a goal which will benefit all in this region,
to carry on trying to prove the necessity of 2003-15, and to not sway,
as it is important for a lot of us that it gets passed ASAP, without a
delay of an ammendment to the proposal. But more importantly, we must
all realise that we are part of a worldwide community, and we are not
the only ones with problems and hinderances, with our eyes opened more
widely to the problems that other regions are experiencing, it is our
duty to support policies such as 2003-03.

Jonathan Lydall,

Online Digital Solutions. 



From german at lacnic.net  Wed Oct  1 15:07:28 2003
From: german at lacnic.net (German Valdez)
Date: Wed, 01 Oct 2003 14:07:28 -0500
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for
  the Africa Portion of the ARIN Region
In-Reply-To: <20031001005559.GA88615@ussenterprise.ufp.org>
References: <Pine.GSO.4.44.0309291103460.8405-100000@paixhost.pch.net>
 <LPENICNLCKCKPNDPFKBACEIBEHAA.William@zanet.co.za>
 <E1A4Rc3-0006vZ-DQ@ran.psg.com>
 <LPENICNLCKCKPNDPFKBAKEHPEHAA.William@zanet.co.za>
 <20031001005559.GA88615@ussenterprise.ufp.org>
Message-ID: <6.0.0.22.0.20031001140325.045bbae8@lacnic.net.uy>

At 07:55 p.m. 30/09/2003, Leo Bicknell wrote:
>In a message written on Wed, Oct 01, 2003 at 01:02:52AM +0200, William 
>Stucke wrote:
> > RIR           MIN SIZE        ELIGIBILITY
> > APNIC         /20             /22
> > RIPE          /20             /22
> > LACNIC        /20             /22
> > ARIN          /20             /20
> >
> > In addition, in terms of "inter-registry policy coordination", RIPE
> > currently makes /22 allocations for their "Micro Members" and only requires
> > a demonstrated need for a /22, I believe. AfriNIC intends doing the same.
> > Why is ARIN out of step?
>
>I've never thought to ask the question before, but I agree 100% that
>ARIN is out of step, and wonder why.

It is not neccesary out of step.  RIRs have a strong relationship and 
coordination work, but this doesn't mean they are fixing policies according 
to others regions.

Policies are based on the caractheristics of the region that RIRs serve 
specially with IPv4 issues.


German Valdez
LACNIC Policy Liaison
Potos? 1517
Montevideo 11500 - Uruguay
Tel: +598 2 606 2822
Fax: +598 2 601 5509
www.lacnic.net 



From owen at delong.com  Wed Oct  1 13:40:07 2003
From: owen at delong.com (Owen DeLong)
Date: Wed, 01 Oct 2003 10:40:07 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the
 Africa Portion of the ARIN Region
In-Reply-To: <LPENICNLCKCKPNDPFKBAGEILEHAA.William@zanet.co.za>
References: <LPENICNLCKCKPNDPFKBAGEILEHAA.William@zanet.co.za>
Message-ID: <2147483647.1065004807@imac-en0.delong.sj.ca.us>

Fair enough.  I had not realized that they were not synonymous.  My
apologies.  I will endeavor to use the term sub-saharan Africa
hence forth.  Please understand that all of my previous posts
regarding "southern Africa" refer to the whole of that portion
of Africa served by ARIN.

Owen


--On Wednesday, October 1, 2003 11:00 AM +0200 William Stucke 
<William at zanet.co.za> wrote:

> Owen (and others) have said words along the lines of: -
>
>>  I am inclined to believe it would be good for *Southern Africa*
>
> Just to be strictly accurate, AfriNIC consists of six sub-regions: -
>
> North Africa
> East Africa
> West Africa
> Central Africa
> Southern Africa
> Indian Ocean
>
> The ARIN area includes *ALL* of these except for North Africa and Indian
> Ocean. That's why we use the term "sub-Saharan Africa", rather than
> "Southern Africa" ;-)
>
> Regards,
>
> William Stucke
> ZAnet Internet Services (Pty) Ltd
> +27 11 465 0700
> William at zanet.co.za
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.504 / Virus Database: 302 - Release Date: 2003/07/24
>




From owen at delong.com  Wed Oct  1 13:43:06 2003
From: owen at delong.com (Owen DeLong)
Date: Wed, 01 Oct 2003 10:43:06 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the
 Africa Portion of the ARIN Region
In-Reply-To: <LPENICNLCKCKPNDPFKBAGEINEHAA.William@zanet.co.za>
References: <LPENICNLCKCKPNDPFKBAGEINEHAA.William@zanet.co.za>
Message-ID: <2147483647.1065004986@imac-en0.delong.sj.ca.us>

Yes... That's why they need to be changed ARIN wide.

Owen


--On Wednesday, October 1, 2003 11:26 AM +0200 William Stucke 
<William at zanet.co.za> wrote:

> Raul said: -
>
>> This comparison is very incomplete.
>
> I know. I said: -
>
>> Adapted from ...
>
> ;-) I also gave the reference so that people could get the full story for
> themselves - which isn't quite true either, because RIPE will assign as
> small as a /29, as per Leo Vegoda's email.
>
> Nevertheless, I think that you will agree that ARIN's policies are the
> most restrictive of the four RIRs, in the sense of restricting the
> smaller ISP.
>
> Regards,
>
> William Stucke
> ZAnet Internet Services (Pty) Ltd
> +27 11 465 0700
> William at zanet.co.za
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.504 / Virus Database: 302 - Release Date: 2003/07/24
>




From owen at delong.com  Wed Oct  1 13:53:44 2003
From: owen at delong.com (Owen DeLong)
Date: Wed, 01 Oct 2003 10:53:44 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for th e
 Africa Portion of the ARIN Region
In-Reply-To: <200310011228.39616.gregm@datapro.co.za>
References: <20031001005559.GA88615@ussenterprise.ufp.org>
 <200310011228.39616.gregm@datapro.co.za>
Message-ID: <2147483647.1065005624@imac-en0.delong.sj.ca.us>

I absolutely want to echo what Gregory is saying here.  It is not fair
to judge 2003-15 on the lack of vocal support from Africa for 2002-3.

I think that Africa has been largely disenfranchised from the ARIN process
until very recently (possibly as recent as a couple of months ago), and
that has been most unfortunate.

I think we need to judge 2003-15 on it's merits.  I will be very surprised
if the people from Africa do not support 2002-3.  However, 2002-3 only
provides minimal relief, since it only allows for assignments and not
allocations.  Furhter, I think that a combined push for a /22 allocation
policy is needed.  I'm hoping that we can achieve that by amending 2003-15
and getting it passed at the next public policy meeting.

There is another possibility that has occured to me, but, I want to ask
some questions of some AC members before I publish it.  I'll try to get
it out later today or let you know that it was a non-starter.

Owen



From Stacy_Taylor at icgcomm.com  Wed Oct  1 14:01:13 2003
From: Stacy_Taylor at icgcomm.com (Taylor, Stacy)
Date: Wed, 1 Oct 2003 12:01:13 -0600 
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for th
	e Africa Portion of the ARIN Region
Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DAE457@DENEXG21>

Brilliantly put.
/S

-----Original Message-----
From: Jonathan Lydall [mailto:jonathan at ods.co.za]
Sent: Wednesday, October 01, 2003 10:21 AM
To: ppml at arin.net
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
Africa Portion of the ARIN Region


I was under the under the impression that each policy is "independent"
to each other, it's not like we are voting for a president, where we are
voting for one or the other? Can we not vote yes or no for both
policies? Surely then each policy will either be accepted or rejected by
their own merits or faults?

I acknowledge the frustration of other other list members pushing for
2003-03, however it is evident that a deadlock exists  or did exist and
hence the reason it has been going for a long time. Infact, the reason
Sub-Saharan African's have submitted their own independent policy
proposal is precisely because of this reason.

In regard to upstream providers, it goes without saying that they like
the way things are, the way that smaller ISPs can only change upstream
providers if they are willing to do massive IP address changes to all
their clients. Certainly they would be happy enough if things stayed the
way they are, however, they are certainly not opposing 2003-15, and a
couple of them are even for it, which implies that as a group we stand
together, to do what is best for the end user, and most importantly,
making people who have actually obtained internet at high expense, to
have made solid investment, which will not require time eating tasks
such as IP address renumbering.

While our Telecom is monopolistic, our upstream ISPs are not, and a
company like the one I work for definitely needs the ability to be able
to change upstream ISPs without the need of having to inconvenience
clients of ours who have mail servers or do web/application hosting and
especially DNS hosting. The ISP I work for would also greatly benefit by
plugging into our local up and running INX point, something where an ASN
for BGP would be incredibly useful.

Now, if I was only one of a few ISPs in this position I would understand
that it would shrugged off because it's the little guy whining, but the
majority of ISPs in this country are in a very similar position. We need
the smaller allocation / requirements so that we can meet the needs of
our clients, and provide what is best for them. By making action on our
side easier in the event of a problem, we can serve our clients better
by not interupting them.

The biggest drive is the INX points, with smaller requirements, the
relative number of ISPs connecting to these points will be huge, our INX
point will grow, making a lot more bandwidth available internal to our
country. 2003-15 will act aa highly effective catalyst to growth, and
more importantly, reliabilty of the internet where I live.

"Scale of economy" is the primary phrase here. Yes, while in a place
like North America, there may be a lot more ISPs than in Africa which
could also do with a policy like 2003-15, they may (I say may, because I
cannot truly say what the situation is like there), relatively speaking,
be the little guys. Where I live, by our standards, its not the "little
guy" who has current ARIN policy in their way, it is businesses which
are no longer considered start ups, have gotten over the hurdle of
starting out, and are here to stay.

We submitted this proposal, independently, because we are a united
region, all excited with the recent increase in growth of the internet
in our region, and very excited for the not so distant day when AfriNIC
starts allocating out IP addresses for itself. While we cannot ignore or
forget the rest of our collegues under the ARIN region, our part of the
region is different to them. You cannot ignore the significant number of
increases to mailing list form our region, and we are now hearing th
voice of other members on this list.

Now, I encourage all the recent additions to mailing list (myself
included) from the Sub-saharan region to carry on pushing for this goal
we've set out to achieve, a goal which will benefit all in this region,
to carry on trying to prove the necessity of 2003-15, and to not sway,
as it is important for a lot of us that it gets passed ASAP, without a
delay of an ammendment to the proposal. But more importantly, we must
all realise that we are part of a worldwide community, and we are not
the only ones with problems and hinderances, with our eyes opened more
widely to the problems that other regions are experiencing, it is our
duty to support policies such as 2003-03.

Jonathan Lydall,

Online Digital Solutions. 


From bicknell at ufp.org  Wed Oct  1 14:01:49 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 1 Oct 2003 14:01:49 -0400
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <6.0.0.22.0.20031001140325.045bbae8@lacnic.net.uy>
References: <Pine.GSO.4.44.0309291103460.8405-100000@paixhost.pch.net> <LPENICNLCKCKPNDPFKBACEIBEHAA.William@zanet.co.za> <E1A4Rc3-0006vZ-DQ@ran.psg.com> <LPENICNLCKCKPNDPFKBAKEHPEHAA.William@zanet.co.za> <20031001005559.GA88615@ussenterprise.ufp.org> <6.0.0.22.0.20031001140325.045bbae8@lacnic.net.uy>
Message-ID: <20031001180149.GA24653@ussenterprise.ufp.org>

In a message written on Wed, Oct 01, 2003 at 02:07:28PM -0500, German Valdez wrote:
> It is not neccesary out of step.  RIRs have a strong relationship and 
> coordination work, but this doesn't mean they are fixing policies according 
> to others regions.

I do believe all the RIR's should have similar, if not identical
policies when it comes to IPv4 allocation and assignment criteria.
That's not to say they will always be 100% the same, in general
policy changes will need to start somewhere or be tested somewhere
first...but I really believe that when dealing with the global
numbering issue that affects a large number of global companies the
rules should be as identical as possible.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031001/be65388b/attachment.sig>

From owen at delong.com  Wed Oct  1 14:11:08 2003
From: owen at delong.com (Owen DeLong)
Date: Wed, 01 Oct 2003 11:11:08 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the
 Africa Portion of the ARIN Region
In-Reply-To: <20031001141303.GA14561@ussenterprise.ufp.org>
References: <20031001005559.GA88615@ussenterprise.ufp.org>
 <200310011228.39616.gregm@datapro.co.za>
 <20031001005559.GA88615@ussenterprise.ufp.org>
 <LPENICNLCKCKPNDPFKBAGEIMEHAA.William@zanet.co.za>
 <web-1781374@multicasttech.com>
 <2147483647.1064958913@dhcp157-204.corp.tellme.com>
 <20031001141303.GA14561@ussenterprise.ufp.org>
Message-ID: <2147483647.1065006668@imac-en0.delong.sj.ca.us>

> In a message written on Wed, Oct 01, 2003 at 12:28:39PM +0200, Gregory
> Massel wrote:
>> Leo, maybe I'm misreading you, but the impression I get is that you're
>> saying  you're concerned to support "Africa People" because they were
>> not vocal  earlier in the year.
>
> No, that is not the reason at all.  The reason is that I fear they
> are derailing an existing process to get 2002-3 passed.  The fact
> that they were not vocal as an issue by itself has little meaning
> to me, but the fact that they didn't take the time to look that
> there was existing discussion and proposals that would do what they
> want in the process already before introducing their own does concern
> me.
>
Leo,
	That is an unfair characterization.  By the time they were
aware to look, the allocation-specific portions of the proposals on the
table were dead.  That is not their fault.

> I can understand that, as I joined myself not all that long ago.
> However, participating on a mailing list and introducing a policy
> are two different things.  Before you introduce a policy you need
> to do more research and make sure you're not stepping on other toes.
> That seems to have not been done.  Moreover, some people here who
> have indicated they have "participated" (to what degree I don't
> know) in the AfriNIC meetings/proposals are long time list members,
> who clearly didn't step up and point out efforts were already going
> on to fix this problem.
>
Their policy proposal does not step on any toes that were visible
when they opened the door.  It is unfortunate that they were not more
aware of the history of the proposals, but, in their current form, there
is no other proposal that grants allocations of /22s.  Their actions were
reasonable from the context they had to work with.  That having been said,
I think it is too important to get allocations of /22s for all of ARIN to
allow a partial policy to pass to the potential exclusion of an all-ARIN
policy.

>> I have not yet seen a single posting from any one of the "Africa People"
>> rejecting 2002-3, although I have seen quite a number supporting it.
>
> No one has rejected it as bad, a few have refused to support it though,
> prefering their own amendment.
>
Do you not think that this helps make Leo's case about splitting the vote?

>> So if were talking about standing united, then it means we all have to
>> give  and take a bit. The best compromise I've seen to date is that we
>> all stand  united in support of both 2002-3 and 2003-15. This is the
>> only win-win  situation for all that does not involve the excessive
>> delays that amending  either or both policies would introduce.
>
> With both we still have the potential to have split votes.  Thus I
> consider having both (fully supported) is risker than having just one.
> Also, on a side note to the concensus talk, I still have a problem with
> region specific policy, particularly when global policy is also on the
> table.
>
Again, I advocate supporting both policies, but, only if we can amend
2003-15 to be an all-ARIN solution.  (use of the term global is dangerous
because others will be quick to point out we can't affect RIPE/APNIC/LACNIC
policies).  I have an idea on how we might be able to make this work.  I'm
waiting for a reply from an AC member to find out if it is workable within
the ARIN process.  As soon as I hear back, I'll let the list know.

Again, Leo, and others that think as I do that 2003-15 needs to be an
all-ARIN policy, please don't be critical of the AfriNIC people for
proposing it.  It is definitely not their fault they have been late
to the party.  Further, such criticisms or accusations will only serve
to further divide us and create perceptions that we don't understand
their situation.  We need to do all that we can to understand their
position and embrace their support for good policy while encouraging
them to accept it as good policy for ALL of ARIN, not just sub-saharan
Africa.

Owen



From owen at delong.com  Wed Oct  1 14:23:46 2003
From: owen at delong.com (Owen DeLong)
Date: Wed, 01 Oct 2003 11:23:46 -0700
Subject: [ppml] My idea was a non-starter
Message-ID: <2147483647.1065007426@imac-en0.delong.sj.ca.us>

Just got word back.  The idea I had for expiditing 2003-15 for Africa, while
still tying it to getting what is needed for all of ARIN would still delay
it, so, I think our best bet is still:

	Pass 2002-3 as is at this meeting.
	Amend 2003-15 to be ARIN-wide and ask the AC to fast track it
		for approval at the next meeting.

Owen



From lee.howard at mci.com  Wed Oct  1 17:04:58 2003
From: lee.howard at mci.com (Lee Howard)
Date: Wed, 1 Oct 2003 17:04:58 -0400 (EDT)
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
In-Reply-To: <Pine.GSO.4.44.0310010323530.11780-100000@paixhost.pch.net>
Message-ID: <Pine.GSO.4.20.0310011641370.3089-100000@sun222-31.corp.us.uu.net>


On Wed, 1 Oct 2003, Bill Woodcock wrote:

> Date: Wed, 01 Oct 2003 03:25:19 -0700 (PDT)
> From: Bill Woodcock <woody at pch.net>
> To: Mury <mury at goldengate.net>
> Cc: William Stucke <William at zanet.co.za>, ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for
>     the Africa Portion of the ARIN Region
> 
>       On Wed, 1 Oct 2003, Mury wrote:
>     > If the problem lies with these monopolies not giving IPs to their
>     > downstream customers, why are they going to cooperate and route IPs
>     > allocated from ARIN?
> 
> Again, nobody asks them to cooperate.  ISPs simply tunnel through them,
> and announce the prefixes to transit providers in other locations where
> market forces make them more cooperative.
> 
>                                 -Bill

I'm still confused, trying to draw a network diagram and see if I 
understand the situation.  

Let's say I'm Joe Bob's ISP, Bait and Tackle in Botswana. 

I have 1000 dial-up ports, but my tyrannical upstream (who I'm legally
obligated to use because it's a government/monopoly PTT) won't give me
more than a /26 because I might be competing with them.  Or because
they don't understand that my plan to multihome means I justify a /24,
and that they can apply to ARIN for more space when they've used 80%.

Cleverly using traceroute, I find that BotswanaNet.bw has connectivity
through MegaISP.za, so I call up MegaISP.za and explain my plight.  
They sympathize with me and the money I offer them, and they allocate
me a /22 so I can now number all of my equipment, and we set up a GRE
tunnel (to an address from my .bw IP space) so I can route that /22.  
However, I still can't multihome, because AnotherISP.za is not going
to accept MegaISP.za address space coming from me. 

To compound the problem, either A) I can't afford a leased line to
either big ISP or B) Botswana law prohibits me from using another
provider.  I may actually be breaking the law by using non-Botswanan
address space.

This is the most common configuration in sub-equatorial Africa?

I have no position on this policy proposal--I don't understand the
need for it well enough to judge.  I am grateful for the participation
of the African community, and I hope we'll continue to see you on
other policy discussions.


Lee



*  Sorry for picking on Botswana and South Africa in particular.




From gregm at datapro.co.za  Wed Oct  1 18:38:43 2003
From: gregm at datapro.co.za (Gregory Massel)
Date: Thu, 2 Oct 2003 00:38:43 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
References: <Pine.GSO.4.20.0310011641370.3089-100000@sun222-31.corp.us.uu.net>
Message-ID: <009801c3886c$c4beccf0$0a1929c4@tipsy>

> Cleverly using traceroute, I find that BotswanaNet.bw has connectivity
> through MegaISP.za, so I call up MegaISP.za and explain my plight.
> They sympathize with me and the money I offer them, and they allocate
> me a /22 so I can now number all of my equipment, and we set up a GRE
> tunnel (to an address from my .bw IP space) so I can route that /22.
> However, I still can't multihome, because AnotherISP.za is not going
> to accept MegaISP.za address space coming from me.

I'd like to clarify this. As Rosi mentioned, many ZA ISPs will allow you to
advertise another providers address space to them if that other provider
consents. In fact, I recently had discussions with Rosi on such a topic. I
was able to deal with my client's request really quickly because I'd met
Rosi before, knew to speak to her and we were on good terms despite working
for competing companies.

The problems I've seen with this, however, are:
1. You cannot just accept announcements of another ISP's address space
without their consent. Eg. In the aforementioned case, the client had
cancelled service and the addresses he wanted me to accept were no longer
allocated to him!!!

2. Most  ISPs only advertise their supernet aggregates upstream. If you're
trying to multihome, this causes the route to be preferred by your other
upstream provider since the announcement doesn't form part of their
supernets and is more specific down that path.

3. ZA has a pretty competitive ISP industry, signficant routing expertise,
and a small enough ISP industry for us to know who to contact. In many other
parts of Africa, there are anti-competitive forces at play, politics, lack
of technical understanding, etc. Also, if you're multi-homing between ISPs
in multiple countries, you cannot expect that the ISPs will be as
co-operative. I may co-operate with Rosi regarding a mutual client because I
trust her and the ISP she works for. If, however, an ISP I'd never heard of
asked me if they could announce my address space on behalf of a mutual
client, I'd be very hesitant because I'd have almost no guarantee that if
the client cancelled their service with me that I'd be able to recover that
address space.

I hope this clarifies why it is generally not practical to multi-home
without your own address allocation.

> To compound the problem, either A) I can't afford a leased line to
> either big ISP or B) Botswana law prohibits me from using another
> provider.  I may actually be breaking the law by using non-Botswanan
> address space.

I stand to be corrected on this, but to the best of my knowlege there is not
a single African country that regulates how you - as an ISP - route your
traffic or obtain addresses.

In fact, the problem is that most communications legislation is so old or
backward-thinking that its restrictions are specifically aimed at upholding
existing monopolies which tend to be around telco services.

So as an ISP, your typical restriction is that you have to buy your
leased-line from the monopoly telco. This gives them the leverage to refuse
to provide you with a leased-line to an upstream ISP in another country and
force you to buy IP transit through them.

> This is the most common configuration in sub-equatorial Africa?

I don't believe this to be the case. In many situations, the legislation is
reasonable enough to allow you to connect to whomever you like. However,
where it is hopeless is in price control. This means that the monopoly telco
in almost every African country will sell you IP transit for a fraction of
the cost of a leased-line to another IP transit provider in another country
(typically 1/10th to 1/100th). In this way, they never have to refuse to
provide service and risk legal challenges, because they simply make sure
that any ISP who purchases an international leased-circuit will pay so much
that their charges to clients for IP access will have to be 10-100 times as
much as the telco's.

Regards
Greg




From calvin at orange-tree.alt.za  Thu Oct  2 01:01:33 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 02 Oct 2003 07:01:33 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
	Africa Portion of the ARIN Region
In-Reply-To: <Pine.GSO.4.20.0310011641370.3089-100000@sun222-31.corp.us.uu.net>
References: 	 <Pine.GSO.4.20.0310011641370.3089-100000@sun222-31.corp.us.uu.net>
Message-ID: <1065070893.9453.40.camel@pear.orange-tree.alt.za>

Lee,

On Wed, 2003-10-01 at 23:04, Lee Howard wrote:
> On Wed, 1 Oct 2003, Bill Woodcock wrote:
> 
> > Date: Wed, 01 Oct 2003 03:25:19 -0700 (PDT)
> > From: Bill Woodcock <woody at pch.net>
> > To: Mury <mury at goldengate.net>
> > Cc: William Stucke <William at zanet.co.za>, ppml at arin.net
> > Subject: RE: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for
> >     the Africa Portion of the ARIN Region
> > 
> >       On Wed, 1 Oct 2003, Mury wrote:
> >     > If the problem lies with these monopolies not giving IPs to their
> >     > downstream customers, why are they going to cooperate and route IPs
> >     > allocated from ARIN?
> > 
> > Again, nobody asks them to cooperate.  ISPs simply tunnel through them,
> > and announce the prefixes to transit providers in other locations where
> > market forces make them more cooperative.
> > 
> >                                 -Bill
> 
> I'm still confused, trying to draw a network diagram and see if I 
> understand the situation.  

some slight confusion - generally the provision of ISP services is
'competitive' - in that any one can provide the services. It generally
has to be done over the monopoly PTT's copper. The PTT is also an ISP.
There are normally a couple of first tier ISP's with their links
overseas leased through the monopoly PTT. Sometimes there may even be
more than one International provider (just DON'T use VoIP!).

Having a look at http://ispmap.org.za/ particularly the previous maps
might help understand it further.

> 
> Let's say I'm Joe Bob's ISP, Bait and Tackle in Botswana. 
> 
> I have 1000 dial-up ports, but my tyrannical upstream (who I'm legally
> obligated to use because it's a government/monopoly PTT) won't give me
> more than a /26 because I might be competing with them.  Or because
> they don't understand that my plan to multihome means I justify a /24,
> and that they can apply to ARIN for more space when they've used 80%.
> 
> Cleverly using traceroute, I find that BotswanaNet.bw has connectivity
> through MegaISP.za, so I call up MegaISP.za and explain my plight.  
> They sympathize with me and the money I offer them, and they allocate
> me a /22 so I can now number all of my equipment, and we set up a GRE
> tunnel (to an address from my .bw IP space) so I can route that /22.  
> However, I still can't multihome, because AnotherISP.za is not going
> to accept MegaISP.za address space coming from me. 
> 
> To compound the problem, either A) I can't afford a leased line to
> either big ISP or B) Botswana law prohibits me from using another
> provider.  I may actually be breaking the law by using non-Botswanan
> address space.

we generally need to distinguish between Telco Provider and ISP
provider. I've yet to see a place where IP address space was legislated
(although the SA monopoly PTT did try to have IP declared in their
exclusive domain and a telecoms service).

> 
> This is the most common configuration in sub-equatorial Africa?
> 
> I have no position on this policy proposal--I don't understand the
> need for it well enough to judge.  I am grateful for the participation
> of the African community, and I hope we'll continue to see you on
> other policy discussions.

I'm still uncomfortable with AfriNIC people getting involved with
2002-3. I don't know enough about N. American networking to understand
it. Anyone who sees me supporting 2002-3 needs to weigh up that fact and
adjust my support accordingly (This should by no means be interpreted as
saying that 2002-3 should not be passed, just that *I* have no idea).
But when it comes to Africa, well, in the past month or two, I've
interacted with Kenyans, Ghanaians, Zimbabweans, Rwandans, Tanzanians,
Tunisian, Mozambicans, Sudanese and in fact, yesterday I got a call from
someone involved with the regulator in Botswana asking about setting up
a peering point (I'm going to put him onto the appropriate people
shortly as this is not my forte).

> 
> 
> Lee

--Calvin

> 
> 
> 
> *  Sorry for picking on Botswana and South Africa in particular.
> 

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------


From calvin at orange-tree.alt.za  Thu Oct  2 01:37:20 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 02 Oct 2003 07:37:20 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
	Africa Portion of the ARIN Region
In-Reply-To: <2147483647.1065001551@imac-en0.delong.sj.ca.us>
References: <Pine.GSO.4.44.0309291103460.8405-100000@paixhost.pch.net>
	 <LPENICNLCKCKPNDPFKBACEIBEHAA.William@zanet.co.za>
	 <E1A4Rc3-0006vZ-DQ@ran.psg.com>
	 <LPENICNLCKCKPNDPFKBAKEHPEHAA.William@zanet.co.za>
	 <20031001005559.GA88615@ussenterprise.ufp.org>
	 <1064986004.8397.10.camel@pear.orange-tree.alt.za>
	 <2147483647.1065001551@imac-en0.delong.sj.ca.us>
Message-ID: <1065073040.9453.77.camel@pear.orange-tree.alt.za>

On Wed, 2003-10-01 at 18:45, Owen DeLong wrote:
> > As someone who has no knowledge of the North American networking scene,
> > I'd be hard pressed to support or go against anything proposed for that
> > region. I'd prefer those people to sort out their stuff in a way that
> > suits them. In fact, it would be extremely arrogant and rude of me to
> > adopt any other line.
> > The converse if course, applies.
> >
> 
> Right... since 2002-3 will affect sub-saharan Africa, decide on it based
> on whether you think it is a positive of negative effect for sub-saharan
> Africa or all of ARIN.  You can decide that.

No I can't decide on 2002-3 on this basis. Even though 2002-3 will bring
the region I know about and am involved in, the relief it needs, tying
the two together is just wrong. This is not a judgment on 2002-3, just a
reminder that the relief it will bring me is inadvertent.

> 
> The point Leo and I are making is that it is one thing for us to weigh
> in and/or make policy for ARIN as a single region which we are a part of.
> In that case, we have a stake in the process, and, we are representing
> our views of what should be for something we are part of.

I think that you and Leo and everyone else should ignore the sub-saharan
region's needs when assessing 2002-3.

> 
> It is arrogant and presumptuous for us to attempt to dictate policy for
> an area we are not part of.  It is even worse for us to vote in favor
> of something we think is needed where we are, but, only to give it
> to someone else at the exclusion of the area we are actually in.

I believe you shouldn't even be in this position. Maybe 2002-3 should
actually have wording to the effect of something like 'This only applies
to blocks allocated to the N. American region of arin. The blocks
allocated to the Sub-Saharan region will have separate policies as
decided by the members in that region'.

As Randy indicated 2003-15 is a hack.

> 
> For us to vote in favor of 2003-15 in it's current form would be equivalant
> to handing our neighbor a band-aid while we continue to bleed, since we
> think our neighbor might have a bigger cut the bandaid won't actually
> handle.

Remember - AfriNIC will happen. I believe late next year. Then the
neighbors will pass what they need for them anyway. And then their
policies will have as much effect on arin's policies as lacnic's, ripe's
and apnic's have on arin right now.

> 
> Owen

I really think you want to debate 2002-3 on its merits and leave the
bleeding(hearts) out of it.

regards

--Calvin

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------


From mlawrie at zanet.co.za  Thu Oct  2 01:53:54 2003
From: mlawrie at zanet.co.za (mlawrie at zanet.co.za)
Date: Thu, 02 Oct 2003 07:53:54 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <2147483647.1065007426@imac-en0.delong.sj.ca.us>
Message-ID: <3F7BD992.21549.440E36@localhost>

Owen DeLong wrote:-

> Just got word back.  The idea I had for expiditing 2003-15 for Africa,
> while still tying it to getting what is needed for all of ARIN would
> still delay it,.....

...yet your "best bet" proposal will also delay 2003-15 by at least 
one meeting.....


>.... so, I think our best bet is still:
> 
>  Pass 2002-3 as is at this meeting.
>  Amend 2003-15 to be ARIN-wide and ask the AC to fast track it
>   for approval at the next meeting.

The position of that word "still" is open to debate, it implies that 
at some stage the agreed best bet actually *was* as you propose, and 
this is not the case. Perhaps you "still think" as per your (not 
"our") best bet, and many "still disagree" with your thinking.

It is easy to read from your proposal that

a) you accept that 2002-3 is inadequate, because you concede that 
2003-15 is necessary in some form or other as well

b) you are willing to delay a desparately needed 2003-15 for the sole 
reason that you don't wish *anyone* to get what they are asking for 
until *everyone* can get this as well, even though no one has 
submitted a proposal requesting this and could have done so had they 
wished

c) you don't believe that getting a concession for one area of ARIN's 
control eases the path for subsequently extending that concession, 
which belief runs contrary to a great deal of experience.

IMHO, the best action is

   Decouple 2002-3 from 2003-15
   Deal with each proposal on its individual merits
   Deal with extending 2003-15 (were this needed) at a later meeting

Mike
-- 
Mike Lawrie.
Ph +27 12 348 0944 or 072 480 8898
<mlawrie at zanet.co.za>


From william at elan.net  Thu Oct  2 00:15:48 2003
From: william at elan.net (william at elan.net)
Date: Wed, 1 Oct 2003 21:15:48 -0700 (PDT)
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for  the
 Africa Portion of the ARIN Region
In-Reply-To: <2147483647.1065004986@imac-en0.delong.sj.ca.us>
Message-ID: <Pine.LNX.4.44.0310010816340.17208-100000@sokol.elan.net>

On Wed, 1 Oct 2003, Owen DeLong wrote:

> > Nevertheless, I think that you will agree that ARIN's policies are the
> > most restrictive of the four RIRs, in the sense of restricting the
> > smaller ISP.
> Yes... That's why they need to be changed ARIN wide.

I completely agree and have voiced this opinion for last several years on 
ARIN meetings (sometimes the only one saying this). I very much want ARIN 
to be less centric towards policies that benefit larger ISPs and businesses
and want them to provide micro-allocations like this is done at other RIRs.

But, at the same time, I do not think that blocking AfriNIC proposal (don't
pick on the wording here) in order to achieve these ARIN goals is fair 
practice and its also disregarding their immediate needs and as others 
pointed, ultimately it would yet again show how americans take their
self-interests above everything else in the rest of the world.

I think the best way to do is to allow south africans those micro-allocations
(in part to have more members from that area for future AfriNIC) and work 
separately towards extending 2002-3 to include micro-allocations or 
possibly making micro-assignments something "neutral" which includes 
notion of micro-allocations (i.e. companies that got micro-assignment 
block can if they want subswip it to their customers as if it was a 
micro-allocation).

---
William Leibzon
Elan Networks
william at elan.net



From bs at lantic.net  Thu Oct  2 04:26:48 2003
From: bs at lantic.net (Byron Sorgdrager)
Date: Thu, 2 Oct 2003 10:26:48 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <3F7BD992.21549.440E36@localhost>
References: <3F7BD992.21549.440E36@localhost>
Message-ID: <200310021026.48258.bs@lantic.net>

The way I understand policy 2002-3, is it's design is to give smaller ISP's in 
North America some relief. (This would also impact on the African Region of 
ARIN).

I know what the smaller ISP's go through (from an African perspective of 
course), so in this sense I would support the proposal.

As Calvin Browne mentioned, I don't have ENOUGH of a grasp on how/what the 
American Internet politics are like, but I do understand the plight of the 
"little guy"....

Based on this understanding alone, I would support 2002-3. But I also support 
2003-15, since it directly impacts on African ISP's...

If BOTH can get passed, we ALL win ! I don't however see that 2002-3 and 
2003-15 should be linked in any way. 

Any other takers for helping not just ourselves, but the Americans as well 
(since they ARE trying to help us in return) ?

One last question though, is it too late to add another proposal ? Once that 
would include maybe a combination of the best parts out of both proposals? 
(just thinking of increasing all of our chances to get what we want/need 
passed without delay)

Byron Sorgdrager
(speaking, as usual, for myself)

-- 
Every word is like an unnecessary stain on silence and nothingness.
                -- Beckett




************************************************************
Scanned by @lantic IS Virus Control Service
This message was scanned for viruses and dangerous content.
@lantic Internet Services (Pty) Ltd. - http://www.lantic.net
eScan for Windows-based PCs - http://www.escan.co.za
************************************************************



From Michael.Dillon at radianz.com  Thu Oct  2 05:53:30 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Thu, 2 Oct 2003 10:53:30 +0100
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa
 Portion of the ARIN Region
Message-ID: <OF42663C82.3EFD2D84-ON80256DB3.00350CA7-80256DB3.00365620@radianz.com>

>I was under the under the impression that each policy is "independent"
>to each other, it's not like we are voting for a president, where we are
>voting for one or the other? Can we not vote yes or no for both
>policies? Surely then each policy will either be accepted or rejected by
>their own merits or faults?

Indeed you are correct. There is nothing stopping
people from supporting both policies or any combination
of policies. 

I believe that supporting 2003-15 has nothing to
do with addressing and everything to do with
supporting Africans in setting the policies for
their own region. I don't particularly care 
what the wording is in 2003-15 because the
fundamental truth is that Afrinic supports
this policy officially and the African ISPs
in the ARIN region also support it. Therefore
I would pass this policy regardless of its
content even if I thought that the content
was bad policy.

I don't pretend to fully understand the
social, political and legal climate in the
many countries of the African continent and
I will not suggest any particular alternatives
to them because I don't want to be counselling
people to break the laws of their country.

As far as I'm concerned, there is no relation
between 2003-15 and any of the policy
proposals that we are discussing for the
core North American ARIN region.

>Now, I encourage all the recent additions to mailing list (myself
>included) from the Sub-saharan region to carry on pushing for this goal
>we've set out to achieve, a goal which will benefit all in this region,

Remember that ARIN does not make policy 
DECISIONS on this mailing list and that 
the ARIN members meeting vote does not 
directly determine policy. Once the members
meeting has voted, the proposal goes to
the Advisory Council who may make changes
before they make a recommendation to the
Board of Trustees. The Board will then 
consider the recommendation from the AC
in conjunction with the input from other
sources, i.e. mailing list, meeting votes,
opinions polls, letters, petitions, consultation
with ARIN's lawyer, etc. After this, the
Board makes the actual decision about the
new policy.

I suggest that African ISPs from the African
countries that are still served by ARIN
should all sign a letter and post it to
the ARIN Board of Trustees. It would be
best for all of you to agree on the wording
of the letter on your own mailing list and
then each person can print and post their
own copy from their own country on company
letterhead. No guarantees, but if there
truly is consensus in the ARIN African
countries, this will clearly demonstrate
it to the Board.

--Michael Dillon

P.S. The rest of ARIN has wasted too much
time on this issue already. It is something
which has zero impact on ISPs operating
in North America.






From Michael.Dillon at radianz.com  Thu Oct  2 05:59:17 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Thu, 2 Oct 2003 10:59:17 +0100
Subject: [ppml] My idea was a non-starter
Message-ID: <OFE9630010.F425F1DF-ON80256DB3.003698D4-80256DB3.0036DDE3@radianz.com>

>I think our best bet is still:
>                Pass 2002-3 as is at this meeting.
>                Amend 2003-15 to be ARIN-wide and ask the AC to fast 
track it
>                                for approval at the next meeting.

I think our best bet is:
    Pass 2003-15 as is at this meeting
    Pass 2003-3 as is at this meeting
    Introduce a new proposal to cover the missing 
            bits from 2003-3 for the next meeting.

That's assuming that you think the specifics from 2003-15 should apply to 
North America.

---Michael Dillon



From ahp at hilander.com  Thu Oct  2 09:38:09 2003
From: ahp at hilander.com (Alec H. Peterson)
Date: Thu, 02 Oct 2003 07:38:09 -0600
Subject: [ppml] My idea was a non-starter
In-Reply-To: <OFE9630010.F425F1DF-ON80256DB3.003698D4-80256DB3.0036DDE3@radianz.com>
References: <OFE9630010.F425F1DF-ON80256DB3.003698D4-80256DB3.0036DDE3@radia
 nz.com>
Message-ID: <1272596478.1065080289@[192.168.0.101]>

As it happens the information Owen had about how the policy process works 
(which came from me) was not entirely correct.  We can indeed change the 
content of 2002-3 and/or 2003-15 without another policy cycle provided 
there is general consensus for said changes.  I'm not exactly sure why I 
thought anything else was the case, it probably has to do with the fact 
that we have never had anything close to consensus on anything related to 
ARIN's minimum allocation size, so another policy cycle has always been 
necessary.  At any rate, I apologize for misleading people about that.

So, as far as how to move forward, at this point the AC is considered the 
'author' for 2002-3 (the original authors did not want to continue work on 
it).  So the people on the AC who have been working on 2002-3 have been 
following the discussion and will decide on an appropriate plan of attack. 
2003-15 is not an AC proposal at this point, so any changes made to it 
prior to the AC meeting will probably need to be initiated by said 
author[s].

Note that consensus on these issues is far from guaranteed, as we've 
already been through several policy cycles without much luck, but hopefully 
the compromise the AC has tried to strike with 2002-3 will allow things to 
finally move forward.

Alec
Chair, ARIN AC



From lee.howard at mci.com  Thu Oct  2 10:31:47 2003
From: lee.howard at mci.com (Lee Howard)
Date: Thu, 2 Oct 2003 10:31:47 -0400 (EDT)
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
In-Reply-To: <009801c3886c$c4beccf0$0a1929c4@tipsy>
Message-ID: <Pine.GSO.4.20.0310020949180.3089-100000@sun222-31.corp.us.uu.net>

On Thu, 2 Oct 2003, Gregory Massel wrote:

> Date: Thu, 02 Oct 2003 00:38:43 +0200
> From: Gregory Massel <gregm at datapro.co.za>
> To: Lee Howard <lee.howard at mci.com>, Bill Woodcock <woody at pch.net>
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for
>     the Africa Portion of the ARIN Region
> 
> 
> I'd like to clarify this. As Rosi mentioned, many ZA ISPs will allow you to
> advertise another providers address space to them if that other provider
> consents. In fact, I recently had discussions with Rosi on such a topic. I
> was able to deal with my client's request really quickly because I'd met
> Rosi before, knew to speak to her and we were on good terms despite working
> for competing companies.
> 
> The problems I've seen with this, however, are:
> 1. You cannot just accept announcements of another ISP's address space
> without their consent. Eg. In the aforementioned case, the client had
> cancelled service and the addresses he wanted me to accept were no longer
> allocated to him!!!

Well yes, that's true, the client can not use that address space.  But
you or another provider could assign address space to that client.


> 2. Most  ISPs only advertise their supernet aggregates upstream. If you're
> trying to multihome, this causes the route to be preferred by your other
> upstream provider since the announcement doesn't form part of their
> supernets and is more specific down that path.

I don't understand.  When I say "multi-homing" I mean "announcing my
assigned prefixes to two or more autonomous systems which transit my
traffic by propagating my announcments as originating from my ASN."  
Suppressing more-specifics that originate from a downstream AS 
defeats the purpose of BGP.

If Leet Networking buys transit from MCI and Sprint, we may assign 
them a /23 based on their utilization.  We'll announce our /12 as
originating from AS701, but we'll also propagate the /23 from AS37337.

Elsewhere people have said that upstreams' peers would not accept the
prefixes because they were too small.  That should not be the case,
for two reasons:

 - ARIN allocations to Africa are from Class C space, and are not
	generally filtered at shorter prefix-length.  Your mileage 
	may vary.
 - Multi-homing is sufficient justification for a /24 re-assignment


> 3. ZA has a pretty competitive ISP industry, signficant routing expertise,
> and a small enough ISP industry for us to know who to contact. In many other
> parts of Africa, there are anti-competitive forces at play, politics, lack
> of technical understanding, etc. Also, if you're multi-homing between ISPs
> in multiple countries, you cannot expect that the ISPs will be as
> co-operative. I may co-operate with Rosi regarding a mutual client because I
> trust her and the ISP she works for. If, however, an ISP I'd never heard of
> asked me if they could announce my address space on behalf of a mutual
> client, I'd be very hesitant because I'd have almost no guarantee that if
> the client cancelled their service with me that I'd be able to recover that
> address space.

This is a problem we generally don't encounter in the rest of the world
(including North and South America, Europe, and Asia, in my experience).
If I call the NOC at an ISP (using the number in SWIP or WHOIS) and say,
"Stop announcing my prefixes" they'll check the appropriate databases
(SWIP, RIPE, RADB) to verify that the space is not assigned to their 
customer, and stop announcing it.

To all of our friends in sub-equatorial Africa:
Is this a major problem?
Does this problem generally result from ignorance or malice?


> > To compound the problem, either A) I can't afford a leased line to
> > either big ISP or B) Botswana law prohibits me from using another
> > provider.  I may actually be breaking the law by using non-Botswanan
> > address space.
> 
> I stand to be corrected on this, but to the best of my knowlege there is not
> a single African country that regulates how you - as an ISP - route your
> traffic or obtain addresses.
> 
> In fact, the problem is that most communications legislation is so old or
> backward-thinking that its restrictions are specifically aimed at upholding
> existing monopolies which tend to be around telco services.
> 
> So as an ISP, your typical restriction is that you have to buy your
> leased-line from the monopoly telco. This gives them the leverage to refuse
> to provide you with a leased-line to an upstream ISP in another country and
> force you to buy IP transit through them.

That's unfair and not in the economic interest of the nation.  But how
will ARIN policy redress the unfairness?  


> 
> > This is the most common configuration in sub-equatorial Africa?
> 
> I don't believe this to be the case. In many situations, the legislation is
> reasonable enough to allow you to connect to whomever you like. However,
> where it is hopeless is in price control. This means that the monopoly telco
> in almost every African country will sell you IP transit for a fraction of
> the cost of a leased-line to another IP transit provider in another country
> (typically 1/10th to 1/100th). In this way, they never have to refuse to
> provide service and risk legal challenges, because they simply make sure
> that any ISP who purchases an international leased-circuit will pay so much
> that their charges to clients for IP access will have to be 10-100 times as
> much as the telco's.

I think I may be conflating two different topologies in my head.

There's topology A, which you described in the top half of the post,
where the little guy flits back and forth between the lowest-cost ISP
(always using PTT copper, of course) and needs PI (Provider-Independent)
space to save from having to renumber every time, and to improve his
chances of having his prefixes routed properly.

There's topology B, where the only affordable transit provider is the
PTT.  ARIN policy cannot redress this situation, and we just leave this
whole section out of this debate.  

Let me know if I'm spiraling in toward accurate understanding of the
situation in Africa.

> Regards
> Greg

Thanks for taking the time and having the patience to help me improve
my understanding.

Lee




From owen at delong.com  Thu Oct  2 15:53:15 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 02 Oct 2003 12:53:15 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
In-Reply-To: <200310021026.48258.bs@lantic.net>
References: <3F7BD992.21549.440E36@localhost>
 <200310021026.48258.bs@lantic.net>
Message-ID: <2147483647.1065099195@imac-en0.delong.sj.ca.us>



--On Thursday, October 2, 2003 10:26 AM +0200 Byron Sorgdrager 
<bs at lantic.net> wrote:

> The way I understand policy 2002-3, is it's design is to give smaller
> ISP's in  North America some relief. (This would also impact on the
> African Region of  ARIN).
>
Sort of.  2002-3 will actually give no permanent relief to ISPs.  It 
provides
only for assignments to end users from ARIN, and does not facilitate
allocations to ISPs.

> I know what the smaller ISP's go through (from an African perspective of
> course), so in this sense I would support the proposal.
>
> As Calvin Browne mentioned, I don't have ENOUGH of a grasp on how/what
> the  American Internet politics are like, but I do understand the plight
> of the  "little guy"....
>
Good... That is a very good start.  Now, if we can extend that understanding
to realize that 2002-3 provides good relief for end users, but, only
marginal/questionable relief for small(er) ISPs, we get a step closer.
Then, the next step is to realize that small(er) ISPs have asked for and
tried to get policy for allocations.  Indeed, at the last ARIN meeting
and the previous ARIN meeting, there were a number of proposals very
similar to 2003-15, but, for all of ARIN.  These proposals all got rolled
by the AC into 2002-3.  For various reasons, and, with much debate, the
AC decided to restrict 2002-3 to assignments, while, many of the comments
called for allocations and assignments.  That is why 2003-15 as is would
disenfranchise those who have supported allocations for so long.  That is
why I cannot abide it unless it is all-ARIN policy.

> Based on this understanding alone, I would support 2002-3. But I also
> support  2003-15, since it directly impacts on African ISP's...
>
Cool.  Hopefully by applying the above expanded understanding you will
come to realize the need to expand the scope of 2003-15.

> If BOTH can get passed, we ALL win ! I don't however see that 2002-3 and
> 2003-15 should be linked in any way.
>
They shouldn't.  However, in some peoples minds, they probably will be.
However, 2003-15 as is will disenfranchise those ISPs that have been
struggling for smaller allocations because it comes at exactly the same
time the AC has taken their request off the table by rolling out 2002-3
without allocation and not producing a corresponding micro-allocation
policy.  It is unfortunate that this is the case.  If 2003-15 had been
initially proposed for all of ARIN, I think that would have been a good
thing.  Since it is the way it is, regardless of the intent of the group
proposing it, it _WILL_ disenfranchise a significant portion of ARIN
membership without amendment.

> Any other takers for helping not just ourselves, but the Americans as
> well  (since they ARE trying to help us in return) ?
>
> One last question though, is it too late to add another proposal ? Once
> that  would include maybe a combination of the best parts out of both
> proposals?  (just thinking of increasing all of our chances to get what
> we want/need  passed without delay)
>
It is too late to get such a thing on the agenda for this meeting.  Policies
have to be published for discussion 30 days prior to the meeting as I
understand it.  The AC may correct me here.


Thanks, Byron.

Owen



From owen at delong.com  Thu Oct  2 15:59:14 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 02 Oct 2003 12:59:14 -0700
Subject: [ppml] My idea was a non-starter
In-Reply-To: <OFE9630010.F425F1DF-ON80256DB3.003698D4-80256DB3.0036DDE3@radianz.com>
References: <OFE9630010.F425F1DF-ON80256DB3.003698D4-80256DB3.0036DDE3@radia
 nz.com>
Message-ID: <2147483647.1065099554@imac-en0.delong.sj.ca.us>

> I think our best bet is:
>     Pass 2003-15 as is at this meeting
>     Pass 2003-3 as is at this meeting

I believe that's 2002-3, not 2003-3.

>     Introduce a new proposal to cover the missing
>             bits from 2003-3 for the next meeting.
>

Except that this already existed and the AC rolled them up together in
2002-3, leaving allcation out.

Passing 2003-15 as is WILL disenfranchise a significant portion of the
ARIN constituency (or at least the potential ARIN constituency) by granting
relief that was asked for previously by all of ARIN to a sub-portion of
ARIN.  I believe that is not good policy.

> That's assuming that you think the specifics from 2003-15 should apply to
> North America.
>
I think the speicifics of 2003-15 should apply everywhere.  However, 
currently,
I can only affect their application to ARIN, so, that's what I will try to 
do.

Owen





From owen at delong.com  Thu Oct  2 16:13:24 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 02 Oct 2003 13:13:24 -0700
Subject: [ppml] My idea was a non-starter
In-Reply-To: <1272596478.1065080289@[192.168.0.101]>
References: <OFE9630010.F425F1DF-ON80256DB3.003698D4-80256DB3.0036DDE3@radia
 nz.com> <1272596478.1065080289@[192.168.0.101]>
Message-ID: <2147483647.1065100404@imac-en0.delong.sj.ca.us>

Thank you, Alec,

	As a result, I would like to advocate that we do the following:

	1.	I think it would be helpful to call the questions in the
		following order at the meeting:

		2002-3 can we get consensus if it includes allocation and
			assignment.

		if not:

		2002-3 can we get consensus if it is assignment only.


		if not:
		2003-15 can we get consensus if it includes all of ARIN
	

		if not:
		2003-15 can we get consensus as is.

	2.	If we can ask the questions in that order, then, I
		will support each and every one of those until one
		passes.  I think this is fair because it allows the
		community to decide progressively from the most open
		policy to the most restrictive.  It still provides a
		possibility for AfriNIC to get what they need even if
		ARIN cannot achieve consensus around rational ARIN-wide
		policy.

I hope that the representatives from AfriNIC and everyone who wants
micro-allocations and assignments in North America will join me in
supporting this approach.  I think it provides our best chance of
getting good policy implemented for everyone, while, simultaneously
preserving the ability to do as much good as we can if we cannot
get relief for everyone.  Further, I think this prevents most of
the potential delay impacts of previously discussed amendment
strategies.

To clarify... If the questions are called in the above order and
we cannot get consensus on making an ARIN-wide /22 allocation policy,
I will support 2003-15 as is because I do believe that the relief is
needed in Africa and I do believe that AfriNIC wants this.  However,
absent calling the other questions first, I think we do a great injustice
to the ARIN membership that has been trying to achieve this througout
ARIN for more than a year.  If we do not pass an ARIN wide /22 allocation
policy, then, we are, as a body, choosing to disenfranchise a significant
portion of the constituency.

I did not present this earlier because I promised Alec that I would wait
for a definitive answer from the AC on what was possible.  I didn't want
to create unnecessary confusion.  I want to thank Alec for his substantial
efforts on this issue and for his assistance in getting this clarification
so rapidly.  I hope that in light of this new data we can achieve consensus
around a complete /22 allocation and assignment policy for all of ARIN
at the upcoming meeting.

Thanks,

Owen

--On Thursday, October 2, 2003 7:38 AM -0600 "Alec H. Peterson" 
<ahp at hilander.com> wrote:

> As it happens the information Owen had about how the policy process works
> (which came from me) was not entirely correct.  We can indeed change the
> content of 2002-3 and/or 2003-15 without another policy cycle provided
> there is general consensus for said changes.  I'm not exactly sure why I
> thought anything else was the case, it probably has to do with the fact
> that we have never had anything close to consensus on anything related to
> ARIN's minimum allocation size, so another policy cycle has always been
> necessary.  At any rate, I apologize for misleading people about that.
>
> So, as far as how to move forward, at this point the AC is considered the
> 'author' for 2002-3 (the original authors did not want to continue work
> on it).  So the people on the AC who have been working on 2002-3 have
> been following the discussion and will decide on an appropriate plan of
> attack. 2003-15 is not an AC proposal at this point, so any changes made
> to it prior to the AC meeting will probably need to be initiated by said
> author[s].
>
> Note that consensus on these issues is far from guaranteed, as we've
> already been through several policy cycles without much luck, but
> hopefully the compromise the AC has tried to strike with 2002-3 will
> allow things to finally move forward.
>
> Alec
> Chair, ARIN AC
>




From william at elan.net  Thu Oct  2 14:10:16 2003
From: william at elan.net (william at elan.net)
Date: Thu, 2 Oct 2003 11:10:16 -0700 (PDT)
Subject: [ppml] My idea was a non-starter
In-Reply-To: <2147483647.1065100404@imac-en0.delong.sj.ca.us>
Message-ID: <Pine.LNX.4.44.0310021052170.32524-100000@sokol.elan.net>

I generally support what Owen wrote about the order and making substantial 
effort to pass micro-assignments and allocations with minimum number of 
extra policies for each case and as soon as possible. I would like few 
minor adjustments to question and how they are asked:

Question 1:
		Is there support if 2002-3 were modified and term
		"end-user" replaced with term "organization" and words
		"assigned by ARIN" replaced with "assigned or allocated by 
		ARIN" and similarly everhwere where it says "assignments" 
		replaced with "assingments and allocations".
 
Question 2 (asked if question 1 does not majority support or if its clear 
people want assignmetns and allocations in separate policies):
		Is there support for 2002-3 as is

Question3 (asked no matter what support Question 2 had):
		Is there support for 2003-15 if it was modified and 
		references to it being only for African portion of ARIN
		are removed

Question 4 (asked if there is no clear support on Question 3)
		Is there support for 2003-15 if it was modified and
		references to it being only for African portion of ARIN 
		removed and if it included only option "b" (multi-homing
		requirement with existing use of two /24s) under allocation
		criteria

Question 5 (asked no matter what support is there for Question 4)
		Is there support for 2003-15 as is only for African Region


On Thu, 2 Oct 2003, Owen DeLong wrote:

> Thank you, Alec,
> 
> 	As a result, I would like to advocate that we do the following:
> 
> 	1.	I think it would be helpful to call the questions in the
> 		following order at the meeting:
> 
> 		2002-3 can we get consensus if it includes allocation and
> 			assignment.
> 
> 		if not:
> 
> 		2002-3 can we get consensus if it is assignment only.
> 
> 
> 		if not:
> 		2003-15 can we get consensus if it includes all of ARIN
> 	
> 
> 		if not:
> 		2003-15 can we get consensus as is.
> 
> 	2.	If we can ask the questions in that order, then, I
> 		will support each and every one of those until one
> 		passes.  I think this is fair because it allows the
> 		community to decide progressively from the most open
> 		policy to the most restrictive.  It still provides a
> 		possibility for AfriNIC to get what they need even if
> 		ARIN cannot achieve consensus around rational ARIN-wide
> 		policy.
> 
> I hope that the representatives from AfriNIC and everyone who wants
> micro-allocations and assignments in North America will join me in
> supporting this approach.  I think it provides our best chance of
> getting good policy implemented for everyone, while, simultaneously
> preserving the ability to do as much good as we can if we cannot
> get relief for everyone.  Further, I think this prevents most of
> the potential delay impacts of previously discussed amendment
> strategies.
> 
> To clarify... If the questions are called in the above order and
> we cannot get consensus on making an ARIN-wide /22 allocation policy,
> I will support 2003-15 as is because I do believe that the relief is
> needed in Africa and I do believe that AfriNIC wants this.  However,
> absent calling the other questions first, I think we do a great injustice
> to the ARIN membership that has been trying to achieve this througout
> ARIN for more than a year.  If we do not pass an ARIN wide /22 allocation
> policy, then, we are, as a body, choosing to disenfranchise a significant
> portion of the constituency.
> 
> I did not present this earlier because I promised Alec that I would wait
> for a definitive answer from the AC on what was possible.  I didn't want
> to create unnecessary confusion.  I want to thank Alec for his substantial
> efforts on this issue and for his assistance in getting this clarification
> so rapidly.  I hope that in light of this new data we can achieve consensus
> around a complete /22 allocation and assignment policy for all of ARIN
> at the upcoming meeting.
> 
> Thanks,
> 
> Owen
> 
> --On Thursday, October 2, 2003 7:38 AM -0600 "Alec H. Peterson" 
> <ahp at hilander.com> wrote:
> 
> > As it happens the information Owen had about how the policy process works
> > (which came from me) was not entirely correct.  We can indeed change the
> > content of 2002-3 and/or 2003-15 without another policy cycle provided
> > there is general consensus for said changes.  I'm not exactly sure why I
> > thought anything else was the case, it probably has to do with the fact
> > that we have never had anything close to consensus on anything related to
> > ARIN's minimum allocation size, so another policy cycle has always been
> > necessary.  At any rate, I apologize for misleading people about that.
> >
> > So, as far as how to move forward, at this point the AC is considered the
> > 'author' for 2002-3 (the original authors did not want to continue work
> > on it).  So the people on the AC who have been working on 2002-3 have
> > been following the discussion and will decide on an appropriate plan of
> > attack. 2003-15 is not an AC proposal at this point, so any changes made
> > to it prior to the AC meeting will probably need to be initiated by said
> > author[s].
> >
> > Note that consensus on these issues is far from guaranteed, as we've
> > already been through several policy cycles without much luck, but
> > hopefully the compromise the AC has tried to strike with 2002-3 will
> > allow things to finally move forward.
> >
> > Alec
> > Chair, ARIN AC
> >



From william at elan.net  Thu Oct  2 14:23:23 2003
From: william at elan.net (william at elan.net)
Date: Thu, 2 Oct 2003 11:23:23 -0700 (PDT)
Subject: [ppml] My idea was a non-starter
In-Reply-To: <Pine.LNX.4.44.0310021052170.32524-100000@sokol.elan.net>
Message-ID: <Pine.LNX.4.44.0310021113010.32524-100000@sokol.elan.net>

And do note that I used term "majority support" and not "conscensus". 
Based on previous meeting proceedings and general opposition to both 
micro-assignents by some larger ISPs (which account for majority of ISP 
representatives on the meeting) I do not believe there is a clear 
consensus on any of these issues, but majority support of those
expressing opinion on this topic maybe available. 

I should also like to point out that both BoT and AC promised to make 
their decisions not only based on the opinions expressed at the meeting 
but also based on the support they see on this very mailing list. I would 
like to think they have seen the kind of support 2003-15 had and that 
there is no longer any serious opposition on technical merits to 2002-3 
or for either micro-assignments or allocations in general. I hope that 
this will be taken into account by the BoT and AC on their official 
decisions no matter what exact "show of hands" from the participants at 
the live meeting is.

On Thu, 2 Oct 2003 william at elan.net wrote:

> I generally support what Owen wrote about the order and making substantial 
> effort to pass micro-assignments and allocations with minimum number of 
> extra policies for each case and as soon as possible. I would like few 
> minor adjustments to question and how they are asked:
> 
> Question 1:
> 		Is there support if 2002-3 were modified and term
> 		"end-user" replaced with term "organization" and words
> 		"assigned by ARIN" replaced with "assigned or allocated by 
> 		ARIN" and similarly everhwere where it says "assignments" 
> 		replaced with "assingments and allocations".
>  
> Question 2 (asked if question 1 does not majority support or if its clear 
> people want assignmetns and allocations in separate policies):
> 		Is there support for 2002-3 as is
> 
> Question3 (asked no matter what support Question 2 had):
> 		Is there support for 2003-15 if it was modified and 
> 		references to it being only for African portion of ARIN
> 		are removed
> 
> Question 4 (asked if there is no clear support on Question 3)
> 		Is there support for 2003-15 if it was modified and
> 		references to it being only for African portion of ARIN 
> 		removed and if it included only option "b" (multi-homing
> 		requirement with existing use of two /24s) under allocation
> 		criteria
> 
> Question 5 (asked no matter what support is there for Question 4)
> 		Is there support for 2003-15 as is only for African Region
> 
> 
> On Thu, 2 Oct 2003, Owen DeLong wrote:
> 
> > Thank you, Alec,
> > 
> > 	As a result, I would like to advocate that we do the following:
> > 
> > 	1.	I think it would be helpful to call the questions in the
> > 		following order at the meeting:
> > 
> > 		2002-3 can we get consensus if it includes allocation and
> > 			assignment.
> > 
> > 		if not:
> > 
> > 		2002-3 can we get consensus if it is assignment only.
> > 
> > 
> > 		if not:
> > 		2003-15 can we get consensus if it includes all of ARIN
> > 	
> > 
> > 		if not:
> > 		2003-15 can we get consensus as is.
> > 
> > 	2.	If we can ask the questions in that order, then, I
> > 		will support each and every one of those until one
> > 		passes.  I think this is fair because it allows the
> > 		community to decide progressively from the most open
> > 		policy to the most restrictive.  It still provides a
> > 		possibility for AfriNIC to get what they need even if
> > 		ARIN cannot achieve consensus around rational ARIN-wide
> > 		policy.
> > 
> > I hope that the representatives from AfriNIC and everyone who wants
> > micro-allocations and assignments in North America will join me in
> > supporting this approach.  I think it provides our best chance of
> > getting good policy implemented for everyone, while, simultaneously
> > preserving the ability to do as much good as we can if we cannot
> > get relief for everyone.  Further, I think this prevents most of
> > the potential delay impacts of previously discussed amendment
> > strategies.
> > 
> > To clarify... If the questions are called in the above order and
> > we cannot get consensus on making an ARIN-wide /22 allocation policy,
> > I will support 2003-15 as is because I do believe that the relief is
> > needed in Africa and I do believe that AfriNIC wants this.  However,
> > absent calling the other questions first, I think we do a great injustice
> > to the ARIN membership that has been trying to achieve this througout
> > ARIN for more than a year.  If we do not pass an ARIN wide /22 allocation
> > policy, then, we are, as a body, choosing to disenfranchise a significant
> > portion of the constituency.
> > 
> > I did not present this earlier because I promised Alec that I would wait
> > for a definitive answer from the AC on what was possible.  I didn't want
> > to create unnecessary confusion.  I want to thank Alec for his substantial
> > efforts on this issue and for his assistance in getting this clarification
> > so rapidly.  I hope that in light of this new data we can achieve consensus
> > around a complete /22 allocation and assignment policy for all of ARIN
> > at the upcoming meeting.
> > 
> > Thanks,
> > 
> > Owen
> > 
> > --On Thursday, October 2, 2003 7:38 AM -0600 "Alec H. Peterson" 
> > <ahp at hilander.com> wrote:
> > 
> > > As it happens the information Owen had about how the policy process works
> > > (which came from me) was not entirely correct.  We can indeed change the
> > > content of 2002-3 and/or 2003-15 without another policy cycle provided
> > > there is general consensus for said changes.  I'm not exactly sure why I
> > > thought anything else was the case, it probably has to do with the fact
> > > that we have never had anything close to consensus on anything related to
> > > ARIN's minimum allocation size, so another policy cycle has always been
> > > necessary.  At any rate, I apologize for misleading people about that.
> > >
> > > So, as far as how to move forward, at this point the AC is considered the
> > > 'author' for 2002-3 (the original authors did not want to continue work
> > > on it).  So the people on the AC who have been working on 2002-3 have
> > > been following the discussion and will decide on an appropriate plan of
> > > attack. 2003-15 is not an AC proposal at this point, so any changes made
> > > to it prior to the AC meeting will probably need to be initiated by said
> > > author[s].
> > >
> > > Note that consensus on these issues is far from guaranteed, as we've
> > > already been through several policy cycles without much luck, but
> > > hopefully the compromise the AC has tried to strike with 2002-3 will
> > > allow things to finally move forward.
> > >
> > > Alec
> > > Chair, ARIN AC



From owen at delong.com  Thu Oct  2 16:58:07 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 02 Oct 2003 13:58:07 -0700
Subject: [ppml] My idea was a non-starter
In-Reply-To: <Pine.LNX.4.44.0310021052170.32524-100000@sokol.elan.net>
References: <Pine.LNX.4.44.0310021052170.32524-100000@sokol.elan.net>
Message-ID: <2147483647.1065103087@imac-en0.delong.sj.ca.us>



--On Thursday, October 2, 2003 11:10 AM -0700 william at elan.net wrote:

> I generally support what Owen wrote about the order and making
> substantial  effort to pass micro-assignments and allocations with
> minimum number of  extra policies for each case and as soon as possible.
> I would like few  minor adjustments to question and how they are asked:
>
> Question 1:
> 		Is there support if 2002-3 were modified and term
> 		"end-user" replaced with term "organization" and words
> 		"assigned by ARIN" replaced with "assigned or allocated by
> 		ARIN" and similarly everhwere where it says "assignments"
> 		replaced with "assingments and allocations".
>
This is simply a more formal wording of my intent, so, I have no problem
with that if the AC feels that level of formailty is necessary.

> Question 2 (asked if question 1 does not majority support or if its clear
> people want assignmetns and allocations in separate policies):
> 		Is there support for 2002-3 as is
>
Again, I believe this is just a formalization of the intent of my statement.

> Question3 (asked no matter what support Question 2 had):
> 		Is there support for 2003-15 if it was modified and
> 		references to it being only for African portion of ARIN
> 		are removed
>
I think this is mooot if Question 1 passes.  If Question 1 does not carry,
then, I believe Question 3 is necessary regardless of the outcome of
Question 2.  As such, I support this change.

> Question 4 (asked if there is no clear support on Question 3)
> 		Is there support for 2003-15 if it was modified and
> 		references to it being only for African portion of ARIN
> 		removed and if it included only option "b" (multi-homing
> 		requirement with existing use of two /24s) under allocation
> 		criteria
>
I'm not sure whether that would still meet the needs of AfriNIC, so, absent
positive comment on this from them, I would hesitate to introduce such a
question.  I don't think we should do this if they don't support it.

> Question 5 (asked no matter what support is there for Question 4)
> 		Is there support for 2003-15 as is only for African Region
>

I have no problem with this.  I view it as a formalization of what I 
originally
posted.

Owen



From jmcburnett at msmgmt.com  Thu Oct  2 17:00:24 2003
From: jmcburnett at msmgmt.com (McBurnett, Jim)
Date: Thu, 2 Oct 2003 17:00:24 -0400
Subject: [ppml] My idea was a non-starter
Message-ID: <9BF6F06C4BC90746ADD6806746492A336909D4@msmmail01.msmgmt.com>

-> I hope that 
->this will be taken into account by the BoT and AC on their official 
->decisions no matter what exact "show of hands" from the 
->participants at 
->the live meeting is.

Thank you William, I agree. 
If the large ISP's had their way there would be little ISP's
nor large customers with ARIN guiding ability...


Later,
J


From owen at delong.com  Thu Oct  2 17:04:38 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 02 Oct 2003 14:04:38 -0700
Subject: [ppml] My idea was a non-starter
In-Reply-To: <Pine.LNX.4.44.0310021113010.32524-100000@sokol.elan.net>
References: <Pine.LNX.4.44.0310021113010.32524-100000@sokol.elan.net>
Message-ID: <2147483647.1065103478@imac-en0.delong.sj.ca.us>

On this, I completely agree.  Unfortunately, the codified standard that
the AC MUST adopt WRT changing the policies at the meeting is that
there must be clear consensus for the change or it requires another
policy cycle.

I am hoping that we can achieve clear consensus at the meeting, although,
I think that will be difficult.

Owen


--On Thursday, October 2, 2003 11:23 AM -0700 william at elan.net wrote:

> And do note that I used term "majority support" and not "conscensus".
> Based on previous meeting proceedings and general opposition to both
> micro-assignents by some larger ISPs (which account for majority of ISP
> representatives on the meeting) I do not believe there is a clear
> consensus on any of these issues, but majority support of those
> expressing opinion on this topic maybe available.
>
> I should also like to point out that both BoT and AC promised to make
> their decisions not only based on the opinions expressed at the meeting
> but also based on the support they see on this very mailing list. I would
> like to think they have seen the kind of support 2003-15 had and that
> there is no longer any serious opposition on technical merits to 2002-3
> or for either micro-assignments or allocations in general. I hope that
> this will be taken into account by the BoT and AC on their official
> decisions no matter what exact "show of hands" from the participants at
> the live meeting is.
>
> On Thu, 2 Oct 2003 william at elan.net wrote:
>
>> I generally support what Owen wrote about the order and making
>> substantial  effort to pass micro-assignments and allocations with
>> minimum number of  extra policies for each case and as soon as possible.
>> I would like few  minor adjustments to question and how they are asked:
>>
>> Question 1:
>> 		Is there support if 2002-3 were modified and term
>> 		"end-user" replaced with term "organization" and words
>> 		"assigned by ARIN" replaced with "assigned or allocated by
>> 		ARIN" and similarly everhwere where it says "assignments"
>> 		replaced with "assingments and allocations".
>>
>> Question 2 (asked if question 1 does not majority support or if its
>> clear  people want assignmetns and allocations in separate policies): Is
>> 		there support for 2002-3 as is
>>
>> Question3 (asked no matter what support Question 2 had):
>> 		Is there support for 2003-15 if it was modified and
>> 		references to it being only for African portion of ARIN
>> 		are removed
>>
>> Question 4 (asked if there is no clear support on Question 3)
>> 		Is there support for 2003-15 if it was modified and
>> 		references to it being only for African portion of ARIN
>> 		removed and if it included only option "b" (multi-homing
>> 		requirement with existing use of two /24s) under allocation
>> 		criteria
>>
>> Question 5 (asked no matter what support is there for Question 4)
>> 		Is there support for 2003-15 as is only for African Region
>>
>>
>> On Thu, 2 Oct 2003, Owen DeLong wrote:
>>
>> > Thank you, Alec,
>> >
>> > 	As a result, I would like to advocate that we do the following:
>> >
>> > 	1.	I think it would be helpful to call the questions in the
>> > 		following order at the meeting:
>> >
>> > 		2002-3 can we get consensus if it includes allocation and
>> > 			assignment.
>> >
>> > 		if not:
>> >
>> > 		2002-3 can we get consensus if it is assignment only.
>> >
>> >
>> > 		if not:
>> > 		2003-15 can we get consensus if it includes all of ARIN
>> > 	
>> >
>> > 		if not:
>> > 		2003-15 can we get consensus as is.
>> >
>> > 	2.	If we can ask the questions in that order, then, I
>> > 		will support each and every one of those until one
>> > 		passes.  I think this is fair because it allows the
>> > 		community to decide progressively from the most open
>> > 		policy to the most restrictive.  It still provides a
>> > 		possibility for AfriNIC to get what they need even if
>> > 		ARIN cannot achieve consensus around rational ARIN-wide
>> > 		policy.
>> >
>> > I hope that the representatives from AfriNIC and everyone who wants
>> > micro-allocations and assignments in North America will join me in
>> > supporting this approach.  I think it provides our best chance of
>> > getting good policy implemented for everyone, while, simultaneously
>> > preserving the ability to do as much good as we can if we cannot
>> > get relief for everyone.  Further, I think this prevents most of
>> > the potential delay impacts of previously discussed amendment
>> > strategies.
>> >
>> > To clarify... If the questions are called in the above order and
>> > we cannot get consensus on making an ARIN-wide /22 allocation policy,
>> > I will support 2003-15 as is because I do believe that the relief is
>> > needed in Africa and I do believe that AfriNIC wants this.  However,
>> > absent calling the other questions first, I think we do a great
>> > injustice to the ARIN membership that has been trying to achieve this
>> > througout ARIN for more than a year.  If we do not pass an ARIN wide
>> > /22 allocation policy, then, we are, as a body, choosing to
>> > disenfranchise a significant portion of the constituency.
>> >
>> > I did not present this earlier because I promised Alec that I would
>> > wait for a definitive answer from the AC on what was possible.  I
>> > didn't want to create unnecessary confusion.  I want to thank Alec for
>> > his substantial efforts on this issue and for his assistance in
>> > getting this clarification so rapidly.  I hope that in light of this
>> > new data we can achieve consensus around a complete /22 allocation and
>> > assignment policy for all of ARIN at the upcoming meeting.
>> >
>> > Thanks,
>> >
>> > Owen
>> >
>> > --On Thursday, October 2, 2003 7:38 AM -0600 "Alec H. Peterson"
>> > <ahp at hilander.com> wrote:
>> >
>> > > As it happens the information Owen had about how the policy process
>> > > works (which came from me) was not entirely correct.  We can indeed
>> > > change the content of 2002-3 and/or 2003-15 without another policy
>> > > cycle provided there is general consensus for said changes.  I'm not
>> > > exactly sure why I thought anything else was the case, it probably
>> > > has to do with the fact that we have never had anything close to
>> > > consensus on anything related to ARIN's minimum allocation size, so
>> > > another policy cycle has always been necessary.  At any rate, I
>> > > apologize for misleading people about that.
>> > >
>> > > So, as far as how to move forward, at this point the AC is
>> > > considered the 'author' for 2002-3 (the original authors did not
>> > > want to continue work on it).  So the people on the AC who have been
>> > > working on 2002-3 have been following the discussion and will decide
>> > > on an appropriate plan of attack. 2003-15 is not an AC proposal at
>> > > this point, so any changes made to it prior to the AC meeting will
>> > > probably need to be initiated by said author[s].
>> > >
>> > > Note that consensus on these issues is far from guaranteed, as we've
>> > > already been through several policy cycles without much luck, but
>> > > hopefully the compromise the AC has tried to strike with 2002-3 will
>> > > allow things to finally move forward.
>> > >
>> > > Alec
>> > > Chair, ARIN AC
>




From william at elan.net  Thu Oct  2 14:36:39 2003
From: william at elan.net (william at elan.net)
Date: Thu, 2 Oct 2003 11:36:39 -0700 (PDT)
Subject: [ppml] My idea was a non-starter
In-Reply-To: <2147483647.1065103087@imac-en0.delong.sj.ca.us>
Message-ID: <Pine.LNX.4.44.0310021128300.32524-100000@sokol.elan.net>


> > Question 4 (asked if there is no clear support on Question 3)
> > 		Is there support for 2003-15 if it was modified and
> > 		references to it being only for African portion of ARIN
> > 		removed and if it included only option "b" (multi-homing
> > 		requirement with existing use of two /24s) under allocation
> > 		criteria
> >
> I'm not sure whether that would still meet the needs of AfriNIC, so, absent
> positive comment on this from them, I would hesitate to introduce such a
> question.  I don't think we should do this if they don't support it.

That is exactly why below I wrote that Question 5 should be asked no 
matter what support is there for question 4 (micro-allocations only to 
multi-homed ISPs may have larger support in US, but such micro-allocations
maybe needed for african region even without multi-homing requirement 
because they do not have as many providers and in some countries telecom
services are monopolized by country telco as has been previously discussed)

In case both Question 4 and Question 5 have support, the policy will need 
to be modified by AC after the meeting prior to it being sent to BOT to 
say that option a. (no multi-homing but 4 previously allocated /24) is 
available only for ISPs in African region while option b. would remain
available for other ARIN regions as well.

> > Question 5 (asked no matter what support is there for Question 4)
> > 		Is there support for 2003-15 as is only for African Region
> >
> 
> I have no problem with this.  I view it as a formalization of what I 
> originally posted.
>
>
> Owen



From calvin at orange-tree.alt.za  Fri Oct  3 01:09:09 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 03 Oct 2003 07:09:09 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
	Africa Portion of the ARIN Region
In-Reply-To: <2147483647.1065096857@imac-en0.delong.sj.ca.us>
References: <Pine.GSO.4.44.0309291103460.8405-100000@paixhost.pch.net>
	 <LPENICNLCKCKPNDPFKBACEIBEHAA.William@zanet.co.za>
	 <E1A4Rc3-0006vZ-DQ@ran.psg.com>
	 <LPENICNLCKCKPNDPFKBAKEHPEHAA.William@zanet.co.za>
	 <20031001005559.GA88615@ussenterprise.ufp.org>
	 <1064986004.8397.10.camel@pear.orange-tree.alt.za>
	 <2147483647.1065001551@imac-en0.delong.sj.ca.us>
	 <1065073040.9453.77.camel@pear.orange-tree.alt.za>
	 <2147483647.1065096857@imac-en0.delong.sj.ca.us>
Message-ID: <1065157749.12344.19.camel@pear.orange-tree.alt.za>

On Thu, 2003-10-02 at 21:14, Owen DeLong wrote:

<SNIP>

> 
> I think that trying to pretend that ARIN is two separate sub-regions and 
> create
> two separate voting bodies within ARIN to set policies for those sub-regions
> isn't likely to be a successful strategy.

Actually, as I understand it, ARIN already runs separate policies for
sub-regions - at least we get our addresses from separate blocks
according to which sub-region we're in - this has happened for a while.
We get to mess in each other's affairs to an extent we probably
shouldn't :).
It's wrong, it's broken, but it's the reality and we're busy fixing it
:)

--Calvin

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------



From calvin at orange-tree.alt.za  Fri Oct  3 01:17:50 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 03 Oct 2003 07:17:50 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa
	Portion of the ARIN Region - was Re: [ppml] My idea was a non-starter
In-Reply-To: <2147483647.1065100404@imac-en0.delong.sj.ca.us>
References: 	 <OFE9630010.F425F1DF-ON80256DB3.003698D4-80256DB3.0036DDE3@radia nz.com>
	 <1272596478.1065080289@[192.168.0.101]>
	 <2147483647.1065100404@imac-en0.delong.sj.ca.us>
Message-ID: <1065158269.12344.25.camel@pear.orange-tree.alt.za>

On Thu, 2003-10-02 at 22:13, Owen DeLong wrote:
> Thank you, Alec,
> 
> 	As a result, I would like to advocate that we do the following:
> 
> 	1.	I think it would be helpful to call the questions in the
> 		following order at the meeting:
> 
> 		2002-3 can we get consensus if it includes allocation and
> 			assignment.
> 
> 		if not:
> 
> 		2002-3 can we get consensus if it is assignment only.
> 
> 
> 		if not:
> 		2003-15 can we get consensus if it includes all of ARIN
> 	
> 
> 		if not:
> 		2003-15 can we get consensus as is.
> 

now were starting to find an approach that may let some of the crayfish
out, even if some stay behind :)

<SNIP>

--Calvin

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------



From jonathan at ods.co.za  Fri Oct  3 02:28:08 2003
From: jonathan at ods.co.za (Jonathan Lydall)
Date: Fri, 3 Oct 2003 08:28:08 +0200
Subject: [ppml] My idea was a non-starter
In-Reply-To: <2147483647.1065100404@imac-en0.delong.sj.ca.us>
Message-ID: <000f01c38977$8352c8a0$0564a8c0@jon>

Hi Owen,

I support this proposal entirely. It offers a very nice approach to all
concerns I have seen raised on this mailing list.

>From a sub-saharan african ISP supporting 2003-15, first prize is a win
for all parties, the second question, while not exactly what I was
looking for in 2003-15, it is in no way detrimental to the success of
2003-15 and I have no reason to appose it. I am 100% for your below
mentioned strategy.

Thanks,

Jonathan Lydall


On Thursday, 02 October 2003 10:13, Owen DeLong Wrote:
> 
> Thank you, Alec,
> 
> 	As a result, I would like to advocate that we do the following:
> 
> 	1.	I think it would be helpful to call the questions in the
> 		following order at the meeting:
> 
> 		2002-3 can we get consensus if it includes 
> allocation and
> 			assignment.
> 
> 		if not:
> 
> 		2002-3 can we get consensus if it is assignment only.
> 
> 
> 		if not:
> 		2003-15 can we get consensus if it includes all of ARIN
> 	
> 
> 		if not:
> 		2003-15 can we get consensus as is.
> 
> 	2.	If we can ask the questions in that order, then, I
> 		will support each and every one of those until one
> 		passes.  I think this is fair because it allows the
> 		community to decide progressively from the most open
> 		policy to the most restrictive.  It still provides a
> 		possibility for AfriNIC to get what they need even if
> 		ARIN cannot achieve consensus around rational ARIN-wide
> 		policy.
> 
> I hope that the representatives from AfriNIC and everyone who wants
> micro-allocations and assignments in North America will join me in
> supporting this approach.  I think it provides our best chance of
> getting good policy implemented for everyone, while, simultaneously
> preserving the ability to do as much good as we can if we cannot
> get relief for everyone.  Further, I think this prevents most of
> the potential delay impacts of previously discussed amendment
> strategies.
> 
> To clarify... If the questions are called in the above order and
> we cannot get consensus on making an ARIN-wide /22 allocation policy,
> I will support 2003-15 as is because I do believe that the relief is
> needed in Africa and I do believe that AfriNIC wants this.  However,
> absent calling the other questions first, I think we do a 
> great injustice
> to the ARIN membership that has been trying to achieve this througout
> ARIN for more than a year.  If we do not pass an ARIN wide 
> /22 allocation
> policy, then, we are, as a body, choosing to disenfranchise a 
> significant
> portion of the constituency.
> 
> I did not present this earlier because I promised Alec that I 
> would wait
> for a definitive answer from the AC on what was possible.  I 
> didn't want
> to create unnecessary confusion.  I want to thank Alec for 
> his substantial
> efforts on this issue and for his assistance in getting this 
> clarification
> so rapidly.  I hope that in light of this new data we can 
> achieve consensus
> around a complete /22 allocation and assignment policy for all of ARIN
> at the upcoming meeting.
> 
> Thanks,
> 
> Owen
> 
> --On Thursday, October 2, 2003 7:38 AM -0600 "Alec H. Peterson" 
> <ahp at hilander.com> wrote:
> 
> > As it happens the information Owen had about how the policy 
> process works
> > (which came from me) was not entirely correct.  We can 
> indeed change the
> > content of 2002-3 and/or 2003-15 without another policy 
> cycle provided
> > there is general consensus for said changes.  I'm not 
> exactly sure why I
> > thought anything else was the case, it probably has to do 
> with the fact
> > that we have never had anything close to consensus on 
> anything related to
> > ARIN's minimum allocation size, so another policy cycle has 
> always been
> > necessary.  At any rate, I apologize for misleading people 
> about that.
> >
> > So, as far as how to move forward, at this point the AC is 
> considered the
> > 'author' for 2002-3 (the original authors did not want to 
> continue work
> > on it).  So the people on the AC who have been working on 
> 2002-3 have
> > been following the discussion and will decide on an 
> appropriate plan of
> > attack. 2003-15 is not an AC proposal at this point, so any 
> changes made
> > to it prior to the AC meeting will probably need to be 
> initiated by said
> > author[s].
> >
> > Note that consensus on these issues is far from guaranteed, as we've
> > already been through several policy cycles without much luck, but
> > hopefully the compromise the AC has tried to strike with 2002-3 will
> > allow things to finally move forward.
> >
> > Alec
> > Chair, ARIN AC
> >
> 



From bs at lantic.net  Fri Oct  3 03:31:23 2003
From: bs at lantic.net (Byron Sorgdrager)
Date: Fri, 3 Oct 2003 09:31:23 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region - was Re: [ppml] My idea was a non-starter
In-Reply-To: <2147483647.1065100404@imac-en0.delong.sj.ca.us>
References: <OFE9630010.F425F1DF-ON80256DB3.003698D4-80256DB3.0036DDE3@radia nz.com> <1272596478.1065080289@[192.168.0.101]> <2147483647.1065100404@imac-en0.delong.sj.ca.us>
Message-ID: <200310030931.23787.bs@lantic.net>

I would support this flow.

On Thursday 02 October 2003 22:13, Owen DeLong wrote:
> Thank you, Alec,
>
> 	As a result, I would like to advocate that we do the following:
>
> 	1.	I think it would be helpful to call the questions in the
> 		following order at the meeting:
>
> 		2002-3 can we get consensus if it includes allocation and
> 			assignment.
>
> 		if not:
>
> 		2002-3 can we get consensus if it is assignment only.
>
>
> 		if not:
> 		2003-15 can we get consensus if it includes all of ARIN
>
>
> 		if not:
> 		2003-15 can we get consensus as is.
>

<snip>

-- 
Every word is like an unnecessary stain on silence and nothingness.
                -- Beckett




************************************************************
Scanned by @lantic IS Virus Control Service
This message was scanned for viruses and dangerous content.
@lantic Internet Services (Pty) Ltd. - http://www.lantic.net
eScan for Windows-based PCs - http://www.escan.co.za
************************************************************



From mlawrie at zanet.co.za  Fri Oct  3 06:18:38 2003
From: mlawrie at zanet.co.za (mlawrie at zanet.co.za)
Date: Fri, 03 Oct 2003 12:18:38 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <2147483647.1065097957@imac-en0.delong.sj.ca.us>
References: <3F7BD992.21549.440E36@localhost>
Message-ID: <3F7D691E.25375.65D0479@localhost>

Owen DeLong wrote:-

> --On Thursday, October 2, 2003 7:53 AM +0200 mlawrie at zanet.co.za
> wrote:
> ...[snip]....
> > IMHO, the best action is
> >
> >    Decouple 2002-3 from 2003-15
> 
> Agreed.  I've never intended to couple them.

Well, you've fooled me on this point. So let's look at 2003-15 on its 
own, and leave 2002-3 to its own devices and for discussion under 
subject that refers to 2002-3 and not 2003-15.

> 
> >    Deal with each proposal on its individual merits
> 
> ...[snip 2002-3 stuff]...
> 
> 2003-15, as is, has significant disenfranchising effects on small(er)
> ISPs in North America and, as such, would do substantial damage to
> ARIN as an organization.  It contains good policy, but, the
> sub-regional exclusivitiy is extremely harmful, and, should not be
> allowed to pass.

The term "disenfranchise" in this neck of the woods means to take 
something away (like a vote, or some power or right or suchlike). 
2003-15 does no such thing, it takes nothing from anyone. It 
endeavours to make Internet services in a particular sub-region of 
ARIN's control more accessible (ie it "enfranchises" ISPs). That it 
does so to a subset of the ARIN region of control is true, and it 
seems presumptious to suggest that this action will have some kind of 
blocking effect should other subregions ask for similar 
enfranchising. The argument can go either way, ie "it's working OK in 
one subregion without the sky falling on our heads so let's try it 
elsewhere", or "it was an utter disaster in the first subregion so 
never again". If perchance it is the latter situation, ARIN has the 
sunset in sight with the pending activation of AfriNIC, and there 
will be full recovery from the disaster. If the former, the policy 
will surely spread to other subregions.

So if others that operate elsewhere in ARIN's region of control want 
a similar enfrancising, let them motivate accordingly, but that's a 
separate and subsequent matter.

It is very difficult from here (Africa) to see any reason why 
exclusinve subregional enfranchising is "extremely harmful" to 
anyone. A subsequent proposal to extend the enfranchised subregion 
will surely stand or fall on its merits at the time, and should not 
be pre-judged at the time that 2003-15 is debated.


> >    Deal with extending 2003-15 (were this needed) at a later meeting
> >
> If 2003-15 is passed as is, it will become virtually impossible to do
> this.

I will defend your right to have your beliefs, but for sure I 
disagree completely with this particular one of yours.

Mike
-- 
Mike Lawrie.
Ph +27 12 348 0944 or 072 480 8898
<mlawrie at zanet.co.za>


From calvin at orange-tree.alt.za  Fri Oct  3 08:06:19 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 03 Oct 2003 14:06:19 +0200
Subject: [ppml] Policy Proposal 2002-3
In-Reply-To: <2147483647.1065099195@imac-en0.delong.sj.ca.us>
References: <3F7BD992.21549.440E36@localhost>
	 <200310021026.48258.bs@lantic.net>
	 <2147483647.1065099195@imac-en0.delong.sj.ca.us>
Message-ID: <1065182777.15411.10.camel@calvin.coza.net.za>

After the murk of the clash between 2002-3 and 2003-15 (which seems to
be nicely resolved with Owen's suggestion), I'd like to turn the
discussion back to 2002-3, mainly for my own understanding.

Why should 2002-3 not be passed? or what are the arguments for not
passing it?
(and no, "because there are better suggestions" is not a valid answer
IMHO).

I can't remember seeing any detractors, just people suggesting 'better
ideas'.

regards

--Calvin

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------




From calvin at orange-tree.alt.za  Fri Oct  3 08:43:36 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 03 Oct 2003 14:43:36 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
	Africa Portion of the ARIN Region
In-Reply-To: <2147483647.1065096105@imac-en0.delong.sj.ca.us>
References: 	 <Pine.GSO.4.20.0310011641370.3089-100000@sun222-31.corp.us.uu.net>
	 <1065070893.9453.40.camel@pear.orange-tree.alt.za>
	 <2147483647.1065096105@imac-en0.delong.sj.ca.us>
Message-ID: <1065185016.15411.43.camel@calvin.coza.net.za>

On Thu, 2003-10-02 at 21:01, Owen DeLong wrote:
> > I'm still uncomfortable with AfriNIC people getting involved with
> > 2002-3. I don't know enough about N. American networking to understand
> > it. Anyone who sees me supporting 2002-3 needs to weigh up that fact and
> > adjust my support accordingly (This should by no means be interpreted as
> > saying that 2002-3 should not be passed, just that *I* have no idea).
> > But when it comes to Africa, well, in the past month or two, I've
> > interacted with Kenyans, Ghanaians, Zimbabweans, Rwandans, Tanzanians,
> > Tunisian, Mozambicans, Sudanese and in fact, yesterday I got a call from
> > someone involved with the regulator in Botswana asking about setting up
> > a peering point (I'm going to put him onto the appropriate people
> > shortly as this is not my forte).
> >
> 2002-3 will affect Africa every bit as much as 2003-15.  You should base
> your decision about 2002-3 on the effect it will have where you are.  There
> are plenty of people who will vote on 2002-3 based on their North American
> perceptions.  Unlike 2003-15, 2002-3 is NOT specific to a portion of ARIN.

I find this logic flawed - its like Lesotho having veto rights over
South African transport rules, purely because it is wholy surrounded by
SA.
My reasoning tells me to act towards 2002-3 in the same manner as if
AfriNIC were up and functioning.

Maybe, you can pretend I'm in S. America and not S. Africa and let me
know why I should support 2002-3 outside of the fact that it will also
help those Southern Africans accross the pond (change the subject so
that it gets recorded under 2002-3).

> 
> I hope you will support 2002-3.  Further, I hope you will support the idea
> of amending 2003-15 to encompass all of ARIN when the time comes, since I
> hope you will be able to see that it is good for everyone, not just Africa
> that way.  I will support 2002-3.  I will support 2003-15 if it is an
> ARIN-wide policy.  I cannot support 2003-15 as an Africa-specific policy
> because I don't know enough about Africa to make decisions for them.

I'm going to need arguments other than "it will inadvertantly help you"
before I change my stance from 'no negative comment, do it if there is
enough consensus amongst yourselves' to 'yeah - I support it'.

> I can oppose 2003-15 as an Africa-specific policy because I believe it
> will do harm to ARIN as a whole regardless of any positive impact it may
> have on Africa.

If 2003-15 is going to do harm to ARIN as a whole or in part, then it
*should* be opposed - but I don't believe your arguments are valid on
this.
I read your reasoning as being '2003-15 will ease the pressure on ARIN
for lowering allocations requirements accross the board, and so it is
bad'. This doesn't reconcile with my understanding that ARIN already has
sub-region policies. Heck - it is so obvious, they they didn't even go
through the normal policy procedure when they implemented it - they just
snuck it in when people were not looking ;-).

> 
> Owen

regards

--Calvin

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------



From calvin at orange-tree.alt.za  Fri Oct  3 08:48:22 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 03 Oct 2003 14:48:22 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
	Africa Portion of the ARIN Region
In-Reply-To: <2147483647.1065096105@imac-en0.delong.sj.ca.us>
References: 	 <Pine.GSO.4.20.0310011641370.3089-100000@sun222-31.corp.us.uu.net>
	 <1065070893.9453.40.camel@pear.orange-tree.alt.za>
	 <2147483647.1065096105@imac-en0.delong.sj.ca.us>
Message-ID: <1065185302.15411.48.camel@calvin.coza.net.za>

On Thu, 2003-10-02 at 21:01, Owen DeLong wrote:

<SNIP>

> I can oppose 2003-15 as an Africa-specific policy because I believe it
> will do harm to ARIN as a whole regardless of any positive impact it may
> have on Africa.

please refresh me on this - why do you believe 2003-15 'will do harm to
ARIN as a whole'?

thanks

--Calvin

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------




From ron at aol.net  Fri Oct  3 09:29:34 2003
From: ron at aol.net (Ron da Silva)
Date: Fri, 3 Oct 2003 09:29:34 -0400
Subject: [ppml] My idea was a non-starter
In-Reply-To: <2147483647.1065103478@imac-en0.delong.sj.ca.us> <2147483647.1065100404@imac-en0.delong.sj.ca.us>
References: <Pine.LNX.4.44.0310021113010.32524-100000@sokol.elan.net> <2147483647.1065103478@imac-en0.delong.sj.ca.us> <OFE9630010.F425F1DF-ON80256DB3.003698D4-80256DB3.0036DDE3@radianz.com> <1272596478.1065080289@[192.168.0.101]> <2147483647.1065100404@imac-en0.delong.sj.ca.us>
Message-ID: <20031003132934.GB27767@aol.net>


On Thu, Oct 02, 2003 at 02:04:38PM -0700, Owen DeLong wrote:
> I am hoping that we can achieve clear consensus at the meeting, although,
> I think that will be difficult.

Better would be to determine that consensus here on the list and then
simply confirm it at the meeting.  To summarize,  I believe we have
thusfar seen some support AND opposition to 2002-3 and 2003-15 as-is.
There appears to be some interest in changing either to include
all of ARIN and both assignments and allocations.  I have yet to
see any principal objection to moving assignments/allocations to /22
under any permutation of 200x-315.  So, anyone care to argue AGAINST
changing either assignments or allocations under ANY policy variation?
Or, do we all support (or don't care to comment) such a change under
one of these new or modified policies?

fyi...not that this is an issue, but folks may be interested, other RIRs
have micro assignments but not micro allocations:

http://www.arin.net/library/internet_info/rir_comp_matrix.html

-ron


From william at elan.net  Fri Oct  3 07:44:31 2003
From: william at elan.net (william at elan.net)
Date: Fri, 3 Oct 2003 04:44:31 -0700 (PDT)
Subject: [ppml] My idea was a non-starter
In-Reply-To: <20031003132934.GB27767@aol.net>
Message-ID: <Pine.LNX.4.44.0310030420390.32524-100000@sokol.elan.net>

On Fri, 3 Oct 2003, Ron da Silva wrote:

> fyi...not that this is an issue, but folks may be interested, other RIRs
> have micro assignments but not micro allocations:
> 
> http://www.arin.net/library/internet_info/rir_comp_matrix.html

The matrix is a little outdated as it does not show latest policies from 
LACNIC. Also its not quite true that other RIRs do not make micro-allocations.
In fact as RIPE person here already pointed out they do make micro-allocations
(and if you're interested, I can produce you exact list of those for RIPE &
APNIC by looking at blocks with ALOCATED PI and ALLOCATED PORTABLE status in
whois with block size of /24 - /21), but other RIRs have different meaning for
allocations/assigned blocks which make those two terms seem almost the same.

What is true is that it appears that for other RIRs, micro allocations or
assignments are made only to non-members (but possibly APNIC allows members
to get micro-assignments/allocations too). For LIR/ISPs the minimum allocation
size is /20 but non-members can also request micro (aka portable, aka 
provider independent) assignment or allocation either through any LIR
(with RIPE) or directly coming to RIR (as with APNIC and possibly LACNIC).

The details of policies on this topic are all very different among RIRs
so its difficult to compare exactly (even the matrix does not help on this 
particular issue), but I do think all other RIRs have policies that allow 
organizations (ISPs or not) to get blocks smaller then /20 if they need.

-- 
William Leibzon
Elan Networks
william at elan.net



From dawn.martin at mci.com  Fri Oct  3 10:10:00 2003
From: dawn.martin at mci.com (Dawn Martin)
Date: Fri, 03 Oct 2003 10:10:00 -0400
Subject: [ppml]How far is too far?
In-Reply-To: <20031003132934.GB27767@aol.net>
Message-ID: <001a01c389b8$092f52f0$e3df2799@wcomnet.com>

Just wondering how far we intend on taking this? All assignments and
all allocations coming directly from the RIR's? 
-Dawn Martin

-----Original Message-----
From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Ron
da Silva
Sent: Friday, October 03, 2003 9:30 AM
To: ppml at arin.net
Subject: Re: [ppml] My idea was a non-starter



On Thu, Oct 02, 2003 at 02:04:38PM -0700, Owen DeLong wrote:
> I am hoping that we can achieve clear consensus at the meeting, although,
> I think that will be difficult.

Better would be to determine that consensus here on the list and then
simply confirm it at the meeting.  To summarize,  I believe we have
thusfar seen some support AND opposition to 2002-3 and 2003-15 as-is.
There appears to be some interest in changing either to include
all of ARIN and both assignments and allocations.  I have yet to
see any principal objection to moving assignments/allocations to /22
under any permutation of 200x-315.  So, anyone care to argue AGAINST
changing either assignments or allocations under ANY policy variation?
Or, do we all support (or don't care to comment) such a change under
one of these new or modified policies?

fyi...not that this is an issue, but folks may be interested, other RIRs
have micro assignments but not micro allocations:

http://www.arin.net/library/internet_info/rir_comp_matrix.html

-ron


From Michael.Dillon at radianz.com  Fri Oct  3 10:20:39 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Fri, 3 Oct 2003 15:20:39 +0100
Subject: [ppml] My idea was a non-starter
Message-ID: <OFF44B63BD.F568091D-ON80256DB4.004DE552-80256DB4.004ECBC3@radianz.com>

>So, anyone care to argue AGAINST
>changing either assignments or allocations under ANY policy variation?

I am opposed to changing the assignments/allocations
language of proposal 2003-15 for reasons which I
have stated before and which several people have 
publicly agreed with. Namely, this is a "made-in-Africa"
policy proposal for Africans and we should simply
rubberstamp it based on the fact that the Africans
have agreed to this proposal.

I am also opposed to changing 2003-3 in any way.
If people feel that it doesn't go far enough, then
they should 100% support this as an incremental 
proposal and later introduce a new proposal that 
will complete what was started *LAST YEAR*. This
is not about designing networks or new product
offerings, its about policy. That, by definition,
is politics and it can be messy and ugly and
anything but elegant.

When considering purely the North American
situation and the comments people have made
about micro address blocks I have not seen a
single negative comment against 2002-3 that
was anything more than a complaint that it 
was an ugly and non-elegant way to go about
things.

We don't need elegance here and we don't need
to solve all problems in a single new policy.
But we do need to give clear *DIRECTION* to 
the AC and the BoT. That word again is "direction"
and not "final solution". If an area needs
new policy and there is a proposal that
heads in the right direction then we should
all support it and move on.

There is always the next meeting for any
additional changes.

--Michael Dillon




From billd at cait.wustl.edu  Fri Oct  3 10:34:20 2003
From: billd at cait.wustl.edu (Bill Darte)
Date: Fri, 3 Oct 2003 09:34:20 -0500 
Subject: [ppml]How far is too far?
Message-ID: <DA8A7734F2B39240977D7883C732FF9B02D924@kronos.cait.wustl.edu>

Text forwarded to the list by me earlier proposed that barring unanticipated
problems with route table growth, etc. that the boundary would advance from
/22 to /23 in a year.  There was some feedback that suggested a year my be
to limited a timeframe for the impact evaluation.... this because it will
take time for the knowledge that smaller assignments are available to become
well known and therefore for the full number of requests to be made and also
it takes time for those assignments to make their way into the production
environment.  Subsequent to movement to /23 another waiting and analysis
period would determine the ability to move again to /24 where the process
would stop..........again, this was simply a statement of intent related to
the 2002-3 policy proposal, not something embedded in the policy itself.

Bill Darte
ARIN Advisory Council 


> -----Original Message-----
> From: Dawn Martin [mailto:dawn.martin at mci.com]
> Sent: Friday, October 03, 2003 9:10 AM
> To: ppml at arin.net
> Subject: [ppml]How far is too far?
> 
> 
> Just wondering how far we intend on taking this? All assignments and
> all allocations coming directly from the RIR's? 
> -Dawn Martin
> 
> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Ron
> da Silva
> Sent: Friday, October 03, 2003 9:30 AM
> To: ppml at arin.net
> Subject: Re: [ppml] My idea was a non-starter
> 
> 
> 
> On Thu, Oct 02, 2003 at 02:04:38PM -0700, Owen DeLong wrote:
> > I am hoping that we can achieve clear consensus at the 
> meeting, although,
> > I think that will be difficult.
> 
> Better would be to determine that consensus here on the list and then
> simply confirm it at the meeting.  To summarize,  I believe we have
> thusfar seen some support AND opposition to 2002-3 and 2003-15 as-is.
> There appears to be some interest in changing either to include
> all of ARIN and both assignments and allocations.  I have yet to
> see any principal objection to moving assignments/allocations to /22
> under any permutation of 200x-315.  So, anyone care to argue AGAINST
> changing either assignments or allocations under ANY policy variation?
> Or, do we all support (or don't care to comment) such a change under
> one of these new or modified policies?
> 
> fyi...not that this is an issue, but folks may be interested, 
> other RIRs
> have micro assignments but not micro allocations:
> 
> http://www.arin.net/library/internet_info/rir_comp_matrix.html
> 
> -ron
> 


From william at elan.net  Fri Oct  3 07:59:59 2003
From: william at elan.net (william at elan.net)
Date: Fri, 3 Oct 2003 04:59:59 -0700 (PDT)
Subject: [ppml]How far is too far?
In-Reply-To: <001a01c389b8$092f52f0$e3df2799@wcomnet.com>
Message-ID: <Pine.LNX.4.44.0310030448450.32524-100000@sokol.elan.net>

On Fri, 3 Oct 2003, Dawn Martin wrote:

> Just wondering how far we intend on taking this? All assignments and
> all allocations coming directly from the RIR's? 

I doubt it would ever be substantial amount even if we allow everybody to 
get ips easily with no conditions because most companies just get ISP 
services and expect their isp to provide ip as part of the package.

Personally I think the deciding issue should be if organization is 
multi-homed (has asn and traffic independent of any particular isp), then 
it should be left up to organization to get ips from its ISP or from RIR
(and since its multihomed they already announce their ips as separate 
prefix, so independ assignment from RIR would not cause increase of 
routing table)

And the charge for ips directly from RIR (even micro-allocation) should be
substantial enough to make it seem easier to get ips from their ISP unless
their ISP is monopolistic or trying to charge very high fee for ips (as in 
countries or possibly smaller towns where competition is minimum and you 
do not have much choice who to use).

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Ron
> da Silva
> Sent: Friday, October 03, 2003 9:30 AM
> To: ppml at arin.net
> Subject: Re: [ppml] My idea was a non-starter
> 
> 
> 
> On Thu, Oct 02, 2003 at 02:04:38PM -0700, Owen DeLong wrote:
> > I am hoping that we can achieve clear consensus at the meeting, although,
> > I think that will be difficult.
> 
> Better would be to determine that consensus here on the list and then
> simply confirm it at the meeting.  To summarize,  I believe we have
> thusfar seen some support AND opposition to 2002-3 and 2003-15 as-is.
> There appears to be some interest in changing either to include
> all of ARIN and both assignments and allocations.  I have yet to
> see any principal objection to moving assignments/allocations to /22
> under any permutation of 200x-315.  So, anyone care to argue AGAINST
> changing either assignments or allocations under ANY policy variation?
> Or, do we all support (or don't care to comment) such a change under
> one of these new or modified policies?
> 
> fyi...not that this is an issue, but folks may be interested, other RIRs
> have micro assignments but not micro allocations:
> 
> http://www.arin.net/library/internet_info/rir_comp_matrix.html
> 
> -ron



From bicknell at ufp.org  Fri Oct  3 10:38:04 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 3 Oct 2003 10:38:04 -0400
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <1065185016.15411.43.camel@calvin.coza.net.za>
References: <Pine.GSO.4.20.0310011641370.3089-100000@sun222-31.corp.us.uu.net> <1065070893.9453.40.camel@pear.orange-tree.alt.za> <2147483647.1065096105@imac-en0.delong.sj.ca.us> <1065185016.15411.43.camel@calvin.coza.net.za>
Message-ID: <20031003143804.GA18550@ussenterprise.ufp.org>

In a message written on Fri, Oct 03, 2003 at 02:43:36PM +0200, Calvin Browne wrote:
> I'm going to need arguments other than "it will inadvertantly help you"
> before I change my stance from 'no negative comment, do it if there is
> enough consensus amongst yourselves' to 'yeah - I support it'.

I've seen this comment a couple of times, and as a supporter of
2002-3 I want to clarify my position.

If you go back in the archive you'll see I've proposed many times
that I believe if you have an AS number you should be able to get
a /24 (or larger block if you can justify it).  Remember that the
AS criteria already requires you to be multihomed.  That is, I
support that every multi-homed ISP should be able to get their own
addresses independant of their upstream.

I believe that should be true for EVERYONE EVERYWHERE in the WORLD.

Now, it has become clear to me we're not going to get to what I
want in one step (if we ever get there), so for the moment 2002-3
is the best step forward I think we can get supported.  That doesn't
change my believe that it should apply to everyone, everywhere.

So please, don't think we drafted a US based policy and are now
happy it inadvertantly helps some other group.  I think most
supporters believe this should be a global policy, and while this
is the ARIN mailing list would argue for the same on a RIPE mailing
list, or an APNIC mailing list, or if it were a real registry an
AfriNIC mailing list.

So, we may not have realized the impact this would have on Africa
when we drafted it specifically, but that does not change the fact
that we thought it was good for everyone, and know that we know
Africans are part of everyone that doesn't change one bit.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031003/e93e6fd5/attachment.sig>

From ahp at hilander.com  Fri Oct  3 10:38:14 2003
From: ahp at hilander.com (Alec H. Peterson)
Date: Fri, 03 Oct 2003 08:38:14 -0600
Subject: [ppml]How far is too far?
In-Reply-To: <Pine.LNX.4.44.0310030448450.32524-100000@sokol.elan.net>
References: <Pine.LNX.4.44.0310030448450.32524-100000@sokol.elan.net>
Message-ID: <2147483647.1065170294@[192.168.0.101]>

--On Friday, October 3, 2003 4:59 -0700 william at elan.net wrote:

>
> I doubt it would ever be substantial amount even if we allow everybody to
> get ips easily with no conditions because most companies just get ISP
> services and expect their isp to provide ip as part of the package.

That is merely because that is the way business has been done in recent 
times.  Before any allocation policies were even in place the standard 
practice was to go to the InterNIC to get address space.  Granted there 
were far fewer companies connecting to the Internet, but that is the way it 
was.

My point is that it is a fallacy to think that by making a drastic change 
to our allocation and assignment policies there will be no change in the 
general behavior of those connecting to the Internet.

Alec



From ron at aol.net  Fri Oct  3 10:32:11 2003
From: ron at aol.net (Ron da Silva)
Date: Fri, 3 Oct 2003 10:32:11 -0400
Subject: [ppml] My idea was a non-starter
In-Reply-To: <OFF44B63BD.F568091D-ON80256DB4.004DE552-80256DB4.004ECBC3@radianz.com>
References: <OFF44B63BD.F568091D-ON80256DB4.004DE552-80256DB4.004ECBC3@radianz.com>
Message-ID: <20031003143211.GF27767@aol.net>

On Fri, Oct 03, 2003 at 03:20:39PM +0100, Michael.Dillon at radianz.com wrote:
> There is always the next meeting for any
> additional changes.

we don't need to wait for yet another meeting to make additional
changes that general folks support anyhow.  if we can clearly identify
changes that reflect the consensus of folks here, we can (and should!)
incorporate those changes now rather than continue a perpetual discussion
on micro stuff.  :-)

-ron


From bicknell at ufp.org  Fri Oct  3 10:42:34 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 3 Oct 2003 10:42:34 -0400
Subject: [ppml]How far is too far?
In-Reply-To: <001a01c389b8$092f52f0$e3df2799@wcomnet.com>
References: <20031003132934.GB27767@aol.net> <001a01c389b8$092f52f0$e3df2799@wcomnet.com>
Message-ID: <20031003144234.GB18550@ussenterprise.ufp.org>

In a message written on Fri, Oct 03, 2003 at 10:10:00AM -0400, Dawn Martin wrote:
> Just wondering how far we intend on taking this? All assignments and
> all allocations coming directly from the RIR's? 

I believe anyone with an AS number (so, meets all those requirements)
should be able to get space from an RIR.  They are already interfacing
with an RIR anyway, they are already multi-homed so they probably
are already putting entries in the global table anyway.  Plus, if
we give each AS a big enough block we can get closer to 1 block per
AS (which would be a smaller routing table than today) rather than
having each AS announce 10 little bits they've cobbled together.

In general those without an AS should be getting from their upstream.
I can see how larger, yet single homed entities might want their
own RIR space so they don't have to renumber when they move, and
that's ok.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031003/43195d1d/attachment.sig>

From ron at aol.net  Fri Oct  3 10:38:41 2003
From: ron at aol.net (Ron da Silva)
Date: Fri, 3 Oct 2003 10:38:41 -0400
Subject: [ppml]How far is too far?
In-Reply-To: <20031003144234.GB18550@ussenterprise.ufp.org>
References: <20031003132934.GB27767@aol.net> <001a01c389b8$092f52f0$e3df2799@wcomnet.com> <20031003144234.GB18550@ussenterprise.ufp.org>
Message-ID: <20031003143841.GG27767@aol.net>

On Fri, Oct 03, 2003 at 10:42:34AM -0400, Leo Bicknell wrote:
> In general those without an AS should be getting from their upstream.
> I can see how larger, yet single homed entities might want their
> own RIR space so they don't have to renumber when they move, and
> that's ok.

There is no ASN requirement currently for end-user space
(aka assignments).  So should,

1) a change from /20 to /22 for assignments require ASN from some RIR
2) should ALL assignments (micro or not) be required an ASN
3) should NO assignments (mirco or not) be required an ASN ??

-ron


From william at elan.net  Fri Oct  3 08:30:30 2003
From: william at elan.net (william at elan.net)
Date: Fri, 3 Oct 2003 05:30:30 -0700 (PDT)
Subject: [ppml]How far is too far?
In-Reply-To: <20031003143841.GG27767@aol.net>
Message-ID: <Pine.LNX.4.44.0310030522580.32524-100000@sokol.elan.net>

> On Fri, Oct 03, 2003 at 10:42:34AM -0400, Leo Bicknell wrote:
> > In general those without an AS should be getting from their upstream.
> > I can see how larger, yet single homed entities might want their
> > own RIR space so they don't have to renumber when they move, and
> > that's ok.
> 
> There is no ASN requirement currently for end-user space
That is fine for larger (/20 or even preferably /19 blocks).

> (aka assignments).  So should,
> 1) a change from /20 to /22 for assignments require ASN from some RIR
Yes. Yes. Yes.

> 2) should ALL assignments (micro or not) be required an ASN>
> 3) should NO assignments (mirco or not) be required an ASN ??
All micro assignments and allocations should generally require ASN.

But I'm willing to give an exception for micro-allocation for African region
primarily because of how bad situation is described there with monopoly 
telcos in some countries. I do not believe this is a problem in US or Canada.

To clarify if 5 questions are to be asked the way I sent it yesterday, I would
vote no on question 3 (modifying 2003-15 to be for entire arin region) but
would vote yes on question 4 (modifying 2003-15 for entire arin region but 
only allow micro-allocations if organization has an ASN and is multihomed) 
and I would vote yes on question 5 (2003-15 as-is allowing for special 
circumstance of non-multihomed ISP in African getting a micro-allocation).

-- 
William Leibzon
Elan Networks
william at elan.net



From bicknell at ufp.org  Fri Oct  3 11:03:00 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 3 Oct 2003 11:03:00 -0400
Subject: [ppml]How far is too far?
In-Reply-To: <20031003143841.GG27767@aol.net>
References: <20031003132934.GB27767@aol.net> <001a01c389b8$092f52f0$e3df2799@wcomnet.com> <20031003144234.GB18550@ussenterprise.ufp.org> <20031003143841.GG27767@aol.net>
Message-ID: <20031003150259.GA19792@ussenterprise.ufp.org>

In a message written on Fri, Oct 03, 2003 at 10:38:41AM -0400, Ron da Silva wrote:
> There is no ASN requirement currently for end-user space
> (aka assignments).  So should,
> 
> 1) a change from /20 to /22 for assignments require ASN from some RIR
> 2) should ALL assignments (micro or not) be required an ASN
> 3) should NO assignments (mirco or not) be required an ASN ??

If I were rewriting policy from scratch, my personal view is that:

1) To get an ASN you should have to document that you are multihomed.
   (There are a few possible exceptions, like ISP's may be able to get
   a second as a "customer AS" as many do, and critical infrastructure 
   should have one, even if not immediately multihomed.)
2) Everyone with an ASN should be able to get a /24 with no
   justification.
3) Everyone with an ASN should be able to get a /1-/23, as appropriate,
   with proper justification.  (And no, I'm not sure if I like the 80%,
   or some of the other proposals, so I'll leave it at proper
   justification.)
4) ASN's should be limited to getting space from a single RIR, the RIR
   where the ASN was assigned.  (To insure one entity has full review
   over all the space, when reviews are conducted).
5) Single homed groups with a need for a large amount of space, or
   groups not today connected to the internet but able to demonstrate
   that it is likely they will be in the future should be able to 
   go through a justification process to get space, with a minimum of
   probably a /19.

That said, we're not rewriting from scratch, so a wholesale change
such as I would like is not going to work.  I understand that, and
I'm quite willing to chip away at the problem.

Also, to answer what may be another likely question, I believe that
all RIR's should have the same criteria, so yes, I think what I've
outlined would be good for the world.  (Note, that makes #4 make a
little more sense then it does in today's multi-policy world.)

Note, I think something similar should be true for IPv6 as well,
of course with the boundaries being different, and with 5 being
relaxed since there is A) more space, and B) predicting if unconnected
networks will be connected to the IPv6 backbone in the future is
much harder now, so err on the side that they will.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031003/7d84d51f/attachment.sig>

From alan at futureperfect.co.za  Fri Oct  3 12:01:48 2003
From: alan at futureperfect.co.za (Alan Levin)
Date: Fri, 3 Oct 2003 18:01:48 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <Pine.GSO.4.20.0310020949180.3089-100000@sun222-31.corp.us.uu.net>
Message-ID: <E4EBEAE6-F5BA-11D7-9BAA-000A957A0234@futureperfect.co.za>

Hi Lee,

Re:
> Let me know if I'm spiraling in toward accurate understanding of the
> situation in Africa.

I'm not sure, depends on my shallow view of the following....

> Elsewhere people have said that upstreams' peers would not accept the
> prefixes because they were too small.  That should not be the case,
> for two reasons:
>
>  - ARIN allocations to Africa are from Class C space, and are not
> 	generally filtered at shorter prefix-length.  Your mileage
> 	may vary.

Please can someone else confirm this. My understanding is that only 
legacy class C space (swamp space) is not filtered at shorter 
prefix-length.

>  - Multi-homing is sufficient justification for a /24 re-assignment

My limited understanding is that because of the above, only the 
preferred route to the larger blocks are followed thus limiting 
international multi-homing.   Please keep in mind that there are three 
major ISPs in SA. Not all of them buy transit from anywhere other than 
the US.

I recall at the ICANN meeting in Sweden, when the US link went down, 
only IP's on the one of the three networks was running since they were 
the only ones that had a european transit connection. At that same 
time, our small network - which had local multi-homing enabled - was 
not accessible because the multi-homing was only between the local 
upstream ISPs.

Since >85% of SA traffic is international it is important to ISPs that 
don't own their own global connections that their multi-homing is 
global.

e.g aside but fyi, I use my.yahoo. and some yahoo decided that SA 
traffic should be - automatically - served by the .uk servers...
[neo:~] alanlevin% traceroute www.yahoo.co.uk
traceroute to www2.vip.ukl.yahoo.com (217.12.3.11), 30 hops max, 40 
byte packets
  1  172.16.0.250 (172.16.0.250)  0.448 ms  0.216 ms  0.195 ms
  2  router.barn.za.net (196.7.14.130)  33.258 ms  27.34 ms  29.02 ms
  3  s8-0-7chan23.gw1.cpt1.alter.net (196.31.167.105)  78.872 ms  96.771 
ms  61.185 ms
  4  atm8-0-0sub100.ir2.mia16.alter.net (196.30.229.170)  366.408 ms  
256.937 ms  369.133 ms
  5  pos0-1-0.ih4.mia4.alter.net (152.63.86.145)  278.556 ms  366.868 ms 
  309.099 ms
  6  302.at-6-1-0.xr2.mia4.alter.net (152.63.7.226)  379.2 ms  286.42 ms 
  369.123 ms
  8  0.so-4-2-0.xl2.atl5.alter.net (152.63.81.81)  498.393 ms  307.793 
ms  299.738 mss
  9  pos7-0.br4.atl5.alter.net (152.63.84.153)  358.356 ms  327.266 ms  
379.133 ms
10  204.255.174.206 (204.255.174.206)  338.559 ms  356.398 ms  319.14 ms
11  so-6-0-0.gar2.atlanta1.level3.net (209.247.9.161)  388.705 ms  
347.246 ms  308.971 ms
12  so-0-3-0.bbr2.atlanta1.level3.net (209.247.11.225)  288.686 ms  
315.806 ms  339.516 ms
13  so-0-1-0.bbr2.washington1.level3.net (64.159.0.230)  408.239 ms  
316.926 ms  359.099 ms
14  so-0-0-0.mp2.london2.level3.net (212.187.128.133)  488.702 ms  
497.021 ms  429.077 ms
15  unknown.level3.net (212.187.129.212)  448.61 ms  396.833 ms  
398.985 ms
16  unknown.level3.net (212.113.10.210)  378.574 ms  383.855 ms  398.79 
ms
17  alteon1.34.ukl.yahoo.com (217.12.6.6)  418.382 ms  396.943 ms  
389.141 ms

but when one look a little closer it looks like london is closer to 
miami than silicon valley is...
[neo:~] alanlevin% traceroute my.yahoo.com
traceroute to my.yahoo.akadns.net (66.163.171.129), 30 hops max, 40 
byte packets
  1  172.16.0.250 (172.16.0.250)  0.45 ms  0.222 ms  0.203 ms
  2  router.barn.za.net (196.7.14.130)  16.761 ms  29.095 ms  25.352 ms
  3  s8-0-7chan23.gw1.cpt1.alter.net (196.31.167.105)  73.165 ms  34.876 
ms  53.336 ms
  4  atm8-0-0sub100.ir2.mia16.alter.net (196.30.229.170)  498.812 ms  
398.726 ms  398.98 ms
  5  pos0-1-0.ih4.mia4.alter.net (152.63.86.145)  308.705 ms  268.373 ms 
  349.085 ms
  6  302.at-5-1-0.xr2.mia4.alter.net (152.63.7.182)  288.547 ms  317.476 
ms  329.102 ms
  7  0.so-4-2-0.xl2.mia4.alter.net (152.63.101.46)  308.484 ms  268.485 
ms  289.17 ms
  8  0.so-7-0-0.xl4.atl5.alter.net (152.63.85.194)  378.555 ms  307.495 
ms  359.259 ms
  9  192.atm6-0.br1.atl5.alter.net (152.63.80.121)  278.311 ms  298.481 
ms  299.1 ms
10  204.255.168.74 (204.255.168.74)  288.495 ms  306.661 ms  279.229 ms
11  agr4-loopback.atlanta.cw.net (208.172.66.104)  318.539 ms  336.417 
ms  349.04 ms
12  dcr2-so-1-3-0.atlanta.cw.net (208.172.75.157)  287.664 ms  386.454 
ms  359.082 ms
13  dcr1-loopback.santaclara.cw.net (208.172.146.99)  358.692 ms  
336.632 ms  359.019 ms
14  bhr1-pos-0-0.santaclarasc5.cw.net (208.172.156.74)  408.659 ms  
396.393 ms  469.122 ms
15  csr3-ve243.santaclarasc5.cw.net (64.56.192.146)  458.536 ms  
376.603 ms  398.942 ms
16  g2-1.bas1-m.sc5.yahoo.com (64.56.207.146)  456.941 ms  396.889 ms  
368.972 ms
17  vl48.bas2-m.sc5.yahoo.com (66.163.160.214)  408.563 ms  437.369 ms  
418.622 ms
18  alteon5.128.sc5.yahoo.com (216.136.129.1)  438.14 ms  416.581 ms  
419.057 ms

> Thanks for taking the time and having the patience to help me improve
> my understanding.

Please excuse me if this doesn't relate directly to the policy in 
discussion.....

hth,

Alan

---------------------------------------------
Alan Levin
Tel: +27 21 409-7997



From alan at futureperfect.co.za  Fri Oct  3 12:06:33 2003
From: alan at futureperfect.co.za (Alan Levin)
Date: Fri, 3 Oct 2003 18:06:33 +0200
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region
In-Reply-To: <3F7D691E.25375.65D0479@localhost>
Message-ID: <8EC0C17E-F5BB-11D7-9BAA-000A957A0234@futureperfect.co.za>

Mlawrie wrote:
> It is very difficult from here (Africa) to see any reason why
> exclusinve subregional enfranchising is "extremely harmful" to
> anyone. A subsequent proposal to extend the enfranchised subregion
> will surely stand or fall on its merits at the time, and should not
> be pre-judged at the time that 2003-15 is debated.

Mike, I think this relates to my previous point about economic 
empowerment and comes down to the difference between affirmative action 
and economic empowerment. My understanding is that affirmative action 
has not been much of a success in the US, or in SA. Although very 
closely related and often confused, economic empowerment is more narrow 
and as I understand is far more of a win/win.

alan



From owen at delong.com  Fri Oct  3 13:23:07 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 03 Oct 2003 10:23:07 -0700
Subject: [ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the
 Africa Portion of the ARIN Region
In-Reply-To: <1065157749.12344.19.camel@pear.orange-tree.alt.za>
References: <Pine.GSO.4.44.0309291103460.8405-100000@paixhost.pch.net>	
 <LPENICNLCKCKPNDPFKBACEIBEHAA.William@zanet.co.za>	
 <E1A4Rc3-0006vZ-DQ@ran.psg.com>	
 <LPENICNLCKCKPNDPFKBAKEHPEHAA.William@zanet.co.za>	
 <20031001005559.GA88615@ussenterprise.ufp.org>	
 <1064986004.8397.10.camel@pear.orange-tree.alt.za>	
 <2147483647.1065001551@imac-en0.delong.sj.ca.us>	
 <1065073040.9453.77.camel@pear.orange-tree.alt.za>	
 <2147483647.1065096857@imac-en0.delong.sj.ca.us>
 <1065157749.12344.19.camel@pear.orange-tree.alt.za>
Message-ID: <2147483647.1065176587@imac-en0.delong.sj.ca.us>

>>
>> I think that trying to pretend that ARIN is two separate sub-regions and
>> create
>> two separate voting bodies within ARIN to set policies for those
>> sub-regions isn't likely to be a successful strategy.
>
> Actually, as I understand it, ARIN already runs separate policies for
> sub-regions - at least we get our addresses from separate blocks
> according to which sub-region we're in - this has happened for a while.

That is not policy, that is just good space management knowing that the
separation is likely coming.  Pretending that having ARIN set separate
policy for Sub-Equatorial Africa separately from the rest of ARIN will
somehow be a good thing for ARIN or for AfriNIC when all it really does
is create a larger set of policies for AfriNIC to have to combine/
sort out in creating a unified AfriNIC policy is not a good plan for
ARIN.

> We get to mess in each other's affairs to an extent we probably
> shouldn't :).

Agreed.  The solution for that is to create AfriNIC and have it be it's
own RIR with it's own policies.  I fully support that.  Creating more
ARIN policy that is specific to Sub-Equatorial Africa is a bad hack and
in my opinion will create more problems than it will solve.  However, I'm
hoping that since we have found we may be able to get the policies we
need without dealy, you will:

	1.	Support expanding 2002-3 to include allocations and passing
		that at the meeting.

	2.	Failing 1, support 2002-3 as is.

	3.	Failing 1, support expanding 2003-15 to include all of ARIN
		and passing it at the meeting.

	4.	Failing 1 and 3, accept my support of 2003-15 as is with a
		request that the AC bring an all-ARIN /22 allocation policy
		to the next meeting for passage.

As I said, if we absolutely can't get what is needed for ALL of ARIN, then,
I will be willing to support getting what is needed for Africa.  However,
since all of ARIN needs this, I will _NOT_ support giving it to just Africa
until we have determined that the voting body of ARIN trul wants to
disenfranchise the small(er) North American Organizations.

> It's wrong, it's broken, but it's the reality and we're busy fixing it
> :)
>
Absolutely.  We don't disagree on anything here except the validity of
one particular bandaid in the fix process.  I think our differences come
from a difference in historical perspective on the issue.  I suspect that
you and most of your colleagues are not very familiar with the history of
this issue in ARIN, so, you don't see the disenfranchisement of which I
speak.  I think each and every one of you on the list has done an excellent
job of representing your position, and, I applaud your efforts even though
I don't agree with part of your conclusion.

I am hoping that the above order of support is something you and your
colleagues will be able to unite with North American ISPs and support.
Let's try first to fix this for everyone and get AfriNIC up and running
to make it's own policies ASAP.  Let's treat the symptoms only if we
are denied the cure.

Thanks,

Owen



From owen at delong.com  Fri Oct  3 14:05:02 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 03 Oct 2003 11:05:02 -0700
Subject: [ppml] Policy Proposal 2003-15...
Message-ID: <2147483647.1065179102@imac-en0.delong.sj.ca.us>

>> 2003-15, as is, has significant disenfranchising effects on small(er)
>> ISPs in North America and, as such, would do substantial damage to
>> ARIN as an organization.  It contains good policy, but, the
>> sub-regional exclusivitiy is extremely harmful, and, should not be
>> allowed to pass.
>
> The term "disenfranchise" in this neck of the woods means to take
> something away (like a vote, or some power or right or suchlike).

Right.  By passing 2003-15 as is, in my opinion, it sends the clear
message to small(er) Orgs in North America that their voice does not
and never will matter within ARIN.  That while they can have a vote,
their vote will never be meaningful because they will always have
less sway than the large(r) providers.  Afterall, it sends the message
that they can't have /22 allocations, but, Sub-Equatorial Africa can.

> 2003-15 does no such thing, it takes nothing from anyone. It

In it's words, it obviously doesn't intend to do that.  However, I hope
that I have shown you how it effectively would do exactly that.

> endeavours to make Internet services in a particular sub-region of
> ARIN's control more accessible (ie it "enfranchises" ISPs). That it
> does so to a subset of the ARIN region of control is true, and it
> seems presumptious to suggest that this action will have some kind of
> blocking effect should other subregions ask for similar
> enfranchising. The argument can go either way, ie "it's working OK in

If they hadn't already made that request and had it sort of evaporate
without a trace, I would agree with you.  However, since such a request
has a multi-year history within ARIN, it seems to me that passing it
for Sub-Equatorial Africa first would absolutely have exactly that kind
of effect.

Owen




From owen at delong.com  Fri Oct  3 14:08:40 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 03 Oct 2003 11:08:40 -0700
Subject: [ppml] Policy Proposal 2002-3
In-Reply-To: <1065182777.15411.10.camel@calvin.coza.net.za>
References: <3F7BD992.21549.440E36@localhost>	
 <200310021026.48258.bs@lantic.net>	
 <2147483647.1065099195@imac-en0.delong.sj.ca.us>
 <1065182777.15411.10.camel@calvin.coza.net.za>
Message-ID: <2147483647.1065179320@imac-en0.delong.sj.ca.us>

The main detractors expressed traditionally have been:

	1.	It will lead to explosive growth of the routing table
		causing collapse of the internet.

	2.	It's hard to evaluate it's possible consequences to the
		routing table, so, we shouldn't do it.

Other things expressed have been more along the lines of "there are better
ideas".

In my opinion, 1 is FUD* and 2 is an effort to soften the FUD.

*FUD -- Fear, Uncertainty, and Doubt -- A tool often used by the American
	Media and politicians to manipulate society into making or accepting
	really bad policy decisions in the name of safety.

Owen


--On Friday, October 3, 2003 2:06 PM +0200 Calvin Browne 
<calvin at orange-tree.alt.za> wrote:

> After the murk of the clash between 2002-3 and 2003-15 (which seems to
> be nicely resolved with Owen's suggestion), I'd like to turn the
> discussion back to 2002-3, mainly for my own understanding.
>
> Why should 2002-3 not be passed? or what are the arguments for not
> passing it?
> (and no, "because there are better suggestions" is not a valid answer
> IMHO).
>
> I can't remember seeing any detractors, just people suggesting 'better
> ideas'.
>
> regards
>
> --Calvin
>
> ---------------------* My opinions are mine *---------------------------
>  Calvin Browne calvin at UniForum.org.za c at lvin.co.za
>                Office phone: 080 314 0077        +27 11 314-0077
>                http://orange-tree.alt.za Mobile: +27 83 303-0663
>                Call me for Linux/Internet consulting
> ------------------------------------------------------------------------
>
>




From owen at delong.com  Fri Oct  3 14:27:51 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 03 Oct 2003 11:27:51 -0700
Subject: [ppml]How far is too far?
In-Reply-To: <001a01c389b8$092f52f0$e3df2799@wcomnet.com>
References: <001a01c389b8$092f52f0$e3df2799@wcomnet.com>
Message-ID: <2147483647.1065180471@imac-en0.delong.sj.ca.us>

I doubt it.  I think all of the policies proposed preserve the requirement
for either multihoming or unique routing policy for assignments and
I don't think it is unreasonable for an ISP to be able to get their
allocation directly from the RIR whatever size is needed.  However,
for now, I'd like to see things evaluated based on the proposed /22
boundary without clouding it about where things might go in the future.

Future proposals for longer prefixes should be evaluated on their merit
and in the context of the state of the internet at that time.

Owen


--On Friday, October 3, 2003 10:10 AM -0400 Dawn Martin 
<dawn.martin at mci.com> wrote:

> Just wondering how far we intend on taking this? All assignments and
> all allocations coming directly from the RIR's?
> -Dawn Martin
>
> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Ron
> da Silva
> Sent: Friday, October 03, 2003 9:30 AM
> To: ppml at arin.net
> Subject: Re: [ppml] My idea was a non-starter
>
>
>
> On Thu, Oct 02, 2003 at 02:04:38PM -0700, Owen DeLong wrote:
>> I am hoping that we can achieve clear consensus at the meeting, although,
>> I think that will be difficult.
>
> Better would be to determine that consensus here on the list and then
> simply confirm it at the meeting.  To summarize,  I believe we have
> thusfar seen some support AND opposition to 2002-3 and 2003-15 as-is.
> There appears to be some interest in changing either to include
> all of ARIN and both assignments and allocations.  I have yet to
> see any principal objection to moving assignments/allocations to /22
> under any permutation of 200x-315.  So, anyone care to argue AGAINST
> changing either assignments or allocations under ANY policy variation?
> Or, do we all support (or don't care to comment) such a change under
> one of these new or modified policies?
>
> fyi...not that this is an issue, but folks may be interested, other RIRs
> have micro assignments but not micro allocations:
>
> http://www.arin.net/library/internet_info/rir_comp_matrix.html
>
> -ron




From owen at delong.com  Fri Oct  3 14:33:23 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 03 Oct 2003 11:33:23 -0700
Subject: [ppml] My idea was a non-starter
In-Reply-To: <OFF44B63BD.F568091D-ON80256DB4.004DE552-80256DB4.004ECBC3@radianz.com>
References: <OFF44B63BD.F568091D-ON80256DB4.004DE552-80256DB4.004ECBC3@radia
 nz.com>
Message-ID: <2147483647.1065180803@imac-en0.delong.sj.ca.us>

Michael,
	I'd like your answer to the following questions as if they
were being called for a vote at the meeting in the following order.
Each is a yes, no. or abstain question:

	Should the AC implement a policy similar to 2002-3, but, with the
	language expanded to include allocations as well as assignments
	of /22?

	Should the AC implement 2002-3 as is?

	Should the AC implement a policy similar to 2003-15, but, for
	all of ARIN instead of just Sub-Equitorial Africa?

	Should the AC implement 2003-15 as is?

	Please answer based on the idea that if the first question receives
a large yes vote, the other questions become moot and don't need to be
asked.  If question 1 fails, then questions 2 and 3 will be asked.  If
question receives a large yes vote, question 4 becomes moot and does not
need to be asked.  If question 3 fails, then question 4 will be asked.

Thanks,

Owen



From owen at delong.com  Fri Oct  3 14:41:30 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 03 Oct 2003 11:41:30 -0700
Subject: [ppml]How far is too far?
In-Reply-To: <20031003143841.GG27767@aol.net>
References: <20031003132934.GB27767@aol.net>
 <001a01c389b8$092f52f0$e3df2799@wcomnet.com>
 <20031003144234.GB18550@ussenterprise.ufp.org>
 <20031003143841.GG27767@aol.net>
Message-ID: <2147483647.1065181290@imac-en0.delong.sj.ca.us>

> There is no ASN requirement currently for end-user space
> (aka assignments).  So should,
>
There is, however, a requirement for multihoming or a unique routing
policy.  Either of those should be sufficient.  Either of those would
be sufficient to get an ASN, thus making the ASN requirement moot.

Owen



From arin-member at quadrix.com  Sat Oct  4 09:35:14 2003
From: arin-member at quadrix.com (Bill Van Emburg)
Date: Sat, 04 Oct 2003 09:35:14 -0400
Subject: [ppml]How far is too far?
In-Reply-To: <20031003143841.GG27767@aol.net>
References: <20031003132934.GB27767@aol.net>
 <001a01c389b8$092f52f0$e3df2799@wcomnet.com>
 <20031003144234.GB18550@ussenterprise.ufp.org> <20031003143841.GG27767@aol.net>
Message-ID: <3F7ECC92.7010801@quadrix.com>

Ron da Silva wrote:

> On Fri, Oct 03, 2003 at 10:42:34AM -0400, Leo Bicknell wrote:
> 
>>In general those without an AS should be getting from their upstream.
>>I can see how larger, yet single homed entities might want their
>>own RIR space so they don't have to renumber when they move, and
>>that's ok.
> 
> 
> There is no ASN requirement currently for end-user space
> (aka assignments).  So should,
> 
> 1) a change from /20 to /22 for assignments require ASN from some RIR
> 2) should ALL assignments (micro or not) be required an ASN
> 3) should NO assignments (mirco or not) be required an ASN ??
> 
You need to be careful here.  AS numbers are actually a more limited 
resource than IPv4 addresses!  While I haven't looked at the ARIN graphs 
recently, a couple years ago ASN exhaustion was the most immediate 
threat, although plans were being discussed to extend it....
-- 
				     -- Bill Van Emburg
					Quadrix Solutions, Inc.
Phone: 732-742-0475			(mailto:bve at quadrix.com)
Fax:   309-404-7749			(http://quadrix.com)
		The eBusiness Solutions Company



From jmcburnett at msmgmt.com  Sat Oct  4 10:06:54 2003
From: jmcburnett at msmgmt.com (McBurnett, Jim)
Date: Sat, 4 Oct 2003 10:06:54 -0400
Subject: [ppml]How far is too far?
Message-ID: <9BF6F06C4BC90746ADD6806746492A33499A@msmmail01.msmgmt.com>

> You need to be careful here.  AS numbers are actually a more limited 
> resource than IPv4 addresses!  While I haven't looked at the 
> ARIN graphs 
> recently, a couple years ago ASN exhaustion was the most immediate 
> threat, although plans were being discussed to extend it....
> -- 

Please forgive my ignorance here.
But after the dot-bomb shouldn't a large number of ASN's
now be unused?  and not just that, what about the 
mergers? uunet alternet worldcom etc...
When looking at the netatlantis.org site, I seem to 
see large gaps..

Should we not be considering ASN reclamation?

just a thought...


Jim 


From tme at multicasttech.com  Sat Oct  4 11:00:37 2003
From: tme at multicasttech.com (Marshall Eubanks)
Date: Sat, 04 Oct 2003 11:00:37 -0400
Subject: [ppml]How far is too far?
In-Reply-To: <9BF6F06C4BC90746ADD6806746492A33499A@msmmail01.msmgmt.com>
Message-ID: <web-1783471@multicasttech.com>

On Sat, 4 Oct 2003 10:06:54 -0400
 "McBurnett, Jim" <jmcburnett at msmgmt.com> wrote:
> > You need to be careful here.  AS numbers are actually a more limited 
> > resource than IPv4 addresses!  While I haven't looked at the 
> > ARIN graphs 
> > recently, a couple years ago ASN exhaustion was the most immediate 
> > threat, although plans were being discussed to extend it....
> > -- 
> 
> Please forgive my ignorance here.
> But after the dot-bomb shouldn't a large number of ASN's
> now be unused?  and not just that, what about the 
> mergers? uunet alternet worldcom etc...
> When looking at the netatlantis.org site, I seem to 
> see large gaps..


15776 in my BGP address tables, 30,000 or so assigned or allocated (IANA
isn't talking to me this morning...).

Exhaustion looks to be about one doubling away, with a doubling time
of ~ 5 years.

So you might be able to recover 50% if you were very aggressive, which would buy
you 3 years or so, which I regard as highly optimistic.


                                 Regards
                                 Marshall Eubanks

T.M. Eubanks
e-mail : tme at multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv


I suspect you would have a hard time getting back any ASN currently in use.


> 
> Should we not be considering ASN reclamation?
> 
> just a thought...
> 
> 
> Jim 



From owen at delong.com  Sat Oct  4 12:00:59 2003
From: owen at delong.com (Owen DeLong)
Date: Sat, 04 Oct 2003 09:00:59 -0700
Subject: [ppml]How far is too far?
In-Reply-To: <9BF6F06C4BC90746ADD6806746492A33499A@msmmail01.msmgmt.com>
References: <9BF6F06C4BC90746ADD6806746492A33499A@msmmail01.msmgmt.com>
Message-ID: <2147483647.1065258059@imac-en0.delong.sj.ca.us>

We should.  However, until we have a successful ASN reclamation process
underway, making policy based on the assumption that we can reclaim
ASNs is probably not the best plan.

Since the requirement already exists for end user assignments that the
end user be multihomed or have a unique routing policy, I think the ASN
requirement on this policy would be harmful.  Afterall, if the end user
meets those requirements, they can apply for and get an ASN.  Making them
do so only serves to accelerate ASN exhaustion.

As to ISPs, I believe ISPs which are seeking to do this also need to
be multihomed as part of their justification.  As such, they're probably
already in posession of an ASN, so, virtually no effect there, either.

Owen


--On Saturday, October 4, 2003 10:06 AM -0400 "McBurnett, Jim" 
<jmcburnett at msmgmt.com> wrote:

>> You need to be careful here.  AS numbers are actually a more limited
>> resource than IPv4 addresses!  While I haven't looked at the
>> ARIN graphs
>> recently, a couple years ago ASN exhaustion was the most immediate
>> threat, although plans were being discussed to extend it....
>> --
>
> Please forgive my ignorance here.
> But after the dot-bomb shouldn't a large number of ASN's
> now be unused?  and not just that, what about the
> mergers? uunet alternet worldcom etc...
> When looking at the netatlantis.org site, I seem to
> see large gaps..
>
> Should we not be considering ASN reclamation?
>
> just a thought...
>
>
> Jim




From william at elan.net  Sat Oct  4 10:28:15 2003
From: william at elan.net (william at elan.net)
Date: Sat, 4 Oct 2003 07:28:15 -0700 (PDT)
Subject: [ppml]How far is too far?
In-Reply-To: <web-1783471@multicasttech.com>
Message-ID: <Pine.LNX.4.44.0310040639230.5734-100000@sokol.elan.net>

On Sat, 4 Oct 2003, Marshall Eubanks wrote:

> > Please forgive my ignorance here.
> > But after the dot-bomb shouldn't a large number of ASN's
> > now be unused?  and not just that, what about the 
> > mergers? uunet alternet worldcom etc...
> > When looking at the netatlantis.org site, I seem to 
> > see large gaps..
> 
> 15776 in my BGP address tables, 30,000 or so assigned or allocated (IANA
> isn't talking to me this morning...).

About 29,000 ASNs are allocated (I can check and give exact number of 
somebody needs) because IANA allocates larger blocks, and then RIRs 
allocates from that, and RIRs have not yet allocated entire sets of ASNs 
that was given to them.  IANA's last allocation is 30720-31743 to RIPE 
(they reported it several days ago). That means about 45% of ASNs (based 
on 29,000 number) are allocated or 48% based on 31743 number. And of that
about 55% of ASNs allocated are actively in use.

For ip blocks similar numbers are 7580573 (/24 blocks) or 51% of ip space
(if calculating based on exact allocations by RIRs) or 129 /8 (57% of 
possible ip space when not counting reserved for multicast). For 
comparison number of ip blocks in routing table is 4757590 /24 blocks
or 32% of IPv4 space, so 62% of the number of ip blocks assigned/allocated
are actively in use.

Based on those numbers it is absolutly not clear that we would run out of 
ASNs before running out of IPv4 ips. What is true is that more organizations
got multihomed especially after .bomb of last 3 years, besides that prices
dropped which made things easier. 

Its also clear that we need to start thinking of reclamation process, this 
should preferably be done by joint policy for all RIRs and should apply 
not only to ASNs (and ip blocks) announced by them but for the the ASNs 
and ip blocks given previously by Internic (legacy assignments), those
have largest precentage of unused ip space and asns. Starting reclamation 
from ASNs would be good test before moving to more complex issues with ip 
blocks.

I'll provide link to some of my statistics data for ip blocks next week, 
so you cansee what the current situation is.

-- 
William Leibzon
Elan Networks
william at elan.net



From gih at telstra.net  Sat Oct  4 17:31:05 2003
From: gih at telstra.net (Geoff Huston)
Date: Sun, 05 Oct 2003 07:31:05 +1000
Subject: [ppml]How far is too far?
In-Reply-To: <web-1783471@multicasttech.com>
References: <9BF6F06C4BC90746ADD6806746492A33499A@msmmail01.msmgmt.com>
Message-ID: <5.1.0.14.2.20031005072522.00b3e620@kahuna.telstra.net>

At 11:00 AM 4/10/2003 -0400, Marshall Eubanks wrote:
>On Sat, 4 Oct 2003 10:06:54 -0400
>  "McBurnett, Jim" <jmcburnett at msmgmt.com> wrote:
> > > You need to be careful here.  AS numbers are actually a more limited
> > > resource than IPv4 addresses!  While I haven't looked at the
> > > ARIN graphs
> > > recently, a couple years ago ASN exhaustion was the most immediate
> > > threat, although plans were being discussed to extend it....
> > > --
> >
> > Please forgive my ignorance here.
> > But after the dot-bomb shouldn't a large number of ASN's
> > now be unused?  and not just that, what about the
> > mergers? uunet alternet worldcom etc...
> > When looking at the netatlantis.org site, I seem to
> > see large gaps..
>
>
>15776 in my BGP address tables, 30,000 or so assigned or allocated (IANA
>isn't talking to me this morning...).
>
>Exhaustion looks to be about one doubling away, with a doubling time
>of ~ 5 years.
>
>So you might be able to recover 50% if you were very aggressive, which 
>would buy
>you 3 years or so, which I regard as highly optimistic.


I did some work on this earlier this year, and presented it at the March 
IEPG meeting
prior to the IETF.

http://www.potaroo.net/iepg/march-2003/BGP%20AS%20Number%20Exhaustion.pdf

At current rates the 16 bit AS numbers will exhaust somewhere between 2009
(no reclamation efforts) and 2011 (complete reclamation)

I don't think we have deviated from this projection over the intervening 
months.

It would appear to be prudent that we all swing into using 32 bit AS numbers
somewhere around 2006, in which case extensive AS reclamation would be an
exercise of dubious benefit.


Geoff





From gih at telstra.net  Sun Oct  5 07:56:53 2003
From: gih at telstra.net (Geoff Huston)
Date: Sun, 05 Oct 2003 21:56:53 +1000
Subject: [ppml]How far is too far?
In-Reply-To: <Pine.LNX.4.44.0310040639230.5734-100000@sokol.elan.net>
References: <web-1783471@multicasttech.com>
Message-ID: <5.1.0.14.2.20031005215554.00b3e7a8@kahuna.telstra.net>

 > I'll provide link to some of my statistics data for ip blocks next week,
 > so you cansee what the current situation is.


http://www.potaroo.net/ispcolumn/2003-07-v4-address-lifetime/ale.html

contains an analysis of IPv4 address consumption and trend analysis






From billd at cait.wustl.edu  Sun Oct  5 10:28:38 2003
From: billd at cait.wustl.edu (Bill Darte)
Date: Sun, 5 Oct 2003 09:28:38 -0500 
Subject: [ppml]How far is too far?
Message-ID: <DA8A7734F2B39240977D7883C732FF9B02D92F@kronos.cait.wustl.edu>

No one mentions the work/discussion that I understadng was taking place in
IETF for extending ASN to 64 bits... could someone update me/us on this.

Thanks,

Bill Darte
AC

-----Original Message-----
From: Geoff Huston
To: william at elan.net; ppml at arin.net
Sent: 10/5/03 6:56 AM
Subject: Re: [ppml]How far is too far?

 > I'll provide link to some of my statistics data for ip blocks next
week,
 > so you cansee what the current situation is.


http://www.potaroo.net/ispcolumn/2003-07-v4-address-lifetime/ale.html

contains an analysis of IPv4 address consumption and trend analysis





From owen at delong.com  Sun Oct  5 19:29:58 2003
From: owen at delong.com (Owen DeLong)
Date: Sun, 05 Oct 2003 16:29:58 -0700
Subject: [ppml]How far is too far?
In-Reply-To: <20031005014252.GA28369@aol.net>
References: <9BF6F06C4BC90746ADD6806746492A33499A@msmmail01.msmgmt.com>
 <2147483647.1065258059@imac-en0.delong.sj.ca.us>
 <20031005014252.GA28369@aol.net>
Message-ID: <2147483647.1065371398@imac-en0.delong.sj.ca.us>

You are correct... What I was remembering as that requirement is not there.
The actual requirement is somewhat different from what I stated.
It is contained in RFC 2050 on page 7 and reads as follows:

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
   conditions:

      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.


I stand corrected, but, I still think this is sufficient requirement to
make it unnecessary to require an ASN as a prerequisite.

Owen

--On Saturday, October 4, 2003 9:42 PM -0400 Ron da Silva <ron at aol.net> 
wrote:

>
> Owen,
>
> On Sat, Oct 04, 2003 at 09:00:59AM -0700, Owen DeLong wrote:
>> ...since the requirement already exists for end user assignments that the
>> end user be multihomed or have a unique routing policy...
>
> I'm having difficulty in finding this.  My reading of end-user policy
> is simply that you have to justify space.  There is no multihoming
> or unique routing requirements to obtain an assignment.
>
> http://www.arin.net/policy/ipv4.html#enduser
>
> Now, there are some additional ways of justification for 'allocations'
> (for ISPs) which include multihoming, but not that I can figure for
> end-user space.
>
> I could be missing something, so please point it out if I am!!  :-)
>
> thanks,
> -ron
>




From Michael.Dillon at radianz.com  Mon Oct  6 06:37:06 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 6 Oct 2003 11:37:06 +0100
Subject: [ppml] My idea was a non-starter
Message-ID: <OF82840CBF.C803D635-ON80256DB7.0039B229-80256DB7.003A5422@radianz.com>

>                I'd like your answer to the following questions as if 
they
>were being called for a vote at the meeting in the following order.
>Each is a yes, no. or abstain question:

Sorry, we have 13 policy proposals to be decided on at
the Chicago meeting. I'm not willing to get into 
any more discussion about possible changes to a proposal
(2002-3) that has already gone through the mill
last year. The time has come to make a decision
on 2002-3 and move on. 

If 2002-3 is not sufficient, then we can introduce
a new proposal AFTER 2002-3 has been decided upon.

Personally, on the subject of micro-allocations,
I believe that ARIN should allocate blocks as
small as /24 that are all allocated out of a
clearly identifiable (for filtering purposes)
block of address space. Maybe recycling the
swamp space if ICANN agrees.

But that's not under discussion for this meeting.

--Michael Dillon




From Trevor.Paquette at TeraGo.ca  Mon Oct  6 18:49:16 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Mon, 6 Oct 2003 16:49:16 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <Pine.GSO.4.44.0309301044360.26322-100000@paixhost.pch.net>
Message-ID: <06b101c38c5c$12b4bb20$2a45fea9@teraint.net>

> subdividing. Internal North American issues are irrelevant to 2003-15.

Wrong. Granting 'special' status to ANY group is an issue for everyone, like it or not.

> This is a unique situation that will not happen again and an opportunity
> for us to make a gesture of goodwill towards the ISPs in southern African
> countries.

How do you know it 'will not happen again'?? In Canada, Quebec has had a vote for sovereignty and it failed. However, the local regional politicians have stated very bluntly that they will try and try and try; until it does happens. And if they succed, look for them to also request 'special' status;

IMHO, You'll be setting a precident that others 'will' want to follow or bend to their own 'special' situation; which in the long term will not help 'everyone'. (The needs of the many outweight the needs of the few)

Don't assume this whole Africa thing will never happen again.. You'd best err on the side of 'when' it happens again.. and 'when' it does, look for that new country to want their own policies etc.. Wait till Russia wants thier own RIR.. and all of the other new contries that were created by the breakup of the USSR.

For the record, as a member of ARIN in good standing, I cannot vote in favor of 
2003-15.




From woody at pch.net  Mon Oct  6 18:51:06 2003
From: woody at pch.net (Bill Woodcock)
Date: Mon, 6 Oct 2003 15:51:06 -0700 (PDT)
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <06b101c38c5c$12b4bb20$2a45fea9@teraint.net>
Message-ID: <Pine.GSO.4.44.0310061548480.16360-100000@paixhost.pch.net>

      On Mon, 6 Oct 2003, Trevor Paquette wrote:
    > Don't assume this whole Africa thing will never happen again..
    > You'd best err on the side of 'when' it happens again.. and 'when'
    > it does, look for that new country to want their own policies etc..
    > For the record, as a member of ARIN in good standing, I cannot vote
    > in favor of 2003-15.

For the record, do you think that Canada will secede from North America,
or the U.S. will?

                                -Bill




From william at elan.net  Mon Oct  6 16:46:14 2003
From: william at elan.net (william at elan.net)
Date: Mon, 6 Oct 2003 13:46:14 -0700 (PDT)
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <06b101c38c5c$12b4bb20$2a45fea9@teraint.net>
Message-ID: <Pine.LNX.4.44.0310061328480.32052-100000@sokol.elan.net>


> How do you know it 'will not happen again'?? In Canada, Quebec has had 
> a vote for sovereignty and it failed. However, the local regional 
> politicians have stated very bluntly that they will try and try and try; 
> until it does happens. And if they succed, look for them to also request 
> 'special' status;
Like what - "continent of Quebec"? Be serious!

The only thing I do think that is relevent about Quebec is that ARIN should 
consider providing services in French (which would also apply for large 
parts of Africa that ARIN serves) and translating some of the important
documents on website. They'd appreaciate this and besides other RIRs 
provide services languages in major languages spoken in its region, like 
LACNIC operates entirely in 3 languages for everything, apnic provides 
support in 6+ languages and I think RIPE does as well. I never understood 
before why ARIN has not translated the site or provided support in Spanish 
for when latin american countries were still part of ARIN, but now I guess
its not relevant. But this is completely different topic.

> IMHO, You'll be setting a precident that others 'will' want to follow 
> or bend to their own 'special' situation; which in the long term will 
> not help 'everyone'. (The needs of the many outweight the needs of the few)

If there comes time when there is another RIR in the future in process of 
being setup and process is accepted and supported by other RIRs , I'd not 
have problem with it requesting some special status of its relevent.

-- 
William Leibzon
Elan Networks
william at elan.net



From bmanning at karoshi.com  Mon Oct  6 19:17:49 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Mon, 6 Oct 2003 16:17:49 -0700 (PDT)
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <Pine.GSO.4.44.0310061548480.16360-100000@paixhost.pch.net> from "Bill Woodcock" at Oct 06, 2003 03:51:06 PM
Message-ID: <200310062317.h96NHn726189@karoshi.com>

> 
>       On Mon, 6 Oct 2003, Trevor Paquette wrote:
>     > Don't assume this whole Africa thing will never happen again..
>     > You'd best err on the side of 'when' it happens again.. and 'when'
>     > it does, look for that new country to want their own policies etc..
>     > For the record, as a member of ARIN in good standing, I cannot vote
>     > in favor of 2003-15.
> 
> For the record, do you think that Canada will secede from North America,
> or the U.S. will?
> 
>                                 -Bill
> 
> 
	My money is on Texas... :)

--bill


From Stacy_Taylor at icgcomm.com  Mon Oct  6 19:24:21 2003
From: Stacy_Taylor at icgcomm.com (Taylor, Stacy)
Date: Mon, 6 Oct 2003 17:24:21 -0600 
Subject: [ppml] Afrinic and so-called sub-regional policies
Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DAE476@DENEXG21>


Dude!  Northern California will be the first!!

Stacy
> 
	My money is on Texas... :)

--bill


From Trevor.Paquette at TeraGo.ca  Mon Oct  6 19:45:26 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Mon, 6 Oct 2003 17:45:26 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <Pine.GSO.4.44.0310061548480.16360-100000@paixhost.pch.net>
Message-ID: <06cb01c38c63$eba00690$2a45fea9@teraint.net>

Appreciate the humor and the shot at me, but I did not necessarily mean the US or Canada.. I meant parts there of..

Who's to say that some new 'country' won't want to be considered to have their own RIR?

'Self-Government' as someone else put it...


> -----Original Message-----
> From: Bill Woodcock [mailto:woody at pch.net]
> Sent: Monday, October 06, 2003 4:51 PM
> To: Trevor Paquette
> Cc: Michael.Dillon at radianz.com; ppml at arin.net
> Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> 
> 
>       On Mon, 6 Oct 2003, Trevor Paquette wrote:
>     > Don't assume this whole Africa thing will never happen again..
>     > You'd best err on the side of 'when' it happens again.. 
> and 'when'
>     > it does, look for that new country to want their own 
> policies etc..
>     > For the record, as a member of ARIN in good standing, I 
> cannot vote
>     > in favor of 2003-15.
> 
> For the record, do you think that Canada will secede from 
> North America,
> or the U.S. will?
> 
>                                 -Bill
> 
> 



From Trevor.Paquette at TeraGo.ca  Mon Oct  6 20:15:26 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Mon, 6 Oct 2003 18:15:26 -0600
Subject: [ppml] Policy Proposal 2002-3
In-Reply-To: <1065182777.15411.10.camel@calvin.coza.net.za>
Message-ID: <06e401c38c68$1c2c5260$2a45fea9@teraint.net>


> -----Original Message-----
> From: Calvin Browne
> Sent: Friday, October 03, 2003 6:06 AM
> Subject: Re: [ppml] Policy Proposal 2002-3
> 
.... 
> Why should 2002-3 not be passed? or what are the arguments for not
> passing it?

Folks used to be able to receive direct assignments from ARIN (and other registries) in the past. This ability was revoked for some reason, and it seems that no-one can remember why...

I'd hate for us to go back down the same path and encounter the same problems as did our predecessors only to later go 'DOH!.. no wonder they revoked this ability'.

Why was this ability revoked and the current policy put in place?? Can anyone explain that?



From jmcburnett at msmgmt.com  Mon Oct  6 21:02:53 2003
From: jmcburnett at msmgmt.com (McBurnett, Jim)
Date: Mon, 6 Oct 2003 21:02:53 -0400
Subject: [ppml] Policy Proposal 2002-3
Message-ID: <9BF6F06C4BC90746ADD6806746492A33499D@msmmail01.msmgmt.com>

Trevor,
As far as I see, an end user can STILL
get a direct allocation from ARIN.
but that is for /20 or shorter..
2002-3, which I hugely favor, is for smaller blocks
and based on the fact that a user is multihomed...
http://www.arin.net/policy/2002_3.html

Jim

> -----Original Message-----
> From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca]
> Sent: Monday, October 06, 2003 8:15 PM
> To: calvin at orange-tree.alt.za; ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2002-3
> 
> 
> 
> > -----Original Message-----
> > From: Calvin Browne
> > Sent: Friday, October 03, 2003 6:06 AM
> > Subject: Re: [ppml] Policy Proposal 2002-3
> > 
> .... 
> > Why should 2002-3 not be passed? or what are the arguments for not
> > passing it?
> 
> Folks used to be able to receive direct assignments from ARIN 
> (and other registries) in the past. This ability was revoked 
> for some reason, and it seems that no-one can remember why...
> 
> I'd hate for us to go back down the same path and encounter 
> the same problems as did our predecessors only to later go 
> 'DOH!.. no wonder they revoked this ability'.
> 
> Why was this ability revoked and the current policy put in 
> place?? Can anyone explain that?
> 
> 


From plzak at arin.net  Mon Oct  6 21:09:42 2003
From: plzak at arin.net (Ray Plzak)
Date: Mon, 6 Oct 2003 21:09:42 -0400
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <06cb01c38c63$eba00690$2a45fea9@teraint.net>
Message-ID: <001601c38c6f$b23370c0$1a8888c0@arin.net>

As a point of reference:  An RIR must represent a region that is
continental in scope.  

Ray

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of Trevor Paquette
> Sent: Monday, October 06, 2003 7:45 PM
> To: 'Bill Woodcock'
> Cc: Michael.Dillon at radianz.com; ppml at arin.net
> Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> 
> 
> Appreciate the humor and the shot at me, but I did not 
> necessarily mean the US or Canada.. I meant parts there of..
> 
> Who's to say that some new 'country' won't want to be 
> considered to have their own RIR?
> 
> 'Self-Government' as someone else put it...
> 
> 
> > -----Original Message-----
> > From: Bill Woodcock [mailto:woody at pch.net]
> > Sent: Monday, October 06, 2003 4:51 PM
> > To: Trevor Paquette
> > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > 
> > 
> >       On Mon, 6 Oct 2003, Trevor Paquette wrote:
> >     > Don't assume this whole Africa thing will never happen again..
> >     > You'd best err on the side of 'when' it happens again.. 
> > and 'when'
> >     > it does, look for that new country to want their own 
> > policies etc..
> >     > For the record, as a member of ARIN in good standing, I 
> > cannot vote
> >     > in favor of 2003-15.
> > 
> > For the record, do you think that Canada will secede from 
> > North America,
> > or the U.S. will?
> > 
> >                                 -Bill
> > 
> > 
> 



From plzak at arin.net  Mon Oct  6 21:13:07 2003
From: plzak at arin.net (Ray Plzak)
Date: Mon, 6 Oct 2003 21:13:07 -0400
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <Pine.LNX.4.44.0310061328480.32052-100000@sokol.elan.net>
Message-ID: <001701c38c70$2c181f30$1a8888c0@arin.net>

As a point of reference ARIN has provided Spanish language versions
templates for years.  Because of the database upgrade these templates
became invalid.  ARIN is currently undertaking an update of this not
only in Spanish but also in French.  Other documents will be included as
well.  

Ray

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of william at elan.net
> Sent: Monday, October 06, 2003 4:46 PM
> To: ppml at arin.net
> Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> 
> 
> 
> > How do you know it 'will not happen again'?? In Canada, 
> Quebec has had 
> > a vote for sovereignty and it failed. However, the local regional 
> > politicians have stated very bluntly that they will try and 
> try and try; 
> > until it does happens. And if they succed, look for them to 
> also request 
> > 'special' status;
> Like what - "continent of Quebec"? Be serious!
> 
> The only thing I do think that is relevent about Quebec is 
> that ARIN should 
> consider providing services in French (which would also apply 
> for large 
> parts of Africa that ARIN serves) and translating some of the 
> important
> documents on website. They'd appreaciate this and besides other RIRs 
> provide services languages in major languages spoken in its 
> region, like 
> LACNIC operates entirely in 3 languages for everything, apnic 
> provides 
> support in 6+ languages and I think RIPE does as well. I 
> never understood 
> before why ARIN has not translated the site or provided 
> support in Spanish 
> for when latin american countries were still part of ARIN, 
> but now I guess
> its not relevant. But this is completely different topic.
> 
> > IMHO, You'll be setting a precident that others 'will' want 
> to follow 
> > or bend to their own 'special' situation; which in the long 
> term will 
> > not help 'everyone'. (The needs of the many outweight the 
> needs of the few)
> 
> If there comes time when there is another RIR in the future 
> in process of 
> being setup and process is accepted and supported by other 
> RIRs , I'd not 
> have problem with it requesting some special status of its relevent.
> 
> -- 
> William Leibzon
> Elan Networks
> william at elan.net
> 



From owen at delong.com  Mon Oct  6 21:47:15 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 06 Oct 2003 18:47:15 -0700
Subject: [ppml] Policy Proposal 2002-3
In-Reply-To: <06e401c38c68$1c2c5260$2a45fea9@teraint.net>
References: <06e401c38c68$1c2c5260$2a45fea9@teraint.net>
Message-ID: <2147483647.1065466035@dhcp157-204.corp.tellme.com>



--On Monday, October 6, 2003 18:15 -0600 Trevor Paquette 
<Trevor.Paquette at terago.ca> wrote:

>
>> -----Original Message-----
>> From: Calvin Browne
>> Sent: Friday, October 03, 2003 6:06 AM
>> Subject: Re: [ppml] Policy Proposal 2002-3
>>
> ....
>> Why should 2002-3 not be passed? or what are the arguments for not
>> passing it?
>
> Folks used to be able to receive direct assignments from ARIN (and other
> registries) in the past. This ability was revoked for some reason, and it
> seems that no-one can remember why...
>
It was not revoked.  I recently got several direct assignments from ARIN.
The convenient boundary for getting an assignment is currently /20.  The
original intent of RFC2050 appears to have been /20, except in some
circumstances which allow a /24.  The /24 ability seems to have been mostly
deprecated by ARIN policy.  2002-3 without modification attempts to move the
current /20 boundary for end-user assignments to /22.

> I'd hate for us to go back down the same path and encounter the same
> problems as did our predecessors only to later go 'DOH!.. no wonder they
> revoked this ability'.
>
It was never revoked.  It was raised up to /18 and later relaxed to /20.
This was done because of routing table growth and backbone routers that
could not handle the scaling of the routing table.  At the time, routers
were having trouble handling more than 50-70k prefixes.  Today, routers
are handling the 120+k prefixes in today's routing table without difficulty.
There is little to indicate that relaxing this to a /22 at this point would
outstrip the gains in router technology since that time.

> Why was this ability revoked and the current policy put in place?? Can
> anyone explain that?
>
It was not revoked.  Current policy was put in place as a relaxation from
the initial over-reaction to the situation.  This is a further 
rationalization
of that towards the original policy now that the technology can handle it.



Owen



From Trevor.Paquette at TeraGo.ca  Mon Oct  6 22:22:45 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Mon, 6 Oct 2003 20:22:45 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <001601c38c6f$b23370c0$1a8888c0@arin.net>
Message-ID: <070d01c38c79$e5679c50$2a45fea9@teraint.net>

Point of reference...

The following countries are part of LACNIC, and the last time I checked a map they are part of North America (and hence should be part of ARIN, not LACNIC)

PANAMA 
COSTA RICA 
CUBA
DOMINICAN REPUBLIC 
HONDURAS 
MEXICO 
NICARAGUA 
GUATEMALA 
ARUBA 
TRINIDAD AND TOBAGO 

The argument regarding continental scope does not apply.

It's very easy to shift boundaries to meet one's goals... as in the case of LACNIC, which is based more on a common language and culture, then on something that is continental in scope. Saying it is continental is just a 'convenience'.


> -----Original Message-----
> From: Ray Plzak [mailto:plzak at arin.net]
> Sent: Monday, October 06, 2003 7:10 PM
> To: 'Trevor Paquette'; 'Bill Woodcock'
> Cc: Michael.Dillon at radianz.com; ppml at arin.net
> Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> 
> 
> As a point of reference:  An RIR must represent a region that is
> continental in scope.  
> 
> Ray
> 
> > -----Original Message-----
> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> > Behalf Of Trevor Paquette
> > Sent: Monday, October 06, 2003 7:45 PM
> > To: 'Bill Woodcock'
> > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > 
> > 
> > Appreciate the humor and the shot at me, but I did not 
> > necessarily mean the US or Canada.. I meant parts there of..
> > 
> > Who's to say that some new 'country' won't want to be 
> > considered to have their own RIR?
> > 
> > 'Self-Government' as someone else put it...
> > 
> > 
> > > -----Original Message-----
> > > From: Bill Woodcock [mailto:woody at pch.net]
> > > Sent: Monday, October 06, 2003 4:51 PM
> > > To: Trevor Paquette
> > > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > > 
> > > 
> > >       On Mon, 6 Oct 2003, Trevor Paquette wrote:
> > >     > Don't assume this whole Africa thing will never 
> happen again..
> > >     > You'd best err on the side of 'when' it happens again.. 
> > > and 'when'
> > >     > it does, look for that new country to want their own 
> > > policies etc..
> > >     > For the record, as a member of ARIN in good standing, I 
> > > cannot vote
> > >     > in favor of 2003-15.
> > > 
> > > For the record, do you think that Canada will secede from 
> > > North America,
> > > or the U.S. will?
> > > 
> > >                                 -Bill
> > > 
> > > 
> > 
> 



From woody at pch.net  Mon Oct  6 22:30:33 2003
From: woody at pch.net (Bill Woodcock)
Date: Mon, 6 Oct 2003 19:30:33 -0700 (PDT)
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <070d01c38c79$e5679c50$2a45fea9@teraint.net>
Message-ID: <Pine.GSO.4.44.0310061929420.19925-100000@paixhost.pch.net>

      On Mon, 6 Oct 2003, Trevor Paquette wrote:
    > Point of reference...
    > The following countries are part of LACNIC, and the last time I checked a map they are part of North America (and hence should be part of ARIN, not LACNIC)

Um, what exactly does "Latin American" mean to you, then?

Where are these arguments going?

                                -Bill




From john at chagres.net  Mon Oct  6 22:48:42 2003
From: john at chagres.net (John Brown)
Date: Mon, 6 Oct 2003 20:48:42 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <070d01c38c79$e5679c50$2a45fea9@teraint.net>; from Trevor.Paquette@TeraGo.ca on Mon, Oct 06, 2003 at 08:22:45PM -0600
References: <001601c38c6f$b23370c0$1a8888c0@arin.net> <070d01c38c79$e5679c50$2a45fea9@teraint.net>
Message-ID: <20031006204842.A50993@alderaan.chagres.net>

Hi,

Being that I was *born and raised* in what we called Latin America,
ergo a country call Panama, I'd say that LACNIC is properly
defined.


Inso far as the long winded rants about policy, borders 
and the like...

Policies created within ARIN *should* apply to the entire ARIN
region.  Sub-region seems like a bad direction....


Cheers

john brown


On Mon, Oct 06, 2003 at 08:22:45PM -0600, Trevor Paquette wrote:
> Point of reference...
> 
> The following countries are part of LACNIC, and the last time I checked a map they are part of North America (and hence should be part of ARIN, not LACNIC)
> 
> PANAMA 
> COSTA RICA 
> CUBA
> DOMINICAN REPUBLIC 
> HONDURAS 
> MEXICO 
> NICARAGUA 
> GUATEMALA 
> ARUBA 
> TRINIDAD AND TOBAGO 
> 
> The argument regarding continental scope does not apply.
> 
> It's very easy to shift boundaries to meet one's goals... as in the case of LACNIC, which is based more on a common language and culture, then on something that is continental in scope. Saying it is continental is just a 'convenience'.
> 
> 
> > -----Original Message-----
> > From: Ray Plzak [mailto:plzak at arin.net]
> > Sent: Monday, October 06, 2003 7:10 PM
> > To: 'Trevor Paquette'; 'Bill Woodcock'
> > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > 
> > 
> > As a point of reference:  An RIR must represent a region that is
> > continental in scope.  
> > 
> > Ray
> > 
> > > -----Original Message-----
> > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> > > Behalf Of Trevor Paquette
> > > Sent: Monday, October 06, 2003 7:45 PM
> > > To: 'Bill Woodcock'
> > > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > > 
> > > 
> > > Appreciate the humor and the shot at me, but I did not 
> > > necessarily mean the US or Canada.. I meant parts there of..
> > > 
> > > Who's to say that some new 'country' won't want to be 
> > > considered to have their own RIR?
> > > 
> > > 'Self-Government' as someone else put it...
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Bill Woodcock [mailto:woody at pch.net]
> > > > Sent: Monday, October 06, 2003 4:51 PM
> > > > To: Trevor Paquette
> > > > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > > > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > > > 
> > > > 
> > > >       On Mon, 6 Oct 2003, Trevor Paquette wrote:
> > > >     > Don't assume this whole Africa thing will never 
> > happen again..
> > > >     > You'd best err on the side of 'when' it happens again.. 
> > > > and 'when'
> > > >     > it does, look for that new country to want their own 
> > > > policies etc..
> > > >     > For the record, as a member of ARIN in good standing, I 
> > > > cannot vote
> > > >     > in favor of 2003-15.
> > > > 
> > > > For the record, do you think that Canada will secede from 
> > > > North America,
> > > > or the U.S. will?
> > > > 
> > > >                                 -Bill
> > > > 
> > > > 
> > > 
> > 
> 


From billd at cait.wustl.edu  Mon Oct  6 23:59:31 2003
From: billd at cait.wustl.edu (Bill Darte)
Date: Mon, 6 Oct 2003 22:59:31 -0500 
Subject: [ppml] Policy Proposal 2002-3
Message-ID: <DA8A7734F2B39240977D7883C732FF9B02D941@kronos.cait.wustl.edu>

Not to nit pick your message, but for the sake of consistency...
End Users indeed may receive "assignments" from ARIN.

Bill Darte
ARIN AC

-----Original Message-----
From: McBurnett, Jim
To: Trevor Paquette; calvin at orange-tree.alt.za; ppml at arin.net
Sent: 10/6/03 8:02 PM
Subject: RE: [ppml] Policy Proposal 2002-3

Trevor,
As far as I see, an end user can STILL
get a direct allocation from ARIN.
but that is for /20 or shorter..
2002-3, which I hugely favor, is for smaller blocks
and based on the fact that a user is multihomed...
http://www.arin.net/policy/2002_3.html

Jim

> -----Original Message-----
> From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca]
> Sent: Monday, October 06, 2003 8:15 PM
> To: calvin at orange-tree.alt.za; ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2002-3
> 
> 
> 
> > -----Original Message-----
> > From: Calvin Browne
> > Sent: Friday, October 03, 2003 6:06 AM
> > Subject: Re: [ppml] Policy Proposal 2002-3
> > 
> .... 
> > Why should 2002-3 not be passed? or what are the arguments for not
> > passing it?
> 
> Folks used to be able to receive direct assignments from ARIN 
> (and other registries) in the past. This ability was revoked 
> for some reason, and it seems that no-one can remember why...
> 
> I'd hate for us to go back down the same path and encounter 
> the same problems as did our predecessors only to later go 
> 'DOH!.. no wonder they revoked this ability'.
> 
> Why was this ability revoked and the current policy put in 
> place?? Can anyone explain that?
> 
> 


From calvin at orange-tree.alt.za  Tue Oct  7 01:57:20 2003
From: calvin at orange-tree.alt.za (Calvin Browne)
Date: 07 Oct 2003 07:57:20 +0200
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <Pine.LNX.4.44.0310061328480.32052-100000@sokol.elan.net>
References: <Pine.LNX.4.44.0310061328480.32052-100000@sokol.elan.net>
Message-ID: <1065506240.4860.1.camel@calvin.coza.net.za>

On Mon, 2003-10-06 at 22:46, william at elan.net wrote:
<SNIP>

> 
> > IMHO, You'll be setting a precident that others 'will' want to follow 
> > or bend to their own 'special' situation; which in the long term will 
> > not help 'everyone'. (The needs of the many outweight the needs of the few)
> 
> If there comes time when there is another RIR in the future in process of 
> being setup and process is accepted and supported by other RIRs , I'd not 
> have problem with it requesting some special status of its relevent.

I thought that thats what 
http://www.afrinic.org/afrinic_support_2003_15.pdf was.

regards

--Calvin

---------------------* My opinions are mine *---------------------------
 Calvin Browne calvin at UniForum.org.za c at lvin.co.za
               Office phone: 080 314 0077        +27 11 314-0077
               http://orange-tree.alt.za Mobile: +27 83 303-0663
               Call me for Linux/Internet consulting
------------------------------------------------------------------------




From lea.roberts at stanford.edu  Tue Oct  7 02:45:54 2003
From: lea.roberts at stanford.edu (Lea Roberts)
Date: Mon, 6 Oct 2003 23:45:54 -0700 (PDT)
Subject: [ppml] Policy Proposal 2002-3
In-Reply-To: <06e401c38c68$1c2c5260$2a45fea9@teraint.net>
Message-ID: <Pine.GSO.4.44.0310062344420.26039-100000@networking.Stanford.EDU>

Trevor -

the basic problem is that old model for everyone to get direct assignments
from the InterNIC (or now the RIRs :-) just doesn't scale.

in the early 1990s, it was asserted that IPv4 addresses were being
consumed too rapidly.  Back then addresses were assigned in "classes". If
a site needed more than a /24 (Class C) they would get a /16 (Class B) and
class B assignments were being made at an increasingly rapid rate.  In
response to this, Classless InterDomain Routing (CIDR) was born and
addresses could be assigned more efficiently with variable "prefix"
lengths. (see RFC 1519, September 1993)

then, as Owen has said, there were problems with the explosion of routing
table size approaching the limits of the hardware then running in the
core.  the solution was to encourage hierarchical address assignment, also
known as provider assigned addresses, so that an ISP could aggregate a
number of its sites into one advertisement into the global routing table.
thus CIDR came to the rescure for the routing table problem as well.
it's taken most of these ten years for the paradigm shift to solidify and
I would hate to see a rush back to where individual assignments from an
RIR would be the norm rather than a special case.

note there is another dichotomy.  when ARIN makes address assignments, it
cannot guarantee the routability of the addresses.  there are other
players in the scene, e.g. the network operators.  they can negate the
effect of a prefix length change by refusing to accept the routes.  an
unroutable assignment is not worth much!  :-)

since ARIN was formed, one of the challenges has been to establish
policies that preserve the stability of the internet while allowing it to
continue to expand.  the struggle over micro-assignments is ongoing, many
of us who were around 10 years ago still feel that it is wise to be
cautious in changing the size of assignments.  there are ongoing studies
on the next potential for network instability: the convergence time after
route flaps, which is also related to the routing table size.

so while router hardware has improved, there may need to be protocol and
other software improvements in the backbone before advocating the end of
hierachical address assignments makes sense.  As the "swamp"  of original
address assignments reminds us and as you express as a wise concern, the
assignment of addresses is almost completely a one way street.  once the
boundary is moved, we won't be able to undo the assigments should the next
performance barrier be reached.  thus some of us on the Advisory Council
are suggesting that these changes should be gradual and their effects
monitored carefully before moving the boundary again.

		there's never a dull moment in networking land,  /Lea


On Mon, 6 Oct 2003, Trevor Paquette wrote:

> Folks used to be able to receive direct assignments from ARIN (and other registries) in the past. This ability was revoked for some reason, and it seems that no-one can remember why...
>
> I'd hate for us to go back down the same path and encounter the same problems as did our predecessors only to later go 'DOH!.. no wonder they revoked this ability'.
>
> Why was this ability revoked and the current policy put in place?? Can anyone explain that?



From gregm at datapro.co.za  Tue Oct  7 05:59:14 2003
From: gregm at datapro.co.za (Gregory Massel)
Date: Tue, 7 Oct 2003 11:59:14 +0200
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <06b101c38c5c$12b4bb20$2a45fea9@teraint.net>
References: <06b101c38c5c$12b4bb20$2a45fea9@teraint.net>
Message-ID: <200310071159.14325.gregm@datapro.co.za>

> Don't assume this whole Africa thing will never happen again.. You'd best
> err on the side of 'when' it happens again.. and 'when' it does, look for
> that new country to want their own policies etc.. Wait till Russia wants
> thier own RIR.. and all of the other new contries that were created by the
> breakup of the USSR.

I didn't know whether to burst out laughing or in tears when I read this.

The last time I checked, 'Africa' was a *CONTINENT*, comprising 53 countries 
20% of the earth's land, and approximately 778 million people.

Its population is approximately 1.61 times the population of the North 
American continent and its size approximately 1.23 times the size of the 
North American continent.

I cannot confirm the exact validity of this data, but the source I've obtained 
it from is http://www.worldatlas.com/ and I have no reason to disbelieve it.

I hope that puts your concerns in perspective...

--Greg



From jmcburnett at msmgmt.com  Tue Oct  7 06:47:06 2003
From: jmcburnett at msmgmt.com (McBurnett, Jim)
Date: Tue, 7 Oct 2003 06:47:06 -0400
Subject: [ppml] Policy Proposal 2002-3
Message-ID: <9BF6F06C4BC90746ADD6806746492A336909F3@msmmail01.msmgmt.com>

oops..
Thanks!
Jim

> -----Original Message-----
> From: Bill Darte [mailto:billd at cait.wustl.edu]
> Sent: Tuesday, October 07, 2003 12:00 AM
> To: McBurnett, Jim; 'Trevor Paquette '; 'calvin at orange-tree.alt.za ';
> 'ppml at arin.net '
> Subject: RE: [ppml] Policy Proposal 2002-3
> 
> 
> Not to nit pick your message, but for the sake of consistency...
> End Users indeed may receive "assignments" from ARIN.
> 
> Bill Darte
> ARIN AC
> 
> -----Original Message-----
> From: McBurnett, Jim
> To: Trevor Paquette; calvin at orange-tree.alt.za; ppml at arin.net
> Sent: 10/6/03 8:02 PM
> Subject: RE: [ppml] Policy Proposal 2002-3
> 
> Trevor,
> As far as I see, an end user can STILL
> get a direct allocation from ARIN.
> but that is for /20 or shorter..
> 2002-3, which I hugely favor, is for smaller blocks
> and based on the fact that a user is multihomed...
> http://www.arin.net/policy/2002_3.html
> 
> Jim
> 
> > -----Original Message-----
> > From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca]
> > Sent: Monday, October 06, 2003 8:15 PM
> > To: calvin at orange-tree.alt.za; ppml at arin.net
> > Subject: RE: [ppml] Policy Proposal 2002-3
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Calvin Browne
> > > Sent: Friday, October 03, 2003 6:06 AM
> > > Subject: Re: [ppml] Policy Proposal 2002-3
> > > 
> > .... 
> > > Why should 2002-3 not be passed? or what are the arguments for not
> > > passing it?
> > 
> > Folks used to be able to receive direct assignments from ARIN 
> > (and other registries) in the past. This ability was revoked 
> > for some reason, and it seems that no-one can remember why...
> > 
> > I'd hate for us to go back down the same path and encounter 
> > the same problems as did our predecessors only to later go 
> > 'DOH!.. no wonder they revoked this ability'.
> > 
> > Why was this ability revoked and the current policy put in 
> > place?? Can anyone explain that?
> > 
> > 
> 


From ron at aol.net  Tue Oct  7 08:51:09 2003
From: ron at aol.net (Ron da Silva)
Date: Tue, 7 Oct 2003 08:51:09 -0400
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA04DAE476@DENEXG21>
References: <5BDB545714D0764F8452CC5A25DDEEFA04DAE476@DENEXG21>
Message-ID: <20031007125109.GA29289@aol.net>

On Mon, Oct 06, 2003 at 05:24:21PM -0600, Taylor, Stacy wrote:
> 
> Dude!  Northern California will be the first!!

...only because of some major tectonic movement westward!  ;-)
-ron



From Trevor.Paquette at TeraGo.ca  Tue Oct  7 11:09:33 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Tue, 7 Oct 2003 09:09:33 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <20031006204842.A50993@alderaan.chagres.net>
Message-ID: <00ac01c38ce5$045a6be0$2a45fea9@teraint.net>

> -----Original Message-----
> From: John Brown [mailto:john at chagres.net]
> Sent: Monday, October 06, 2003 8:49 PM
> To: Trevor Paquette
> Cc: 'Ray Plzak'; 'Bill Woodcock'; Michael.Dillon at radianz.com;
> ppml at arin.net
> Subject: Re: [ppml] Afrinic and so-called sub-regional policies
...
 
> Policies created within ARIN *should* apply to the entire ARIN
> region.  Sub-region seems like a bad direction....

My point exactly.. policies by and for ARIN should apply to ALL of ARIN; not just a sub-region.

What then would stop California or Saskatchewan to say 'We need a special policy that applies just to us'.





From Trevor.Paquette at TeraGo.ca  Tue Oct  7 11:19:09 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Tue, 7 Oct 2003 09:19:09 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <Pine.GSO.4.44.0310061929420.19925-100000@paixhost.pch.net>
Message-ID: <016501c38ce6$5baff210$2a45fea9@teraint.net>

> -----Original Message-----
> From: Bill Woodcock [mailto:woody at pch.net]
> Sent: Monday, October 06, 2003 8:31 PM
> To: Trevor Paquette
> Cc: 'Ray Plzak'; Michael.Dillon at radianz.com; ppml at arin.net
> Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> 
> 
>       On Mon, 6 Oct 2003, Trevor Paquette wrote:
>     > Point of reference...
>     > The following countries are part of LACNIC, and the 
> last time I checked a map they are part of North America (and 
> hence should be part of ARIN, not LACNIC)
> 
> Um, what exactly does "Latin American" mean to you, then?

If you had read my entire post you would have seen the following:
"... as in the case of LACNIC, which is based more on a common language and culture, then on something that is continental in scope."

> Where are these arguments going?

Don't assume that this is a 'one time deal". When you set policy, you set precident. As mentioned in a previous email of mine, policy set by and for ARIN should apply to ALL of ARIN, not just a sub-region.

If and when AFRINIC gets going and can actually set their OWN policies, then they can do what they want for their region(s). Until then and as long as they are part of ARIN, they must abide by the guidelines that are setout for all of ARIN.

If they want to relax their requirements for IP space once they become their own RIR, then they are free to do so; in fact I encourage it as there seems to be a demand from their own special needs.

This is my point. I hope that makes it clear.



From Trevor.Paquette at TeraGo.ca  Tue Oct  7 11:30:16 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Tue, 7 Oct 2003 09:30:16 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <200310071159.14325.gregm@datapro.co.za>
Message-ID: <016c01c38ce7$e9a7d410$2a45fea9@teraint.net>

And out of those 778 million people how many actually "have" Internet services?

Compare that to North America on a percentage basis and I think you'll find that the percentage is considerably higher in North America then in Africa. I hope this puts your concerns into perspective.

I fully support the creation of AFRINIC, there is a need for it as voiced by some members to this group.

However, until AFRINIC becomes a reality and (this is the keyword here 'AND') they can set their own policies and guidelines, they must live within the policies setout for all of ARIN.


> -----Original Message-----
> From: Gregory Massel [mailto:gregm at datapro.co.za]
> Sent: Tuesday, October 07, 2003 3:59 AM
> To: Trevor Paquette
> Cc: ppml at arin.net
> Subject: Re: [ppml] Afrinic and so-called sub-regional policies
> 
> 
> > Don't assume this whole Africa thing will never happen again.. You'd best
> > err on the side of 'when' it happens again.. and 'when' it does, look for
> > that new country to want their own policies etc.. Wait till Russia wants
> > thier own RIR.. and all of the other new contries that were created by the
> > breakup of the USSR.
> 
> I didn't know whether to burst out laughing or in tears when I read this.
> 
> The last time I checked, 'Africa' was a *CONTINENT*, comprising 53 countries 
> 20% of the earth's land, and approximately 778 million people.
> 
> Its population is approximately 1.61 times the population of the North 
> American continent and its size approximately 1.23 times the size of the 
> North American continent.
> 
> I cannot confirm the exact validity of this data, but the source I've obtained 
> it from is http://www.worldatlas.com/ and I have no reason to disbelieve it.
> 
> I hope that puts your concerns in perspective...
> 
> --Greg
> 



From john at chagres.net  Tue Oct  7 11:43:40 2003
From: john at chagres.net (John Brown)
Date: Tue, 7 Oct 2003 09:43:40 -0600
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
Message-ID: <20031007094340.A69167@alderaan.chagres.net>


The ARIN sub-region known as "Rural America", those
localities with a population of less than 1 million
persons here by proposes the following Policy Proposal.


Background:

Rural America service providers have been held captive
and have been disenfranchised via the ARIN process.

Rural America service providers operate at a significant
economic disadvantage with respect to the allocation
of Internet Numbering resources from ARIN.

Rural America service provdiers are captive to their
upstream "backbone" providers as current ARIN policy
prohibits Rural America providers from receiving 
direct allocations from ARIN.

Rural America service providers are unable to, based
on population densities of the serviced area, to qualify
for direct allocation from ARIN.

Rural America service providers typically service between
2000 and 10,000 dial up customers.  Based on typical over
subscription ratios, this means the Rural America service
provider only needs 1 to 4 /24 sized prefixes.  This does
not count the slow growth of other services

Rural America, our "Heart Land" is a vital part of the
American economy.  As such they now depend on reliable and
stable internet connectivity to conduct much of their
commerce.   

Rural America customers require their service provdiers
to operate in a more stable manner.

Rural America service providers are unable to easly and
with low impact to their customers switch backbone providers.

Rural America providers are *required* to renumber each
and every time they change backbone providers.  Backbone
providers use this as a way to hold these Rural America
providers captive.

Rural America needs the freedom and flexibility to control
their destiny and their operations

Rural America internet users have the "right" to receive
reliable and stable internet services, to have a choice
of local providers for that service and to not have to
renumber many times.


Therefore,  This policy proposal serves to help this 
sub-regional group known as Rural America.  This policy
applies to Rural America only.  It specifically *excludes*
non-rural locations, those providers operating in
non-rural locations.



1. Minimum Allocation:  The minimum allocation size
for ISP's located within Rural America is changed to
a /22

2. Allocation Criteria.

   a.  The requesting org must show the efficient 
utilization of an entire previously allocated /23
from their upstream ISP.  This allocation (/23) may
have been provide by one or more upstream providers
and does not have to be contiguous.


   b.  A multi-homed org must show an efficient utilization 
of an entire previously allocated /23 from their 
upstream(s).  This allocation (/23) may have been provided
by one or more upstream provdiers, and does not have
to be contiguous in numbering.


   c.  Additional alloctions.  Rural America organizations
may apply for additional space, and ARIN will allocate 
additional space on a /22 basis, at a minimum.  Nothing here
prevents the Rural America orginzation from requesting and
receiving larger allocations, providing the usage is justified.


3.  Utilization Reporting and Justification.  All other
ARIN policies reguarding the reporting of justification information
for the allocation of IPv4 address space will remain 
in effect.

4.  IPv6 considerations:  Rural America providers are eager
to start testing and deploying IPv6 networks.  Rural America
operators have the ability to deploy IPv6 quicker than larger
providers.  Therefor, providers that receive IPv4 space
under this policy shall also be permitted to request and 
receive a single /48 of IPv6 space.  This will help enable
rural providers and move them forward with IPv6 technology.
Further allocations will be handled under current IPv6 policy.


5.  Pricing.  The ARIN BOT will review and evaluate the pricing
for these allocations, taking into strong consideration the 
economic conditions of Rural America providers.  The suggested
"cost" for these allocations will be $1250 USD per year.



      BUY AMERICAN, SUPPORT YOUR LOCAL RURAL AMERICAN ISP.


John Brown
Former ARIN AC



----- End forwarded message -----


From Trevor.Paquette at TeraGo.ca  Tue Oct  7 11:49:20 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Tue, 7 Oct 2003 09:49:20 -0600
Subject: [ppml] OT: Others that said 'It will never happen...'
Message-ID: <016f01c38cea$93350ff0$2a45fea9@teraint.net>

As oft proven time and time again.. never say never... Enjoy :-)


Everything that can be invented has been invented.. -- Charles H. Duell, Commissioner, US Patent Office, 1899

640K ought to be enough for anybody.. -- Bill Gates, Chairman, Microsoft, 1981

The bomb will never go off. I speak as an expert in explosives.. -- Admiral William Leahy, Manhattan Project, 1943

Stocks have reached what looks like a permanently high plateau - Irving Fisher,  Professor of Economics, Yale University, 1929 

Airplanes are interesting toys but of no military value - Marechal Ferdinand Foch, 
Professor of Strategy, Ecole Superieure de Guerre. 

This telephone has too many shortcomings to be seriously considered as a means of communication. The device is inherently of no value to us. -- An internal Western Union memo, 1876 

There is no reason anyone would want a computer in their home. -- Ken Olson, founder, chairman & president of DEC, 1977

A rocket will never be able to leave the earth's atmosphere. --The New York Times, 1936

I have traveled the length and breadth of this country and talked with the best people, and I can assure you that data processing is a fad that won't last out the year. --The editor in charge of business books for Prentice Hall, 1957

There is no likelihood man can ever tap the power of the atom. --Nobel Prize-winning physicist Robert Milliken, 1923

Television won't last because people will soon get tired of staring at a plywood box every night. --Producer Darryl Zanuck, 20th Century Fox, 1946

--

Trevor Paquette
Lead Systems Architect
TeraGo Networks Inc.
Suite 300, 300 Manning Road N.E.
Calgary, Alberta, Canada T2E 8K4
Phone:(403)668-5321 Mobile:(403)703-8738 Fax:(403)668-5344
www.terago.ca




From Trevor.Paquette at TeraGo.ca  Tue Oct  7 11:56:06 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Tue, 7 Oct 2003 09:56:06 -0600
Subject: [ppml] Policy Proposal 2002-3
In-Reply-To: <Pine.GSO.4.44.0310062217460.26039-100000@networking.Stanford.EDU>
Message-ID: <017401c38ceb$857d9930$2a45fea9@teraint.net>

Finally a decent answer to expain historically why boundaries were moved.
THANK YOU!

> -----Original Message-----
> From: Lea Roberts [mailto:lea.roberts at stanford.edu]
> Sent: Tuesday, October 07, 2003 12:31 AM
> To: Trevor Paquette
> Cc: ppml at arin.net
> Subject: RE: [ppml] Policy Proposal 2002-3
> 
> 
> Trevor -
> 
> the basic problem is that old model for everyone to get 
> direct assignments
> from the InterNIC (or now the RIRs :-) just doesn't scale.
> 
> in the early 1990s, it was asserted that IPv4 addresses were being
> consumed too rapidly.  Back then addresses were assigned in "classes". If
> a site needed more than a /24 (Class C) they would get a /16 (Class B) and
> class B assignments were being made at an increasingly rapid rate.  In
> response to this, Classless InterDomain Routing (CIDR) was born and
> addresses could be assigned more efficiently with variable "prefix"
> lengths. (see RFC 1519, September 1993)
> 
> then, as Owen has said, there were problems with the explosion of routing
> table size approaching the limits of the hardware then running in the
> core.  the solution was to encourage hierarchical address assignment, also
> known as provider assigned addresses, so that an ISP could aggregate a
> number of its sites into one advertisement into the global routing table.
> thus CIDR came to the rescure for the routing table problem as well.
> it's taken most of these ten years for the paradigm shift to solidify and
> I would hate to see a rush back to where individual assignments from an
> RIR would be the norm rather than a special case.
> 
> note there is another dichotomy.  when ARIN makes address assignments, it
> cannot guarantee the routability of the addresses.  there are other
> players in the scene, e.g. the network operators.  they can negate the
> effect of a prefix length change by refusing to accept the routes.  an
> unroutable assignment is not worth much!  :-)
> 
> since ARIN was formed, one of the challenges has been to establish
> policies that preserve the stability of the internet while allowing it to
> continue to expand.  the struggle over micro-assignments is ongoing, many
> of us who were around 10 years ago still feel that it is wise to be
> cautious in changing the size of assignments.  there are ongoing studies
> on the next potential for network instability: the convergence time after
> route flaps, which is also related to the routing table size.
> 
> so while router hardware has improved, there may need to be protocol and
> other software improvements in the backbone before advocating the end of
> hierachical address assignments makes sense.  As the "swamp" of original
> address assignments reminds us and as you express as a wise concern, the
> assignment of addresses is almost completely a one way street.  once the
> boundary is moved, we won't be able to undo the assigments should the next
> performance barrier be reached.  thus some of us on the Advisory Council
> are suggesting that these changes should be gradual and their effects
> monitored carefully before moving the boundary again.
> 
> 		there's never a dull moment in networking land,  /Lea
> 
> On Mon, 6 Oct 2003, Trevor Paquette wrote:
> 
> >
> > Folks used to be able to receive direct assignments from 
> ARIN (and other registries) in the past. This ability was 
> revoked for some reason, and it seems that no-one can remember why...
> >
> > I'd hate for us to go back down the same path and encounter 
> the same problems as did our predecessors only to later go 
> 'DOH!.. no wonder they revoked this ability'.
> >
> > Why was this ability revoked and the current policy put in 
> place?? Can anyone explain that?



From Michael.Dillon at radianz.com  Tue Oct  7 12:00:49 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Tue, 7 Oct 2003 17:00:49 +0100
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
Message-ID: <OFE7D98F48.7951EECF-ON80256DB8.005719AD-80256DB8.0057F756@radianz.com>

>The ARIN sub-region known as "Rural America", those
>localities with a population of less than 1 million
>persons here by proposes the following Policy Proposal.

This is an example of a poorly thought out
policy proposal. It doesn't conform to the
simple structure requested by ARIN on the
website and it wasn't submitted to the ARIN
Member Services prior to being announced.
Given that this is being proposed a couple
of weeks before the meeting, I think it should
also have started life in the Policy BOF
that was expressly created to help people
put together better, more coherent policy 
proposals.

>3.  Utilization Reporting and Justification.  All other
>ARIN policies reguarding the reporting of justification information
>for the allocation of IPv4 address space will remain 
>in effect.

Totally unneccesary verbage. A policy proposal
onle ever changes the parts of policy that it changes. 
There is no need to say that the rest of the 
policies will be unchanged.

>4.  IPv6 considerations:  Rural America providers are eager
>to start testing and deploying IPv6 networks.  Rural America
>operators have the ability to deploy IPv6 quicker than larger
>providers.  Therefor, providers that receive IPv4 space
>under this policy shall also be permitted to request and 
>receive a single /48 of IPv6 space.  This will help enable
>rural providers and move them forward with IPv6 technology.
>Further allocations will be handled under current IPv6 policy.

This is a radical change to the IPv6 policy and should
really be discussed on its own. This is the equivalent
of saying that rural ISPs should get a single /32 allocation
of IPv4 addresses which is ludicrous. If there is some
reason why this class of ISP cannot justify an IPv6 /32
then we should work on changing that aspect of the
IPv6 policy.

>5.  Pricing.  The ARIN BOT will review and evaluate the pricing
>for these allocations, taking into strong consideration the 
>economic conditions of Rural America providers.  The suggested
>"cost" for these allocations will be $1250 USD per year.

This item is not a policy change; it is a request
for the BoT to review and act. It doesn't belong 
in a policy proposal and may, indeed, have merit 
on its own as an item of business at an ARIN meeting
outside of the policy process.

--Michael Dillon


 



From jb at jbacher.com  Tue Oct  7 12:12:07 2003
From: jb at jbacher.com (J Bacher)
Date: Tue, 07 Oct 2003 11:12:07 -0500
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <OFE7D98F48.7951EECF-ON80256DB8.005719AD-80256DB8.0057F756@
 radianz.com>
Message-ID: <5.1.0.14.2.20031007111048.025d9ba8@localhost>

At 05:00 PM 10/7/2003 +0100, you wrote:
> >The ARIN sub-region known as "Rural America", those
> >localities with a population of less than 1 million
> >persons here by proposes the following Policy Proposal.
>
>This is an example of a poorly thought out
>policy proposal. It doesn't conform to the

This is an example of determining how many people will accept a 
double-standard when there ought not be.

John's analogy is excellent.



From jlewis at lewis.org  Tue Oct  7 12:15:17 2003
From: jlewis at lewis.org (jlewis at lewis.org)
Date: Tue, 7 Oct 2003 12:15:17 -0400 (EDT)
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <OFE7D98F48.7951EECF-ON80256DB8.005719AD-80256DB8.0057F756@radianz.com>
Message-ID: <Pine.LNX.4.44.0310071210060.8137-100000@redhat1.mmaero.com>

On Tue, 7 Oct 2003 Michael.Dillon at radianz.com wrote:

> >The ARIN sub-region known as "Rural America", those
> >localities with a population of less than 1 million
> >persons here by proposes the following Policy Proposal.
> 
> This is an example of a poorly thought out
> policy proposal. It doesn't conform to the

I assumed this was a joking example of why sub-region special exceptions 
to RIR policies are a bad idea.
 
Was I alone in that assumption?  BTW...this is exactly what I meant when I 
said the future AfriNIC members are not special. 

----------------------------------------------------------------------
 Jon Lewis *jlewis at lewis.org*|  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |  
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From john at chagres.net  Tue Oct  7 13:14:40 2003
From: john at chagres.net (John Brown)
Date: Tue, 7 Oct 2003 11:14:40 -0600
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <Pine.LNX.4.44.0310071210060.8137-100000@redhat1.mmaero.com>; from jlewis@lewis.org on Tue, Oct 07, 2003 at 12:15:17PM -0400
References: <OFE7D98F48.7951EECF-ON80256DB8.005719AD-80256DB8.0057F756@radianz.com> <Pine.LNX.4.44.0310071210060.8137-100000@redhat1.mmaero.com>
Message-ID: <20031007111440.C69167@alderaan.chagres.net>

No Joke,

Deadly serious.

As far as the format of the proposal, much
of the language came directly from the current
AF proposal.  If its not properly formated then
both are guilty of that.

The Rural America ISP's will work to enhance and 
better write a policy to be submitted via the 
proper process.



On Tue, Oct 07, 2003 at 12:15:17PM -0400, jlewis at lewis.org wrote:
> On Tue, 7 Oct 2003 Michael.Dillon at radianz.com wrote:
> 
> > >The ARIN sub-region known as "Rural America", those
> > >localities with a population of less than 1 million
> > >persons here by proposes the following Policy Proposal.
> > 
> > This is an example of a poorly thought out
> > policy proposal. It doesn't conform to the
> 
> I assumed this was a joking example of why sub-region special exceptions 
> to RIR policies are a bad idea.
>  
> Was I alone in that assumption?  BTW...this is exactly what I meant when I 
> said the future AfriNIC members are not special. 
> 
> ----------------------------------------------------------------------
>  Jon Lewis *jlewis at lewis.org*|  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |  
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> 


From john at chagres.net  Tue Oct  7 13:21:48 2003
From: john at chagres.net (John Brown)
Date: Tue, 7 Oct 2003 11:21:48 -0600
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <OFE7D98F48.7951EECF-ON80256DB8.005719AD-80256DB8.0057F756@radianz.com>; from Michael.Dillon@radianz.com on Tue, Oct 07, 2003 at 05:00:49PM +0100
References: <OFE7D98F48.7951EECF-ON80256DB8.005719AD-80256DB8.0057F756@radianz.com>
Message-ID: <20031007112148.F69167@alderaan.chagres.net>

> >3.  Utilization Reporting and Justification.  All other
> >ARIN policies reguarding the reporting of justification information
> >for the allocation of IPv4 address space will remain 
> >in effect.
> 
> Totally unneccesary verbage. A policy proposal
> onle ever changes the parts of policy that it changes. 
> There is no need to say that the rest of the 
> policies will be unchanged.
 
Same language as whats in the current Africa policy...


> >4.  IPv6 considerations:  Rural America providers are eager
> >to start testing and deploying IPv6 networks.  Rural America
> >operators have the ability to deploy IPv6 quicker than larger
> >providers.  Therefor, providers that receive IPv4 space
> >under this policy shall also be permitted to request and 
> >receive a single /48 of IPv6 space.  This will help enable
> >rural providers and move them forward with IPv6 technology.
> >Further allocations will be handled under current IPv6 policy.
> 
> This is a radical change to the IPv6 policy and should
> really be discussed on its own. This is the equivalent
> of saying that rural ISPs should get a single /32 allocation
> of IPv4 addresses which is ludicrous. If there is some
> reason why this class of ISP cannot justify an IPv6 /32
> then we should work on changing that aspect of the
> IPv6 policy.
 
Simple reason.  Rural America Providers can't get ARIN IPv4 
space today, thus they can't get IPv6 either.  Rural America 
providers wish to deploy and start testing IPv6.  Their
upstreams do not provide such address space.  

You can not get IPv6 space from

SprintLink
UUNET
ATT
Level 3
Qwest
Time Warner

Yet many of these providers have space from ARIN.. 
 
> >5.  Pricing.  The ARIN BOT will review and evaluate the pricing
> >for these allocations, taking into strong consideration the 
> >economic conditions of Rural America providers.  The suggested
> >"cost" for these allocations will be $1250 USD per year.
> 
> This item is not a policy change; it is a request
> for the BoT to review and act. It doesn't belong 
> in a policy proposal and may, indeed, have merit 
> on its own as an item of business at an ARIN meeting
> outside of the policy process.

Rural providers are damaged because of the current Pricing
Policies that ARIN has.  They are underrepresented.


> 
> --Michael Dillon
> 
> 
>  
> 


From owen at delong.com  Tue Oct  7 13:43:21 2003
From: owen at delong.com (Owen DeLong)
Date: Tue, 07 Oct 2003 10:43:21 -0700
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <OFE7D98F48.7951EECF-ON80256DB8.005719AD-80256DB8.0057F756@radianz.com>
References: <OFE7D98F48.7951EECF-ON80256DB8.005719AD-80256DB8.0057F756@radia
 nz.com>
Message-ID: <2147483647.1065523400@imac-en0.delong.sj.ca.us>

Michael,
	I think you missed, entirely, the point of John's post.  I doubt
that he is actually trying to put this forward as a policy (although, if
2003-15 passes, I'd support it with some cleanup work).  I think he was
trying to clarify his opposition to sub-regional policies and point out
that AfriNIC is not a one-time special case.

Owen


--On Tuesday, October 7, 2003 5:00 PM +0100 Michael.Dillon at radianz.com 
wrote:

>> The ARIN sub-region known as "Rural America", those
>> localities with a population of less than 1 million
>> persons here by proposes the following Policy Proposal.
>
> This is an example of a poorly thought out
> policy proposal. It doesn't conform to the
> simple structure requested by ARIN on the
> website and it wasn't submitted to the ARIN
> Member Services prior to being announced.
> Given that this is being proposed a couple
> of weeks before the meeting, I think it should
> also have started life in the Policy BOF
> that was expressly created to help people
> put together better, more coherent policy
> proposals.
>
>> 3.  Utilization Reporting and Justification.  All other
>> ARIN policies reguarding the reporting of justification information
>> for the allocation of IPv4 address space will remain
>> in effect.
>
> Totally unneccesary verbage. A policy proposal
> onle ever changes the parts of policy that it changes.
> There is no need to say that the rest of the
> policies will be unchanged.
>
>> 4.  IPv6 considerations:  Rural America providers are eager
>> to start testing and deploying IPv6 networks.  Rural America
>> operators have the ability to deploy IPv6 quicker than larger
>> providers.  Therefor, providers that receive IPv4 space
>> under this policy shall also be permitted to request and
>> receive a single /48 of IPv6 space.  This will help enable
>> rural providers and move them forward with IPv6 technology.
>> Further allocations will be handled under current IPv6 policy.
>
> This is a radical change to the IPv6 policy and should
> really be discussed on its own. This is the equivalent
> of saying that rural ISPs should get a single /32 allocation
> of IPv4 addresses which is ludicrous. If there is some
> reason why this class of ISP cannot justify an IPv6 /32
> then we should work on changing that aspect of the
> IPv6 policy.
>
>> 5.  Pricing.  The ARIN BOT will review and evaluate the pricing
>> for these allocations, taking into strong consideration the
>> economic conditions of Rural America providers.  The suggested
>> "cost" for these allocations will be $1250 USD per year.
>
> This item is not a policy change; it is a request
> for the BoT to review and act. It doesn't belong
> in a policy proposal and may, indeed, have merit
> on its own as an item of business at an ARIN meeting
> outside of the policy process.
>
> --Michael Dillon
>
>
>
>




From john at chagres.net  Tue Oct  7 14:02:46 2003
From: john at chagres.net (John Brown)
Date: Tue, 7 Oct 2003 12:02:46 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <001601c38c6f$b23370c0$1a8888c0@arin.net>; from plzak@arin.net on Mon, Oct 06, 2003 at 09:09:42PM -0400
References: <06cb01c38c63$eba00690$2a45fea9@teraint.net> <001601c38c6f$b23370c0$1a8888c0@arin.net>
Message-ID: <20031007120246.A73515@alderaan.chagres.net>

Africa is a continent.

why are there two RIR's serving that single continent then?

it would seem by your definition this is already broken...


On Mon, Oct 06, 2003 at 09:09:42PM -0400, Ray Plzak wrote:
> As a point of reference:  An RIR must represent a region that is
> continental in scope.  
> 
> Ray
> 
> > -----Original Message-----
> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> > Behalf Of Trevor Paquette
> > Sent: Monday, October 06, 2003 7:45 PM
> > To: 'Bill Woodcock'
> > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > 
> > 
> > Appreciate the humor and the shot at me, but I did not 
> > necessarily mean the US or Canada.. I meant parts there of..
> > 
> > Who's to say that some new 'country' won't want to be 
> > considered to have their own RIR?
> > 
> > 'Self-Government' as someone else put it...
> > 
> > 
> > > -----Original Message-----
> > > From: Bill Woodcock [mailto:woody at pch.net]
> > > Sent: Monday, October 06, 2003 4:51 PM
> > > To: Trevor Paquette
> > > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > > 
> > > 
> > >       On Mon, 6 Oct 2003, Trevor Paquette wrote:
> > >     > Don't assume this whole Africa thing will never happen again..
> > >     > You'd best err on the side of 'when' it happens again.. 
> > > and 'when'
> > >     > it does, look for that new country to want their own 
> > > policies etc..
> > >     > For the record, as a member of ARIN in good standing, I 
> > > cannot vote
> > >     > in favor of 2003-15.
> > > 
> > > For the record, do you think that Canada will secede from 
> > > North America,
> > > or the U.S. will?
> > > 
> > >                                 -Bill
> > > 
> > > 
> > 
> 


From plzak at arin.net  Tue Oct  7 14:07:34 2003
From: plzak at arin.net (Raymond Plzak)
Date: Tue, 7 Oct 2003 14:07:34 -0400 (EDT)
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <20031007120246.A73515@alderaan.chagres.net>
References: <06cb01c38c63$eba00690$2a45fea9@teraint.net>
 <001601c38c6f$b23370c0$1a8888c0@arin.net> <20031007120246.A73515@alderaan.chagres.net>
Message-ID: <Pine.GSO.4.51.0310071405460.6346@ops.arin.net>

John,

Africa is being served by 3 RIRs.  It is not broken.  It is an emerging
region.  Up until Oct 2002 ARIN served 2 continents and a portion of a
third.

Ray

On Tue, 7 Oct 2003, John Brown wrote:

> Date: Tue, 7 Oct 2003 12:02:46 -0600
> From: John Brown <john at chagres.net>
> To: Ray Plzak <plzak at arin.net>
> Cc: 'Trevor Paquette' <Trevor.Paquette at TeraGo.ca>,
>      'Bill Woodcock' <woody at pch.net>, Michael.Dillon at radianz.com,
>      ppml at arin.net
> Subject: Re: [ppml] Afrinic and so-called sub-regional policies
>
> Africa is a continent.
>
> why are there two RIR's serving that single continent then?
>
> it would seem by your definition this is already broken...
>
>
> On Mon, Oct 06, 2003 at 09:09:42PM -0400, Ray Plzak wrote:
> > As a point of reference:  An RIR must represent a region that is
> > continental in scope.
> >
> > Ray
> >
> > > -----Original Message-----
> > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On
> > > Behalf Of Trevor Paquette
> > > Sent: Monday, October 06, 2003 7:45 PM
> > > To: 'Bill Woodcock'
> > > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > >
> > >
> > > Appreciate the humor and the shot at me, but I did not
> > > necessarily mean the US or Canada.. I meant parts there of..
> > >
> > > Who's to say that some new 'country' won't want to be
> > > considered to have their own RIR?
> > >
> > > 'Self-Government' as someone else put it...
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bill Woodcock [mailto:woody at pch.net]
> > > > Sent: Monday, October 06, 2003 4:51 PM
> > > > To: Trevor Paquette
> > > > Cc: Michael.Dillon at radianz.com; ppml at arin.net
> > > > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> > > >
> > > >
> > > >       On Mon, 6 Oct 2003, Trevor Paquette wrote:
> > > >     > Don't assume this whole Africa thing will never happen again..
> > > >     > You'd best err on the side of 'when' it happens again..
> > > > and 'when'
> > > >     > it does, look for that new country to want their own
> > > > policies etc..
> > > >     > For the record, as a member of ARIN in good standing, I
> > > > cannot vote
> > > >     > in favor of 2003-15.
> > > >
> > > > For the record, do you think that Canada will secede from
> > > > North America,
> > > > or the U.S. will?
> > > >
> > > >                                 -Bill
> > > >
> > > >
> > >
> >
>


From antonio at nambu.uem.mz  Tue Oct  7 14:15:15 2003
From: antonio at nambu.uem.mz (antonio at nambu.uem.mz)
Date: Tue, 7 Oct 2003 20:15:15 +0200
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <016501c38ce6$5baff210$2a45fea9@teraint.net>
References: <Pine.GSO.4.44.0310061929420.19925-100000@paixhost.pch.net>
Message-ID: <200310071819.h97IHx93015874@oceano.uem.mz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>       On Mon, 6 Oct 2003, Trevor Paquette wrote:

"Don't assume that this is a 'one time deal". When you set policy, you
set precident. As mentioned in a previous email of mine, policy set by
and for ARIN should apply to ALL of ARIN, not just a sub-region.

If and when AFRINIC gets going and can actually set their OWN
policies, then they can do what they want for their region(s). Until
then and as long as they are part of ARIN, they must abide by the
guidelines that are setout for all of ARIN.

If they want to relax their requirements for IP space once they become
their own RIR, then they are free to do so; in fact I encourage it as
there seems to be a demand from their own special needs.

This is my point. I hope that makes it clear."

How does this differ from what is being asked???? The same 
supposed sub-region will become Afrinic, so what's the problem here?
The only diff is that the African ISPs will be moving forward earlier 
than wait until Afrinic takes form.



-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5 -- QDPGP 2.12 
Comment: http://community.wow.net/grt/qdpgp.html

iQA/AwUBP4LmlCN9iWWR27GKEQJ5nQCgt4dCpAXDlQnAKsCeqD21IsXHE+8AoPx4
knhTjNjIDI7gxK30G4InqWrt
=/f62
-----END PGP SIGNATURE-----
Antonio Godinho
B.Sc., 
MCP, MCP+Internet, MCSE (Microsoft Certified Systems Engineer)
CCNA (Cisco Certified Network Associate)
CCNP (Cisco Certified Network Professional)
Tel. +258-1-490860
Cell +258-82-300392



From antonio at nambu.uem.mz  Tue Oct  7 14:18:04 2003
From: antonio at nambu.uem.mz (antonio at nambu.uem.mz)
Date: Tue, 7 Oct 2003 20:18:04 +0200
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <016c01c38ce7$e9a7d410$2a45fea9@teraint.net>
References: <200310071159.14325.gregm@datapro.co.za>
Message-ID: <200310071821.h97IKc8v015929@oceano.uem.mz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You sound like a dictator.


> However, until AFRINIC becomes a reality and (this is the keyword here
> 'AND') they can set their own policies and guidelines, they must live
> within the policies setout for all of ARIN.
> 


> 
> > -----Original Message-----
> > From: Gregory Massel [mailto:gregm at datapro.co.za]
> > Sent: Tuesday, October 07, 2003 3:59 AM
> > To: Trevor Paquette
> > Cc: ppml at arin.net
> > Subject: Re: [ppml] Afrinic and so-called sub-regional policies
> > 
> > 
> > > Don't assume this whole Africa thing will never happen again..
> > > You'd best err on the side of 'when' it happens again.. and 'when'
> > > it does, look for that new country to want their own policies
> > > etc.. Wait till Russia wants thier own RIR.. and all of the other
> > > new contries that were created by the breakup of the USSR.
> > 
> > I didn't know whether to burst out laughing or in tears when I read
> > this.
> > 
> > The last time I checked, 'Africa' was a *CONTINENT*, comprising 53
> > countries 20% of the earth's land, and approximately 778 million
> > people.
> > 
> > Its population is approximately 1.61 times the population of the
> > North American continent and its size approximately 1.23 times the
> > size of the North American continent.
> > 
> > I cannot confirm the exact validity of this data, but the source
> > I've obtained it from is http://www.worldatlas.com/ and I have no
> > reason to disbelieve it.
> > 
> > I hope that puts your concerns in perspective...
> > 
> > --Greg
> > 
> 



-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5 -- QDPGP 2.12 
Comment: http://community.wow.net/grt/qdpgp.html

iQA/AwUBP4LnPSN9iWWR27GKEQKFrACg2I+ClzkRdmTtTA8qRY7zH9tUrTIAoOvA
o8eH2iZw1pA9BAh8kGOz1qiL
=Y8t8
-----END PGP SIGNATURE-----
Antonio Godinho
B.Sc., 
MCP, MCP+Internet, MCSE (Microsoft Certified Systems Engineer)
CCNA (Cisco Certified Network Associate)
CCNP (Cisco Certified Network Professional)
Tel. +258-1-490860
Cell +258-82-300392



From Trevor.Paquette at TeraGo.ca  Tue Oct  7 14:38:58 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Tue, 7 Oct 2003 12:38:58 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <200310071819.h97IHx90015874@oceano.uem.mz>
Message-ID: <05d401c38d02$45f96890$2a45fea9@teraint.net>

You obviously missed the following keyphrases:

"policy set by and for ARIN should apply to ALL of ARIN, not just a sub-region."

and

"If and when AFRINIC gets going and can actually set their OWN policies, then they can do what they want for their region(s)."

What is being asked is to make a special policy based on an 'exception'.. This is not in the best interest for ALL of ARIN. Again, when AFRINIC can make and enforce their own policies, then by all means bring up 2003-15 to them. In the mean time, as long as 2003-15 is a region specific policy and does not benefit ALL of ARIN, I cannot support it.

> -----Original Message-----
> From: antonio at nambu.uem.mz [mailto:antonio at nambu.uem.mz]
> Sent: Tuesday, October 07, 2003 12:15 PM
> To: Trevor Paquette
> Cc: 'Ray Plzak'; Michael.Dillon at radianz.com; ppml at arin.net
> Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> >       On Mon, 6 Oct 2003, Trevor Paquette wrote:
> 
> "Don't assume that this is a 'one time deal". When you set policy, you
> set precident. As mentioned in a previous email of mine, policy set by
> and for ARIN should apply to ALL of ARIN, not just a sub-region.
> 
> If and when AFRINIC gets going and can actually set their OWN
> policies, then they can do what they want for their region(s). Until
> then and as long as they are part of ARIN, they must abide by the
> guidelines that are setout for all of ARIN.
> 
> If they want to relax their requirements for IP space once they become
> their own RIR, then they are free to do so; in fact I encourage it as
> there seems to be a demand from their own special needs.
> 
> This is my point. I hope that makes it clear."
> 
> How does this differ from what is being asked???? The same 
> supposed sub-region will become Afrinic, so what's the problem here?
> The only diff is that the African ISPs will be moving forward earlier 
> than wait until Afrinic takes form.
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 5.5.5 -- QDPGP 2.12 
> Comment: http://community.wow.net/grt/qdpgp.html
> 
> iQA/AwUBP4LmkCN9iWWR27GKEQLmFQCg51Ray629CD0A4tFsPWWzbtHRi14AoLoq
> bRpm7NFJ2bEKRZ5k0sMSEwPb
> =He9w
> -----END PGP SIGNATURE-----
> Antonio Godinho
> B.Sc., 
> MCP, MCP+Internet, MCSE (Microsoft Certified Systems Engineer)
> CCNA (Cisco Certified Network Associate)
> CCNP (Cisco Certified Network Professional)
> Tel. +258-1-490860
> Cell +258-82-300392
> 



From tme at multicasttech.com  Tue Oct  7 14:44:42 2003
From: tme at multicasttech.com (Marshall Eubanks)
Date: Tue, 07 Oct 2003 14:44:42 -0400
Subject: [ppml] Policy Proposal 2002-3
In-Reply-To: <017401c38ceb$857d9930$2a45fea9@teraint.net>
Message-ID: <web-1784985@multicasttech.com>

On Tue, 7 Oct 2003 09:56:06 -0600
 "Trevor Paquette" <Trevor.Paquette at TeraGo.ca> wrote:
> Finally a decent answer to expain historically why boundaries were moved.
> THANK YOU!
> 

Hello;

The original (and still) purpose of 2002-3 was to rectify the situation faced
by small multi-homers, who get an ASN but no space directly assigned to them.
While it is true that the ranks of small multi-homers is growing, they
still remain a small portion of the total BGP table. By virtue of being
multi-homed, they have an assignment from one or more of their providers, and
if they are properly routed, then this assignment cannot be aggregated by
at least part of the net (if I multi-home to providers A and B, and have a /24
from provider A, then providers who see my A /24 addresses through provider B
cannot aggregate that /24).

So, doing micro-assignments to small multi-homers will not break CIDR and 
will not increase the size of the routing tables, but will remove the problems
found by 
those who multi-home without direct address assignments. I have found that
providers will route small assignments from ARIN as a matter of course, but to
get my /24 from UUNet routed properly by Verio took some patient pleading and
inside knowledge.

Regards
Marshall Eubanks


> > -----Original Message-----
> > From: Lea Roberts [mailto:lea.roberts at stanford.edu]
> > Sent: Tuesday, October 07, 2003 12:31 AM
> > To: Trevor Paquette
> > Cc: ppml at arin.net
> > Subject: RE: [ppml] Policy Proposal 2002-3
> > 
> > 
> > Trevor -
> > 
> > the basic problem is that old model for everyone to get 
> > direct assignments
> > from the InterNIC (or now the RIRs :-) just doesn't scale.
> > 
> > in the early 1990s, it was asserted that IPv4 addresses were being
> > consumed too rapidly.  Back then addresses were assigned in "classes". If
> > a site needed more than a /24 (Class C) they would get a /16 (Class B) and
> > class B assignments were being made at an increasingly rapid rate.  In
> > response to this, Classless InterDomain Routing (CIDR) was born and
> > addresses could be assigned more efficiently with variable "prefix"
> > lengths. (see RFC 1519, September 1993)
> > 
> > then, as Owen has said, there were problems with the explosion of routing
> > table size approaching the limits of the hardware then running in the
> > core.  the solution was to encourage hierarchical address assignment, also
> > known as provider assigned addresses, so that an ISP could aggregate a
> > number of its sites into one advertisement into the global routing table.
> > thus CIDR came to the rescure for the routing table problem as well.
> > it's taken most of these ten years for the paradigm shift to solidify and
> > I would hate to see a rush back to where individual assignments from an
> > RIR would be the norm rather than a special case.
> > 
> > note there is another dichotomy.  when ARIN makes address assignments, it
> > cannot guarantee the routability of the addresses.  there are other
> > players in the scene, e.g. the network operators.  they can negate the
> > effect of a prefix length change by refusing to accept the routes.  an
> > unroutable assignment is not worth much!  :-)
> > 
> > since ARIN was formed, one of the challenges has been to establish
> > policies that preserve the stability of the internet while allowing it to
> > continue to expand.  the struggle over micro-assignments is ongoing, many
> > of us who were around 10 years ago still feel that it is wise to be
> > cautious in changing the size of assignments.  there are ongoing studies
> > on the next potential for network instability: the convergence time after
> > route flaps, which is also related to the routing table size.
> > 
> > so while router hardware has improved, there may need to be protocol and
> > other software improvements in the backbone before advocating the end of
> > hierachical address assignments makes sense.  As the "swamp" of original
> > address assignments reminds us and as you express as a wise concern, the
> > assignment of addresses is almost completely a one way street.  once the
> > boundary is moved, we won't be able to undo the assigments should the next
> > performance barrier be reached.  thus some of us on the Advisory Council
> > are suggesting that these changes should be gradual and their effects
> > monitored carefully before moving the boundary again.
> > 
> > 		there's never a dull moment in networking land,  /Lea
> > 
> > On Mon, 6 Oct 2003, Trevor Paquette wrote:
> > 
> > >
> > > Folks used to be able to receive direct assignments from 
> > ARIN (and other registries) in the past. This ability was 
> > revoked for some reason, and it seems that no-one can remember why...
> > >
> > > I'd hate for us to go back down the same path and encounter 
> > the same problems as did our predecessors only to later go 
> > 'DOH!.. no wonder they revoked this ability'.
> > >
> > > Why was this ability revoked and the current policy put in 
> > place?? Can anyone explain that?
> 



From owen at delong.com  Tue Oct  7 14:49:02 2003
From: owen at delong.com (Owen DeLong)
Date: Tue, 07 Oct 2003 11:49:02 -0700
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <Pine.GSO.4.51.0310071405460.6346@ops.arin.net>
References: <06cb01c38c63$eba00690$2a45fea9@teraint.net>
 <001601c38c6f$b23370c0$1a8888c0@arin.net>
 <20031007120246.A73515@alderaan.chagres.net>
 <Pine.GSO.4.51.0310071405460.6346@ops.arin.net>
Message-ID: <2147483647.1065527342@imac-en0.delong.sj.ca.us>

And now, ARIN serves parts of 2 continents and, soon, if AfriNIC comes
to fruition, just part of 1.

Owen


--On Tuesday, October 7, 2003 2:07 PM -0400 Raymond Plzak <plzak at arin.net> 
wrote:

> John,
>
> Africa is being served by 3 RIRs.  It is not broken.  It is an emerging
> region.  Up until Oct 2002 ARIN served 2 continents and a portion of a
> third.
>
> Ray
>
> On Tue, 7 Oct 2003, John Brown wrote:
>
>> Date: Tue, 7 Oct 2003 12:02:46 -0600
>> From: John Brown <john at chagres.net>
>> To: Ray Plzak <plzak at arin.net>
>> Cc: 'Trevor Paquette' <Trevor.Paquette at TeraGo.ca>,
>>      'Bill Woodcock' <woody at pch.net>, Michael.Dillon at radianz.com,
>>      ppml at arin.net
>> Subject: Re: [ppml] Afrinic and so-called sub-regional policies
>>
>> Africa is a continent.
>>
>> why are there two RIR's serving that single continent then?
>>
>> it would seem by your definition this is already broken...
>>
>>
>> On Mon, Oct 06, 2003 at 09:09:42PM -0400, Ray Plzak wrote:
>> > As a point of reference:  An RIR must represent a region that is
>> > continental in scope.
>> >
>> > Ray
>> >
>> > > -----Original Message-----
>> > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On
>> > > Behalf Of Trevor Paquette
>> > > Sent: Monday, October 06, 2003 7:45 PM
>> > > To: 'Bill Woodcock'
>> > > Cc: Michael.Dillon at radianz.com; ppml at arin.net
>> > > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
>> > >
>> > >
>> > > Appreciate the humor and the shot at me, but I did not
>> > > necessarily mean the US or Canada.. I meant parts there of..
>> > >
>> > > Who's to say that some new 'country' won't want to be
>> > > considered to have their own RIR?
>> > >
>> > > 'Self-Government' as someone else put it...
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: Bill Woodcock [mailto:woody at pch.net]
>> > > > Sent: Monday, October 06, 2003 4:51 PM
>> > > > To: Trevor Paquette
>> > > > Cc: Michael.Dillon at radianz.com; ppml at arin.net
>> > > > Subject: RE: [ppml] Afrinic and so-called sub-regional policies
>> > > >
>> > > >
>> > > >       On Mon, 6 Oct 2003, Trevor Paquette wrote:
>> > > >     > Don't assume this whole Africa thing will never happen
>> > > >     > again.. You'd best err on the side of 'when' it happens
>> > > >     > again..
>> > > > and 'when'
>> > > >     > it does, look for that new country to want their own
>> > > > policies etc..
>> > > >     > For the record, as a member of ARIN in good standing, I
>> > > > cannot vote
>> > > >     > in favor of 2003-15.
>> > > >
>> > > > For the record, do you think that Canada will secede from
>> > > > North America,
>> > > > or the U.S. will?
>> > > >
>> > > >                                 -Bill
>> > > >
>> > > >
>> > >
>> >
>>




From owen at delong.com  Tue Oct  7 14:56:28 2003
From: owen at delong.com (Owen DeLong)
Date: Tue, 07 Oct 2003 11:56:28 -0700
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <200310071819.h97IHx93015874@oceano.uem.mz>
References: <Pine.GSO.4.44.0310061929420.19925-100000@paixhost.pch.net>
 <200310071819.h97IHx93015874@oceano.uem.mz>
Message-ID: <2147483647.1065527788@imac-en0.delong.sj.ca.us>



--On Tuesday, October 7, 2003 8:15 PM +0200 antonio at nambu.uem.mz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>>       On Mon, 6 Oct 2003, Trevor Paquette wrote:
>
> "Don't assume that this is a 'one time deal". When you set policy, you
> set precident. As mentioned in a previous email of mine, policy set by
> and for ARIN should apply to ALL of ARIN, not just a sub-region.
>
> If and when AFRINIC gets going and can actually set their OWN
> policies, then they can do what they want for their region(s). Until
> then and as long as they are part of ARIN, they must abide by the
> guidelines that are setout for all of ARIN.
>
> If they want to relax their requirements for IP space once they become
> their own RIR, then they are free to do so; in fact I encourage it as
> there seems to be a demand from their own special needs.
>
> This is my point. I hope that makes it clear."
>
> How does this differ from what is being asked???? The same
> supposed sub-region will become Afrinic, so what's the problem here?
> The only diff is that the African ISPs will be moving forward earlier
> than wait until Afrinic takes form.
>

That is NOT ture.  What is currently the Africa portion of ARIN is only
part of what will become AfriNIC.  Part of what will become AfriNIC is
currently served by RIPE.  Part is currently served by APNIC.  There
is no one-to-one correlation here, but, overalapping different fractions.
It's downright messy.

Owen

>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 5.5.5 -- QDPGP 2.12
> Comment: http://community.wow.net/grt/qdpgp.html
>
> iQA/AwUBP4LmlCN9iWWR27GKEQJ5nQCgt4dCpAXDlQnAKsCeqD21IsXHE+8AoPx4
> knhTjNjIDI7gxK30G4InqWrt
> =/f62
> -----END PGP SIGNATURE-----
> Antonio Godinho
> B.Sc.,
> MCP, MCP+Internet, MCSE (Microsoft Certified Systems Engineer)
> CCNA (Cisco Certified Network Associate)
> CCNP (Cisco Certified Network Professional)
> Tel. +258-1-490860
> Cell +258-82-300392
>




From arin-member at quadrix.com  Tue Oct  7 22:22:34 2003
From: arin-member at quadrix.com (Bill Van Emburg)
Date: Tue, 07 Oct 2003 22:22:34 -0400
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <5.1.0.14.2.20031007111048.025d9ba8@localhost>
References: <5.1.0.14.2.20031007111048.025d9ba8@localhost>
Message-ID: <3F8374EA.10706@quadrix.com>

J Bacher wrote:

> At 05:00 PM 10/7/2003 +0100, you wrote:
> 
>> >The ARIN sub-region known as "Rural America", those
>> >localities with a population of less than 1 million
>> >persons here by proposes the following Policy Proposal.
>>
>> This is an example of a poorly thought out
>> policy proposal. It doesn't conform to the
> 
> This is an example of determining how many people will accept a 
> double-standard when there ought not be.
> 
> John's analogy is excellent.

Absolutely not!  As someone else on this list mentioned, we're talking 
about a different policy for a different CONTINENT, and one which is 
made up of mostly "3rd-world" countries.  Rural America is much more 
similar to the rest of the U.S., and does not, in any case, represent a 
easily separable geography.

...and don't try to say that 2003-15 doesn't represent a continent.  It 
represents the portion of that different continent that ARIN currently 
has control over.  (...and only has that control for historical reasons, 
a problem that AfriNIC is trying to fix!)

2003-15 and this "Rural America" proposal are very different things, and 
there is no reason to consider them the same.
-- 
				     -- Bill Van Emburg
					Quadrix Solutions, Inc.




From john at chagres.net  Tue Oct  7 23:03:07 2003
From: john at chagres.net (John Brown)
Date: Tue, 7 Oct 2003 21:03:07 -0600
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <3F8374EA.10706@quadrix.com>; from arin-member@quadrix.com on Tue, Oct 07, 2003 at 10:22:34PM -0400
References: <5.1.0.14.2.20031007111048.025d9ba8@localhost> <3F8374EA.10706@quadrix.com>
Message-ID: <20031007210307.A80066@alderaan.chagres.net>

Hi Bill,

Interesting comments.

As a person that has lived and built companies, including
2 ISP's and helped dozens more, in rural america, I'd have
to disagree....

Rural America is *NOT*  New Jersey.  Rural America is
thousands of square miles of open land.  Its miles between
people or homes.  Its where $20 a month is actual real
money......

Lets see...

The largest ISP on the eastern part of New Mexico is tied
to Sprint for a /22 worth of IP.  If he leaves Sprint, he
has to renumber *Again*.

Estimated at costing over $10,000 in labor, loss of 
business, extended support issues, and business disruption.

The largest ISP in the Tularosa Basin, New Mexico is also
using /22 worth of IP space.   Again tied to their upstreams
for that space.  If they change or want to leave, they must
burden the cost of renumbering.  


Both can't get ARIN space.


Why, because ARIN does not have a policy to support them....


I can list 60+ more thru out the western US.

If you depend on Qwest to get phone lines, they can take
up to 1.5 years to install.  Almost as long as it takes to
get a land line in Rio, .BR

Yup, it can take over a year to get a phone line in the
good ol'e United States of America.....

And here we thought we had competition, free market and
super technology leadership.  

Ya know a First World Nation....



On Tue, Oct 07, 2003 at 10:22:34PM -0400, Bill Van Emburg wrote:
> J Bacher wrote:
> 
> > At 05:00 PM 10/7/2003 +0100, you wrote:
> > 
> >> >The ARIN sub-region known as "Rural America", those
> >> >localities with a population of less than 1 million
> >> >persons here by proposes the following Policy Proposal.
> >>
> >> This is an example of a poorly thought out
> >> policy proposal. It doesn't conform to the
> > 
> > This is an example of determining how many people will accept a 
> > double-standard when there ought not be.
> > 
> > John's analogy is excellent.
> 
> Absolutely not!  As someone else on this list mentioned, we're talking 
> about a different policy for a different CONTINENT, and one which is 
> made up of mostly "3rd-world" countries.  Rural America is much more 
> similar to the rest of the U.S., and does not, in any case, represent a 
> easily separable geography.
> 
> ...and don't try to say that 2003-15 doesn't represent a continent.  It 
> represents the portion of that different continent that ARIN currently 
> has control over.  (...and only has that control for historical reasons, 
> a problem that AfriNIC is trying to fix!)
 
Great, when AfriNIC actually stands up and becomes real like LacNic
then they can go set policy for their membership.  Until then they 
are under ARIN and ARIN should not create special interest policy.

The same technical reasons that have been spewed before on why ARIN
shouldn't dip below a /20 apply (imho) to Africa. 

Land rush for IP space will use up route table memory

Land rush for ASN's will exhaust AS resources 

Providers will filter and thus its not in the interest of the 
community to reduce the allocation.

> 
> 2003-15 and this "Rural America" proposal are very different things, and 
> there is no reason to consider them the same.
 
There should be uniformed policy from ARIN for the ARIN region.

> -- 
> 				     -- Bill Van Emburg


From woody at pch.net  Tue Oct  7 23:02:37 2003
From: woody at pch.net (Bill Woodcock)
Date: Tue, 7 Oct 2003 20:02:37 -0700 (PDT)
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <00ac01c38ce5$045a6be0$2a45fea9@teraint.net>
Message-ID: <Pine.GSO.4.44.0310072000460.9924-100000@paixhost.pch.net>

      On Tue, 7 Oct 2003, Trevor Paquette wrote:
    > What would stop California or Saskatchewan to say 'We need a
    > special policy that applies just to us'.

Nothing at all.  Which is exactly how the policy-development process is
supposed to work.  If California or Saskatchewan folks believed they had
some specific policy need, _the whole point of the policy process_ is to
ensure that they get a venue in which to have it heard and considered _on
its own merits_ and passed or not, as its merits may justify.

                                -Bill




From woody at pch.net  Wed Oct  8 03:34:10 2003
From: woody at pch.net (Bill Woodcock)
Date: Wed, 8 Oct 2003 00:34:10 -0700 (PDT)
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <06b101c38c5c$12b4bb20$2a45fea9@teraint.net>
Message-ID: <Pine.GSO.4.44.0310080030550.9924-100000@paixhost.pch.net>

      On Mon, 6 Oct 2003, Trevor Paquette wrote:
    > Don't assume this whole Africa thing will never happen again..
    > You'd best err on the side of 'when' it happens again..
    > Wait till Russia wants thier own RIR..

If it's a country, it's an NIR, not an RIR.  Please, please, please, try
to inform yourself at least a little bit about the status quo and the
process we're involved in before ranting about Quebequois separatism or
whatever, and trying to equate Africa and Quebec.  Africa is a continent.
A continent full of people who have vastly different problems than you do.

                                -Bill





From Michael.Dillon at radianz.com  Wed Oct  8 05:39:16 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 8 Oct 2003 10:39:16 +0100
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
Message-ID: <OF0D08F308.7CC8AA13-ON80256DB9.00347C70-80256DB9.0035089F@radianz.com>

At 05:00 PM 10/7/2003 +0100, you wrote:
>> >The ARIN sub-region known as "Rural America", those
>> >localities with a population of less than 1 million
>> >persons here by proposes the following Policy Proposal.
>>
>>This is an example of a poorly thought out
>>policy proposal. It doesn't conform to the

>This is an example of determining how many people will accept a 
>double-standard when there ought not be.

>John's analogy is excellent.

ARIN has always had policies that apply
to only a subset of the organizations in the
ARIN region. For instance, some policies
are directed at ISPs and others at end users.
Some are directed at small ISPs just beginning
to multihome, others to larger ISPs that
are expanding their use of IP addresses and
yet others to organizations who are
beginning to use IPv6.

When ARIN first shifted the minimum allocation
size, it was to make it easier for the large
number of smaller independent ISPs to get
a portable block of addresses to enable them to
multihome. That policy was targetted at a specific
subset of ISPs and had no impact whatsoever on
the larger ISPs of the day like UUNET.

There is a good argument to be made for
making it easier for low population areas
to get portable address space, but this is
not the time or the place. I'd really like
to see this sort of thing discussed at the
policy BOF before it gets to the proposal
stage.

--Michael Dillon





From bicknell at ufp.org  Wed Oct  8 10:41:04 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 8 Oct 2003 10:41:04 -0400
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <Pine.GSO.4.44.0310080030550.9924-100000@paixhost.pch.net>
References: <06b101c38c5c$12b4bb20$2a45fea9@teraint.net> <Pine.GSO.4.44.0310080030550.9924-100000@paixhost.pch.net>
Message-ID: <20031008144104.GB87018@ussenterprise.ufp.org>


There seems to be some disagreement in the documentation.

At http://www.iana.org/ipaddress/ip-addresses.htm, we find that:

   ] Both IPv4 and IPv6 addresses are assigned in a delegated manner. Users
   ] are assigned IP addresses by Internet service providers (ISPs). ISPs
   ] obtain allocations of IP addresses from a local Internet registry (LIR)
   ] or national Internet registry (NIR), or from their appropriate Regional
   ] Internet Registry (RIR):

   From this it's already a bit unclear if the picture is:

           RIR                 RIR
          /   \        or     /   \
        NIR   LIR           NIR   NIR
                           /   \  
                         LIR   LIR

However, if we dig deeper, at http://www.iana.org/icp/icp-2.htm,
we find that NIR is never mentioned in this document.  Humm, they
seem to have disappeared.  But, we do have a geographic requirement
for RIR's:

   ] 1) The region of coverage should meet the scale to be defined by ICANN,
   ] given the need to avoid global address fragmentation
   ] 
   ] The proposed RIR must operate internationally in a large geographical
   ] region of approximately continental size.
   ] 
   ] Each region should be served by a single RIR, established under one
   ] management and in one location. The establishment of multiple RIRs in
   ] one region is likely to lead to:
   ] 
   ] fragmentation of address space allocated to the region; 
   ] difficulty for co-ordination and co-operation between the RIRs; 
   ] confusion for the community within the region. 
   ] 
   ] The internal administrative or membership structure of an RIR must also
   ] not be such as to cause any of these effects.

So, the standard here is "large geographical region" of "approximately
continental size".  Not a must be a continent, just a large size.

However, this document also mentions ICANN.  However when you go
to ICANN, all I can find is http://www.icann.org/icp/icp-2.htm,
which seems to be a copy of the document on the IANA site.

These two documents also have this interesting wording:

   ] IP address space is currently distributed by the three existing RIRs
   ] that receive address space from IANA and allocate it further to Local
   ] Internet Registries (LIRs) or Internet Service Providers (ISPs). These
   ] LIRs*, in turn, assign addresses to end-users for use in operational
   ] networks.

   ] (*) For the purposes of this document, any reference to LIRs can be
   ] taken to mean LIRs and ISPs.

I'm going to assume from the footnote that LIR != ISP (eg, they are
not synonyms, merely treated equally).

If we go back further in history, there is also
http://www.faqs.org/rfcs/rfc2050.html.  I'll not quote as I believe
it's been largely superseded by the other documents mentioned,
however of interest is Section 1, which has RIR's and LIR's (no
NIR's).  This reading also has some other very interesting (historical)
requirements in it.

Also of interest, particularly when looking at AfriNIC, is
http://www.iana.org/reports/lacnic-report-07nov02.htm, the report
on LACNIC's acceptance.  Of note in this document:

   ] 6) Adherence to global policies regarding address space conservation,
   ] aggregation and registration.
   ] 
   ] The LACNIC application satisfies Principle 6. Throughout the transition,
   ] LACNIC has operated under the ARIN policies that have historically been
   ] applicable to allocations and assignments to operators within its
   ] service region. Those policies are consistent with the global policies
   ] applicable to IP address allocation and assignment.

While it's not a requirement that a new RIR have the same policies
as an existing RIR, it was seen as a positive the LACNIC had the
same policies as ARIN during the transition.  I would presume it
would be similarly positive if AfriNIC had the same policies as
{RIPE,ARIN,APNIC} during their transition.

This leaves me with a few questions.  I'm interested in answers for all
RIR's, but of course extra interested in ARIN's bit of the world:

1) Are there any NIR's?

2) Are there any LIR's? (Not ISP's)

3) Has AfriNIC written a document themselves, or had someone
   independently review what they have done in the context of ICP-2?
   This would help evaluate how close they are to really being a
   recognized registry.

4) Do people feel that "approximately continental size" would only
   mean of continent size or greater, or that, particularly for
   big continents, it could mean more than one "RIR" in  a continent
   (by design, not by the happy accident that is currently the
   Africa situation).

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031008/49ac42e4/attachment.sig>

From Trevor.Paquette at TeraGo.ca  Wed Oct  8 11:03:40 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Wed, 8 Oct 2003 09:03:40 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <Pine.GSO.4.44.0310080030550.9924-100000@paixhost.pch.net>
Message-ID: <018401c38dad$5c44feb0$2a45fea9@teraint.net>

Alot of folks do understand the point that I am trying to put across, and agree with me.

Africa can solve their problems on their terms with their own RIR. There is no reason why ARIN needs to make special one-offs for every special interest group.

My opinion and hope you can respect that. Please 'educate' people when you see a mis-interpretation of definitions vs taking pot-shots in a public forum.

> -----Original Message-----
> From: Bill Woodcock [mailto:woody at pch.net]
> Sent: Wednesday, October 08, 2003 1:34 AM
> To: Trevor Paquette
> Cc: Michael.Dillon at radianz.com; ppml at arin.net
> Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> 
> 
>       On Mon, 6 Oct 2003, Trevor Paquette wrote:
>     > Don't assume this whole Africa thing will never happen again..
>     > You'd best err on the side of 'when' it happens again..
>     > Wait till Russia wants thier own RIR..
> 
> If it's a country, it's an NIR, not an RIR.  Please, please, 
> please, try
> to inform yourself at least a little bit about the status quo and the
> process we're involved in before ranting about Quebequois 
> separatism or
> whatever, and trying to equate Africa and Quebec.  Africa is 
> a continent.
> A continent full of people who have vastly different problems 
> than you do.
> 
>                                 -Bill
> 
> 
> 



From Trevor.Paquette at TeraGo.ca  Wed Oct  8 11:11:18 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Wed, 8 Oct 2003 09:11:18 -0600
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <20031008144104.GB87018@ussenterprise.ufp.org>
Message-ID: <018501c38dae$6d8fea80$2a45fea9@teraint.net>

Thank you Leo for clearing up RIR vs NIR vs LIR...

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Leo
> Bicknell
> Sent: Wednesday, October 08, 2003 8:41 AM
> To: ppml at arin.net
> Subject: Re: [ppml] Afrinic and so-called sub-regional policies
> 
> 
> 
> There seems to be some disagreement in the documentation.
> 
> At http://www.iana.org/ipaddress/ip-addresses.htm, we find that:
> 
>    ] Both IPv4 and IPv6 addresses are assigned in a delegated 
> manner. Users
>    ] are assigned IP addresses by Internet service providers 
> (ISPs). ISPs
>    ] obtain allocations of IP addresses from a local Internet 
> registry (LIR)
>    ] or national Internet registry (NIR), or from their 
> appropriate Regional
>    ] Internet Registry (RIR):
> 
>    From this it's already a bit unclear if the picture is:
> 
>            RIR                 RIR
>           /   \        or     /   \
>         NIR   LIR           NIR   NIR
>                            /   \  
>                          LIR   LIR
> 
> However, if we dig deeper, at http://www.iana.org/icp/icp-2.htm,
> we find that NIR is never mentioned in this document.  Humm, they
> seem to have disappeared.  But, we do have a geographic requirement
> for RIR's:
> 
>    ] 1) The region of coverage should meet the scale to be 
> defined by ICANN,
>    ] given the need to avoid global address fragmentation
>    ] 
>    ] The proposed RIR must operate internationally in a large 
> geographical
>    ] region of approximately continental size.
>    ] 
>    ] Each region should be served by a single RIR, 
> established under one
>    ] management and in one location. The establishment of 
> multiple RIRs in
>    ] one region is likely to lead to:
>    ] 
>    ] fragmentation of address space allocated to the region; 
>    ] difficulty for co-ordination and co-operation between the RIRs; 
>    ] confusion for the community within the region. 
>    ] 
>    ] The internal administrative or membership structure of 
> an RIR must also
>    ] not be such as to cause any of these effects.
> 
> So, the standard here is "large geographical region" of "approximately
> continental size".  Not a must be a continent, just a large size.
> 
> However, this document also mentions ICANN.  However when you go
> to ICANN, all I can find is http://www.icann.org/icp/icp-2.htm,
> which seems to be a copy of the document on the IANA site.
> 
> These two documents also have this interesting wording:
> 
>    ] IP address space is currently distributed by the three 
> existing RIRs
>    ] that receive address space from IANA and allocate it 
> further to Local
>    ] Internet Registries (LIRs) or Internet Service Providers 
> (ISPs). These
>    ] LIRs*, in turn, assign addresses to end-users for use in 
> operational
>    ] networks.
> 
>    ] (*) For the purposes of this document, any reference to 
> LIRs can be
>    ] taken to mean LIRs and ISPs.
> 
> I'm going to assume from the footnote that LIR != ISP (eg, they are
> not synonyms, merely treated equally).
> 
> If we go back further in history, there is also
> http://www.faqs.org/rfcs/rfc2050.html.  I'll not quote as I believe
> it's been largely superseded by the other documents mentioned,
> however of interest is Section 1, which has RIR's and LIR's (no
> NIR's).  This reading also has some other very interesting 
> (historical)
> requirements in it.
> 
> Also of interest, particularly when looking at AfriNIC, is
> http://www.iana.org/reports/lacnic-report-07nov02.htm, the report
> on LACNIC's acceptance.  Of note in this document:
> 
>    ] 6) Adherence to global policies regarding address space 
> conservation,
>    ] aggregation and registration.
>    ] 
>    ] The LACNIC application satisfies Principle 6. Throughout 
> the transition,
>    ] LACNIC has operated under the ARIN policies that have 
> historically been
>    ] applicable to allocations and assignments to operators within its
>    ] service region. Those policies are consistent with the 
> global policies
>    ] applicable to IP address allocation and assignment.
> 
> While it's not a requirement that a new RIR have the same policies
> as an existing RIR, it was seen as a positive the LACNIC had the
> same policies as ARIN during the transition.  I would presume it
> would be similarly positive if AfriNIC had the same policies as
> {RIPE,ARIN,APNIC} during their transition.
> 
> This leaves me with a few questions.  I'm interested in 
> answers for all
> RIR's, but of course extra interested in ARIN's bit of the world:
> 
> 1) Are there any NIR's?
> 
> 2) Are there any LIR's? (Not ISP's)
> 
> 3) Has AfriNIC written a document themselves, or had someone
>    independently review what they have done in the context of ICP-2?
>    This would help evaluate how close they are to really being a
>    recognized registry.
> 
> 4) Do people feel that "approximately continental size" would only
>    mean of continent size or greater, or that, particularly for
>    big continents, it could mean more than one "RIR" in  a continent
>    (by design, not by the happy accident that is currently the
>    Africa situation).
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> 



From jb at jbacher.com  Wed Oct  8 11:31:14 2003
From: jb at jbacher.com (J Bacher)
Date: Wed, 08 Oct 2003 10:31:14 -0500
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <OF0D08F308.7CC8AA13-ON80256DB9.00347C70-80256DB9.0035089F@
 radianz.com>
Message-ID: <5.1.0.14.2.20031008100353.032bd880@localhost>


> >>This is an example of a poorly thought out
> >>policy proposal. It doesn't conform to the
>
> >This is an example of determining how many people will accept a
> >double-standard when there ought not be.
>
> >John's analogy is excellent.
>
>ARIN has always had policies that apply
>to only a subset of the organizations in the
>ARIN region. For instance, some policies
>are directed at ISPs and others at end users.

The use of ISP (allocator) vs end user (final recipient) identifies how the 
space is being used than it does providing greater restrictions on one 
group over the other.  It is not politically biased.  It is not 
geographically biased.  It is not cost  or profit biased.  Neither body is 
not restricted and may convert to the other body.

If this is not the time or day for the argument to provide portable space 
for low population areas based upon the availability of connection 
resources, I fail to see how this can become the time or day to reduce the 
allocation requirement based upon availability of connection resources.

Reading the extensive arguments against this proposal, I'm seeing the 
repeating theme to be not that the policy shouldn't be considered but that 
it should be considered with consistency within the ARIN membership -- even 
if only the African membership benefits.  Don't put forth a policy for a 
subset of the membership to the exclusion of the rest.



From billd at cait.wustl.edu  Wed Oct  8 11:46:26 2003
From: billd at cait.wustl.edu (Bill Darte)
Date: Wed, 8 Oct 2003 10:46:26 -0500 
Subject: [ppml] Afrinic and so-called sub-regional policies
Message-ID: <DA8A7734F2B39240977D7883C732FF9B02D94D@kronos.cait.wustl.edu>

WAN (wide-area), LAN (local-area), PAN (premises or now personal-area), CAN
(campus-area)... each representing a area of coverage...
SAN (storage-area) representing a functional environment.
RIR, NIR, LIR, ISP
....lots of acronyms attempting to relate scale and functional status, lots
of confusion.
Little confusion about the meaning of RIR at this point.
Correct me if I am wrong, but Mexico operated a (country-wide) NIR until
being incorporated within LACNIC.  Every ISP is a LIR (localized) relative
to a RIR (regionalized) and there are no independant (non-ISP) LIRs unless
there are remaining NIRs of which I am unaware.  An even more localized ISP
will be a LIR relative to a larger ISP, which again, is a LIR of a larger
scope RIR....right?

Bill Darte
ARIN AC

> -----Original Message-----
> From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca]
> Sent: Wednesday, October 08, 2003 10:11 AM
> To: 'Leo Bicknell'; ppml at arin.net
> Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> 
> 
> Thank you Leo for clearing up RIR vs NIR vs LIR...
> 
> > -----Original Message-----
> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On 
> Behalf Of Leo
> > Bicknell
> > Sent: Wednesday, October 08, 2003 8:41 AM
> > To: ppml at arin.net
> > Subject: Re: [ppml] Afrinic and so-called sub-regional policies
> > 
> > 
> > 
> > There seems to be some disagreement in the documentation.
> > 
> > At http://www.iana.org/ipaddress/ip-addresses.htm, we find that:
> > 
> >    ] Both IPv4 and IPv6 addresses are assigned in a delegated 
> > manner. Users
> >    ] are assigned IP addresses by Internet service providers 
> > (ISPs). ISPs
> >    ] obtain allocations of IP addresses from a local Internet 
> > registry (LIR)
> >    ] or national Internet registry (NIR), or from their 
> > appropriate Regional
> >    ] Internet Registry (RIR):
> > 
> >    From this it's already a bit unclear if the picture is:
> > 
> >            RIR                 RIR
> >           /   \        or     /   \
> >         NIR   LIR           NIR   NIR
> >                            /   \  
> >                          LIR   LIR
> > 
> > However, if we dig deeper, at http://www.iana.org/icp/icp-2.htm,
> > we find that NIR is never mentioned in this document.  Humm, they
> > seem to have disappeared.  But, we do have a geographic requirement
> > for RIR's:
> > 
> >    ] 1) The region of coverage should meet the scale to be 
> > defined by ICANN,
> >    ] given the need to avoid global address fragmentation
> >    ] 
> >    ] The proposed RIR must operate internationally in a large 
> > geographical
> >    ] region of approximately continental size.
> >    ] 
> >    ] Each region should be served by a single RIR, 
> > established under one
> >    ] management and in one location. The establishment of 
> > multiple RIRs in
> >    ] one region is likely to lead to:
> >    ] 
> >    ] fragmentation of address space allocated to the region; 
> >    ] difficulty for co-ordination and co-operation between 
> the RIRs; 
> >    ] confusion for the community within the region. 
> >    ] 
> >    ] The internal administrative or membership structure of 
> > an RIR must also
> >    ] not be such as to cause any of these effects.
> > 
> > So, the standard here is "large geographical region" of 
> "approximately
> > continental size".  Not a must be a continent, just a large size.
> > 
> > However, this document also mentions ICANN.  However when you go
> > to ICANN, all I can find is http://www.icann.org/icp/icp-2.htm,
> > which seems to be a copy of the document on the IANA site.
> > 
> > These two documents also have this interesting wording:
> > 
> >    ] IP address space is currently distributed by the three 
> > existing RIRs
> >    ] that receive address space from IANA and allocate it 
> > further to Local
> >    ] Internet Registries (LIRs) or Internet Service Providers 
> > (ISPs). These
> >    ] LIRs*, in turn, assign addresses to end-users for use in 
> > operational
> >    ] networks.
> > 
> >    ] (*) For the purposes of this document, any reference to 
> > LIRs can be
> >    ] taken to mean LIRs and ISPs.
> > 
> > I'm going to assume from the footnote that LIR != ISP (eg, they are
> > not synonyms, merely treated equally).
> > 
> > If we go back further in history, there is also
> > http://www.faqs.org/rfcs/rfc2050.html.  I'll not quote as I believe
> > it's been largely superseded by the other documents mentioned,
> > however of interest is Section 1, which has RIR's and LIR's (no
> > NIR's).  This reading also has some other very interesting 
> > (historical)
> > requirements in it.
> > 
> > Also of interest, particularly when looking at AfriNIC, is
> > http://www.iana.org/reports/lacnic-report-07nov02.htm, the report
> > on LACNIC's acceptance.  Of note in this document:
> > 
> >    ] 6) Adherence to global policies regarding address space 
> > conservation,
> >    ] aggregation and registration.
> >    ] 
> >    ] The LACNIC application satisfies Principle 6. Throughout 
> > the transition,
> >    ] LACNIC has operated under the ARIN policies that have 
> > historically been
> >    ] applicable to allocations and assignments to operators 
> within its
> >    ] service region. Those policies are consistent with the 
> > global policies
> >    ] applicable to IP address allocation and assignment.
> > 
> > While it's not a requirement that a new RIR have the same policies
> > as an existing RIR, it was seen as a positive the LACNIC had the
> > same policies as ARIN during the transition.  I would presume it
> > would be similarly positive if AfriNIC had the same policies as
> > {RIPE,ARIN,APNIC} during their transition.
> > 
> > This leaves me with a few questions.  I'm interested in 
> > answers for all
> > RIR's, but of course extra interested in ARIN's bit of the world:
> > 
> > 1) Are there any NIR's?
> > 
> > 2) Are there any LIR's? (Not ISP's)
> > 
> > 3) Has AfriNIC written a document themselves, or had someone
> >    independently review what they have done in the context of ICP-2?
> >    This would help evaluate how close they are to really being a
> >    recognized registry.
> > 
> > 4) Do people feel that "approximately continental size" would only
> >    mean of continent size or greater, or that, particularly for
> >    big continents, it could mean more than one "RIR" in  a continent
> >    (by design, not by the happy accident that is currently the
> >    Africa situation).
> > 
> > -- 
> >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> >         PGP keys at http://www.ufp.org/~bicknell/
> > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> > 
> 


From bicknell at ufp.org  Wed Oct  8 11:56:20 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 8 Oct 2003 11:56:20 -0400
Subject: [ppml] Afrinic and so-called sub-regional policies
In-Reply-To: <DA8A7734F2B39240977D7883C732FF9B02D94D@kronos.cait.wustl.edu>
References: <DA8A7734F2B39240977D7883C732FF9B02D94D@kronos.cait.wustl.edu>
Message-ID: <20031008155620.GB91148@ussenterprise.ufp.org>

In a message written on Wed, Oct 08, 2003 at 10:46:26AM -0500, Bill Darte wrote:
> Little confusion about the meaning of RIR at this point.
> Correct me if I am wrong, but Mexico operated a (country-wide) NIR until
> being incorporated within LACNIC.  Every ISP is a LIR (localized) relative
> to a RIR (regionalized) and there are no independant (non-ISP) LIRs unless
> there are remaining NIRs of which I am unaware.  An even more localized ISP
> will be a LIR relative to a larger ISP, which again, is a LIR of a larger
> scope RIR....right?

I can't speak to mexico.  But my own thought on terms:

ISP has a definition that exists outside of IANA/ICANN/ARIN.  There
are many things that fit this global definition of ISP that do not
fit the definition of LIR.  For instance, a web hosting company may
be called an "ISP" in many circles, but may receive addresses only
from their upstream, never reassign addresses, and look more like an
"End User" from a address registry perspective.

Thus, I think using the term "ISP" (to define a class) in a policy
document is a bad idea.

Further, for the ISP's that do qualify as "LIR's", I think that
term is quite inappropriate.  There is nothing local about large
ISP's.  Indeed, several ISP's (my employer included) have allocations
from APNIC, RIPE, and ARIN because they reach a more global scope
than the RIR's.  Thus using "LIR" to refer to the qualifing ISP's
is a very misleading as well.

So, at the end of the day there are:

RIR's            - Regional Internet Registries
Allocation Users - Users who assign space to downstreams.
Assignment Users - Users who do not assign space to downstreams.

Those seem to be the only precise terms, with everything else being
poorly defined and/or not existing (anymore?).  As such perhaps those
are the only three terms we should use, for clarity?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031008/f5488a9e/attachment.sig>

From owen at delong.com  Wed Oct  8 11:56:36 2003
From: owen at delong.com (Owen DeLong)
Date: Wed, 08 Oct 2003 08:56:36 -0700
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <OF0D08F308.7CC8AA13-ON80256DB9.00347C70-80256DB9.0035089F@radianz.com>
References: <OF0D08F308.7CC8AA13-ON80256DB9.00347C70-80256DB9.0035089F@radia
 nz.com>
Message-ID: <2147483647.1065603396@imac-en0.delong.sj.ca.us>

>> This is an example of determining how many people will accept a
>> double-standard when there ought not be.
>
>> John's analogy is excellent.
>
> ARIN has always had policies that apply
> to only a subset of the organizations in the
> ARIN region. For instance, some policies
> are directed at ISPs and others at end users.
> Some are directed at small ISPs just beginning
> to multihome, others to larger ISPs that
> are expanding their use of IP addresses and
> yet others to organizations who are
> beginning to use IPv6.
>
These are groupings based on technical requirements.  It has been well
established that the TECHNICAL requirements for /22 prefix allocations
are similar between small(er) organizations in North America and those
in sub-equitorial Africa.  ARIN does not currently have any policies
which subdivide it's actions based on any geographical, economic, or
other arbitrary and non-technical boundaries.

> When ARIN first shifted the minimum allocation
> size, it was to make it easier for the large
> number of smaller independent ISPs to get
> a portable block of addresses to enable them to
> multihome. That policy was targetted at a specific
> subset of ISPs and had no impact whatsoever on
> the larger ISPs of the day like UUNET.
>
But, the policy applies to ANYONE in ARIN who wishes to apply under the
policy.

> There is a good argument to be made for
> making it easier for low population areas
> to get portable address space, but this is
> not the time or the place. I'd really like
> to see this sort of thing discussed at the
> policy BOF before it gets to the proposal
> stage.
>
I'm sure you would.  However, this is ARIN, not DILLON.  The fact that you
don't want to talk about it at this meeting doesn't mean the rest of the
community wants to sit back and watch prior proposals that had at least
some support evaporate and be told to start over.  It especially doesn't
mean that we want to simultaneously grant the requested capability to
a subset of the intended constituency while excluding the original
requesting portion of the constituency.  While I think John is serious
about the need to get micro-allocations for rural american ISPs, I don't
think he would feel the need to push his policy proposal if there were
not already a discriminatory proposal on the table.  If we can pass 2002-3
with inclusion of allocations, all this becomes moot.  Everyone gets what
they need, and, other than possibly a subset of large(r) providers in North
America, everyone can claim victory.  Then, John's proposal becomes
unnecessary, 2003-15 becomes unnecessary, and, we can avoid the resulting
mess that gets created as each struggling consumer of IP space attempts to
find a small enough subset to specially classify themselves into that they
can get a special policy for what they need.




Owen



From Michael.Dillon at radianz.com  Wed Oct  8 12:10:37 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 8 Oct 2003 17:10:37 +0100
Subject: [ppml] Afrinic and so-called sub-regional policies
Message-ID: <OF723F243A.8B9785FA-ON80256DB9.00582B43-80256DB9.0058DCEC@radianz.com>

>1) Are there any NIR's?

http://www.ripe.net/ripencc/search.html
http://www.apnic.net/apnic-bin/search.cgi

The APNIC search page will be more useful since they have lots of NIRs.

>2) Are there any LIR's? (Not ISP's)

RIPE and APNIC have LIRs which are more or less similar to ISPs.

>3) Has AfriNIC written a document themselves, or had someone

I have previously pointed to the Afrinic website which leads to lots of 
info. 

http://www.afrinic.org

>4) Do people feel that "approximately continental size" would only
mean of continent size or greater, 

Please, let's not try to redefine the English language

Bottom line is that ARIN members can propose any policies they want to 
regardless of whether or not they make sense. The AC can then review and 
reject or revise those proposals and/or recommend the proposals to the 
BoT. The trustees can then accept or reject the AC recommendations.

ARIN policy proposals are not at all like California referendums. They 
don't have to split hairs because the AC can and will change the language 
if necessary.

--Michael Dillon





From Michael.Dillon at radianz.com  Wed Oct  8 12:19:04 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 8 Oct 2003 17:19:04 +0100
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
Message-ID: <OF3DFA8E7B.2BCC4721-ON80256DB9.0058F3C6-80256DB9.0059A322@radianz.com>

>If this is not the time or day for the argument to provide portable space 

>for low population areas based upon the availability of connection 
>resources, I fail to see how this can become the time or day to reduce 
the 
>allocation requirement based upon availability of connection resources.

Let me explain the timing. Policies proposals cannot
be voted on at an ARIN member meeting unless they
have been submitted to ARIN 6 weeks prior to the meeting.
The rural proposal missed that deadline, therefore
this is not really the time to discuss the details
of the proposal. In fact, I don't believe it was
even submitted to ARIN formally so it will not even
get handled at the following member meeting unless 
that is rectified.

Before submitting a proposal about rural 
connectivity needs, we really do need some
more discussion of the issue to deal with the
potential objections that will arise if a policy
is formally proposed. The policy BOF at the next
meeting might be a good place to begin this. After
the meeting is over, this list might be a good
place to continue the discussion. The end result
could be that there is a well-crafted policy
proposal up for voting at the first ARIN meeting
next year.

But right now, it is better if the list focuses
on the proposals listed here 
http://www.arin.net/policy/proposal_archive.html
because that's what we will be voting on in
two weeks or so.

--Michael Dillon




From Michael.Dillon at radianz.com  Wed Oct  8 12:26:58 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 8 Oct 2003 17:26:58 +0100
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
Message-ID: <OFF2861982.37AD004F-ON80256DB9.0059C777-80256DB9.005A5C1E@radianz.com>

> Then, John's proposal becomes
> unnecessary, 2003-15 becomes unnecessary, 

I think it best to ask John whether or
not 2002-3 would make his proposal unnecessary. 
Based on my personal history running an ISP
in rural Canada in the mid '90s, I think John
is right that there is an argument to be made
for special policies that apply to geographical
areas of North America outside of the largest
cities.

>and, we can avoid the resulting
>mess that gets created as each struggling consumer of IP space attempts 
to
>find a small enough subset to specially classify themselves into that 
they
>can get a special policy for what they need.

Politics is always messy. I'm not interested
in avoiding a messy set of policies because I
do not believe that "elegant" policy or 
"theoretical brilliance" are part of ARIN's
charter. If the policy is moving forward
and improving over time, then messy is 
just fine.

--Michael Dillon





From owen at delong.com  Wed Oct  8 12:41:39 2003
From: owen at delong.com (Owen DeLong)
Date: Wed, 08 Oct 2003 09:41:39 -0700
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <OF3DFA8E7B.2BCC4721-ON80256DB9.0058F3C6-80256DB9.0059A322@radianz.com>
References: <OF3DFA8E7B.2BCC4721-ON80256DB9.0058F3C6-80256DB9.0059A322@radia
 nz.com>
Message-ID: <2147483647.1065606099@imac-en0.delong.sj.ca.us>

Michael,
	It has been made clear that we can modify the proposals at the meeting
if there can be a showing of clear consensus.  As such, I think it makes 
sense
to work towards consensus around 2002-3 expanded to include allocations.
You are the primary voice on the list opposing such a discussion, so, you
are partially responsible for John feeling the need to put forth his 
proposal.

Owen


--On Wednesday, October 8, 2003 5:19 PM +0100 Michael.Dillon at radianz.com 
wrote:

>> If this is not the time or day for the argument to provide portable
>> space
>
>> for low population areas based upon the availability of connection
>> resources, I fail to see how this can become the time or day to reduce
> the
>> allocation requirement based upon availability of connection resources.
>
> Let me explain the timing. Policies proposals cannot
> be voted on at an ARIN member meeting unless they
> have been submitted to ARIN 6 weeks prior to the meeting.
> The rural proposal missed that deadline, therefore
> this is not really the time to discuss the details
> of the proposal. In fact, I don't believe it was
> even submitted to ARIN formally so it will not even
> get handled at the following member meeting unless
> that is rectified.
>
> Before submitting a proposal about rural
> connectivity needs, we really do need some
> more discussion of the issue to deal with the
> potential objections that will arise if a policy
> is formally proposed. The policy BOF at the next
> meeting might be a good place to begin this. After
> the meeting is over, this list might be a good
> place to continue the discussion. The end result
> could be that there is a well-crafted policy
> proposal up for voting at the first ARIN meeting
> next year.
>
> But right now, it is better if the list focuses
> on the proposals listed here
> http://www.arin.net/policy/proposal_archive.html
> because that's what we will be voting on in
> two weeks or so.
>
> --Michael Dillon
>
>




From john at chagres.net  Wed Oct  8 12:44:47 2003
From: john at chagres.net (John Brown)
Date: Wed, 8 Oct 2003 10:44:47 -0600
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <OF3DFA8E7B.2BCC4721-ON80256DB9.0058F3C6-80256DB9.0059A322@radianz.com>; from Michael.Dillon@radianz.com on Wed, Oct 08, 2003 at 05:19:04PM +0100
References: <OF3DFA8E7B.2BCC4721-ON80256DB9.0058F3C6-80256DB9.0059A322@radianz.com>
Message-ID: <20031008104447.A5791@alderaan.chagres.net>

Dillon,

you are missing the point.

the rant about how to process a policy is moot and
not the issue.  stop distracting away from the
core issue here and start working on the real issue(s).

i think am quite aware of how ARIN works, and doesn't
work.


On Wed, Oct 08, 2003 at 05:19:04PM +0100, Michael.Dillon at radianz.com wrote:
> >If this is not the time or day for the argument to provide portable space 
> 
> >for low population areas based upon the availability of connection 
> >resources, I fail to see how this can become the time or day to reduce 
> the 
> >allocation requirement based upon availability of connection resources.
> 
> Let me explain the timing. Policies proposals cannot
> be voted on at an ARIN member meeting unless they
> have been submitted to ARIN 6 weeks prior to the meeting.
> The rural proposal missed that deadline, therefore
> this is not really the time to discuss the details
> of the proposal. In fact, I don't believe it was
> even submitted to ARIN formally so it will not even
> get handled at the following member meeting unless 
> that is rectified.
> 
> Before submitting a proposal about rural 
> connectivity needs, we really do need some
> more discussion of the issue to deal with the
> potential objections that will arise if a policy
> is formally proposed. The policy BOF at the next
> meeting might be a good place to begin this. After
> the meeting is over, this list might be a good
> place to continue the discussion. The end result
> could be that there is a well-crafted policy
> proposal up for voting at the first ARIN meeting
> next year.
> 
> But right now, it is better if the list focuses
> on the proposals listed here 
> http://www.arin.net/policy/proposal_archive.html
> because that's what we will be voting on in
> two weeks or so.
> 
> --Michael Dillon
> 
> 


From Michael.Dillon at radianz.com  Wed Oct  8 12:58:02 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 8 Oct 2003 17:58:02 +0100
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
Message-ID: <OFF9F28CA4.68D126B4-ON80256DB9.005CD6E7-80256DB9.005D3493@radianz.com>

> you are missing the point.

So tell me what it is then!

>i think am quite aware of how ARIN works, and doesn't
>work.

Perhaps J Bacher, whose message I was
replying to, isn't as aware of ARIN's workings
as you are.

Is your point that rural ISPs should be able
to easily get an IPv6 /32?

Or is your point that rural ISPs could advance
the use of IPv6 if we set aside some /32's and
suballocate a /45 to each one of them? Maybe
one /32 per state?

--Michael Dillon





From jb at jbacher.com  Wed Oct  8 14:52:28 2003
From: jb at jbacher.com (J Bacher)
Date: Wed, 08 Oct 2003 13:52:28 -0500
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <OFF9F28CA4.68D126B4-ON80256DB9.005CD6E7-80256DB9.005D3493@
 radianz.com>
Message-ID: <5.1.0.14.2.20031008134907.03662dc0@localhost>

At 05:58 PM 10/8/2003 +0100, Dillon wrote:
> > you are missing the point.
>
>So tell me what it is then!
>
> >i think am quite aware of how ARIN works, and doesn't
> >work.
>
>Perhaps J Bacher, whose message I was
>replying to, isn't as aware of ARIN's workings
>as you are.

I am quite aware of how ARIN works.  And to echo John again, "you're 
missing the point."  I (we) don't need a lecture on how the policy process 
works.  The policy process, in and of itself, it not the issue.



From memsvcs at arin.net  Wed Oct  8 16:38:35 2003
From: memsvcs at arin.net (Member Services)
Date: Wed, 8 Oct 2003 16:38:35 -0400 (EDT)
Subject: [ppml] ARIN Policy Process
Message-ID: <200310082038.QAA23803@ops.arin.net>

The current ARIN Internet Resource Policy Evaluation Process 
has been in effect since April, 2001.  At the last ARIN Public 
Policy Meeting changes to the process were discussed.  A new 
process document has been drafted and will be discussed at the 
upcoming ARIN XII meeting.  This draft document is available 
for review at the following location.  A FAQ concerning this 
new process document is also available.

   http://www.arin.net/policy/draft_irpep.html

The current Internet Resource Policy Evaluation Process will 
remain in effect until the new process is approved by the 
ARIN Board of Trustees.  An implementation date will be 
announced upon the Board?s approval.

Best Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From jmcburnett at msmgmt.com  Wed Oct  8 16:40:36 2003
From: jmcburnett at msmgmt.com (McBurnett, Jim)
Date: Wed, 8 Oct 2003 16:40:36 -0400
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
Message-ID: <9BF6F06C4BC90746ADD6806746492A3349A0@msmmail01.msmgmt.com>

Dillion,
I can't say this is John's exact thought, 
but this is my take:


The point is simply this:
If African Sub-Region gets 2003-15 passed.
THEN why not pass a Rural America policy.
1. 2003-15 is for a subset of ARIN
2. Rural America is A SUBSET OF ARIN
3. 2003-15 COULD Benefit MORE THAN JUST AFRICA
4. 2003-15 is what ALL OF ARIN NEEDS.
5. if we start passing sub-regional policies now,
	we will NEVER stop.

I see it this way, today it is African sub-region.
Tomarrow Rural America, next week Alaska,
the week after. 
I guess the question is once we start this, where
will it end? HMM sounds like another thread here..


Jim
->-----Original Message-----
->From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com]
->Sent: Wednesday, October 08, 2003 12:58 PM
->To: ppml at arin.net
->Subject: Re: [ppml] New ARIN Sub-region Policy Proposal 
->(Rural-America)
->
->
->> you are missing the point.
->
->So tell me what it is then!
->
->>i think am quite aware of how ARIN works, and doesn't
->>work.
->
->Perhaps J Bacher, whose message I was
->replying to, isn't as aware of ARIN's workings
->as you are.
->
->Is your point that rural ISPs should be able
->to easily get an IPv6 /32?
->
->Or is your point that rural ISPs could advance
->the use of IPv6 if we set aside some /32's and
->suballocate a /45 to each one of them? Maybe
->one /32 per state?
->
->--Michael Dillon
->
->
->
->


From john at apnic.net  Thu Oct  9 02:03:16 2003
From: john at apnic.net (John Tran)
Date: Thu, 9 Oct 2003 16:03:16 +1000 (EST)
Subject: [ppml] Afrinic and so-called sub-regional policies
Message-ID: <Pine.LNX.4.44.0310091601530.21468-100000@durian.apnic.net>


Hi all,

It seem that quite a few people are confusing about the terms that RIRs are using such as
NIR, LIR and etc. As APNIC have quite a few NIRs therefore our policy document might help
you all with these definition.

http://www.apnic.net/docs/policy/add-manage-policy.html

I hope the above information is useful. Please feel free to send email to helpdesk at apnic.net 
if you need further clarification.

Son
APNIC

---------- Forwarded message ----------
Date: Wed, 8 Oct 2003 10:46:26 -0500
From: Bill Darte <billd at cait.wustl.edu>
To: 'Trevor Paquette' <Trevor.Paquette at TeraGo.ca>,
     'Leo Bicknell' <bicknell at ufp.org>, ppml at arin.net
Subject: [hm-staff] RE: [ppml] Afrinic and so-called sub-regional policies

WAN (wide-area), LAN (local-area), PAN (premises or now personal-area), CAN
(campus-area)... each representing a area of coverage...
SAN (storage-area) representing a functional environment.
RIR, NIR, LIR, ISP
....lots of acronyms attempting to relate scale and functional status, lots
of confusion.
Little confusion about the meaning of RIR at this point.
Correct me if I am wrong, but Mexico operated a (country-wide) NIR until
being incorporated within LACNIC.  Every ISP is a LIR (localized) relative
to a RIR (regionalized) and there are no independant (non-ISP) LIRs unless
there are remaining NIRs of which I am unaware.  An even more localized ISP
will be a LIR relative to a larger ISP, which again, is a LIR of a larger
scope RIR....right?

Bill Darte
ARIN AC

> -----Original Message-----
> From: Trevor Paquette [mailto:Trevor.Paquette at TeraGo.ca]
> Sent: Wednesday, October 08, 2003 10:11 AM
> To: 'Leo Bicknell'; ppml at arin.net
> Subject: RE: [ppml] Afrinic and so-called sub-regional policies
> 
> 
> Thank you Leo for clearing up RIR vs NIR vs LIR...
> 
> > -----Original Message-----
> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On 
> Behalf Of Leo
> > Bicknell
> > Sent: Wednesday, October 08, 2003 8:41 AM
> > To: ppml at arin.net
> > Subject: Re: [ppml] Afrinic and so-called sub-regional policies
> > 
> > 
> > 
> > There seems to be some disagreement in the documentation.
> > 
> > At http://www.iana.org/ipaddress/ip-addresses.htm, we find that:
> > 
> >    ] Both IPv4 and IPv6 addresses are assigned in a delegated 
> > manner. Users
> >    ] are assigned IP addresses by Internet service providers 
> > (ISPs). ISPs
> >    ] obtain allocations of IP addresses from a local Internet 
> > registry (LIR)
> >    ] or national Internet registry (NIR), or from their 
> > appropriate Regional
> >    ] Internet Registry (RIR):
> > 
> >    From this it's already a bit unclear if the picture is:
> > 
> >            RIR                 RIR
> >           /   \        or     /   \
> >         NIR   LIR           NIR   NIR
> >                            /   \  
> >                          LIR   LIR
> > 
> > However, if we dig deeper, at http://www.iana.org/icp/icp-2.htm,
> > we find that NIR is never mentioned in this document.  Humm, they
> > seem to have disappeared.  But, we do have a geographic requirement
> > for RIR's:
> > 
> >    ] 1) The region of coverage should meet the scale to be 
> > defined by ICANN,
> >    ] given the need to avoid global address fragmentation
> >    ] 
> >    ] The proposed RIR must operate internationally in a large 
> > geographical
> >    ] region of approximately continental size.
> >    ] 
> >    ] Each region should be served by a single RIR, 
> > established under one
> >    ] management and in one location. The establishment of 
> > multiple RIRs in
> >    ] one region is likely to lead to:
> >    ] 
> >    ] fragmentation of address space allocated to the region; 
> >    ] difficulty for co-ordination and co-operation between 
> the RIRs; 
> >    ] confusion for the community within the region. 
> >    ] 
> >    ] The internal administrative or membership structure of 
> > an RIR must also
> >    ] not be such as to cause any of these effects.
> > 
> > So, the standard here is "large geographical region" of 
> "approximately
> > continental size".  Not a must be a continent, just a large size.
> > 
> > However, this document also mentions ICANN.  However when you go
> > to ICANN, all I can find is http://www.icann.org/icp/icp-2.htm,
> > which seems to be a copy of the document on the IANA site.
> > 
> > These two documents also have this interesting wording:
> > 
> >    ] IP address space is currently distributed by the three 
> > existing RIRs
> >    ] that receive address space from IANA and allocate it 
> > further to Local
> >    ] Internet Registries (LIRs) or Internet Service Providers 
> > (ISPs). These
> >    ] LIRs*, in turn, assign addresses to end-users for use in 
> > operational
> >    ] networks.
> > 
> >    ] (*) For the purposes of this document, any reference to 
> > LIRs can be
> >    ] taken to mean LIRs and ISPs.
> > 
> > I'm going to assume from the footnote that LIR != ISP (eg, they are
> > not synonyms, merely treated equally).
> > 
> > If we go back further in history, there is also
> > http://www.faqs.org/rfcs/rfc2050.html.  I'll not quote as I believe
> > it's been largely superseded by the other documents mentioned,
> > however of interest is Section 1, which has RIR's and LIR's (no
> > NIR's).  This reading also has some other very interesting 
> > (historical)
> > requirements in it.
> > 
> > Also of interest, particularly when looking at AfriNIC, is
> > http://www.iana.org/reports/lacnic-report-07nov02.htm, the report
> > on LACNIC's acceptance.  Of note in this document:
> > 
> >    ] 6) Adherence to global policies regarding address space 
> > conservation,
> >    ] aggregation and registration.
> >    ] 
> >    ] The LACNIC application satisfies Principle 6. Throughout 
> > the transition,
> >    ] LACNIC has operated under the ARIN policies that have 
> > historically been
> >    ] applicable to allocations and assignments to operators 
> within its
> >    ] service region. Those policies are consistent with the 
> > global policies
> >    ] applicable to IP address allocation and assignment.
> > 
> > While it's not a requirement that a new RIR have the same policies
> > as an existing RIR, it was seen as a positive the LACNIC had the
> > same policies as ARIN during the transition.  I would presume it
> > would be similarly positive if AfriNIC had the same policies as
> > {RIPE,ARIN,APNIC} during their transition.
> > 
> > This leaves me with a few questions.  I'm interested in 
> > answers for all
> > RIR's, but of course extra interested in ARIN's bit of the world:
> > 
> > 1) Are there any NIR's?
> > 
> > 2) Are there any LIR's? (Not ISP's)
> > 
> > 3) Has AfriNIC written a document themselves, or had someone
> >    independently review what they have done in the context of ICP-2?
> >    This would help evaluate how close they are to really being a
> >    recognized registry.
> > 
> > 4) Do people feel that "approximately continental size" would only
> >    mean of continent size or greater, or that, particularly for
> >    big continents, it could mean more than one "RIR" in  a continent
> >    (by design, not by the happy accident that is currently the
> >    Africa situation).
> > 
> > -- 
> >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> >         PGP keys at http://www.ufp.org/~bicknell/
> > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> > 
> 
_______________________________________________
Hostmaster-staff mailing list
Hostmaster-staff at apnic.net
http://mailman.apnic.net/mailman/listinfo/hostmaster-staff



From arin-member at quadrix.com  Thu Oct  9 12:27:22 2003
From: arin-member at quadrix.com (Bill Van Emburg)
Date: Thu, 09 Oct 2003 12:27:22 -0400
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
Message-ID: <3F858C6A.1020103@quadrix.com>

Owen DeLong wrote:

> 3.    John's proposal and 2003-15 are similar.  The difference for you
>     is that John's proposal doesn't help you and 2003-15 does.  This
>     is the same difference for John.
> 4.    Both are a bad idea unless we first obtain a clear vote showing
>     that there is no willingness to grant 2002-3 with allocations
>     added to all of ARIN.
> 
Actually, neither proposal does anything for me.  I am not in Africa,
and I'm not in rural America.  I also happen to support both 2003-15 and
2002-3.  If it's carefully done in small steps, I even support a gradual
movement of the allocation boundary towards /24, which is where I'd like
it to be if the Internet can handle it.  Be careful what you presume.

I don't know if you're aware of the full history behind 2002-3.  Whether
you are or not, it's important to note that 2002-3 is a compromise
proposal that has resulted from years of work by many individuals.  This
debate has raged for a long time, and 2002-3 is intended to be an
initial step towards what you want that will allow more data to be
gathered towards supporting or refuting technical reasons given to not
move the allocation boundary towards longer prefixes.  Rather than
trying, yet again, to change 2002-3, support it, and let the gathered
technical data make your argument (for longer allocation prefixes) for you.

What I *am* arguing against is this preoccupation with the idea that
policies can't be applied to a subset of ARIN's population.  There is
nothing in ARIN's charter, policies or history to support that theory.
It is simply something that some seem to find useful in their argument.
  Your statement in another e-mail, "ARIN does not currently have any
policies which subdivide it's actions based on any geographical,
economic, or other arbitrary and non-technical boundaries," is simply
not true.  You must look no further than the fee structure to see this.
  Charging large ISPs more money to be ARIN members is a policy with no
technical basis.

I also have a problem with trying to win an argument through extensive
repetition of the same points.  Fortunately, I've been with ARIN long
enough to know that the AC and the BoT can see through this technique.

May I suggest that if we don't have something new to add to the
discussion of 2003-15 and/or 2002-3, that we end this back-and-forth?  I
don't think it's possible that anyone has failed to pick up on the
positions that have been presented.

In addition, feel free to present this "rural America" policy, if you
truly feel it is a good way to go.  While it will not see discussion at
this coming meeting, it will be handled as all other policy proposals
are in due time.
-- 
				     -- Bill Van Emburg
					Quadrix Solutions, Inc.

> --On Tuesday, October 7, 2003 22:22 -0400 Bill Van Emburg 
> <arin-member at quadrix.com> wrote:
> 
>> J Bacher wrote:
>>
>>> At 05:00 PM 10/7/2003 +0100, you wrote:
>>>
>>>> > The ARIN sub-region known as "Rural America", those
>>>> > localities with a population of less than 1 million
>>>> > persons here by proposes the following Policy Proposal.
>>>>
>>>> This is an example of a poorly thought out
>>>> policy proposal. It doesn't conform to the
>>>
>>>
>>> This is an example of determining how many people will accept a
>>> double-standard when there ought not be.
>>>
>>> John's analogy is excellent.
>>
>>
>> Absolutely not!  As someone else on this list mentioned, we're talking
>> about a different policy for a different CONTINENT, and one which is made
>> up of mostly "3rd-world" countries.  Rural America is much more similar
>> to the rest of the U.S., and does not, in any case, represent a easily
>> separable geography.
>>
>> ...and don't try to say that 2003-15 doesn't represent a continent.  It
>> represents the portion of that different continent that ARIN currently
>> has control over.  (...and only has that control for historical reasons,
>> a problem that AfriNIC is trying to fix!)
>>
>> 2003-15 and this "Rural America" proposal are very different things, and
>> there is no reason to consider them the same. --
>>                      -- Bill Van Emburg
>>                     Quadrix Solutions, Inc.




From bicknell at ufp.org  Thu Oct  9 12:50:11 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 9 Oct 2003 12:50:11 -0400
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <3F858C6A.1020103@quadrix.com>
References: <3F858C6A.1020103@quadrix.com>
Message-ID: <20031009165011.GA49810@ussenterprise.ufp.org>

In a message written on Thu, Oct 09, 2003 at 12:27:22PM -0400, Bill Van Emburg wrote:
> not true.  You must look no further than the fee structure to see this.
>  Charging large ISPs more money to be ARIN members is a policy with no
> technical basis.

I thought the fee structure represented technical concerns, namely.

1) ISP's generate lots of SWIP requests and the like that need to
   be processed, which takes mail servers, programmers, and people
   to watch over it.  End users do not generate (the same level
   of?) requests.

2) The larger the block assigned the more ARIN's top level in-addr.arpa.
   nameservers will be hit, thus the larger the infrastructure cost.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031009/63285182/attachment.sig>

From william at elan.net  Thu Oct  9 16:11:41 2003
From: william at elan.net (william at elan.net)
Date: Thu, 9 Oct 2003 13:11:41 -0700 (PDT)
Subject: [ppml] Statistics for allocations for each IPv4 /8 block based on RIRs
 whois data
In-Reply-To: <Pine.LNX.4.44.0310040639230.5734-100000@sokol.elan.net>
Message-ID: <Pine.LNX.4.44.0310091250550.31896-100000@sokol.elan.net>

http://www.completewhois.com/statistics/ip_statistics.htm

Above is URL where I put together data for total allocations by RIR for 
each IPv4 /8 block and as well as amount of ip space currently routed,
with nice bargraphs showing how this all looks. This data maybe of some 
use when you are considering the IANA to RIR allocation policy proposal. 
All data is current and webpage is updated daily automaticly.

Also at the http://www.completewhois.com/bogons/ipwhois_data_analysis.htm
there are links to lists of blocks that are not listed properly in RIR 
whois (I notified RIRs already, so for example ARIN already got rid of 
most "direct assignment" orpan blocks smaller then /24), this is actually 
only small percentage of problems in whois - only those that directly 
effected my data collection process.

-- 
William Leibzon
Elan Networks
william at elan.net



From william at elan.net  Thu Oct  9 22:02:18 2003
From: william at elan.net (william at elan.net)
Date: Thu, 9 Oct 2003 19:02:18 -0700 (PDT)
Subject: [ppml] Re: Statistics for allocations for each IPv4 /8 block based on RIRs
 whois data
In-Reply-To: <Pine.LNX.4.44.0310091250550.31896-100000@sokol.elan.net>
Message-ID: <Pine.LNX.4.44.0310091349390.31896-100000@sokol.elan.net>

> http://www.completewhois.com/statistics/ip_statistics.htm
Based on my statistics above, I also gathered some additional data which 
is interesting when evaluating efficiency of RIR ip allocations and how 
it works out in each of their regions.

I've used the term "routing utilization" below to indicate percent of 
allocated space that is actively routed (I could not find another term to 
use for this, if one exist - let me know).

ARIN (/8 blocks 63/8, 64/8, 65/7, 66/8, 67/8, 68/8, 69/8, 207/8, 208/8,
	        209/8, 216/8)
    Number of /24 blocks allocated: 513436
    Number of /24 blocks routed (of above): 495764
    Routing Utilization Ratio: 96.5% (!!!)
    Amount of ip space left unallocated from blocks not in most active 
     allocation use (i.e. except 69/8):  78549 (/24 blocks)
    Percent of space left unallocated before requesting new /8: 12.0%

ARIN OLD (/8 blocks 196/8, 198/8, 199/8, 204/8, 205/8, 206/8)
    Number of /24 blocks allocated: 308704
    Number of /24 blocks routed (of above): 213009
    Routing Utilization Ratio: 69.0%
    Amount of ip space left unallocated from blocks not in most active 
     allocation use (i.e. except 196/8):  30267 (/24 blocks)
    Percent of space left unallocated from these blocks: 9.2%

RIPE (/8 blocks 62/8, 80/8, 81/8, 82/8, 212/8, 213/8, 217/8):
    Number of /24 blocks allocated: 419984
    Number of /24 blocks routed (of above): 378682
    Routing Utilization Ratio: 90.1%
    Amount of ip space left unallocated from blocks not in most active 
     allocation use (i.e. except 82/8):  12848 (/24 blocks)
    Percent of space left unallocated before requesting new /8: 3.26%

RIPE OLD (/8 blocks 193/8, 194/8, 195/8):
    Number of /24 blocks allocated: 191591
    Number of /24 blocks routed (of above): 156456
    Routing Utilization Ratio: 81.6%
    Amount of ip space left unallocated from these blocks: 4837 (/24 
    Percent of space left unallocated from these blocks: 2.46% (!!!)

APNIC (/8 blocks 60/8, 61/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8):
    Number of /24 blocks allocated: 440838
    Number of /24 blocks routed (of above): 387855
    Routing Utilization Ratio: 90%
    Amount of ip space left unallocated from blocks not in most active 
     allocation use (i.e. except 60/8 and 222/8):  30971 (/24 blocks)
    Percent of space left unallocated before requesting new /8: 6.75%

APNIC OLD (/8 blocks 202/8, 203/8):
    Number of /24 blocks allocated: 111682
    Number of /24 blocks routed (of above): 94200
    Routing Utilization Ratio: 84.3%
    Amount of ip space left unallocated from these blocks: 19390 (/24 
    Percent of space left unallocated from these blocks: 14.8% (!!!)

LACNIC (/8 blocks 200/8, 211/8):
    Number of /24 blocks allocated: 62271
    Number of /24 blocks routed (of above): 52171
    Routing Utilization Ratio: 83.8%
    (Note that routing utilization for 200/8 alone is 89.5%)
    Amount of ip space left unallocated in 200/8 block: 8385 (/24 blocks)
    Percent of space left unallocated before requesting new /8: 13%

>From above I think you can all see that ARIN tends to assign blocks of the 
size company needs in immediate future (and companies route exactly that
block) leaving in reserve for the same companies future allocation large 
blocks - this leads to very good routing utilization ratio of 96% for 
north american region, compared to all others, but fairly large amount of 
space left before it requests new /8 from IANA (12%). 

On the other hand RIPE does the opposite and tends to give larger amount 
of space then needed  (I guess all those claims that its hard to get ip 
space of the size you need from RIPE, may not be exactly true...) and 
companies route less space but RIPE will use entire /8 block and leave 
nothing in reserve for the same LIRs future allocation, as a result their 
region has lower routing utilization ratio of 90% bad best ratio for the 
amount of ip blocks left before requesting new /8 (3.25%). 

APNIC is trying to do something in between, I'd guess, but but somehow 
ends up with larger amount of space left in their ip blocks (6.5%) but
the companies there have either time getting ip blocks and route less
of it leaving with the same routing utilization ration of 90% with RIPE,
though their utilization ration is dragged down by 222/8 block from which 
they allocated lots of space lately but not much of that is yet in use.

For LACNIC I can't yet tell anything except they allocated large blocks in 
new 201/8 block and they are not in active use, which drags down their 
routing utilization ration quite bad (otherwise its the same as with RIPE 
and APNIC).

Also below are some of the most interesting (i.e. best/worst) numbers for 
various /8 blocks:

RIR /8 blocks with least amount of unallocated space ( <= 2% not allocated)
  62/8 (RIPE) - < 1% not allocated
  63/8 (ARIN) - 2% not allocated 
  133/8 (JPNIC) - 1% not allocated
  135/8 (Internic Legacy) - 1% not allocated
  136/8 (Internic Legacy) - 1.5% not allocated
  143/8 (Internic Legacy) - 2% not allocated
  147/8 (Internic Legacy) - 1.5% not allocated
  166/8 (Internic Legacy) - 1% not allocated
  195/8 (RIPE) - 1.5% not allocated
  211/8 (APNIC) - 1% not allocated
  212/8 (RIPE) - < 1% not allocated 
  213/8 (RIPE) - 1% not allocated

RIR /8 blocks with with best ratio of routed blocks / allocated blocks
(those with > 95% routing utilization ratio except ripe where its > 94%)
  60/8 (APNIC) - 100% routing utilization (but of the entire /8 only one 
				          /20 is allocated and routed)
  63/8 (ARIN) - 99.1% routing utilization
  68/8 (ARIN) - 97.1% routing utilization
  188/8 (Internic Legacy) - 100% routing utilization (but there is only 
					 one /16 there allocated anyway)
  208/8 (ARIN) - 99.6% routing utilization (!!!)
  217/8 (RIPE) - 94.2% routing utlization
  219/8 (APNIC) - 97.3% routing utilization

RIR /8 blocks with worst routing utilization ratio
(where 50% or more of allocated space is not routed)
  135/8 (Internic Legacy) - 41% routing utilization
  136/8 (Internic Legacy) - 32% routing utilization
  154/8 (Internic Legacy) - 19% routing utilization
  169/8 (Internic Legacy) - 23% routing utilization
  171/8 (Internic Legacy) - 21% routing utilization
  192/8 (Internic Legacy) - 42% routing utilization
  201/8 (LACNIC) - 20% routing utilization (this is their newest block)
  222/8 (APNIC) - 23% routing utilization (also their newwest block)

IANA /8 blocks that are listed as allocated, but that are not routed at all
  9/8 - IBM
  11/8 - US DoD
  19/8 - Ford
  21/8 - DDN-RVN (US DoD)
  22/8 - DISA (ARPANET; US DoD)
  26/8 - DISA (ARPANET; US DoD)
  28/8 - DISA (ARPANET; US DoD)
  29/8 - DISA (ARPANET; US DoD)
  30/8 - DISA (ARPANET; US DoD)
  46/8 - BBN (now L3)
  46/8 - Prudential
  51/8 - UK Department of Social Security
  54/8 - Merck

/8 blocks with least amount of routed space (but at least some)
  6/8 (US-DOD) - 2% routed
  25/8 (UK Royal Signals and Radar Establishment) - 1% routed
  60/8 (APNIC) - < 1% routed (one /20)
  34/8 (Haliburton) - 1% routed (one /16)
  43/8 (V6NIC.NET) - 4% routed
  52/8 (DuPont) - < 1% routed (320 /24 blocks)
  56/8 (US Postal Service) - < 1% routed (160 /24 blocks)
  154/8 (Internic Legacy) - 4% routed
  188/8 (Internic Legacy) - 1% routed (one /16)
  201/8 (LACNIC) - 1% routed
  222/8 (APNIC) - 4% routed

/8 blocks with least amount of allocated space ( < 50% of block allocated)
  153/8 (Internic Legacy) - 44% allocated
  154/8 (Internic Legacy) - 25% allocated
  171/8 (Internic Legacy) - 44% allocated
  172/8 (Internic Legacy) - 39% allocated
  188/8 (Internic Legacy) - < 1% allocated (one /16)
  196/8 (ARIN/AFRINIC) - 17% allocated
  201/8 (LACNIC) - 7% allocated
  222/8 (APNIC) - 19% allocated
  60/8 (APNIC) - < 1% allocated (one /20)
  69/8 (ARIN) - 23% allocated

>From the above, I would especially note large amount of completely unrouted 
blocks for DISA, I think they need to ask they if they really are using 
internally any of that space and if not if they can give some of it back.
I would also ask to. I would also note that there are several internic 
legacy blocks that should really be reassigned to one of RIRs and reused 
(especially 188/8 which has only one /16).

I'll post all this data on separate webpage (linked to statistics page) on 
the website as well, but this was all one-time calculation. Although I'll 
try to setup to at least keep track of RIR data automaticly to see what 
trends there with that in the next 6-12 months.

-- 
William Leibzon
Elan Networks
william at elan.net



From antonio at nambu.uem.mz  Fri Oct 10 07:39:22 2003
From: antonio at nambu.uem.mz (antonio at nambu.uem.mz)
Date: Fri, 10 Oct 2003 13:39:22 +0200
Subject: [ppml] New ARIN Sub-region Policy Proposal (Rural-America)
In-Reply-To: <3F858C6A.1020103@quadrix.com>
Message-ID: <3F86B68A.24581.1F4ED8@localhost>

Nicely put.

On 9 Oct 2003 at 12:27, Bill Van Emburg wrote:

> Owen DeLong wrote:
> 
> > 3.    John's proposal and 2003-15 are similar.  The difference for you
> >     is that John's proposal doesn't help you and 2003-15 does.  This
> >     is the same difference for John.
> > 4.    Both are a bad idea unless we first obtain a clear vote showing
> >     that there is no willingness to grant 2002-3 with allocations
> >     added to all of ARIN.
> > 
> Actually, neither proposal does anything for me.  I am not in Africa,
> and I'm not in rural America.  I also happen to support both 2003-15 and
> 2002-3.  If it's carefully done in small steps, I even support a gradual
> movement of the allocation boundary towards /24, which is where I'd like
> it to be if the Internet can handle it.  Be careful what you presume.
> 
> I don't know if you're aware of the full history behind 2002-3.  Whether
> you are or not, it's important to note that 2002-3 is a compromise
> proposal that has resulted from years of work by many individuals.  This
> debate has raged for a long time, and 2002-3 is intended to be an
> initial step towards what you want that will allow more data to be
> gathered towards supporting or refuting technical reasons given to not
> move the allocation boundary towards longer prefixes.  Rather than
> trying, yet again, to change 2002-3, support it, and let the gathered
> technical data make your argument (for longer allocation prefixes) for you.
> 
> What I *am* arguing against is this preoccupation with the idea that
> policies can't be applied to a subset of ARIN's population.  There is
> nothing in ARIN's charter, policies or history to support that theory.
> It is simply something that some seem to find useful in their argument.
>   Your statement in another e-mail, "ARIN does not currently have any
> policies which subdivide it's actions based on any geographical,
> economic, or other arbitrary and non-technical boundaries," is simply
> not true.  You must look no further than the fee structure to see this.
>   Charging large ISPs more money to be ARIN members is a policy with no
> technical basis.
> 
> I also have a problem with trying to win an argument through extensive
> repetition of the same points.  Fortunately, I've been with ARIN long
> enough to know that the AC and the BoT can see through this technique.
> 
> May I suggest that if we don't have something new to add to the
> discussion of 2003-15 and/or 2002-3, that we end this back-and-forth?  I
> don't think it's possible that anyone has failed to pick up on the
> positions that have been presented.
> 
> In addition, feel free to present this "rural America" policy, if you
> truly feel it is a good way to go.  While it will not see discussion at
> this coming meeting, it will be handled as all other policy proposals
> are in due time.
> -- 
> 				     -- Bill Van Emburg
> 					Quadrix Solutions, Inc.
> 
> > --On Tuesday, October 7, 2003 22:22 -0400 Bill Van Emburg 
> > <arin-member at quadrix.com> wrote:
> > 
> >> J Bacher wrote:
> >>
> >>> At 05:00 PM 10/7/2003 +0100, you wrote:
> >>>
> >>>> > The ARIN sub-region known as "Rural America", those
> >>>> > localities with a population of less than 1 million
> >>>> > persons here by proposes the following Policy Proposal.
> >>>>
> >>>> This is an example of a poorly thought out
> >>>> policy proposal. It doesn't conform to the
> >>>
> >>>
> >>> This is an example of determining how many people will accept a
> >>> double-standard when there ought not be.
> >>>
> >>> John's analogy is excellent.
> >>
> >>
> >> Absolutely not!  As someone else on this list mentioned, we're talking
> >> about a different policy for a different CONTINENT, and one which is made
> >> up of mostly "3rd-world" countries.  Rural America is much more similar
> >> to the rest of the U.S., and does not, in any case, represent a easily
> >> separable geography.
> >>
> >> ...and don't try to say that 2003-15 doesn't represent a continent.  It
> >> represents the portion of that different continent that ARIN currently
> >> has control over.  (...and only has that control for historical reasons,
> >> a problem that AfriNIC is trying to fix!)
> >>
> >> 2003-15 and this "Rural America" proposal are very different things, and
> >> there is no reason to consider them the same. --
> >>                      -- Bill Van Emburg
> >>                     Quadrix Solutions, Inc.
> 
> 





From billd at cait.wustl.edu  Fri Oct 10 10:01:09 2003
From: billd at cait.wustl.edu (Bill Darte)
Date: Fri, 10 Oct 2003 09:01:09 -0500
Subject: [ppml] Alternatives to 2002-3 Wording and Scope - Please Evaluate
Message-ID: <DA8A7734F2B39240977D7883C732FF9B02D965@kronos.cait.wustl.edu>

Hello All,

Following are 4 alternatives to the 2002-3 Micro-Assignments for Multihomed
Networks policy proposal.

The first option is the current proposal that has been around awhile.  The 3
options following are various wordings of an alternative policy proposal
that trims the wording, but expands the objectives of 2002-3 to inlcude
micro-allocations as well as micro-assignments down to /22.

In each case, it is planned to follow the impact of a successful policy
adoption in this realm to ensure that it doesn't break things on the
Internet.

Please review each of these alternatives and register your preference...or
proposal specific and succinct wording changes where you feel appropriate
along with a brief explanation your reasoning.

The results of this exercise and the comments from interaction will be
presented along with those related to 2002-3 here-to-fore on the ppml at the
upcoming meeting in Chicago.  I urge each of you to participate fully in
this exercise and a the upcoming meeting.

Bill Darte
ARIN Advisory Council 


1./  Original 2002-3 Micro-Assignments for Multihomed Networks

If an end-user is not multi-homed, the minimum justified block of IP address
space assigned by ARIN is a /20. If assignments smaller than /20 are needed,
end-users should contact their upstream provider.

If an end-user is multi-homed, and has an ARIN assigned ASN, the minimum
justified block of IP address space assigned by ARIN is a /22. Such
assignment will be made from a reserve block for this purpose. If
multi-homed assignments smaller than a /22 are needed, end users should
contact their upstream provider.


2./  Possible Modified 2002-3 Policy
2002-3 Micro-Allocations and Assignments for Multihomed Networks

Multi-homed entities with an ARIN assigned ASN may justify and obtain a
block of address space with prefix length extending to /22 directly from
ARIN.  When prefixes are longer than /20, these micro-allocations or
micro-assignments will be from a reserved block for that purpose.

3./  2002-3 Micro-Allocations and Assignments for Multihomed Networks
(Alternative Wording)

Multi-homed entities may justify and obtain a block of address space with
prefix length extending to /22 directly from ARIN.  When prefixes are longer
than /20, these micro-allocations or micro-assignments will be from a
reserved block for that purpose.

4./  2002-3 Micro-Allocations and Assignments for Multihomed Networks
(Alternative Wording)

Multi-homed entities with a unique routing policy may justify and obtain a
block of address space with prefix length extending to /22 directly from
ARIN.  When prefixes are longer than /20, these micro-allocations or
micro-assignments will be from a reserved block for that purpose.

Thanks,

Bill Darte
CAIT Senior Technical Associate
314 935-7575 


From owen at delong.com  Fri Oct 10 12:04:19 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 10 Oct 2003 09:04:19 -0700
Subject: [ppml] Alternatives to 2002-3 Wording and Scope - Please
 Evaluate
In-Reply-To: <DA8A7734F2B39240977D7883C732FF9B02D965@kronos.cait.wustl.edu>
References: <DA8A7734F2B39240977D7883C732FF9B02D965@kronos.cait.wustl.edu>
Message-ID: <2147483647.1065776659@imac-en0.delong.sj.ca.us>

> The results of this exercise and the comments from interaction will be
> presented along with those related to 2002-3 here-to-fore on the ppml at
> the upcoming meeting in Chicago.  I urge each of you to participate fully
> in this exercise and a the upcoming meeting.
>
> Bill Darte
> ARIN Advisory Council
>
Thanks, Bill... I'm pretty sure you know where I stand, but...

>
> 1./  Original 2002-3 Micro-Assignments for Multihomed Networks
>
> If an end-user is not multi-homed, the minimum justified block of IP
> address space assigned by ARIN is a /20. If assignments smaller than /20
> are needed, end-users should contact their upstream provider.
>
> If an end-user is multi-homed, and has an ARIN assigned ASN, the minimum
> justified block of IP address space assigned by ARIN is a /22. Such
> assignment will be made from a reserve block for this purpose. If
> multi-homed assignments smaller than a /22 are needed, end users should
> contact their upstream provider.
>
I would vote for this policy.

>
> 2./  Possible Modified 2002-3 Policy
> 2002-3 Micro-Allocations and Assignments for Multihomed Networks
>
> Multi-homed entities with an ARIN assigned ASN may justify and obtain a
> block of address space with prefix length extending to /22 directly from
> ARIN.  When prefixes are longer than /20, these micro-allocations or
> micro-assignments will be from a reserved block for that purpose.
>
I would vote for this policy.  And prefer it over option 1.

> 3./  2002-3 Micro-Allocations and Assignments for Multihomed Networks
> (Alternative Wording)
>
> Multi-homed entities may justify and obtain a block of address space with
> prefix length extending to /22 directly from ARIN.  When prefixes are
> longer than /20, these micro-allocations or micro-assignments will be
> from a reserved block for that purpose.
>
This is even better than option 2.

> 4./  2002-3 Micro-Allocations and Assignments for Multihomed Networks
> (Alternative Wording)
>
> Multi-homed entities with a unique routing policy may justify and obtain a
> block of address space with prefix length extending to /22 directly from
> ARIN.  When prefixes are longer than /20, these micro-allocations or
> micro-assignments will be from a reserved block for that purpose.
>
This one would be my favorite if you dropped the words "with a unique 
routing
policy".  Otherwise, I would still vote for it, but, I prefer option 3.


Thank YOU!!!

Owen



From bicknell at ufp.org  Fri Oct 10 12:49:07 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Oct 2003 12:49:07 -0400
Subject: [ppml] Alternatives to 2002-3 Wording and Scope - Please Evaluate
In-Reply-To: <DA8A7734F2B39240977D7883C732FF9B02D965@kronos.cait.wustl.edu>
References: <DA8A7734F2B39240977D7883C732FF9B02D965@kronos.cait.wustl.edu>
Message-ID: <20031010164907.GC4760@ussenterprise.ufp.org>

In a message written on Fri, Oct 10, 2003 at 09:01:09AM -0500, Bill Darte wrote:
> 2./  Possible Modified 2002-3 Policy
> 2002-3 Micro-Allocations and Assignments for Multihomed Networks
> 
> Multi-homed entities with an ARIN assigned ASN may justify and obtain a
> block of address space with prefix length extending to /22 directly from
> ARIN.  When prefixes are longer than /20, these micro-allocations or
> micro-assignments will be from a reserved block for that purpose.

This would be my choice.  The only thing I would do differently is
removed the first "multi-homed".  That is already a requirement to
get an ASN, so in the current context it's redundant, and although
I think it's very unlikely for the ASN requirements to change in
the future if they do I think those with an ASN should still be
able to get a block, so removing it wouldn't cause an additonal
update to be needed later.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031010/3e2cb358/attachment.sig>

From gregm at datapro.co.za  Mon Oct 13 04:55:16 2003
From: gregm at datapro.co.za (Gregory Massel)
Date: Mon, 13 Oct 2003 10:55:16 +0200
Subject: [ppml] Alternatives to 2002-3 Wording and Scope - Please Eval uate
In-Reply-To: <20031010164907.GC4760@ussenterprise.ufp.org>
References: <20031010164907.GC4760@ussenterprise.ufp.org>
Message-ID: <200310131055.16261.gregm@datapro.co.za>

On Friday 10 October 2003 18:49, Leo Bicknell wrote:
> In a message written on Fri, Oct 10, 2003 at 09:01:09AM -0500, Bill Darte 
wrote:
> > 2./  Possible Modified 2002-3 Policy
> > 2002-3 Micro-Allocations and Assignments for Multihomed Networks
> >
> > Multi-homed entities with an ARIN assigned ASN may justify and obtain a
> > block of address space with prefix length extending to /22 directly from
> > ARIN.  When prefixes are longer than /20, these micro-allocations or
> > micro-assignments will be from a reserved block for that purpose.
>
> This would be my choice.  The only thing I would do differently is
> removed the first "multi-homed".  That is already a requirement to
> get an ASN, so in the current context it's redundant, and although
> I think it's very unlikely for the ASN requirements to change in
> the future if they do I think those with an ASN should still be
> able to get a block, so removing it wouldn't cause an additonal
> update to be needed later.

I think the original wording was pretty good. There requirement for ASN is 
simply a unique routing policy. Eg. If you want to interconnect at an 
exchange / peering point, you need an ASN, but you're not technically 
"multi-homed" because you still only have one transit provider.

I'm a bit concerned about "ARIN assigned ASN." I'm not sure if it's possible, 
but what are the chances of an organisation applying to ARIN for address 
space but having an ASN assigned from elsewhere? Were there historical ASN 
assignments? Maybe ARIN can clarify if this is an issue or not.

-Greg



From william at elan.net  Mon Oct 13 05:18:22 2003
From: william at elan.net (william at elan.net)
Date: Mon, 13 Oct 2003 02:18:22 -0700 (PDT)
Subject: [ppml] Alternatives to 2002-3 Wording and Scope - Please Evaluate
In-Reply-To: <DA8A7734F2B39240977D7883C732FF9B02D965@kronos.cait.wustl.edu>
Message-ID: <Pine.LNX.4.44.0310100746420.31896-100000@sokol.elan.net>


  Requirement for ASN is multihoming or unique routing policy and 
actually multihoming generally applies unique routing policy by default.
So alternatives 3 & 4 (which remove requirement of ASN) do not provide 
anything new, while at the same time removing pre-requirement of ASN and 
company already been working with ARIN and becoming familiar with its 
process and establishing billing account, etc. 
  However we have to recognize that there maybe cases when company has an 
ASN but its not from ARIN but from one of the other RIRs. In this case, 
company should attempt to get space from that RIR first but should not be 
denied going to ARIN.
  Therefore I prose that Alternative 2 be modifed and words "ARIN ASN" be 
replaced with just "ASN":

  2.1  Possible Modified 2002-3 Policy
  2002-3 Micro-Allocations and Assignments for Multihomed Networks
  
  Multi-homed entities which have been assigned an ASN may justify and 
  obtain a block of address space with prefix length extending to /22 
  directly from ARIN.  When prefixes are longer than /20, these 
  micro-allocations ormicro-assignments will be from a reserved block for 
  that purpose.

I also believe it would be usefull (for purposes of keeping routing 
table smaller) to require renumbering when same organization asks for /20 
and prevent the same organization from receiving two /22 micro-assignments.
I propose the following additions

"Organizations may apply for micro-allocations or micro-assignments 
 under this policy only once. Requests for additional assignment and 
 allocations should be done under ARIN's other policies and if larger size 
 allocation or assignment is justified, the micro-allocation or assignment
 must be returned to ARIN within 12 months of receiving new assignment or  
 allocation."

On Fri, 10 Oct 2003, Bill Darte wrote:

> Hello All,
> 
> Following are 4 alternatives to the 2002-3 Micro-Assignments for Multihomed
> Networks policy proposal.
> 
> The first option is the current proposal that has been around awhile.  The 3
> options following are various wordings of an alternative policy proposal
> that trims the wording, but expands the objectives of 2002-3 to inlcude
> micro-allocations as well as micro-assignments down to /22.
> 
> In each case, it is planned to follow the impact of a successful policy
> adoption in this realm to ensure that it doesn't break things on the
> Internet.
> 
> Please review each of these alternatives and register your preference...or
> proposal specific and succinct wording changes where you feel appropriate
> along with a brief explanation your reasoning.
> 
> The results of this exercise and the comments from interaction will be
> presented along with those related to 2002-3 here-to-fore on the ppml at the
> upcoming meeting in Chicago.  I urge each of you to participate fully in
> this exercise and a the upcoming meeting.
> 
> Bill Darte
> ARIN Advisory Council 
> 
> 
> 1./  Original 2002-3 Micro-Assignments for Multihomed Networks
> 
> If an end-user is not multi-homed, the minimum justified block of IP address
> space assigned by ARIN is a /20. If assignments smaller than /20 are needed,
> end-users should contact their upstream provider.
> 
> If an end-user is multi-homed, and has an ARIN assigned ASN, the minimum
> justified block of IP address space assigned by ARIN is a /22. Such
> assignment will be made from a reserve block for this purpose. If
> multi-homed assignments smaller than a /22 are needed, end users should
> contact their upstream provider.
> 
> 
> 2./  Possible Modified 2002-3 Policy
> 2002-3 Micro-Allocations and Assignments for Multihomed Networks
> 
> Multi-homed entities with an ARIN assigned ASN may justify and obtain a
> block of address space with prefix length extending to /22 directly from
> ARIN.  When prefixes are longer than /20, these micro-allocations or
> micro-assignments will be from a reserved block for that purpose.
> 
> 3./  2002-3 Micro-Allocations and Assignments for Multihomed Networks
> (Alternative Wording)
> 
> Multi-homed entities may justify and obtain a block of address space with
> prefix length extending to /22 directly from ARIN.  When prefixes are longer
> than /20, these micro-allocations or micro-assignments will be from a
> reserved block for that purpose.
> 
> 4./  2002-3 Micro-Allocations and Assignments for Multihomed Networks
> (Alternative Wording)
> 
> Multi-homed entities with a unique routing policy may justify and obtain a
> block of address space with prefix length extending to /22 directly from
> ARIN.  When prefixes are longer than /20, these micro-allocations or
> micro-assignments will be from a reserved block for that purpose.
> 
> Thanks,
> 
> Bill Darte
> CAIT Senior Technical Associate
> 314 935-7575 





From jmcburnett at msmgmt.com  Mon Oct 13 08:06:25 2003
From: jmcburnett at msmgmt.com (McBurnett, Jim)
Date: Mon, 13 Oct 2003 08:06:25 -0400
Subject: [ppml] Alternatives to 2002-3 Wording and Scope - Please Evaluate
Message-ID: <9BF6F06C4BC90746ADD6806746492A3349B0@msmmail01.msmgmt.com>


I am not sure this will necessarily be an effective change for its
stated purpose.
In cases I have seen, 2 blocks could mean same company 
different areas, regions etc.
A company I worked with had a /16. But they announced it
as /20's all from different areas, different business models, different
providers.
Granted they were pre-ARIN assignments.
I don't think routing table size is an issue that will can be
covered with this.  Once a user gets that /20 they could annouce it
any way they want. So,IMHO, an assignment/allocation policy will not affect
the routing table or how they annouce. Take the issue with a 
LARGE LEC in the South that just deaggregated a about 1100 /24s and
annoucing them all as seperate /24s. 

Jim


> I also believe it would be usefull (for purposes of keeping routing 
> table smaller) to require renumbering when same organization 
> asks for /20 
> and prevent the same organization from receiving two /22 
> micro-assignments.
> I propose the following additions
 


From bicknell at ufp.org  Mon Oct 13 08:37:11 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 13 Oct 2003 08:37:11 -0400
Subject: [ppml] Alternatives to 2002-3 Wording and Scope - Please Eval uate
In-Reply-To: <200310131055.16261.gregm@datapro.co.za>
References: <20031010164907.GC4760@ussenterprise.ufp.org> <200310131055.16261.gregm@datapro.co.za>
Message-ID: <20031013123711.GA41070@ussenterprise.ufp.org>

In a message written on Mon, Oct 13, 2003 at 10:55:16AM +0200, Gregory Massel wrote:
> I think the original wording was pretty good. There requirement for ASN is 
> simply a unique routing policy. Eg. If you want to interconnect at an 
> exchange / peering point, you need an ASN, but you're not technically 
> "multi-homed" because you still only have one transit provider.

I can live with the original wording.  My though was this might
help usclean up more "mess" and unify it under one general rule.
For example, exchange points have a special micro-assignment policy
today.  Since the ASN policy makes exceptions for them, if we just
go with "have an ASN" they would be covered (up to /24).

More to the point, I can't think of a single case where it would
make sense to give an entity an ASN and not IP space.  An ASN without
IP space is useless, and I find poking holes in upstream blocks
much less preferred to just giving them a /24.

> I'm a bit concerned about "ARIN assigned ASN." I'm not sure if it's possible, 
> but what are the chances of an organization applying to ARIN for address 
> space but having an ASN assigned from elsewhere? Were there historical ASN 
> assignments? Maybe ARIN can clarify if this is an issue or not.

Excellent point.  I never thought about it, but "ARIN assigned ASN"
to me really means "ARIN managed ASN", eg, all the legacy stuff as
well.  My point was simply that the IP space should be obtained
from the same place as the ASN...if we're going to make having an
ASN be a pre-requirement we should make sure we know the requirements
of the assigning entity.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031013/176861b1/attachment.sig>

From woody at pch.net  Mon Oct 13 10:46:13 2003
From: woody at pch.net (Bill Woodcock)
Date: Mon, 13 Oct 2003 07:46:13 -0700 (PDT)
Subject: [ppml] Alternatives to 2002-3 Wording and Scope - Please Eval
 uate
In-Reply-To: <200310131055.16261.gregm@datapro.co.za>
Message-ID: <Pine.GSO.4.44.0310130744300.17628-100000@paixhost.pch.net>

      On Mon, 13 Oct 2003, Gregory Massel wrote:
    > I'm a bit concerned about "ARIN assigned ASN." I'm not sure if it's possible,
    > but what are the chances of an organisation applying to ARIN for address
    > space but having an ASN assigned from elsewhere? Were there historical ASN
    > assignments?

Yes, many ASNs were assigned prior to ARIN's formation, and many ARIN
address recipients utilize ASNs which were assigned in their primary
regions by RIPE or APNIC.  So you're correct that "ARIN assigned ASN" is a
poor choice of words.

                                -Bill




From memsvcs at arin.net  Tue Oct 14 16:28:27 2003
From: memsvcs at arin.net (Member Services)
Date: Tue, 14 Oct 2003 16:28:27 -0400 (EDT)
Subject: [ppml] Implications on Policy Proposal 2002-2
Message-ID: <200310142028.QAA17887@ops.arin.net>

The following Internet Draft has been published and may 
have implications on Policy Proposal 2002-2 (Experimental 
Internet Resource Allocations), depending on the outcome 
of its review through the IETF processes.

http://www.ietf.org/internet-drafts/draft-narten-iana-experimental-allocations-04.txt

Member Services
American Registry for Internet Numbers (ARIN)



From bicknell at ufp.org  Fri Oct 17 19:12:58 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 17 Oct 2003 19:12:58 -0400
Subject: [ppml] Proposal Summary?
Message-ID: <20031017231258.GA89739@ussenterprise.ufp.org>


I just went to the ARIN web site to print out copies of all the
policies so I could carry them on paper for the next week.  Who
knows when you'll be away from wireless.

That said, I realized there is no "printer friendly" version, and
indeed no summary for the upcoming meeting (or I'm not looking in
the right place).  I'm thinking it would be useful to have each
proposal, text only, and then with it the contact info of the
author(s), and any relivant minutes from previous AC meetings.  Putting
them all in one PDF before a meeting seems like it might be useful
to quite a few people.

Would anyone else like to see something similar?  Is it worth some
effort?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031017/e1916e46/attachment.sig>

From william at elan.net  Fri Oct 17 17:00:53 2003
From: william at elan.net (william at elan.net)
Date: Fri, 17 Oct 2003 14:00:53 -0700 (PDT)
Subject: [ppml] Proposal Summary?
In-Reply-To: <20031017231258.GA89739@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.44.0310171358550.3714-100000@sokol.elan.net>

ARIN did it on their own last meeting and presented everybody with printed 
text for every proposal. This was all very good, except after doing so 
they claimed it was not necessary to put proposal up on the main screen.

On Fri, 17 Oct 2003, Leo Bicknell wrote:

> 
> I just went to the ARIN web site to print out copies of all the
> policies so I could carry them on paper for the next week.  Who
> knows when you'll be away from wireless.
> 
> That said, I realized there is no "printer friendly" version, and
> indeed no summary for the upcoming meeting (or I'm not looking in
> the right place).  I'm thinking it would be useful to have each
> proposal, text only, and then with it the contact info of the
> author(s), and any relivant minutes from previous AC meetings.  Putting
> them all in one PDF before a meeting seems like it might be useful
> to quite a few people.
> 
> Would anyone else like to see something similar?  Is it worth some
> effort?
> 



From plzak at arin.net  Fri Oct 17 22:37:10 2003
From: plzak at arin.net (Ray Plzak)
Date: Fri, 17 Oct 2003 22:37:10 -0400
Subject: [ppml] Proposal Summary?
In-Reply-To: <Pine.LNX.4.44.0310171358550.3714-100000@sokol.elan.net>
Message-ID: <009701c39520$bbe8e3c0$198888c0@arin.net>


Hard copy of all policy proposals will be included in the meeting packet
that each registered attendee receives.  The text will be placed on the
main screen during the presentation of the proposal.

Ray


> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of william at elan.net
> Sent: Friday, October 17, 2003 5:01 PM
> To: Leo Bicknell
> Cc: ppml at arin.net
> Subject: Re: [ppml] Proposal Summary?
> 
> 
> ARIN did it on their own last meeting and presented everybody 
> with printed 
> text for every proposal. This was all very good, except after 
> doing so 
> they claimed it was not necessary to put proposal up on the 
> main screen.
> 
> On Fri, 17 Oct 2003, Leo Bicknell wrote:
> 
> > 
> > I just went to the ARIN web site to print out copies of all the
> > policies so I could carry them on paper for the next week.  Who
> > knows when you'll be away from wireless.
> > 
> > That said, I realized there is no "printer friendly" version, and
> > indeed no summary for the upcoming meeting (or I'm not looking in
> > the right place).  I'm thinking it would be useful to have each
> > proposal, text only, and then with it the contact info of the
> > author(s), and any relivant minutes from previous AC 
> meetings.  Putting
> > them all in one PDF before a meeting seems like it might be useful
> > to quite a few people.
> > 
> > Would anyone else like to see something similar?  Is it worth some
> > effort?
> > 
> 



From bicknell at ufp.org  Fri Oct 17 23:09:53 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 17 Oct 2003 23:09:53 -0400
Subject: [ppml] Proposal Summary?
In-Reply-To: <009701c39520$bbe8e3c0$198888c0@arin.net>
References: <Pine.LNX.4.44.0310171358550.3714-100000@sokol.elan.net> <009701c39520$bbe8e3c0$198888c0@arin.net>
Message-ID: <20031018030953.GA3696@ussenterprise.ufp.org>

In a message written on Fri, Oct 17, 2003 at 10:37:10PM -0400, Ray Plzak wrote:
> Hard copy of all policy proposals will be included in the meeting packet
> that each registered attendee receives.  The text will be placed on the
> main screen during the presentation of the proposal.

Very cool.  Any chance the material in the packet could also be a PDF
on the web site?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031017/0a7f636b/attachment.sig>

From plzak at arin.net  Sat Oct 18 08:43:48 2003
From: plzak at arin.net (Ray Plzak)
Date: Sat, 18 Oct 2003 08:43:48 -0400
Subject: [ppml] Proposal Summary?
In-Reply-To: <20031018030953.GA3696@ussenterprise.ufp.org>
Message-ID: <002601c39575$7ae62040$6e8888c0@arin.net>

Leo,

Good point. Don't know if we can get them all converted and uploaded
prior to the meeting.  If we can, we can.  If not we will do it for the
next meeting.

Ray

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of Leo Bicknell
> Sent: Friday, October 17, 2003 11:10 PM
> To: ppml at arin.net
> Subject: Re: [ppml] Proposal Summary?
> 
> 
> In a message written on Fri, Oct 17, 2003 at 10:37:10PM 
> -0400, Ray Plzak wrote:
> > Hard copy of all policy proposals will be included in the 
> meeting packet
> > that each registered attendee receives.  The text will be 
> placed on the
> > main screen during the presentation of the proposal.
> 
> Very cool.  Any chance the material in the packet could also be a PDF
> on the web site?
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> 



From memsvcs at arin.net  Sun Oct 19 23:00:07 2003
From: memsvcs at arin.net (Member Services)
Date: Sun, 19 Oct 2003 23:00:07 -0400 (EDT)
Subject: [ppml] PDF Version of Policy Proposals
Message-ID: <200310200300.XAA19876@ops.arin.net>

PDF versions of the active policy proposals and mailing 
list discussion summaries have been added to the ARIN 
web site.  A link to the PDF file is located at the top 
of the dedicated page for each active policy proposal.  
The list of active policy proposals is available at the 
following location.

    http://www.arin.net/policy/proposal_archive.html

This information has been added to the ARIN web site in 
PDF format in response to general requests from the ARIN 
policy community.

Member Services
American Registry for Internet Numbers (ARIN)



From william at elan.net  Wed Oct 22 11:16:07 2003
From: william at elan.net (william at elan.net)
Date: Wed, 22 Oct 2003 08:16:07 -0700 (PDT)
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also passes
Message-ID: <Pine.LNX.4.44.0310220811310.17869-100000@sokol.elan.net>

 For those of you who are not attending ARIN, you might be interested to 
know that 2002-3 passed with about half of the attendies voting for it and 
only very few against. The policy presented to the meeting included both 
micro-assignments and micro-allocations!
 I'd like to express my personal thanks for the work done to AC and 
particularly to Bill Darte for bringing this issue along to this point.

Also for Africans here, policy 2003-15 also passed which means AC will 
have to most likely either integrate these policies together or remove 
portions of text from 2003-15 which are covered by 2002-3.

-- 
William Leibzon
Elan Networks
william at elan.net



From ahp at hilander.com  Wed Oct 22 14:00:28 2003
From: ahp at hilander.com (Alec H. Peterson)
Date: Wed, 22 Oct 2003 12:00:28 -0600
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also
 passes
In-Reply-To: <Pine.LNX.4.44.0310220811310.17869-100000@sokol.elan.net>
References: <Pine.LNX.4.44.0310220811310.17869-100000@sokol.elan.net>
Message-ID: <2147483647.1066824028@eth-0-30-65-14-8d-1d.dhcp.nanog29.merit.net>

To clarify, what William is talking about is only one part of the policy 
process (ie, consensus at the public policy meeting).  The AC and BoT will 
take that input into consideration when they review the policies.

Alec
Chair, ARIN AC

--On Wednesday, October 22, 2003 8:16 -0700 william at elan.net wrote:

>  For those of you who are not attending ARIN, you might be interested to
> know that 2002-3 passed with about half of the attendies voting for it
> and  only very few against. The policy presented to the meeting included
> both  micro-assignments and micro-allocations!
>  I'd like to express my personal thanks for the work done to AC and
> particularly to Bill Darte for bringing this issue along to this point.
>
> Also for Africans here, policy 2003-15 also passed which means AC will
> have to most likely either integrate these policies together or remove
> portions of text from 2003-15 which are covered by 2002-3.
>
> --
> William Leibzon
> Elan Networks
> william at elan.net
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pkcs7-signature
Size: 3105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031022/03429397/attachment.p7s>

From billd at cait.wustl.edu  Wed Oct 22 14:14:02 2003
From: billd at cait.wustl.edu (Bill Darte)
Date: Wed, 22 Oct 2003 13:14:02 -0500
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also p
	asses
Message-ID: <DA8A7734F2B39240977D7883C732FF9B02D9A9@kronos.cait.wustl.edu>

William, All,

Just a small point of explanation related to this announcement.  I believe
it is more appropriate to express that their was a wide margin of support
expressed for each of these policy proposals.  'Passed' suggests that the
process of proposal evaluation is over and that the proposals 'as presented
and voted on' will become policy.

There remains the AC review of the meeting input and then, given that no
substantive changes are made, the proposal(s) would be forwarded to the ppml
for a 10 day review.  Following that, the proposal and all ppml discussion
would again be reviewed by the AC and again, given no major changes, the AC
would recommend affirmative policy action to the Board.  Given no major
problems during Board review, then the proposal(s) would become policy.

This may seem excessive, but represents the current, open, transparent and
rigorous, policy proposal process.

FYI...

Bill Darte
ARIN AC

-----Original Message-----
From: william at elan.net
To: ppml at arin.net
Sent: 10/22/03 10:16 AM
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also passes

 For those of you who are not attending ARIN, you might be interested to

know that 2002-3 passed with about half of the attendies voting for it
and 
only very few against. The policy presented to the meeting included both

micro-assignments and micro-allocations!
 I'd like to express my personal thanks for the work done to AC and 
particularly to Bill Darte for bringing this issue along to this point.

Also for Africans here, policy 2003-15 also passed which means AC will 
have to most likely either integrate these policies together or remove 
portions of text from 2003-15 which are covered by 2002-3.

-- 
William Leibzon
Elan Networks
william at elan.net


From Trevor.Paquette at TeraGo.ca  Thu Oct 23 15:14:05 2003
From: Trevor.Paquette at TeraGo.ca (Trevor Paquette)
Date: Thu, 23 Oct 2003 13:14:05 -0600
Subject: [ppml] Quick comment on the Meetings..
Message-ID: <000601c39999$d445b510$2a45fea9@teraint.net>

LOVE the live video feed!

Just missing a way for viewers to post questions/comments (IM?).

Trev
--

Trevor Paquette
Lead Systems Architect
TeraGo Networks Inc.
Suite 300, 300 Manning Road N.E.
Calgary, Alberta, Canada T2E 8K4
Phone:(403)668-5321 Mobile:(403)703-8738 Fax:(403)668-5344
www.terago.ca




From billd at cait.wustl.edu  Wed Oct 22 14:14:02 2003
From: billd at cait.wustl.edu (Bill Darte)
Date: Wed, 22 Oct 2003 13:14:02 -0500
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also p
	asses
Message-ID: <DA8A7734F2B39240977D7883C732FF9B02D9A9@kronos.cait.wustl.edu>

William, All,

Just a small point of explanation related to this announcement.  I believe
it is more appropriate to express that their was a wide margin of support
expressed for each of these policy proposals.  'Passed' suggests that the
process of proposal evaluation is over and that the proposals 'as presented
and voted on' will become policy.

There remains the AC review of the meeting input and then, given that no
substantive changes are made, the proposal(s) would be forwarded to the ppml
for a 10 day review.  Following that, the proposal and all ppml discussion
would again be reviewed by the AC and again, given no major changes, the AC
would recommend affirmative policy action to the Board.  Given no major
problems during Board review, then the proposal(s) would become policy.

This may seem excessive, but represents the current, open, transparent and
rigorous, policy proposal process.

FYI...

Bill Darte
ARIN AC

-----Original Message-----
From: william at elan.net
To: ppml at arin.net
Sent: 10/22/03 10:16 AM
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also passes

 For those of you who are not attending ARIN, you might be interested to

know that 2002-3 passed with about half of the attendies voting for it
and 
only very few against. The policy presented to the meeting included both

micro-assignments and micro-allocations!
 I'd like to express my personal thanks for the work done to AC and 
particularly to Bill Darte for bringing this issue along to this point.

Also for Africans here, policy 2003-15 also passed which means AC will 
have to most likely either integrate these policies together or remove 
portions of text from 2003-15 which are covered by 2002-3.

-- 
William Leibzon
Elan Networks
william at elan.net


From louie at equinix.com  Thu Oct 23 15:15:10 2003
From: louie at equinix.com (Louis Lee)
Date: Thu, 23 Oct 2003 12:15:10 -0700
Subject: [ppml] last chance (was: [arin-announce] Policy Proposal 2003-4: IPv6 Policy Changes)
Message-ID: <20031023191509.GA10657@nemo.corp.equinix.com>

We're talking about this policy change at the public policy
meeting today, and we've noted that there hasn't been any
additional comments for about 6 months.  It looks like the
AC is about to act on this proposal.  If you have any new
comments, or if anyone has a change in their view of this
proposal, *please* make them known quickly.

Louie
-------------------------------------------------------
Louis Lee                             louie at equinix.com
Staff Network Engineer            company: 650/513-7000
Equinix, Inc.                        desk: 650/513-7162
http://www.equinix.com/               fax: 650/513-7903

----- Forwarded message from Member Services <memsvcs at arin.net> -----

From: Member Services <memsvcs at arin.net>
Subject: [arin-announce] Policy Proposal 2003-4: IPv6 Policy Changes
Date: Wed, 5 Mar 2003 08:54:51 -0500 (EST)
To: arin-announce at arin.net, ppml at arin.net

ARIN welcomes feedback and discussion about the following policy 
proposal in the weeks leading to the ARIN Public Policy Meeting 
in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback 
received on the mailing list about this policy proposal will be 
included in the discussions that will take place at the upcoming 
Public Policy Meeting. 

This policy proposal discussion will take place on the ARIN Public 
Policy Mailing List (ppml at arin.net). Subscription information is 
available at http://www.arin.net/mailing_lists/index.html 

Richard Jimmerson 
Director of Operations 
American Registry for Internet Numbers (ARIN) 

### * ### 

Policy Proposal 2003-4: IPv6 Policy Changes

The current IPv6 policies are described in the IPv6 Address Allocation 
and Assignment Policy document.

   http://www.arin.net/policy/ipv6_policy.html

It is proposed the IPv6 policy document be updated to include the 
following language and that the changed document be adopted as policy.

5.1.1
	[under d) add:

	Other organizations are defined as any customer of the LIR.
	No distinction will be made in terms of number of IP addresses
	required, even if that number is one.

5.8 Allocation for Early Adopters

5.8.1 Waiver of criteria listed in 5.1.1 (d)

	To promote the allocation of IPv6 space the requirement to make 200
	/48 assignments within two years shall be waived for anyone
	requesting IPv6 space before Dec 31, 2004 or until this policy
	is amended.  In the event that this policy is amended the
	existing IPv6 space holders shall not be subject to new or
	waived criteria for a period of 10 years from their initial
	allocation date.

5.8.2 Waiver of fees

	a) To promote the allocation of IPv6 space all IPv6 related fees
	shall be waived until Dec 31, 2006 for anyone requesting and
	receiving space before Dec 31, 2004.  In the even that this
	policy is amended the existing IPv6 space holders shall
	under no circumstances be subject to waived or new fees until
	Dec 31, 2006.

	b) For billing purposes fees will be due according to normal
	ARIN billing policies on Jan 1, 2007.  All early adopters
	will have the same billing date regardless of the date
	they received their allocation.

5.8.3 Micro Allocations

	a) To promote the allocation and deployment of IPv6 all the
	criteria in 5.1.1 shall be waived to those requesting a /48
	micro allocation before Dec 31, 2004, or until this policy
	is changed.  If this policy is changed, current space holders
	shall not be subject to any new or waived criteria.

	b) All fees shall be waived under the same rules listed in
	5.8.2.

	c) Those receiving micro allocations shall not be allowed to
	make further allocations or assignments out of their /48.  It
	is intended for their internal use only.

	d) When possible those receiving micro allocations shall
	return their allocation and receive a new /48 from their
	upstream provider (a LIR).  This is requested in a good faith
	manner until Jan 1, 2007 at which time all micro allocations
	granted under these waived criteria must be returned.


----- End forwarded message -----


From ahp at hilander.com  Wed Oct 22 14:00:28 2003
From: ahp at hilander.com (Alec H. Peterson)
Date: Wed, 22 Oct 2003 12:00:28 -0600
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also
 passes
In-Reply-To: <Pine.LNX.4.44.0310220811310.17869-100000@sokol.elan.net>
References: <Pine.LNX.4.44.0310220811310.17869-100000@sokol.elan.net>
Message-ID: <2147483647.1066824028@eth-0-30-65-14-8d-1d.dhcp.nanog29.merit.net>

To clarify, what William is talking about is only one part of the policy 
process (ie, consensus at the public policy meeting).  The AC and BoT will 
take that input into consideration when they review the policies.

Alec
Chair, ARIN AC

--On Wednesday, October 22, 2003 8:16 -0700 william at elan.net wrote:

>  For those of you who are not attending ARIN, you might be interested to
> know that 2002-3 passed with about half of the attendies voting for it
> and  only very few against. The policy presented to the meeting included
> both  micro-assignments and micro-allocations!
>  I'd like to express my personal thanks for the work done to AC and
> particularly to Bill Darte for bringing this issue along to this point.
>
> Also for Africans here, policy 2003-15 also passed which means AC will
> have to most likely either integrate these policies together or remove
> portions of text from 2003-15 which are covered by 2002-3.
>
> --
> William Leibzon
> Elan Networks
> william at elan.net
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pkcs7-signature
Size: 3105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031022/03429397/attachment-0001.p7s>

From billd at cait.wustl.edu  Wed Oct 22 14:14:02 2003
From: billd at cait.wustl.edu (Bill Darte)
Date: Wed, 22 Oct 2003 13:14:02 -0500
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also p
	asses
Message-ID: <DA8A7734F2B39240977D7883C732FF9B02D9A9@kronos.cait.wustl.edu>

William, All,

Just a small point of explanation related to this announcement.  I believe
it is more appropriate to express that their was a wide margin of support
expressed for each of these policy proposals.  'Passed' suggests that the
process of proposal evaluation is over and that the proposals 'as presented
and voted on' will become policy.

There remains the AC review of the meeting input and then, given that no
substantive changes are made, the proposal(s) would be forwarded to the ppml
for a 10 day review.  Following that, the proposal and all ppml discussion
would again be reviewed by the AC and again, given no major changes, the AC
would recommend affirmative policy action to the Board.  Given no major
problems during Board review, then the proposal(s) would become policy.

This may seem excessive, but represents the current, open, transparent and
rigorous, policy proposal process.

FYI...

Bill Darte
ARIN AC

-----Original Message-----
From: william at elan.net
To: ppml at arin.net
Sent: 10/22/03 10:16 AM
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also passes

 For those of you who are not attending ARIN, you might be interested to

know that 2002-3 passed with about half of the attendies voting for it
and 
only very few against. The policy presented to the meeting included both

micro-assignments and micro-allocations!
 I'd like to express my personal thanks for the work done to AC and 
particularly to Bill Darte for bringing this issue along to this point.

Also for Africans here, policy 2003-15 also passed which means AC will 
have to most likely either integrate these policies together or remove 
portions of text from 2003-15 which are covered by 2002-3.

-- 
William Leibzon
Elan Networks
william at elan.net


From ahp at hilander.com  Wed Oct 22 14:00:28 2003
From: ahp at hilander.com (Alec H. Peterson)
Date: Wed, 22 Oct 2003 12:00:28 -0600
Subject: [ppml] 2002-3 passes including suballocations; 2003-15 also
 passes
In-Reply-To: <Pine.LNX.4.44.0310220811310.17869-100000@sokol.elan.net>
References: <Pine.LNX.4.44.0310220811310.17869-100000@sokol.elan.net>
Message-ID: <2147483647.1066824028@eth-0-30-65-14-8d-1d.dhcp.nanog29.merit.net>

To clarify, what William is talking about is only one part of the policy 
process (ie, consensus at the public policy meeting).  The AC and BoT will 
take that input into consideration when they review the policies.

Alec
Chair, ARIN AC

--On Wednesday, October 22, 2003 8:16 -0700 william at elan.net wrote:

>  For those of you who are not attending ARIN, you might be interested to
> know that 2002-3 passed with about half of the attendies voting for it
> and  only very few against. The policy presented to the meeting included
> both  micro-assignments and micro-allocations!
>  I'd like to express my personal thanks for the work done to AC and
> particularly to Bill Darte for bringing this issue along to this point.
>
> Also for Africans here, policy 2003-15 also passed which means AC will
> have to most likely either integrate these policies together or remove
> portions of text from 2003-15 which are covered by 2002-3.
>
> --
> William Leibzon
> Elan Networks
> william at elan.net
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pkcs7-signature
Size: 3105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031022/03429397/attachment-0002.p7s>

From jlturner at gblx.net  Thu Oct 23 15:33:25 2003
From: jlturner at gblx.net (Jennifer Turner)
Date: Thu, 23 Oct 2003 12:33:25 -0700 (MST)
Subject: [ppml] Quick comment on the Meetings..
In-Reply-To: <000601c39999$d445b510$2a45fea9@teraint.net>
References: <000601c39999$d445b510$2a45fea9@teraint.net>
Message-ID: <Pine.GSO.4.58.0310231226270.969@shell1.phx.gblx.net>

I second this sentiment.
The live feed has been extremely well executed and makes a remote member
feel like they are still an informed and valuable member of the meeting.
A way to post comments and to vote on the policies at hand (come on - I
know at least one of you out there has a "raise your hand" GUI collecting
dust on the shelf ;) would be a wonderful addition for the next meeting.

- Jenn

On Thu, 23 Oct 2003, Trevor Paquette wrote:

> LOVE the live video feed!
>
> Just missing a way for viewers to post questions/comments (IM?).
>
> Trev
> --
>
> Trevor Paquette
> Lead Systems Architect
> TeraGo Networks Inc.
> Suite 300, 300 Manning Road N.E.
> Calgary, Alberta, Canada T2E 8K4
> Phone:(403)668-5321 Mobile:(403)703-8738 Fax:(403)668-5344
> www.terago.ca
>
>


------------------------------------------------------------------------------
Jennifer Turner
Sr. Access Engineer/ARIN IPADMIN
GlobalCrossing, Inc.
jlturner at gblx.net
800-927-5225 PHONE
-------------------------------------------------------------------------------



From jcurran at istaff.org  Thu Oct 23 15:56:55 2003
From: jcurran at istaff.org (John Curran)
Date: Thu, 23 Oct 2003 14:56:55 -0500
Subject: [ppml] Quick comment on the Meetings..
In-Reply-To: <Pine.GSO.4.58.0310231226270.969@shell1.phx.gblx.net>
References: <000601c39999$d445b510$2a45fea9@teraint.net>
 <Pine.GSO.4.58.0310231226270.969@shell1.phx.gblx.net>
Message-ID: <p06001f08bbbde20cc1f8@[192.35.167.105]>

Jennifer, Trevor:
 
  Thanks for the suggestions...   there's some challenges in managing remote
  interaction but it will definitely get some discussion with the staff and board.

Thanks again!
/John
Chair, ARIN

At 12:33 PM -0700 10/23/03, Jennifer Turner wrote:
>I second this sentiment.
>The live feed has been extremely well executed and makes a remote member
>feel like they are still an informed and valuable member of the meeting.
>A way to post comments and to vote on the policies at hand (come on - I
>know at least one of you out there has a "raise your hand" GUI collecting
>dust on the shelf ;) would be a wonderful addition for the next meeting.
>
>- Jenn
>
>On Thu, 23 Oct 2003, Trevor Paquette wrote:
>
>> LOVE the live video feed!
>>
>> Just missing a way for viewers to post questions/comments (IM?).
>>
>> Trev
>> --
>>
>> Trevor Paquette
>> Lead Systems Architect
>> TeraGo Networks Inc.
>> Suite 300, 300 Manning Road N.E.
>> Calgary, Alberta, Canada T2E 8K4
>> Phone:(403)668-5321 Mobile:(403)703-8738 Fax:(403)668-5344
>> www.terago.ca
>>
>>
>
>
>------------------------------------------------------------------------------
>Jennifer Turner
>Sr. Access Engineer/ARIN IPADMIN
>GlobalCrossing, Inc.
>jlturner at gblx.net
>800-927-5225 PHONE
>-------------------------------------------------------------------------------



From Rob.Vinson at networktelephone.net  Thu Oct 23 16:06:15 2003
From: Rob.Vinson at networktelephone.net (Rob Vinson)
Date: Thu, 23 Oct 2003 15:06:15 -0500
Subject: [ppml] introduction 
Message-ID: <F57026A9F900D411999000D0B73C4DF606F4EC09@pflnoczr.corp.com>

Hello, 

I just wanted to introduce myself to the group. I work for a regional
facilities based CLEC in the southeast as the current IP Admin (amongst
other things). I currently manage a cumulative /17 (multiple /20 direct
allocations from ARIN) and look forward to the dialogue presented on this
list. The web cast of ARIN XII has been excellent & I look forward to
meeting many of you in person the next go around. 

Best Regards, 

___________________________________________
 
Rob Vinson >>>  
Network Design IP Engineer
rob.vinson at networktelephone.net
888.432.4855 x1753


From owen at delong.com  Thu Oct 23 17:00:32 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Oct 2003 14:00:32 -0700
Subject: [ppml] Quick comment on the Meetings..
In-Reply-To: <000601c39999$d445b510$2a45fea9@teraint.net>
References: <000601c39999$d445b510$2a45fea9@teraint.net>
Message-ID: <18770000.1066942832@odlaptop>

Send me your question, I'll try to get it to the mic.

Owen


--On Thursday, October 23, 2003 01:14:05 PM -0600 Trevor Paquette <Trevor.Paquette at terago.ca> wrote:

> LOVE the live video feed!
>
> Just missing a way for viewers to post questions/comments (IM?).
>
> Trev
> --
>
> Trevor Paquette
> Lead Systems Architect
> TeraGo Networks Inc.
> Suite 300, 300 Manning Road N.E.
> Calgary, Alberta, Canada T2E 8K4
> Phone:(403)668-5321 Mobile:(403)703-8738 Fax:(403)668-5344
> www.terago.ca
>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/00ee01b3/attachment.sig>

From bmanning at karoshi.com  Thu Oct 23 17:16:34 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 14:16:34 -0700 (PDT)
Subject: [ppml] allocate/assign
Message-ID: <200310232116.h9NLGYp07071@karoshi.com>


Ok...

	grousing about terms leads me to put my personal thoughts to
	phosphor (or LCD analog):

allocated:  Internet resources earmarked for specific use. period.
assigned:   an allocation is bound to a duely vetted party who agrees
	    to manage the allocation according to the "principles of
	    stewardship" (from the ARIN mission stmt)

	such an assignment is considered delegated when such allocations 
	and assignments are published - say via whois and DNS, perhaps 
	in an rdb.

	thoughts?
--bill


From owen at delong.com  Thu Oct 23 17:20:29 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Oct 2003 14:20:29 -0700
Subject: [ppml] allocate/assign
In-Reply-To: <200310232116.h9NLGYp07071@karoshi.com>
References: <200310232116.h9NLGYp07071@karoshi.com>
Message-ID: <40280000.1066944029@odlaptop>

Does that mean that our legacy space is not assigned?

Owen


--On Thursday, October 23, 2003 02:16:34 PM -0700 bmanning at karoshi.com wrote:

>
> Ok...
>
> 	grousing about terms leads me to put my personal thoughts to
> 	phosphor (or LCD analog):
>
> allocated:  Internet resources earmarked for specific use. period.
> assigned:   an allocation is bound to a duely vetted party who agrees
> 	    to manage the allocation according to the "principles of
> 	    stewardship" (from the ARIN mission stmt)
>
> 	such an assignment is considered delegated when such allocations
> 	and assignments are published - say via whois and DNS, perhaps
> 	in an rdb.
>
> 	thoughts?
> --bill



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/58a70cc8/attachment.sig>

From bmanning at karoshi.com  Thu Oct 23 17:24:46 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 14:24:46 -0700 (PDT)
Subject: [ppml] allocate/assign
In-Reply-To: <40280000.1066944029@odlaptop> from "Owen DeLong" at Oct 23, 2003 02:20:29 PM
Message-ID: <200310232124.h9NLOkx07163@karoshi.com>

> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
> 
> Does that mean that our legacy space is not assigned?
> 
> Owen
> 
> 
> --On Thursday, October 23, 2003 02:16:34 PM -0700 bmanning at karoshi.com wrote:
> 
> >
> > Ok...
> >
> > 	grousing about terms leads me to put my personal thoughts to
> > 	phosphor (or LCD analog):
> >
> > allocated:  Internet resources earmarked for specific use. period.
> > assigned:   an allocation is bound to a duely vetted party who agrees
> > 	    to manage the allocation according to the "principles of
> > 	    stewardship" (from the ARIN mission stmt)
> >
> > 	such an assignment is considered delegated when such allocations
> > 	and assignments are published - say via whois and DNS, perhaps
> > 	in an rdb.
> >
> > 	thoughts?
> > --bill
> 
> 
> 
> 
> --==========1393890028==========
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQE/mEYdn5zKWQ/iqj0RAu16AJ9G93k3mjccpx9742RYyhvrJLrp6QCgkmQy
> ctYbukP1bRCQB2TUa0UjwwI=
> =l/xA
> -----END PGP SIGNATURE-----
> 
> --==========1393890028==========--
> 

	the quote is from the ARIN mission statement.
	again, these are my -PERSONAL- thoughts.
-- bill


From cjw at groovy.com  Thu Oct 23 17:32:33 2003
From: cjw at groovy.com (CJ Wittbrodt)
Date: Thu, 23 Oct 2003 14:32:33 -0700
Subject: [ppml] allocate/assign 
In-Reply-To: Message from bmanning@karoshi.com 
   of "Thu, 23 Oct 2003 14:16:34 PDT." <200310232116.h9NLGYp07071@karoshi.com> 
Message-ID: <200310232132.h9NLWXs48966@duchess.groovy.com>


Bill,

Allocations can be broken up into assignments and given to customers,
but assignments can not be further delegated to other organizations, 
or customers.  

----CJ

    From: bmanning at karoshi.com
    Subject: [ppml] allocate/assign
    
    Ok...
    
    	grousing about terms leads me to put my personal thoughts to
    	phosphor (or LCD analog):
    
    allocated:  Internet resources earmarked for specific use. period.
    assigned:   an allocation is bound to a duely vetted party who agrees
    	    to manage the allocation according to the "principles of
    	    stewardship" (from the ARIN mission stmt)
    
    	such an assignment is considered delegated when such allocations 
    	and assignments are published - say via whois and DNS, perhaps 
    	in an rdb.
    
    	thoughts?
    --bill


From louie at equinix.com  Thu Oct 23 17:33:54 2003
From: louie at equinix.com (Louis Lee)
Date: Thu, 23 Oct 2003 14:33:54 -0700
Subject: [ppml] Policy Proposal 2003-10: Apply the HD Ratio to All Future IPv4 Allocations
In-Reply-To: <OF2840D456.961299BC-ON80256DA3.0052C7FB-80256DA3.0053F45D@radianz.com>
References: <OF2840D456.961299BC-ON80256DA3.0052C7FB-80256DA3.0053F45D@radianz.com>
Message-ID: <20031023213353.GB23951@nemo.corp.equinix.com>

On Tue, Sep 16, 2003 at 04:17:00PM +0100, Michael.Dillon at radianz.com wrote:
> > Is there a good reason to abandon the relatively simple
> > 80% rule in favor of a mathematically more complicated
> > formula that effectively drops the % utilization rules
> > by a noticable amount?
>
> Yes. Most of this is explained in RFC 3194 and in the
> APNIC paper whose URL was incorrectly given in the
> original posting of my justification of the policy.

I would suggest that we do not abandon the original 80%
rule completely.  Perhaps the policy can start off with:

  If an organization requesting an IPv4 allocation cannot
  meet the utilization rate stated in the primary criteria
  that ARIN uses, than the HD ratio may be applied to
  determine adequate utilization for approval of the
  request.

I don't want to explicitly state the 80% figure and how
it's applied to the most recent allocation or all previous
allocations.  This way, the policy is a little more
flexible to allow a change of the 80% figure elsewhere.

(I've got another thought on this issue that I'm sure I'll
remember just after sending this message. :)

Louie
-------------------------------------------------------
Louis Lee                             louie at equinix.com
Staff Network Engineer            company: 650/513-7000
Equinix, Inc.                        desk: 650/513-7162
http://www.equinix.com/               fax: 650/513-7903


From bmanning at karoshi.com  Thu Oct 23 17:39:03 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 14:39:03 -0700 (PDT)
Subject: [ppml] allocate/assign
In-Reply-To: <200310232132.h9NLWXs48966@duchess.groovy.com> from "CJ Wittbrodt" at Oct 23, 2003 02:32:33 PM
Message-ID: <200310232139.h9NLd3T07313@karoshi.com>


	that may be true in your world... :)
	
	I am of the opinion that if I am granted a delegation
	that I need to apply the principles of stewardship, e.g.
	effective utilization of the space ... if that means that
	I have an operational model that allows me to sub-assign
	and sub-allocate space using the same rules for management
	of the delegation for users of my space as apply to me.

	note that "my" here refers not to ownership of the space
	but ownership of the responsiblity for effective stewardship.


> Bill,
> 
> Allocations can be broken up into assignments and given to customers,
> but assignments can not be further delegated to other organizations, 
> or customers.  
> 
> ----CJ
> 
>     From: bmanning at karoshi.com
>     Subject: [ppml] allocate/assign
>     
>     Ok...
>     
>     	grousing about terms leads me to put my personal thoughts to
>     	phosphor (or LCD analog):
>     
>     allocated:  Internet resources earmarked for specific use. period.
>     assigned:   an allocation is bound to a duely vetted party who agrees
>     	    to manage the allocation according to the "principles of
>     	    stewardship" (from the ARIN mission stmt)
>     
>     	such an assignment is considered delegated when such allocations 
>     	and assignments are published - say via whois and DNS, perhaps 
>     	in an rdb.
>     
>     	thoughts?
>     --bill
> 



From cjw at groovy.com  Thu Oct 23 17:41:51 2003
From: cjw at groovy.com (CJ Wittbrodt)
Date: Thu, 23 Oct 2003 14:41:51 -0700
Subject: [ppml] allocate/assign 
In-Reply-To: Message from bmanning@karoshi.com 
   of "Thu, 23 Oct 2003 14:39:03 PDT." <200310232139.h9NLd3T07313@karoshi.com> 
Message-ID: <200310232141.h9NLfqs49130@duchess.groovy.com>


Well the definition in use by all the ISPs I know of and defined
by ARIN is as I have stated.  So you would be in violation.

---CJ

    From: bmanning at karoshi.com
    Subject: Re: [ppml] allocate/assign
    
    	that may be true in your world... :)
    	
    	I am of the opinion that if I am granted a delegation
    	that I need to apply the principles of stewardship, e.g.
    	effective utilization of the space ... if that means that
    	I have an operational model that allows me to sub-assign
    	and sub-allocate space using the same rules for management
    	of the delegation for users of my space as apply to me.
    
    	note that "my" here refers not to ownership of the space
    	but ownership of the responsiblity for effective stewardship.
    
    
    > Bill,
    > 
    > Allocations can be broken up into assignments and given to customers,
    > but assignments can not be further delegated to other organizations, 
    > or customers.  
    > 
    > ----CJ
    > 
    >     From: bmanning at karoshi.com
    >     Subject: [ppml] allocate/assign
    >     
    >     Ok...
    >     
    >     	grousing about terms leads me to put my personal thoughts to
    >     	phosphor (or LCD analog):
    >     
    >     allocated:  Internet resources earmarked for specific use. period.
    >     assigned:   an allocation is bound to a duely vetted party who agrees
    >     	    to manage the allocation according to the "principles of
    >     	    stewardship" (from the ARIN mission stmt)
    >     
    >     	such an assignment is considered delegated when such allocations 
    >     	and assignments are published - say via whois and DNS, perhaps 
    >     	in an rdb.
    >     
    >     	thoughts?
    >     --bill
    > 
    


From bmanning at karoshi.com  Thu Oct 23 17:46:21 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 14:46:21 -0700 (PDT)
Subject: [ppml] allocate/assign
In-Reply-To: <200310232141.h9NLfqs49130@duchess.groovy.com> from "CJ Wittbrodt" at Oct 23, 2003 02:41:51 PM
Message-ID: <200310232146.h9NLkL307404@karoshi.com>


	like I said, -MY- thoughts.  guess I won't be 
	getting any  Internet Protocol resources from
	ARIN anytime soon.

> 
> Well the definition in use by all the ISPs I know of and defined
> by ARIN is as I have stated.  So you would be in violation.
> 
> ---CJ
> 
>     From: bmanning at karoshi.com
>     Subject: Re: [ppml] allocate/assign
>     
>     	that may be true in your world... :)
>     	
>     	I am of the opinion that if I am granted a delegation
>     	that I need to apply the principles of stewardship, e.g.
>     	effective utilization of the space ... if that means that
>     	I have an operational model that allows me to sub-assign
>     	and sub-allocate space using the same rules for management
>     	of the delegation for users of my space as apply to me.
>     
>     	note that "my" here refers not to ownership of the space
>     	but ownership of the responsiblity for effective stewardship.
>     
>     
>     > Bill,
>     > 
>     > Allocations can be broken up into assignments and given to customers,
>     > but assignments can not be further delegated to other organizations, 
>     > or customers.  
>     > 
>     > ----CJ
>     > 
>     >     From: bmanning at karoshi.com
>     >     Subject: [ppml] allocate/assign
>     >     
>     >     Ok...
>     >     
>     >     	grousing about terms leads me to put my personal thoughts to
>     >     	phosphor (or LCD analog):
>     >     
>     >     allocated:  Internet resources earmarked for specific use. period.
>     >     assigned:   an allocation is bound to a duely vetted party who agrees
>     >     	    to manage the allocation according to the "principles of
>     >     	    stewardship" (from the ARIN mission stmt)
>     >     
>     >     	such an assignment is considered delegated when such allocations 
>     >     	and assignments are published - say via whois and DNS, perhaps 
>     >     	in an rdb.
>     >     
>     >     	thoughts?
>     >     --bill
>     > 
>     
> 



From cjw at groovy.com  Thu Oct 23 17:49:07 2003
From: cjw at groovy.com (CJ Wittbrodt)
Date: Thu, 23 Oct 2003 14:49:07 -0700
Subject: [ppml] allocate/assign 
In-Reply-To: Message from bmanning@karoshi.com 
   of "Thu, 23 Oct 2003 14:46:21 PDT." <200310232146.h9NLkL307404@karoshi.com> 
Message-ID: <200310232149.h9NLn7s49342@duchess.groovy.com>


Well it isn't like you're going to need any. You have enough 
legacy space  :-)

    From: bmanning at karoshi.com
    Subject: Re: [ppml] allocate/assign
    
    	like I said, -MY- thoughts.  guess I won't be 
    	getting any  Internet Protocol resources from
    	ARIN anytime soon.
    
    > 
    > Well the definition in use by all the ISPs I know of and defined
    > by ARIN is as I have stated.  So you would be in violation.
    > 
    > ---CJ
    > 
    >     From: bmanning at karoshi.com
    >     Subject: Re: [ppml] allocate/assign
    >     
    >     	that may be true in your world... :)
    >     	
    >     	I am of the opinion that if I am granted a delegation
    >     	that I need to apply the principles of stewardship, e.g.
    >     	effective utilization of the space ... if that means that
    >     	I have an operational model that allows me to sub-assign
    >     	and sub-allocate space using the same rules for management
    >     	of the delegation for users of my space as apply to me.
    >     
    >     	note that "my" here refers not to ownership of the space
    >     	but ownership of the responsiblity for effective stewardship.
    >     
    >     
    >     > Bill,
    >     > 
    >     > Allocations can be broken up into assignments and given to customers,
    >     > but assignments can not be further delegated to other organizations, 
    >     > or customers.  
    >     > 
    >     > ----CJ
    >     > 
    >     >     From: bmanning at karoshi.com
    >     >     Subject: [ppml] allocate/assign
    >     >     
    >     >     Ok...
    >     >     
    >     >     	grousing about terms leads me to put my personal thoughts to
    >     >     	phosphor (or LCD analog):
    >     >     
    >     >     allocated:  Internet resources earmarked for specific use. period.
    >     >     assigned:   an allocation is bound to a duely vetted party who agrees
    >     >     	    to manage the allocation according to the "principles of
    >     >     	    stewardship" (from the ARIN mission stmt)
    >     >     
    >     >     	such an assignment is considered delegated when such allocations 
    >     >     	and assignments are published - say via whois and DNS, perhaps 
    >     >     	in an rdb.
    >     >     
    >     >     	thoughts?
    >     >     --bill
    >     > 
    >     
    > 
    


From ron at aol.net  Thu Oct 23 17:40:00 2003
From: ron at aol.net (Ron da Silva)
Date: Thu, 23 Oct 2003 17:40:00 -0400
Subject: [ppml] allocate/assign
In-Reply-To: <200310232139.h9NLd3T07313@karoshi.com>
References: <200310232132.h9NLWXs48966@duchess.groovy.com> <200310232139.h9NLd3T07313@karoshi.com>
Message-ID: <20031023214000.GL6792@aol.net>


Hmm....please define delegation too.  :-)
-ron



From ron at aol.net  Thu Oct 23 17:41:38 2003
From: ron at aol.net (Ron da Silva)
Date: Thu, 23 Oct 2003 17:41:38 -0400
Subject: [ppml] allocate/assign
In-Reply-To: <200310232146.h9NLkL307404@karoshi.com>
References: <200310232141.h9NLfqs49130@duchess.groovy.com> <200310232146.h9NLkL307404@karoshi.com>
Message-ID: <20031023214138.GM6792@aol.net>

On Thu, Oct 23, 2003 at 02:46:21PM -0700, bmanning at karoshi.com wrote:
> 
> 	like I said, -MY- thoughts.  guess I won't be 
> 	getting any  Internet Protocol resources from
> 	ARIN anytime soon.

or database services either??
-ron


From owen at delong.com  Thu Oct 23 17:53:06 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Oct 2003 14:53:06 -0700
Subject: [ppml] allocate/assign
In-Reply-To: <20031023214000.GL6792@aol.net>
References: <200310232132.h9NLWXs48966@duchess.groovy.com> <200310232139.h9NLd3T07313@karoshi.com> <20031023214000.GL6792@aol.net>
Message-ID: <3950000.1066945986@odlaptop>

Technically, Delegation is the reference of a nameserver for a zone (NS records in the
parent zone).  In ARIN's case, this would be for IN-ADDR.ARPA delegations relevant to
allocations and assignments.

In general, it is often used for all form of allocation and assignment of
a resource from one entity to another.

Owen


--On Thursday, October 23, 2003 05:40:00 PM -0400 Ron da Silva <ron at aol.net> wrote:

>
> Hmm....please define delegation too.  :-)
> -ron
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/39ab4b84/attachment.sig>

From bmanning at karoshi.com  Thu Oct 23 17:55:01 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 14:55:01 -0700 (PDT)
Subject: [ppml] allocate/assign
In-Reply-To: <200310232149.h9NLn7s49342@duchess.groovy.com> from "CJ Wittbrodt" at Oct 23, 2003 02:49:07 PM
Message-ID: <200310232155.h9NLt1c07496@karoshi.com>


	actually, working on the fringes of the "classic"
	ISP/hierarchical models that form the basis of
	98+% of RIR delegations does occasionally require
	coming "back to the well".  

> 
> Well it isn't like you're going to need any. You have enough 
> legacy space  :-)
> 
>     From: bmanning at karoshi.com
>     Subject: Re: [ppml] allocate/assign
>     
>     	like I said, -MY- thoughts.  guess I won't be 
>     	getting any  Internet Protocol resources from
>     	ARIN anytime soon.
>     
>     > 
>     > Well the definition in use by all the ISPs I know of and defined
>     > by ARIN is as I have stated.  So you would be in violation.
>     > 
>     > ---CJ
>     > 
>     >     From: bmanning at karoshi.com
>     >     Subject: Re: [ppml] allocate/assign
>     >     
>     >     	that may be true in your world... :)
>     >     	
>     >     	I am of the opinion that if I am granted a delegation
>     >     	that I need to apply the principles of stewardship, e.g.
>     >     	effective utilization of the space ... if that means that
>     >     	I have an operational model that allows me to sub-assign
>     >     	and sub-allocate space using the same rules for management
>     >     	of the delegation for users of my space as apply to me.
>     >     
>     >     	note that "my" here refers not to ownership of the space
>     >     	but ownership of the responsiblity for effective stewardship.
>     >     
>     >     
>     >     > Bill,
>     >     > 
>     >     > Allocations can be broken up into assignments and given to customers,
>     >     > but assignments can not be further delegated to other organizations, 
>     >     > or customers.  
>     >     > 
>     >     > ----CJ
>     >     > 
>     >     >     From: bmanning at karoshi.com
>     >     >     Subject: [ppml] allocate/assign
>     >     >     
>     >     >     Ok...
>     >     >     
>     >     >     	grousing about terms leads me to put my personal thoughts to
>     >     >     	phosphor (or LCD analog):
>     >     >     
>     >     >     allocated:  Internet resources earmarked for specific use. period.
>     >     >     assigned:   an allocation is bound to a duely vetted party who agrees
>     >     >     	    to manage the allocation according to the "principles of
>     >     >     	    stewardship" (from the ARIN mission stmt)
>     >     >     
>     >     >     	such an assignment is considered delegated when such allocations 
>     >     >     	and assignments are published - say via whois and DNS, perhaps 
>     >     >     	in an rdb.
>     >     >     
>     >     >     	thoughts?
>     >     >     --bill
>     >     > 
>     >     
>     > 
>     
> 



From ron at aol.net  Thu Oct 23 17:46:26 2003
From: ron at aol.net (Ron da Silva)
Date: Thu, 23 Oct 2003 17:46:26 -0400
Subject: [ppml] allocate/assign
In-Reply-To: <3950000.1066945986@odlaptop>
References: <200310232132.h9NLWXs48966@duchess.groovy.com> <200310232139.h9NLd3T07313@karoshi.com> <20031023214000.GL6792@aol.net> <3950000.1066945986@odlaptop>
Message-ID: <20031023214626.GN6792@aol.net>

On Thu, Oct 23, 2003 at 02:53:06PM -0700, Owen DeLong wrote:
> Technically, Delegation is the reference of a nameserver for a zone (NS 
> records in the
> parent zone).  In ARIN's case, this would be for IN-ADDR.ARPA delegations 
> relevant to
> allocations and assignments.
> 
> In general, it is often used for all form of allocation and assignment of
> a resource from one entity to another.

Yeah, but we might need to see Bill's definition for completeness,
otherwise we may not be fully understanding of what he means.  :)

-ron


From bmanning at karoshi.com  Thu Oct 23 17:56:14 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 14:56:14 -0700 (PDT)
Subject: [ppml] allocate/assign
In-Reply-To: <20031023214000.GL6792@aol.net> from "Ron da Silva" at Oct 23, 2003 05:40:00 PM
Message-ID: <200310232156.h9NLuE907518@karoshi.com>

> 
> 
> Hmm....please define delegation too.  :-)
> -ron
> 

	I thought I did.  when the assignment is pubished.

--bill


From bmanning at karoshi.com  Thu Oct 23 17:59:33 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 14:59:33 -0700 (PDT)
Subject: [ppml] allocate/assign
In-Reply-To: <20031023214138.GM6792@aol.net> from "Ron da Silva" at Oct 23, 2003 05:41:38 PM
Message-ID: <200310232159.h9NLxXm07577@karoshi.com>

> 
> On Thu, Oct 23, 2003 at 02:46:21PM -0700, bmanning at karoshi.com wrote:
> > 
> > 	like I said, -MY- thoughts.  guess I won't be 
> > 	getting any  Internet Protocol resources from
> > 	ARIN anytime soon.
> 
> or database services either??
> -ron
> 

	what does that mean?  last I checked, database services
	are not Internet Protcol resources.  And then there is the
	unanswered question of what ARIN signed up to support when
	it came into existance.

	but all that is a slightly different than the discussion/
	over what the terms allocate / assign mean.


--bill




From ron at aol.net  Thu Oct 23 17:52:33 2003
From: ron at aol.net (Ron da Silva)
Date: Thu, 23 Oct 2003 17:52:33 -0400
Subject: [ppml] allocate/assign
In-Reply-To: <200310232156.h9NLuE907518@karoshi.com>
References: <20031023214000.GL6792@aol.net> <200310232156.h9NLuE907518@karoshi.com>
Message-ID: <20031023215233.GP6792@aol.net>

On Thu, Oct 23, 2003 at 02:56:14PM -0700, bmanning at karoshi.com wrote:
> > 
> > 
> > Hmm....please define delegation too.  :-)
> > -ron
> > 
> 
> 	I thought I did.  when the assignment is pubished.

an assignment becomes a delegation when that assignment is
published?

if so, any specifics around who does the publishing or
where that assignment is published?

-ron


From bmanning at karoshi.com  Thu Oct 23 18:04:10 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 15:04:10 -0700 (PDT)
Subject: [ppml] allocate/assign
In-Reply-To: <3950000.1066945986@odlaptop> from "Owen DeLong" at Oct 23, 2003 02:53:06 PM
Message-ID: <200310232204.h9NM4AH07635@karoshi.com>


In the DNS, delegation is a term of Art.  I have tried to make 
the distinction that a delegation is the recognition, by others
then the parties involved, that the allocation and associated
assignment have been made.  In the case of some assignments,
the olny remaining evidence to support that a delegation exists
is the hardcopy letter that can be shown to others to assert
the fact of delegation.


> 
> --==========1808259384==========
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
> 
> Technically, Delegation is the reference of a nameserver for a zone (NS records in the
> parent zone).  In ARIN's case, this would be for IN-ADDR.ARPA delegations relevant to
> allocations and assignments.
> 
> In general, it is often used for all form of allocation and assignment of
> a resource from one entity to another.
> 
> Owen
> 
> 
> --On Thursday, October 23, 2003 05:40:00 PM -0400 Ron da Silva <ron at aol.net> wrote:
> 
> >
> > Hmm....please define delegation too.  :-)
> > -ron
> >
> 
> 
> 
> 
> --==========1808259384==========
> Content-Type: application/pgp-signature
> Content-Transfer-Encoding: 7bit
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQE/mE3En5zKWQ/iqj0RAoDqAJ9r0Bq7DqijrIomPZhc2zeTGzmflwCeKww7
> QKdkRHAiSTwvuD+spMgflCI=
> =5oyB
> -----END PGP SIGNATURE-----
> 
> --==========1808259384==========--
> 



From bmanning at karoshi.com  Thu Oct 23 18:09:29 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 15:09:29 -0700 (PDT)
Subject: [ppml] allocate/assign
In-Reply-To: <20031023215233.GP6792@aol.net> from "Ron da Silva" at Oct 23, 2003 05:52:33 PM
Message-ID: <200310232209.h9NM9Te07689@karoshi.com>

> 
> On Thu, Oct 23, 2003 at 02:56:14PM -0700, bmanning at karoshi.com wrote:
> > > 
> > > 
> > > Hmm....please define delegation too.  :-)
> > > -ron
> > > 
> > 
> > 	I thought I did.  when the assignment is pubished.
> 
> an assignment becomes a delegation when that assignment is
> published?

	yeah, pretty much.
> 
> if so, any specifics around who does the publishing or
> where that assignment is published?

	well, as suggested earlier,  DNS, whois, radb, fax, letter...
	et.al.  
> 
> -ron
> 



From Michael.Dillon at radianz.com  Thu Oct 23 18:12:15 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Thu, 23 Oct 2003 23:12:15 +0100
Subject: [ppml] Allocation and reallocation
Message-ID: <OF567DD1A8.CE1DA628-ON80256DC8.00792ABC-80256DC8.0079F8FB@radianz.com>

ARIN manages numbering resources that can be visualized as a number line.
Organizations can apply to ARIN for a range of those numbers. When ARIN
allocates (or assigns) these ranges of numbers, they also specify whether
or not the recipient is delegated to reallocate (or reassign) these ranges
either in whole or in part. If an organization is delegated reallocation 
rights
then they must agree to apply the ARIN rules of stewardship.

Assignment and allocation are two similar terms which are considered
identical in this context.

--Michael Dillon

P.S. Some people refer to these two types of ranges as delegated 
allocations
and end user allocations to distinguish them.

P.P.S. All organizations receiving allocations (assignments) directly from
ARIN are free to announce them via their own AS or via their ISP's AS. 
In this sense, they are portable allocations. Reallocations 
(reassignments)
are not portable and generally may not be announced by an AS not belonging
to the delegated recipient unless they agree to such announcements.


From bicknell at ufp.org  Thu Oct 23 18:23:55 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 23 Oct 2003 18:23:55 -0400
Subject: [ppml] allocate/assign
In-Reply-To: <200310232116.h9NLGYp07071@karoshi.com>
References: <200310232116.h9NLGYp07071@karoshi.com>
Message-ID: <20031023222355.GA26785@ussenterprise.ufp.org>


I'm going to propose two statements.  I don't know how to make them
shorter yet still be precise.

- ARIN designates stewardship of a range of addresses to an organization.

- Approved organizations may designate stewardship of a subset of the
  addresses to an subordinate organization.

Today the only approved organizations are ISP Members (with "allocations"
in the current nomenclature).

These statements are also generic enough to allow for new membership
types that can or cannot sub-designate stewardship, and also to
allow the possibility that an ARIN member could designate stewardship
to their customer, that customer could go through some "approval"
process with ARIN, and then be allowed to sub-designate a second
level (or further).

Neither are required, neither are prohibited.

The only thing I don't like about these statements is that they are
quite long, and people will want to use something shorter in day
to day conversation.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/f8822374/attachment.sig>

From bicknell at ufp.org  Thu Oct 23 18:26:36 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 23 Oct 2003 18:26:36 -0400
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OF567DD1A8.CE1DA628-ON80256DC8.00792ABC-80256DC8.0079F8FB@radianz.com>
References: <OF567DD1A8.CE1DA628-ON80256DC8.00792ABC-80256DC8.0079F8FB@radianz.com>
Message-ID: <20031023222636.GB26785@ussenterprise.ufp.org>

In a message written on Thu, Oct 23, 2003 at 11:12:15PM +0100, Michael.Dillon at radianz.com wrote:
> Assignment and allocation are two similar terms which are considered
> identical in this context.

Indeed, www.m-w.com (and several others) will return assignment or
allocation as a synonym when the other is entered.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/6d80e226/attachment.sig>

From mury at goldengate.net  Thu Oct 23 18:58:17 2003
From: mury at goldengate.net (Mury)
Date: Thu, 23 Oct 2003 17:58:17 -0500 (CDT)
Subject: [ppml] last chance (was: [arin-announce] Policy Proposal 2003-4:
 IPv6 Policy Changes)
In-Reply-To: <20031023191509.GA10657@nemo.corp.equinix.com>
Message-ID: <Pine.BSI.4.44.0310231755220.26344-100000@dew.goldengate.net>


As the author, my only comment would be that if it looked probable that
this policy change was to be implemented, the dates included in it should
probably be adjusted since this has been sitting around for almost a year.

Thanks.

Mury

On Thu, 23 Oct 2003, Louis Lee wrote:

> We're talking about this policy change at the public policy
> meeting today, and we've noted that there hasn't been any
> additional comments for about 6 months.  It looks like the
> AC is about to act on this proposal.  If you have any new
> comments, or if anyone has a change in their view of this
> proposal, *please* make them known quickly.
>
> Louie
> -------------------------------------------------------
> Louis Lee                             louie at equinix.com
> Staff Network Engineer            company: 650/513-7000
> Equinix, Inc.                        desk: 650/513-7162
> http://www.equinix.com/               fax: 650/513-7903
>
> ----- Forwarded message from Member Services <memsvcs at arin.net> -----
>
> From: Member Services <memsvcs at arin.net>
> Subject: [arin-announce] Policy Proposal 2003-4: IPv6 Policy Changes
> Date: Wed, 5 Mar 2003 08:54:51 -0500 (EST)
> To: arin-announce at arin.net, ppml at arin.net
>
> ARIN welcomes feedback and discussion about the following policy
> proposal in the weeks leading to the ARIN Public Policy Meeting
> in Memphis, Tennessee, scheduled for April 7-8, 2003. All feedback
> received on the mailing list about this policy proposal will be
> included in the discussions that will take place at the upcoming
> Public Policy Meeting.
>
> This policy proposal discussion will take place on the ARIN Public
> Policy Mailing List (ppml at arin.net). Subscription information is
> available at http://www.arin.net/mailing_lists/index.html
>
> Richard Jimmerson
> Director of Operations
> American Registry for Internet Numbers (ARIN)
>
> ### * ###
>
> Policy Proposal 2003-4: IPv6 Policy Changes
>
> The current IPv6 policies are described in the IPv6 Address Allocation
> and Assignment Policy document.
>
>    http://www.arin.net/policy/ipv6_policy.html
>
> It is proposed the IPv6 policy document be updated to include the
> following language and that the changed document be adopted as policy.
>
> 5.1.1
> 	[under d) add:
>
> 	Other organizations are defined as any customer of the LIR.
> 	No distinction will be made in terms of number of IP addresses
> 	required, even if that number is one.
>
> 5.8 Allocation for Early Adopters
>
> 5.8.1 Waiver of criteria listed in 5.1.1 (d)
>
> 	To promote the allocation of IPv6 space the requirement to make 200
> 	/48 assignments within two years shall be waived for anyone
> 	requesting IPv6 space before Dec 31, 2004 or until this policy
> 	is amended.  In the event that this policy is amended the
> 	existing IPv6 space holders shall not be subject to new or
> 	waived criteria for a period of 10 years from their initial
> 	allocation date.
>
> 5.8.2 Waiver of fees
>
> 	a) To promote the allocation of IPv6 space all IPv6 related fees
> 	shall be waived until Dec 31, 2006 for anyone requesting and
> 	receiving space before Dec 31, 2004.  In the even that this
> 	policy is amended the existing IPv6 space holders shall
> 	under no circumstances be subject to waived or new fees until
> 	Dec 31, 2006.
>
> 	b) For billing purposes fees will be due according to normal
> 	ARIN billing policies on Jan 1, 2007.  All early adopters
> 	will have the same billing date regardless of the date
> 	they received their allocation.
>
> 5.8.3 Micro Allocations
>
> 	a) To promote the allocation and deployment of IPv6 all the
> 	criteria in 5.1.1 shall be waived to those requesting a /48
> 	micro allocation before Dec 31, 2004, or until this policy
> 	is changed.  If this policy is changed, current space holders
> 	shall not be subject to any new or waived criteria.
>
> 	b) All fees shall be waived under the same rules listed in
> 	5.8.2.
>
> 	c) Those receiving micro allocations shall not be allowed to
> 	make further allocations or assignments out of their /48.  It
> 	is intended for their internal use only.
>
> 	d) When possible those receiving micro allocations shall
> 	return their allocation and receive a new /48 from their
> 	upstream provider (a LIR).  This is requested in a good faith
> 	manner until Jan 1, 2007 at which time all micro allocations
> 	granted under these waived criteria must be returned.
>
>
> ----- End forwarded message -----
>



From owen at delong.com  Thu Oct 23 18:56:29 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Oct 2003 15:56:29 -0700
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OF567DD1A8.CE1DA628-ON80256DC8.00792ABC-80256DC8.0079F8FB@radianz.com>
References: <OF567DD1A8.CE1DA628-ON80256DC8.00792ABC-80256DC8.0079F8FB@radianz.com>
Message-ID: <13040000.1066949789@odlaptop>

Michael,
        As Kathy pointed out earlier, in ARIN parlance and in the terms used
by most ISPs, ALLOCATION is used to refer to the entrustment of an organization
with the management of a block.  That is, RIRs ALLOCATE to LIRs.  End users,
on the other hand, receive ASSIGNMENTS from LIRs or RIRs.

Owen


--On Thursday, October 23, 2003 11:12:15 PM +0100 Michael.Dillon at radianz.com wrote:

> ARIN manages numbering resources that can be visualized as a number line.
> Organizations can apply to ARIN for a range of those numbers. When ARIN
> allocates (or assigns) these ranges of numbers, they also specify whether
> or not the recipient is delegated to reallocate (or reassign) these ranges
> either in whole or in part. If an organization is delegated reallocation
> rights
> then they must agree to apply the ARIN rules of stewardship.
>
> Assignment and allocation are two similar terms which are considered
> identical in this context.
>
> --Michael Dillon
>
> P.S. Some people refer to these two types of ranges as delegated
> allocations
> and end user allocations to distinguish them.
>
> P.P.S. All organizations receiving allocations (assignments) directly from
> ARIN are free to announce them via their own AS or via their ISP's AS.
> In this sense, they are portable allocations. Reallocations
> (reassignments)
> are not portable and generally may not be announced by an AS not belonging
> to the delegated recipient unless they agree to such announcements.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/452d2014/attachment.sig>

From jlewis at lewis.org  Thu Oct 23 19:09:59 2003
From: jlewis at lewis.org (jlewis at lewis.org)
Date: Thu, 23 Oct 2003 19:09:59 -0400 (EDT)
Subject: [ppml] Quick comment on the Meetings..
In-Reply-To: <000601c39999$d445b510$2a45fea9@teraint.net>
Message-ID: <Pine.LNX.4.44.0310231906280.8137-100000@redhat1.mmaero.com>

On Thu, 23 Oct 2003, Trevor Paquette wrote:

> LOVE the live video feed!

Am I the only one who found the resolution to be just low enough that most 
of the slides (all but the biggest fonts) were unreadable?  I've been 
watching on/off all week (nanog before ARIN).

It's more work/complexity, but if each presenter had their slides on the
web, we could follow along that way and really see what they're talking
about.

> Just missing a way for viewers to post questions/comments (IM?).

That would be very nice.  Something as simple as an IRC channel monitored 
by someone in the room could be used to voice comments/questions from 
those unable to attend.

----------------------------------------------------------------------
 Jon Lewis *jlewis at lewis.org*|  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |  
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From lee.howard at mci.com  Thu Oct 23 19:16:57 2003
From: lee.howard at mci.com (Lee Howard)
Date: Thu, 23 Oct 2003 19:16:57 -0400 (EDT)
Subject: [ppml] allocate/assignxy
In-Reply-To: <200310232139.h9NLd3T07313@karoshi.com>
Message-ID: <Pine.GSO.4.20.0310231906520.28844-100000@instserve0.corp.us.uu.net>

>From RFC2050:

This document makes a distinction between the allocation of IP
   addresses and the assignment of IP addresses.  Addresses are
   allocated to ISPs by regional registries to assign to its customer
   base.
[. . .]
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.

I think "delegation" here is used in a common English sense, and
could be defined from context.  This also clearly explains
"assignment" and "allocation."


>From ARIN's web page (http://www.arin.net/registration/index.html):

A distinction is made between address allocation and address assignment, i.e., ISPs are "allocated" address space, while end-users are "assigned" address space. ISPs are allocated blocks of IP addresses for the purpose of assigning or further allocating that space to their customers, while end-users receive assignments of IP addresses exclusively for use in their operational networks. 


The concern in Wednesday's policy BOF, as I heard it, was not that
the terms are poorly defined, but that even knowing the definitions
it's easy to confuse which term applies to which definition, and maybe
ther distinction isn't necessary after all.

My memory is not perfect, so maybe the person who raised the concern
could raise it again.

Lee

On Thu, 23 Oct 2003 bmanning at karoshi.com wrote:

> Date: Thu, 23 Oct 2003 14:39:03 -0700 (PDT)
> From: bmanning at karoshi.com
> To: CJ Wittbrodt <cjw at groovy.com>
> Cc: bmanning at karoshi.com, ppml at arin.net
> Subject: Re: [ppml] allocate/assign
> 
> 
> 	that may be true in your world... :)
> 	
> 	I am of the opinion that if I am granted a delegation
> 	that I need to apply the principles of stewardship, e.g.
> 	effective utilization of the space ... if that means that
> 	I have an operational model that allows me to sub-assign
> 	and sub-allocate space using the same rules for management
> 	of the delegation for users of my space as apply to me.
> 
> 	note that "my" here refers not to ownership of the space
> 	but ownership of the responsiblity for effective stewardship.
> 
> 
> > Bill,
> > 
> > Allocations can be broken up into assignments and given to customers,
> > but assignments can not be further delegated to other organizations, 
> > or customers.  
> > 
> > ----CJ
> > 
> >     From: bmanning at karoshi.com
> >     Subject: [ppml] allocate/assign
> >     
> >     Ok...
> >     
> >     	grousing about terms leads me to put my personal thoughts to
> >     	phosphor (or LCD analog):
> >     
> >     allocated:  Internet resources earmarked for specific use. period.
> >     assigned:   an allocation is bound to a duely vetted party who agrees
> >     	    to manage the allocation according to the "principles of
> >     	    stewardship" (from the ARIN mission stmt)
> >     
> >     	such an assignment is considered delegated when such allocations 
> >     	and assignments are published - say via whois and DNS, perhaps 
> >     	in an rdb.
> >     
> >     	thoughts?
> >     --bill
> > 
> 
> 



From michael at whisenant.net  Thu Oct 23 19:38:10 2003
From: michael at whisenant.net (Michael Whisenant)
Date: Thu, 23 Oct 2003 18:38:10 -0500
Subject: [ppml] Comments from Open Forum
Message-ID: <6.0.0.22.2.20031023182114.0259fdc0@mail.whisenant.net>

I am confused as to the intention of the remarks that created a stir of 
controversial comments. Let me start with what I heard as the comments, the 
follow on comments, and my comments which may or may not be so relevant 
based on correct understanding of the original comments.

1. I heard a request from the community as to their opinion regarding an 
organization that wants globally unique IPv6 address space, but yet this 
will be routed on a closed network (not necessarily globally routed).

	I do not see that this is any different that what has already being used 
today in that organizations which justify the need for an allocation can 
obtain one, and that they have meet the conditions of the allocation. If 
the person which has this address assignment chooses NOT to have the 
address space or a portion thereof announced that is an operational issue 
and not part of the policy. I do not see any specific policy that states 
that IP address space that is obtained from a RIR must the globally routed, 
and do not see the full intent of this request. Why is this an issue, and 
why would they not just get that address space.

2. A comment was made that private RFC1918 address space could not be 
routed across a providers network in a closed manner.

	This is not the case, as I pointed out L2VPN and separate vrf in BGP 
supports such. Granted that as was pointed out there is a problem if you 
desire to route RFC1918 to other organizations (ie double NAT which breaks 
everything) but I did not hear that the organization wanted to communicate 
between multiple organizations across the private closed network. I 
received lots of immediate negative comments that it had to be routed 
across separate organizations. Yes each separate VPN must have unique 
address space, coordinate use of RFC1918 address space for separate L2VPN. 
It is not technically impossible, but in practice is operationally hard to 
imagine that would be the case, resulting again in the need for globally 
unique address allocation.

So with that stated, and the corrections for item #2 in a short forum, what 
is the issue that was requested from the public when I do not see why they 
can not obtain the address space. The reason for the clarification, was 
that the AC was then tasked to explore how this could be accomplished. I 
support that if this is an issue that the AC should and I trust that they 
will address this specific issue. I am trying to better understand the 
issue , therefore spurring on further discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 170 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/f943c560/attachment.sig>

From michael at whisenant.net  Thu Oct 23 19:48:11 2003
From: michael at whisenant.net (Michael Whisenant)
Date: Thu, 23 Oct 2003 18:48:11 -0500
Subject: [ppml] allocate/assignxy
In-Reply-To: <Pine.GSO.4.20.0310231906520.28844-100000@instserve0.corp.u
 s.uu.net>
References: <200310232139.h9NLd3T07313@karoshi.com>
 <Pine.GSO.4.20.0310231906520.28844-100000@instserve0.corp.us.uu.net>
Message-ID: <6.0.0.22.2.20031023184306.025fa048@mail.whisenant.net>

I think that the discussion on Wednesday (day 1) was in regard to policy 
proposal dealing with Micro allocations/assignments where ISP or 
organization could obtain a smaller allocation than the current /20 
allocation/assignment. By finally including both allocations and 
assignments it removed the objections that several including myself had 
previously raised. Since I was one that had made some comments on the 
policy that could have lead one to gain this position, I felt I would 
reply. However, I make no assertions that this is the comment or concern 
that you were trying to address. Just since I had made comments on 
allocations/assignments regarding that specific policy I would respond so 
that if  no other party should it may clear you view.

At 06:16 PM 10/23/2003, Lee Howard wrote:
> >From RFC2050:
>
>This document makes a distinction between the allocation of IP
>    addresses and the assignment of IP addresses.  Addresses are
>    allocated to ISPs by regional registries to assign to its customer
>    base.
>[. . .]
>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.
>
>I think "delegation" here is used in a common English sense, and
>could be defined from context.  This also clearly explains
>"assignment" and "allocation."
>
>
> >From ARIN's web page (http://www.arin.net/registration/index.html):
>
>A distinction is made between address allocation and address assignment, 
>i.e., ISPs are "allocated" address space, while end-users are "assigned" 
>address space. ISPs are allocated blocks of IP addresses for the purpose 
>of assigning or further allocating that space to their customers, while 
>end-users receive assignments of IP addresses exclusively for use in their 
>operational networks.
>
>
>The concern in Wednesday's policy BOF, as I heard it, was not that
>the terms are poorly defined, but that even knowing the definitions
>it's easy to confuse which term applies to which definition, and maybe
>ther distinction isn't necessary after all.
>
>My memory is not perfect, so maybe the person who raised the concern
>could raise it again.
>
>Lee
>
>On Thu, 23 Oct 2003 bmanning at karoshi.com wrote:
>
> > Date: Thu, 23 Oct 2003 14:39:03 -0700 (PDT)
> > From: bmanning at karoshi.com
> > To: CJ Wittbrodt <cjw at groovy.com>
> > Cc: bmanning at karoshi.com, ppml at arin.net
> > Subject: Re: [ppml] allocate/assign
> >
> >
> >       that may be true in your world... :)
> >
> >       I am of the opinion that if I am granted a delegation
> >       that I need to apply the principles of stewardship, e.g.
> >       effective utilization of the space ... if that means that
> >       I have an operational model that allows me to sub-assign
> >       and sub-allocate space using the same rules for management
> >       of the delegation for users of my space as apply to me.
> >
> >       note that "my" here refers not to ownership of the space
> >       but ownership of the responsiblity for effective stewardship.
> >
> >
> > > Bill,
> > >
> > > Allocations can be broken up into assignments and given to customers,
> > > but assignments can not be further delegated to other organizations,
> > > or customers.
> > >
> > > ----CJ
> > >
> > >     From: bmanning at karoshi.com
> > >     Subject: [ppml] allocate/assign
> > >
> > >     Ok...
> > >
> > >             grousing about terms leads me to put my personal thoughts to
> > >             phosphor (or LCD analog):
> > >
> > >     allocated:  Internet resources earmarked for specific use. period.
> > >     assigned:   an allocation is bound to a duely vetted party who agrees
> > >                 to manage the allocation according to the "principles of
> > >                 stewardship" (from the ARIN mission stmt)
> > >
> > >             such an assignment is considered delegated when such 
> allocations
> > >             and assignments are published - say via whois and DNS, 
> perhaps
> > >             in an rdb.
> > >
> > >             thoughts?
> > >     --bill
> > >
> >
> >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 170 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/3f0f9bcd/attachment.sig>

From memsvcs at arin.net  Thu Oct 23 20:06:48 2003
From: memsvcs at arin.net (Member Services)
Date: Thu, 23 Oct 2003 20:06:48 -0400 (EDT)
Subject: [ppml] NRO MoU Revised
Message-ID: <200310240006.UAA24057@ops.arin.net>

After considering all comments received, the RIR Boards 
have developed a further revision of the proposed NRO MoU, 
as available here:

http://www.arin.net/library/rir-docs/nro.html.

Subject to final formal approval by all RIR boards, this 
document will be signed by the RIR CEOs during the ARIN 
members meeting in Chicago, USA, at 9am 24 October 2003 
(local time).

The RIR Boards would like to stress that they will 
continue working together with the community to refine 
the NRO's functioning.

Paul Wilson
APNIC
on behalf of RIR boards.



From tme at multicasttech.com  Thu Oct 23 20:42:06 2003
From: tme at multicasttech.com (Marshall Eubanks)
Date: Thu, 23 Oct 2003 20:42:06 -0400
Subject: [ppml] Quick comment on the Meetings..
In-Reply-To: <Pine.LNX.4.44.0310231906280.8137-100000@redhat1.mmaero.com>
Message-ID: <E4B43DA8-05BA-11D8-80EB-003065FC3726@multicasttech.com>


On Thursday, October 23, 2003, at 07:09 PM, jlewis at lewis.org wrote:

> On Thu, 23 Oct 2003, Trevor Paquette wrote:
>
>> LOVE the live video feed!
>
> Am I the only one who found the resolution to be just low enough that 
> most
> of the slides (all but the biggest fonts) were unreadable?  I've been
> watching on/off all week (nanog before ARIN).

It's because the encoding whacks high spatial frequencies, and thus
makes fonts (as opposed to faces) hard to follow.

They need a JPEG2000 encoding such as NCAST provides.

>
> It's more work/complexity, but if each presenter had their slides on 
> the
> web, we could follow along that way and really see what they're talking
> about.
>
>> Just missing a way for viewers to post questions/comments (IM?).
>
> That would be very nice.  Something as simple as an IRC channel 
> monitored
> by someone in the room could be used to voice comments/questions from
> those unable to attend.
>
> ----------------------------------------------------------------------
>  Jon Lewis *jlewis at lewis.org*|  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>
>
                                  Regards
                                  Marshall Eubanks

T.M. Eubanks
e-mail : marshall.eubanks at telesuite.com
http://www.telesuite.com



From Michael.Dillon at radianz.com  Thu Oct 23 21:01:39 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Fri, 24 Oct 2003 02:01:39 +0100
Subject: [ppml] Allocation and reallocation
Message-ID: <OF98252FAA.E10C722A-ON80256DC9.000571A8-80256DC9.0005A4A4@radianz.com>

>That is, RIRs ALLOCATE to LIRs.  End users,
>on the other hand, receive ASSIGNMENTS from LIRs or RIRs.

An important point. There are two types of organizations, LIRs and
end users. RIRs assign to LIRs but end users can receive their
allocation from either LIRs (the normal case) or RIRs.

--Michael Dillon




From Michael.Dillon at radianz.com  Thu Oct 23 21:05:58 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Fri, 24 Oct 2003 02:05:58 +0100
Subject: [ppml] Quick comment on the Meetings..
Message-ID: <OF394388F2.1D33AE1E-ON80256DC9.0005B759-80256DC9.00060A51@radianz.com>

>Am I the only one who found the resolution to be just low enough that 
most 
>of the slides (all but the biggest fonts) were unreadable?  I've been 
>watching on/off all week (nanog before ARIN).

Some slides are too small to follow even for those of us onsite.

>It's more work/complexity, but if each presenter had their slides on the
>web, we could follow along that way and really see what they're talking
>about.

Most slides were on the web before the meeting and as a policy presenter,
I would like to point out that ARIN folk asked me twice to submit any
slides I was planning to use. In my case I chose not to use any special
slides but ARIN staff did try to get the slides in advance from the
presenters.

--Michael Dillon





From bicknell at ufp.org  Thu Oct 23 21:28:29 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 23 Oct 2003 21:28:29 -0400
Subject: [ppml] allocate/assignxy
In-Reply-To: <Pine.GSO.4.20.0310231906520.28844-100000@instserve0.corp.us.uu.net>
References: <200310232139.h9NLd3T07313@karoshi.com> <Pine.GSO.4.20.0310231906520.28844-100000@instserve0.corp.us.uu.net>
Message-ID: <20031024012829.GA35586@ussenterprise.ufp.org>

In a message written on Thu, Oct 23, 2003 at 07:16:57PM -0400, Lee Howard wrote:
> The concern in Wednesday's policy BOF, as I heard it, was not that
> the terms are poorly defined, but that even knowing the definitions
> it's easy to confuse which term applies to which definition, and maybe
> ther distinction isn't necessary after all.

That is my concern.  People use allocation and assignment everyday,
and in many contexts (outside of ARIN) those two words are treated
as synonyms.  Further, they are two words that are easily interchanged
(similar length and sound).  It's the same problem that prevents
people from using "0" and "O" or "I" and "1" on license plates
together, it's not that they are not different, or that they are
not well defined, just easily confused.

As an aside, since they are synonyms I'm sure translation of ARIN
policy into other languages creates much more confusion.  Perhaps
those from other RIR's (or the french speaking from Canada) could
comment on how much of a problem this causes in automated or human
translation of the documents.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/e6c4a75c/attachment.sig>

From cire at deckerstone.net  Thu Oct 23 22:24:47 2003
From: cire at deckerstone.net (Eric B. Decker)
Date: Thu, 23 Oct 2003 19:24:47 -0700
Subject: [ppml] Comments on the 10/23/2003 NRO document
Message-ID: <20031024022447.24634.qmail@deckerstone.net>


I'm one of the ARIN elected members to the ASO/AC and I've been
watching the development of the NRO proposal since its inception.

I have a few comments.

In section 6 of the NRO MoU it states that the NRO EC shall only
take action by unanimous agreement.  Doesn't that strike anyone
as a recipe for deadlock?

I've also noticed a few folks bringing up the issue of the mixture
of operational and policy develoment activites.  I also concur
that these should be seperate functions.  I have yet to see
these questions answered cogently.

Thanks for your time,

-c
cire "i am only an egg" eric
"I could have done it in a much more complicated
way", said the Red Queen, immensely proud.
			-- Lewis Carrol, Alice in Wonderland
Eric B. Decker
email:	cire at deckerstone.net


From bmanning at karoshi.com  Thu Oct 23 22:45:30 2003
From: bmanning at karoshi.com (bmanning at karoshi.com)
Date: Thu, 23 Oct 2003 19:45:30 -0700 (PDT)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OF98252FAA.E10C722A-ON80256DC9.000571A8-80256DC9.0005A4A4@radianz.com> from "Michael.Dillon@radianz.com" at Oct 24, 2003 02:01:39 AM
Message-ID: <200310240245.h9O2jUw09581@karoshi.com>

> 
> >That is, RIRs ALLOCATE to LIRs.  End users,
> >on the other hand, receive ASSIGNMENTS from LIRs or RIRs.
> 
> An important point. There are two types of organizations, LIRs and
> end users. RIRs assign to LIRs but end users can receive their
> allocation from either LIRs (the normal case) or RIRs.

	that would be three organizations...
	RIRs, LIRs, and endusers.
	(and there are only three colors, white, black and red)

> --Michael Dillon

--bill


From owen at delong.com  Fri Oct 24 00:35:45 2003
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Oct 2003 21:35:45 -0700
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OF98252FAA.E10C722A-ON80256DC9.000571A8-80256DC9.0005A4A4@radianz.com>
References: <OF98252FAA.E10C722A-ON80256DC9.000571A8-80256DC9.0005A4A4@radianz.com>
Message-ID: <32750000.1066970145@odlaptop>

You came close to correct here Michael, but, you are backwards...

RIRs ALLOCATE to LIRs and both RIR and LIR can ASSIGN to end users.

Owen


--On Friday, October 24, 2003 02:01:39 AM +0100 Michael.Dillon at radianz.com wrote:

>> That is, RIRs ALLOCATE to LIRs.  End users,
>> on the other hand, receive ASSIGNMENTS from LIRs or RIRs.
>
> An important point. There are two types of organizations, LIRs and
> end users. RIRs assign to LIRs but end users can receive their
> allocation from either LIRs (the normal case) or RIRs.
>
> --Michael Dillon
>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031023/e3190ee2/attachment.sig>

From plzak at arin.net  Fri Oct 24 07:37:07 2003
From: plzak at arin.net (Ray Plzak)
Date: Fri, 24 Oct 2003 07:37:07 -0400
Subject: [ppml] RE: [Nro-comments] Comments on the 10/23/2003 NRO document
In-Reply-To: <20031024022447.24634.qmail@deckerstone.net>
Message-ID: <001901c39a23$2acb8660$5e8888c0@arin.net>

Thanks for your comments Eric.

In proposing any structure for joint activity there is an element of
relying on the good intentions and common interest of the participants.
The structure of the NRO is intended as one where the RIRs  engage in
common activities by common consent. If a proposed activity fails to
gain
this level of common consent then the NRO will not force or impel
dissenting RIRs into the activity via the NRO. The most appropriate way
of
expressing this common consent  is through unanimous agreement.

 > I've also noticed a few folks bringing up the issue of the mixture of
 > operational and policy develoment activites.  I also concur that
these
 > should be seperate functions.  I have yet to see these questions
answered
 > cogently.

As pointed out in the Cover Note, (and the quotes are lifted from tis
document) the NRO is proposed as a vehicle for a number of activities:

- to act as a vehicle to "undertake those roles where the coordinated
action of all the RIRs is required or appropriate. There are coordinated
activities of this nature being performed at present, and this proposed
joint entity provides a formal residence for such activities"

- to act as the vehicle "for interaction between the RIR and number
community and ICANN, undertaking the current roles of the Address
Supporting Organization from ICANN's perspective"

and

- an entity that is "capable of providing continuity of coordination of
number resource administrative functions if so required in the event of
failure of ICANN. "

In the first two cases the NRO acts as a facilitator for the development
of global policy, but for not act as the ultimate body for ratification
of
such policies. It has been the case since the inception of ICANN, and it
is our intention that it remains the case, that this function be
undertaken by ICANN, through mechanisms as proposed in the attached
proposed ASO MpU

However as pointed ou in the cover note, "ICANN is a private corporate
entity, and that its future is one that is not absolutely assured. There
is a risk, as with any private corporate entity, that the entity may
fail.
Failure of ICANN includes the risk of a freezing of the unallocated
number
pool, which in turn places a significant risk in the continued operation
of the registries and the application of their policies. The ultimate
risk
here is a shift in the number administration from the careful
preservation
of uniqueness within the assignment of number resources to one of
chaotic
number movement, with its attendant consequences which appear to
inevitably include a breakdown of the coherency of the Internet's
address
realm. Obviously, this is not an acceptable outcome under any
circumstances."

The challenge faced by the RIRs has been to propose an entity that is
capable of preserving an essential continuity of function, but at the
same
time not assuming the current roles and responsibilities of ICANN. The
approach taken has been to propose an NRO that is capable of undertaking
a
review function through the Number Council, and use the NRO Executive
Council as the body that ratifies proposed policies, acting upon the
recommendation of the Number Council. However these are proposed to be
potential capabilities rather than assumed roles, and the policy process
that the RIRs are committed to remains one that includes a role for
ICANN
within the overall global policy development process.

Ray Plzak
ARIN Board Member



> -----Original Message-----
> From: nro-comments-admin at apnic.net 
> [mailto:nro-comments-admin at apnic.net] On Behalf Of Eric B. Decker
> Sent: Thursday, October 23, 2003 10:25 PM
> To: nro-comments at apnic.net
> Cc: ac-coord at aso.icann.org; arin-announce at arin.net; ppml at arin.net
> Subject: [Nro-comments] Comments on the 10/23/2003 NRO document
> 
> 
> 
> I'm one of the ARIN elected members to the ASO/AC and I've been
> watching the development of the NRO proposal since its inception.
> 
> I have a few comments.
> 
> In section 6 of the NRO MoU it states that the NRO EC shall only
> take action by unanimous agreement.  Doesn't that strike anyone
> as a recipe for deadlock?
> 
> I've also noticed a few folks bringing up the issue of the mixture
> of operational and policy develoment activites.  I also concur
> that these should be seperate functions.  I have yet to see
> these questions answered cogently.
> 
> Thanks for your time,
> 
> -c
> cire "i am only an egg" eric
> "I could have done it in a much more complicated
> way", said the Red Queen, immensely proud.
> 			-- Lewis Carrol, Alice in Wonderland
> Eric B. Decker
> email:	cire at deckerstone.net
> _______________________________________________
> Nro-comments mailing list
> Nro-comments at apnic.net
> http://mailman.apnic.net/mailman/listinfo/nro-comments
> 



From cscott at gaslightmedia.com  Fri Oct 24 08:40:31 2003
From: cscott at gaslightmedia.com (Charles Scott)
Date: Fri, 24 Oct 2003 08:40:31 -0400 (EDT)
Subject: [ppml] Policy Proposal 2003-10: Apply the HD Ratio to All Future
 IPv4 Allocations
In-Reply-To: <20031023213353.GB23951@nemo.corp.equinix.com>
Message-ID: <Pine.LNX.4.44.0310240809180.25508-100000@harbor.gaslightmedia.com>


PPML:
  I pointed out a while ago, and I don't believe that anyone challenged,
that RFC3194 specifically describes issues related to actual
implementation of address space (end-users assignments) and not issues
related to the consumption of an allocation that is being assigned in
blocks to end user organizations. It was, and still is, my belief that
confusion over use of the terms allocation and assignment is what is
making consideration of this proposal difficult--which is why I brought up
that point.
  If one accepts that RFC3194 relates to end-user address management, then
it must be evaluated in relation to the 25%/50% guidelines for end-user
utilization, not the 80% guideline for consumption of an ISP's allocation.  
>From that, it's clear that the current guidelines are generous and should
impose no hardship on end-user management or ISP allocations and therefore
the application of H/D ratio to allocations is inappropriate.
  To complicate things further, I think some ISP's have incorrectly caused
the 80% guideline to affect their use of address space that they utilize
internally by not specifically "assigning" blocks of addresses for their
own use.
  I therefore believe that abandoning the 80% guideline is inadvisable,
that the added inefficiency of allocation that would cause is unnecessary,
and would ask that the above points be addressed before adoption of any
such policy.

Chuck Scott



On Thu, 23 Oct 2003, Louis Lee wrote:

> On Tue, Sep 16, 2003 at 04:17:00PM +0100, Michael.Dillon at radianz.com wrote:
> > > Is there a good reason to abandon the relatively simple
> > > 80% rule in favor of a mathematically more complicated
> > > formula that effectively drops the % utilization rules
> > > by a noticable amount?
> >
> > Yes. Most of this is explained in RFC 3194 and in the
> > APNIC paper whose URL was incorrectly given in the
> > original posting of my justification of the policy.
> 
> I would suggest that we do not abandon the original 80%
> rule completely.  Perhaps the policy can start off with:
> 
>   If an organization requesting an IPv4 allocation cannot
>   meet the utilization rate stated in the primary criteria
>   that ARIN uses, than the HD ratio may be applied to
>   determine adequate utilization for approval of the
>   request.
> 
> I don't want to explicitly state the 80% figure and how
> it's applied to the most recent allocation or all previous
> allocations.  This way, the policy is a little more
> flexible to allow a change of the 80% figure elsewhere.
> 
> (I've got another thought on this issue that I'm sure I'll
> remember just after sending this message. :)
> 
> Louie
> -------------------------------------------------------
> Louis Lee                             louie at equinix.com
> Staff Network Engineer            company: 650/513-7000
> Equinix, Inc.                        desk: 650/513-7162
> http://www.equinix.com/               fax: 650/513-7903
> 






From bicknell at ufp.org  Fri Oct 24 08:57:19 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 24 Oct 2003 08:57:19 -0400
Subject: [ppml] Policy Proposal 2003-10: Apply the HD Ratio to All Future IPv4 Allocations
In-Reply-To: <OF2840D456.961299BC-ON80256DA3.0052C7FB-80256DA3.0053F45D@radianz.com>
References: <OF2840D456.961299BC-ON80256DA3.0052C7FB-80256DA3.0053F45D@radianz.com>
Message-ID: <20031024125719.GA60266@ussenterprise.ufp.org>

In a message written on Tue, Sep 16, 2003 at 04:17:00PM +0100, Michael.Dillon at radianz.com wrote:
> The assumption is that if you achieve 80% efficiency on a block today,
> then it will be that way forever. Since the policy only requires ARIN

Does ARIN have any data on the number of people who have failed a
request, or failed an audit due to the 80% rule?

Does anyone else have a measure of the problem that has a larger
scope than a single ISP's issues?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031024/dfa17fbc/attachment.sig>

From owen at delong.com  Fri Oct 24 11:25:58 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 24 Oct 2003 08:25:58 -0700
Subject: [ppml] Proposal
Message-ID: <32930000.1067009158@odlaptop>

I propose that John Curran not be allowed to combine Gong and electronic
amplification.

Reasoning:

The combination of Gong and Electronic Amplification is much like:

        Fingernails and Chalkboards
        TLDs and Wildcard Records

In general, if these things are not combined, the world is a better place.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031024/043d1ed1/attachment.sig>

From jcurran at istaff.org  Fri Oct 24 11:40:45 2003
From: jcurran at istaff.org (John Curran)
Date: Fri, 24 Oct 2003 10:40:45 -0500
Subject: [ppml] Proposal
In-Reply-To: <32930000.1067009158@odlaptop>
References: <32930000.1067009158@odlaptop>
Message-ID: <p06001f01bbbef804dfbb@[192.35.167.105]>

Owen,

The Chicago Downtown Marriott A/V staff apparently agree with you,
as they have been deftly turning down the microphone just before
gongstrike...

:-)
/John

At 8:25 AM -0700 10/24/03, Owen DeLong wrote:
>I propose that John Curran not be allowed to combine Gong and electronic
>amplification.
>
>Reasoning:
>
>The combination of Gong and Electronic Amplification is much like:
>
>       Fingernails and Chalkboards
>       TLDs and Wildcard Records
>
>In general, if these things are not combined, the world is a better place.
>
>Owen


From owen at delong.com  Fri Oct 24 11:44:30 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 24 Oct 2003 08:44:30 -0700
Subject: [ppml] Proposal
In-Reply-To: <p06001f01bbbef804dfbb@[192.35.167.105]>
References: <32930000.1067009158@odlaptop> <p06001f01bbbef804dfbb@[192.35.167.105]>
Message-ID: <48930000.1067010270@odlaptop>

I notice Ray carefully prohibited me from bringing this to the open mike. :-)

Owen


--On Friday, October 24, 2003 10:40:45 AM -0500 John Curran <jcurran at istaff.org> wrote:

> Owen,
>
> The Chicago Downtown Marriott A/V staff apparently agree with you,
> as they have been deftly turning down the microphone just before
> gongstrike...
>
> :-)
> /John
>
> At 8:25 AM -0700 10/24/03, Owen DeLong wrote:
>> I propose that John Curran not be allowed to combine Gong and electronic
>> amplification.
>>
>> Reasoning:
>>
>> The combination of Gong and Electronic Amplification is much like:
>>
>>       Fingernails and Chalkboards
>>       TLDs and Wildcard Records
>>
>> In general, if these things are not combined, the world is a better place.
>>
>> Owen



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031024/b0126160/attachment.sig>

From jlewis at lewis.org  Fri Oct 24 11:51:07 2003
From: jlewis at lewis.org (jlewis at lewis.org)
Date: Fri, 24 Oct 2003 11:51:07 -0400 (EDT)
Subject: [ppml] Proposal
In-Reply-To: <48930000.1067010270@odlaptop>
Message-ID: <Pine.LNX.4.44.0310241149290.8137-100000@redhat1.mmaero.com>

Is there a reason today's meeting/(comedy?) isn't being broadcast?  I
brought in headphones today (hoping to get better sound quality) only to
find the stream doesn't work and a note saying ARIN would only be
streaming the first 2 days.

On Fri, 24 Oct 2003, Owen DeLong wrote:

> I notice Ray carefully prohibited me from bringing this to the open mike. :-)
> 
> Owen
> 
> 
> --On Friday, October 24, 2003 10:40:45 AM -0500 John Curran <jcurran at istaff.org> wrote:
> 
> > Owen,
> >
> > The Chicago Downtown Marriott A/V staff apparently agree with you,
> > as they have been deftly turning down the microphone just before
> > gongstrike...
> >
> > :-)
> > /John
> >
> > At 8:25 AM -0700 10/24/03, Owen DeLong wrote:
> >> I propose that John Curran not be allowed to combine Gong and electronic
> >> amplification.
> >>
> >> Reasoning:
> >>
> >> The combination of Gong and Electronic Amplification is much like:
> >>
> >>       Fingernails and Chalkboards
> >>       TLDs and Wildcard Records
> >>
> >> In general, if these things are not combined, the world is a better place.
> >>
> >> Owen
> 
> 
> 
> 

----------------------------------------------------------------------
 Jon Lewis *jlewis at lewis.org*|  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |  
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From ron at aol.net  Fri Oct 24 11:46:50 2003
From: ron at aol.net (Ron da Silva)
Date: Fri, 24 Oct 2003 11:46:50 -0400
Subject: [ppml] Proposal
In-Reply-To: <Pine.LNX.4.44.0310241149290.8137-100000@redhat1.mmaero.com>
References: <48930000.1067010270@odlaptop> <Pine.LNX.4.44.0310241149290.8137-100000@redhat1.mmaero.com>
Message-ID: <20031024154650.GF7223@aol.net>

On Fri, Oct 24, 2003 at 11:51:07AM -0400, jlewis at lewis.org wrote:
> Is there a reason today's meeting/(comedy?) isn't being broadcast?  I
> brought in headphones today (hoping to get better sound quality) only to
> find the stream doesn't work and a note saying ARIN would only be
> streaming the first 2 days.

The member's meeting is for members only and not public per se.  There
isn't an easy mechanism in place to authenticate listeners to the
stream..

-ron


From owen at delong.com  Fri Oct 24 11:55:55 2003
From: owen at delong.com (Owen DeLong)
Date: Fri, 24 Oct 2003 08:55:55 -0700
Subject: [ppml] Proposal
In-Reply-To: <Pine.LNX.4.44.0310241149290.8137-100000@redhat1.mmaero.com>
References: <Pine.LNX.4.44.0310241149290.8137-100000@redhat1.mmaero.com>
Message-ID: <56840000.1067010955@odlaptop>

Well... I would presume that since it's a MEMBERS meeting, not an open
public policy meeting that there is no way to authenticate MEMBERS on
the webcast and that is why it isn't being webcast.

I also notice that it appears there is no video-taping.

Owen


--On Friday, October 24, 2003 11:51:07 AM -0400 jlewis at lewis.org wrote:

> Is there a reason today's meeting/(comedy?) isn't being broadcast?  I
> brought in headphones today (hoping to get better sound quality) only to
> find the stream doesn't work and a note saying ARIN would only be
> streaming the first 2 days.
>
> On Fri, 24 Oct 2003, Owen DeLong wrote:
>
>> I notice Ray carefully prohibited me from bringing this to the open mike. :-)
>>
>> Owen
>>
>>
>> --On Friday, October 24, 2003 10:40:45 AM -0500 John Curran <jcurran at istaff.org> wrote:
>>
>> > Owen,
>> >
>> > The Chicago Downtown Marriott A/V staff apparently agree with you,
>> > as they have been deftly turning down the microphone just before
>> > gongstrike...
>> >
>> > :-)
>> > /John
>> >
>> > At 8:25 AM -0700 10/24/03, Owen DeLong wrote:
>> >> I propose that John Curran not be allowed to combine Gong and electronic
>> >> amplification.
>> >>
>> >> Reasoning:
>> >>
>> >> The combination of Gong and Electronic Amplification is much like:
>> >>
>> >>       Fingernails and Chalkboards
>> >>       TLDs and Wildcard Records
>> >>
>> >> In general, if these things are not combined, the world is a better place.
>> >>
>> >> Owen
>>
>>
>>
>>
>
> ----------------------------------------------------------------------
>  Jon Lewis *jlewis at lewis.org*|  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031024/962a6a4e/attachment.sig>

From jim.romary at qwest.com  Fri Oct 24 12:22:18 2003
From: jim.romary at qwest.com (Romary, Jim)
Date: Fri, 24 Oct 2003 10:22:18 -0600
Subject: [ppml] Allocation and reallocation
Message-ID: <2328142DF53AD411BC6B0008C78644C010E70957@Denntex020.qwest.net>

Greetings. After a looooong haitus I am back to managing address 
space for a company I work for. For now, at least. I am Jim Romary, 
and I used to be {host|post|news|*}master for SuperNet, a regional ISP
that got
bought at the end of 1997. Among my functions was address acquisition 
and management pre-ARIN. 

I would like to weigh in with my understanding of the two terms. I don't

feel that appeals to Merriam Webster or any other source will produce 
much clarity on this issue, BTW. As in Scrabble, we need to agree on
an authority before we start playing that game. 

My understanding has always been the one recently espoused by Cathy,
which 
is actually less a definition than a statement of some characteristics:

Allocations can be broken up into assignments and given to customers,
but assignments can not be further delegated to other organizations, 
or customers.  

This has been even more succinctly stated by Owen, below. 

Allocations are addresses that should ALWAYS be returned by Assignees
upon 
the latter's seeking a new provider, its demise by bankruptcy, its
swallowing 
by another company with its own allocations, or any other event that
would 
cause the assignee to either go off-net or be topologically different
enough 
(network-wise) to get a new provider. Theoretically, companies that need

assignments come and go, seek new providers with cheaper fares, merge,
go 
off-shore, etc. They are and should be more mobile than Registeries. 
Allocatations to Registries can only be further assigned. Level of
"ownership" 
and control devolves downward as the distance from uber registry, ICANN,

increases. 

Allocations went to RIRs. Assignments went from the Regionals and
Providers 
to their customers. Customers always returned their assignments when
they 
sought a new Provider. I never "allocated" addresses to customers, and
for 
this reason, we never charged for use of address space. The terms
"allocation" 
and "ownership" were too entwined. 

Jim Romary

-----Original Message-----
From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Owen
DeLong
Sent: Thursday, October 23, 2003 10:36 PM
To: Michael.Dillon at radianz.com
Cc: ppml at arin.net
Subject: Re: [ppml] Allocation and reallocation


You came close to correct here Michael, but, you are backwards...

RIRs ALLOCATE to LIRs and both RIR and LIR can ASSIGN to end users.

Owen


--On Friday, October 24, 2003 02:01:39 AM +0100
Michael.Dillon at radianz.com wrote:

>> That is, RIRs ALLOCATE to LIRs.  End users,
>> on the other hand, receive ASSIGNMENTS from LIRs or RIRs.
>
> An important point. There are two types of organizations, LIRs and
> end users. RIRs assign to LIRs but end users can receive their
> allocation from either LIRs (the normal case) or RIRs.
>
> --Michael Dillon
>
>





From Michael.Dillon at radianz.com  Mon Oct 27 03:53:40 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 27 Oct 2003 08:53:40 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OFD76C3BAB.7D514F96-ON80256DCC.003048BB-80256DCC.0030DBA2@radianz.com>

>Allocations are addresses that should ALWAYS be returned by Assignees
>upon 
>the latter's seeking a new provider, its demise by bankruptcy, its

A further illustration of the futility of trying
to redefine the English language. Allocate and 
assign are clearly synonymous in Jim's mind even
though he recognizes a distinction in the properties
that we associate with address blocks. 

We simply do not have an appropriate verb or noun
to express that distinction in English. The normal 
course of events in this situation is to use
adjectives, i.e. black t-shirt and white t-shirt.

What is the essence of the distinction we are trying
to make and what are some of the ADJECTIVES we could
use to express that distinction? Is it simply that
some address blocks can be handed on to others by
the recipient and others can't? Or are there other
important properties that need to be distinguished?

--Michael Dillon







From jromary at kane.jsouth.com  Mon Oct 27 08:31:07 2003
From: jromary at kane.jsouth.com (Jim Romary)
Date: Mon, 27 Oct 2003 06:31:07 -0700 (MST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OFD76C3BAB.7D514F96-ON80256DCC.003048BB-80256DCC.0030DBA2@radianz.com> from "Michael.Dillon@radianz.com" at Oct 27, 2003 08:53:40 AM
Message-ID: <200310271331.GAA15675@kane.jsouth.com>

Actually, my statement was confused more as a result of slop and haste rather
than any imprecision in the language itself. While I agree that definitions
may fail us, I also think that any group can use any words they like
so long as they agree on meaning. Just about every walk of life has
language intrinsic to itself that is meaningless to those outside of the
cohort. If we do not like the words, we can come up with different ones, but 
of course we are still left with defining them. We can fight over the definitions 
and properties of "Sliport" and "Kiotric" as much as we can over "Assignment" 
and "Allocation". We have simply shifted the fight to a different language.  
All groups "redefine" language to suit their purposes.  Of course I meant 

Assignments are addressses that should ALWAYS be returned by Assignees
upon the latter's seeking a new provider, its demise by bankruptcy, its...

My point, imperfectly stated and cut 'n pasted from Outlook to Notepad
to Elm back to Outlook before sending, thus dodging effective review on 
account of all the <CR> and <LF>, was to comment on MY historical understanding 
of the differences between Assignments and Allocations. Regardless of how 
we define Assignees(ors) and Allocatees(ors). 

The issue of "micro-allocations" is again coming to the fore. Regardless of the 
definition of "micro" (what length, how many addrs) the issue is sounding as if
ALL address space will simply be allocated to end users (RIRs and Joe Cable are
both ends of some pipe, btw), and they may do as they wish with them. By that I 
mean "Here ya go! Get yerself a Provider (oops. Need a definition here) with 
a backbone (oops. Another definition) who will route them." Every single
stage of the analysis can be held up due to a certain level of imprecision, 
because every stage uses language. 

Whether AFRINIC, say, is given leave to hand out addrs of of given prefix due
to unique socio-politico-technologico-technical considerations, is different
that the issue of whether someone should be an Assignee or Allocatee.

I have a sneaky suspicion that many with dogs in this fight know full well
what the distinction between the words is. And what it has been ever since
I got into the fray in 1995 or so. They just don't like the policy itself.


|>Allocations are addresses that should ALWAYS be returned by Assignees
|>upon 
|>the latter's seeking a new provider, its demise by bankruptcy, its
|
|A further illustration of the futility of trying
|to redefine the English language. Allocate and 
|assign are clearly synonymous in Jim's mind even
|though he recognizes a distinction in the properties
|that we associate with address blocks. 
|
|We simply do not have an appropriate verb or noun
|to express that distinction in English. The normal 
|course of events in this situation is to use
|adjectives, i.e. black t-shirt and white t-shirt.
|
|What is the essence of the distinction we are trying
|to make and what are some of the ADJECTIVES we could
|use to express that distinction? Is it simply that
|some address blocks can be handed on to others by
|the recipient and others can't? Or are there other
|important properties that need to be distinguished?
|
|--Michael Dillon
|
|
|
|
|



From Michael.Dillon at radianz.com  Mon Oct 27 08:54:45 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 27 Oct 2003 13:54:45 +0000
Subject: [ppml] Is the time for conservation over?
Message-ID: <OF8F78CFA5.6C3777BE-ON80256DCC.004AAE3B-80256DCC.004C6CBA@radianz.com>

One area of address policy that is fairly consistent world-wide is the
view that IPv4 address space is scarce and that the policy must
be conservative, i.e. the policy must make conservation of IPv4
addresses a high priority.

I don't think that's true anymore. 

On the one hand, we have IPv6 deployed commercially in 3 of the
4 policy regions (Europe, AsiaPac, America) which indicates a continuing
trend toward a future time where IPv6 service will be almost as 
easy to find as IPv4 service. On the other hand, the worst possible 
outcomes discussed when CIDR was first deployed are not going
to happen. For instance there was a fear that the People's Republic
of China might want 1/4 of the IPv4 space because they have 1/4
of the planet's population. This has not happened and is now quite
unlikely to happen.

Therefore, I believe that all the RIRs should jointly do some research
to establish a prudent date at which IPv6 will be considered to have
reached critical mass so that there will be a significant migration of
users from IPv4 to IPv6. Once we set our sights on this date we should
set aside a certain amount of buffer in the IPv4 space, and then design 
our policy to consume the rest of the IPv4 space, not to preserve it.
At the same time, this policy shift should be presented as part of
a global IPv6 migration strategy because that is what it is. 

In addition, I don't see any good reason to wait until LIRs come and ask
for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will
be deploying IPv6 sometime. So why don't we just give every single
one of them an IPv6 /32 today. Instead of creating barriers to the 
adoption
of dual v4/v6 networks as we are today, we should be facilitating the
operation of dual v4/v6 networks. We need to create an environment
in which the end user can choose whether to use v4 or v6 rather than
constraining the end users with our v4-centric regulatory bureaucracy.

--Michael Dillon




From bicknell at ufp.org  Mon Oct 27 09:09:58 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 09:09:58 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <200310271331.GAA15675@kane.jsouth.com>
References: <OFD76C3BAB.7D514F96-ON80256DCC.003048BB-80256DCC.0030DBA2@radianz.com> <200310271331.GAA15675@kane.jsouth.com>
Message-ID: <20031027140958.GA27711@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 06:31:07AM -0700, Jim Romary wrote:
> I have a sneaky suspicion that many with dogs in this fight know full well
> what the distinction between the words is. And what it has been ever since
> I got into the fray in 1995 or so. They just don't like the policy itself.

At the BOF in particular, and during several of the comments on
policy people used the wrong term and had to correct themselves,
or be corrected.  In at least several of these cases the mistake
hurt their point, not helped.

Clearly some people would like to change the policy as well, but
I think those people would most like to keep using the confusing
words.  After all if people can't keep them straight they may well
be confused into thinking you want to change the "less important"
one when the reality is you're changing the more important one.

I think this is a huge issue because of the recent 2002-3 discussion.
Policy aside, many people both for and against mixed up the two
terms.  This caused both sides to be frustrated and have a harder
time making their point.  I think it's far more dangerous to have
someone make a mistake (which has happened to many people, many
times) and have it end up in a mailing list archive so that someone
later can pull it up to support the opposite view without realizing
the person was really against the idea the whole time.

Having our own terms is fine.  If we called these two classes of
addresses "snozzlefraz" and "benkendup" that would be a huge
improvement in my book.  Having them be described by words that
don't require you to go to a glossary to understand policy is even
better.

There are short terms that work:

     Assignment       Allocation
     ------------     --------------
     reassignable     non-reassignable
     delegatable      non-delegatable
     divisible        homogeneous

Notice the words I suggest are antonyms, yet the words we use today are
synonyms.  Using synonyms for the same thing is a bad idea.  I think we
can illustrate this with some other bad examples:

     Assignment       Allocation
     ------------     --------------
     digits           numbers
     IP's             addresses
     delegated        designated

What really gets me about all of this though is that this is the
type of issue that keeps people from participating in ARIN.  I've
already had the discussion with people at the office about this
issue and their basic response is "they can't get people to agree
on two simple clear terms to describe what they do, so you sit
around and argue about it for days on end sometimes switching sides
accidently because the terms are confusing?  I have better things
to do."

It's similarly bad when I forward proposals like 2002-3 to my
colleagues and they simply mail back and say "so what's the difference
between an assignment and allocation anyway?"  It seems like for
something that simple they should be able to just figure it out,
don't you think?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/84e6e809/attachment.sig>

From bicknell at ufp.org  Mon Oct 27 09:15:58 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 09:15:58 -0500
Subject: [ppml] Is the time for conservation over?
In-Reply-To: <OF8F78CFA5.6C3777BE-ON80256DCC.004AAE3B-80256DCC.004C6CBA@radianz.com>
References: <OF8F78CFA5.6C3777BE-ON80256DCC.004AAE3B-80256DCC.004C6CBA@radianz.com>
Message-ID: <20031027141558.GB27711@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 01:54:45PM +0000, Michael.Dillon at radianz.com wrote:
> Therefore, I believe that all the RIRs should jointly do some research
> to establish a prudent date at which IPv6 will be considered to have
> reached critical mass so that there will be a significant migration of
> users from IPv4 to IPv6. Once we set our sights on this date we should

I am going to strongly disagree on this point at this time.  We
don't know that there will /ever/ be a strong migration of users
to IPv6.  IPv6 may yet flop completely, be replaced by IPv8 or
something before it ever reaches full deployment, or even always
live side by side with IPv4.

Even if we assume everything migrates to IPv6, I see no reason why
we should change IPv4 policy at all.  First, if people are migrating
IPv4 policy becomes irrevelant anyway.  Second, if the IPv4 policy
is hinderng things we should fix it in IPv6 policy to more quickly
encourage cut over.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/677eeee3/attachment.sig>

From bicknell at ufp.org  Mon Oct 27 09:42:41 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 09:42:41 -0500
Subject: [ppml] Follow on to 2003-4, and suggested change.
Message-ID: <20031027144241.GA30010@ussenterprise.ufp.org>


One aspect of 2003-4 was a waver of 5.1.1.d (in
http://www.arin.net/policy/ipv6_policy.html) which states:

  d) have a plan for making at least 200 /48 assignments to other
     organizations within two years.

Down in section 5.4.1, Assignment address space size, we have
guidelines for /48, /64, and /128 assignments.

Working for a provider who is likely to make a lot of /64 assignments,
at least relative to /58 assignments the wording of section d leaves
an immediate problem.  /64's don't count.

So, leaving the 200 as is for today, I propose the following new text
for 5.1.1.d to replace the existing 5.1.1.d:

  d) have a plan for making at least 200 /1 to /64 assignments
     under the rules defined in section 5.4, Assignment.

This specifically excludes "oddballs" (eg, the /128 case) and more
closely makes it mean (translated from policy to English) "we want
you to get 200 other organizations using IPv6".  The only downside
of the fully inclusive language is that it also includes section
5.4.3, which are internal assignments, but between the fact that
it makes the policy fully consistent and I think 200 is too high
that doesn't really bother me.

I'd specifically prefer this thread not go too deep into the
discussion of the 200 number, if we want to change that number let's
start a different thread and do it independent of this change so
the two don't share fate if they come to a meeting.

Comments?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/7239b164/attachment.sig>

From Michael.Dillon at radianz.com  Mon Oct 27 10:11:42 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 27 Oct 2003 15:11:42 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OFD6575B87.3D57BB3E-ON80256DCC.00521592-80256DCC.0053785D@radianz.com>

>There are short terms that work:
>
>Assignment       Allocation
>------------     --------------
>reassignable     non-reassignable
>delegatable      non-delegatable
>divisible        homogeneous

>Notice the words I suggest are antonyms, yet the words we use today are
>synonyms. 

Remember in my email message I suggested that the proper way
to distinguish address block with different properties was to use
an adjective rather than a verb or a noun? Leo's suggestions are
all adjectives.

I also think his perception about antonyms is right on the mark.

We have tried to change the English language by trying to
use two synonyms to represent two opposite characteristics
and we have failed.

To get back to the point, when an RIR or an ISP takes
a large address block and sets aside a smaller portion
of it for use by another organization, that action is
allocation or assignment or delegation or any other
similar English term.

The block which has been set aside carries with it
a set of properties. Which of these properties are
important enough to be enshrined in policy? Once we are
agreed on that, then how can we clearly express that
policy in plain English so that everyone can understand
the policy without needing an insider to explain it. Even though
the vast majority of people in the ARIN region speak English,
many of them do not speak it as their first language due 
to the large number of immigrants and the large French
and Spanish speaking populations in the region. We cannot
rely on making subtle distinctions with the language because
that only creates an overall negative impression of ARIN
and of the whole IP addressing arena.

For the next meeting in Vancouver, I intend to present
a policy proposal that will completely erase the distinction
between allocation and assignment as well as completely
erase the notion that there are two classes of address blocks.
I believe that a reasonable policy can clearly be expressed
using classes of organization (end user, ISP) and specific
characteristics attached to address blocks issued by ARIN.
Clearly the ability to allocate or assign or delegate subsets
of a block will be one of those characteristics.

Think clarity and simplicity.

--Michael Dillon




From Michael.Dillon at radianz.com  Mon Oct 27 10:23:16 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 27 Oct 2003 15:23:16 +0000
Subject: [ppml] Follow on to 2003-4, and suggested change.
Message-ID: <OF2E0CC206.D7A007FF-ON80256DCC.0053B590-80256DCC.0054877C@radianz.com>

>I'd specifically prefer this thread not go too deep into the
>discussion of the 200 number, if we want to change that number let's
>start a different thread and do it independent of this change so
>the two don't share fate if they come to a meeting.

Actually, I don't think the policy should have a fee waiver at all.
If there is a fee waiver, the BoT should just go ahead and do it
because they can.

>From a policy point of view, it is better to focus on what this
time period is meant to represent. The policy is drawing a distinction
between the time before X number of allocations of size Y or greater.
Why? What changes? Is there a name for the new state of affairs after
the change has occurred?

This is important because if we can put our finger on the essence of
this new state of affairs, then we are better able to go back and 
determine how to best measure its onset.

My take is that the onset of IPv6 critical mass is N ISPs who have
each assigned more than M allocations of /48. In other words, we have
lots of ISPs who are using IPv6 enough so that their IPv6 service has
reached a critical mass for that ISP's own network.

Do you think that "critical mass" is the right threshold event that
we are looking for here?

--Michael Dillon




From bicknell at ufp.org  Mon Oct 27 10:26:36 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 10:26:36 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OFD6575B87.3D57BB3E-ON80256DCC.00521592-80256DCC.0053785D@radianz.com>
References: <OFD6575B87.3D57BB3E-ON80256DCC.00521592-80256DCC.0053785D@radianz.com>
Message-ID: <20031027152636.GA31658@ussenterprise.ufp.org>


I'd like to ask a simple question of those on the list:

  Is there a technical reason to have a distinction between ASSIGNMENT
  and ALLOCATION?

  -or-

  Is the distinction between ASSINGMENT and ALLOCATION a means to
  implementing a fee structure?

I ask, because if it is the latter, fee structures are not to be
part of policy (this was made clear at the meeting by the BoT).

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/dbda887b/attachment.sig>

From Michael.Dillon at radianz.com  Mon Oct 27 10:31:21 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 27 Oct 2003 15:31:21 +0000
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
Message-ID: <OF92C59B7B.4852A479-ON80256DCC.0054D20C-80256DCC.005544A0@radianz.com>

>It sounds a little bit contradictory to give away IPv4 addresses when
>you want people to migrate to IPv6, doesn't it? One of the supposed
>advantage of IPv6 is the as-much-as-you-can-eat approach to addresses

>So I think your proposal is seriously flawed and contradicts your
>desired goal.

You forgot this next bit. Think it through...

>> In addition, I don't see any good reason to wait until LIRs come and 
ask
>> for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will
>> be deploying IPv6 sometime. So why don't we just give every single
>> one of them an IPv6 /32 today. Instead of creating barriers to the
>> adoption

We give out free IPv6 addresses to everyone using IPv4. And we make
it easier for new organizations to receive blocks of globally
unique registered IPv4 addresses, i.e. not hijacked addresses
and not RFC 1918 addresses.

In any case, this is just lowering a barrier. It doesn't solve
every IPv6 issue but it does remove an unecessary barrier.

--Michael Dillon




From lea.roberts at stanford.edu  Mon Oct 27 10:47:46 2003
From: lea.roberts at stanford.edu (Lea Roberts)
Date: Mon, 27 Oct 2003 07:47:46 -0800 (PST)
Subject: [ppml] Follow on to 2003-4, and suggested change.
In-Reply-To: <20031027144241.GA30010@ussenterprise.ufp.org>
Message-ID: <Pine.GSO.4.44.0310270741180.3869-100000@networking.Stanford.EDU>

Leo -

I am curious about your base assumption here. What will be your criteria
for deciding when to "assign" a /64 instead of a /48?  Specifically, are
you thinking of a /64 for other than DSL or modem connections?

						thanks,  /Lea

On Mon, 27 Oct 2003, Leo Bicknell wrote:

>
> One aspect of 2003-4 was a waver of 5.1.1.d (in
> http://www.arin.net/policy/ipv6_policy.html) which states:
>
>   d) have a plan for making at least 200 /48 assignments to other
>      organizations within two years.
>
> Down in section 5.4.1, Assignment address space size, we have
> guidelines for /48, /64, and /128 assignments.
>
> Working for a provider who is likely to make a lot of /64 assignments,
> at least relative to /58 assignments the wording of section d leaves
> an immediate problem.  /64's don't count.
>
> So, leaving the 200 as is for today, I propose the following new text
> for 5.1.1.d to replace the existing 5.1.1.d:
>
>   d) have a plan for making at least 200 /1 to /64 assignments
>      under the rules defined in section 5.4, Assignment.
>
> This specifically excludes "oddballs" (eg, the /128 case) and more
> closely makes it mean (translated from policy to English) "we want
> you to get 200 other organizations using IPv6".  The only downside
> of the fully inclusive language is that it also includes section
> 5.4.3, which are internal assignments, but between the fact that
> it makes the policy fully consistent and I think 200 is too high
> that doesn't really bother me.
>
> I'd specifically prefer this thread not go too deep into the
> discussion of the 200 number, if we want to change that number let's
> start a different thread and do it independent of this change so
> the two don't share fate if they come to a meeting.
>
> Comments?
>
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>



From david.conrad at nominum.com  Mon Oct 27 10:58:10 2003
From: david.conrad at nominum.com (David Conrad)
Date: Mon, 27 Oct 2003 07:58:10 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
In-Reply-To: <OF92C59B7B.4852A479-ON80256DCC.0054D20C-80256DCC.005544A0@radianz.com>
Message-ID: <r02000200-1028-5D70DC5C089611D8AC0B000393DB42B2@[64.81.244.40]>

Hi,

>>> It's not scarce and the vast majority of IPv4 LIRs will
>>> be deploying IPv6 sometime. So why don't we just give every single
>>> one of them an IPv6 /32 today. Instead of creating barriers to the
>>> adoption

The obvious implication of this is that it pretty much guarantees the
creation of a new and potentially much bigger swamp.

I'll leave it to others to determine if that is a serious concern.

Rgds,
-drc


From bicknell at ufp.org  Mon Oct 27 11:00:25 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 11:00:25 -0500
Subject: [ppml] Follow on to 2003-4, and suggested change.
In-Reply-To: <Pine.GSO.4.44.0310270741180.3869-100000@networking.Stanford.EDU>
References: <20031027144241.GA30010@ussenterprise.ufp.org> <Pine.GSO.4.44.0310270741180.3869-100000@networking.Stanford.EDU>
Message-ID: <20031027160025.GA33621@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 07:47:46AM -0800, Lea Roberts wrote:
> I am curious about your base assumption here. What will be your criteria
> for deciding when to "assign" a /64 instead of a /48?  Specifically, are
> you thinking of a /64 for other than DSL or modem connections?

A large aspect of our business is running data centers.  Typically
we drop off a 100Mbps FE, or 1000Mbps GE link to a customer who
plugs in a number of layer 2 switches and installs many servers.

As far as I can tell the best thing to do with these customers is
assign a /64.  A shorter prefix would be a waste, as they own no
layer 3 gear, so they would have no way to break it into separate
lans anyway.  I suspect anyone who runs data centers will generally
be assigning /64's in the data centers to customers.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/df01ed6a/attachment.sig>

From jlewis at lewis.org  Mon Oct 27 11:02:28 2003
From: jlewis at lewis.org (jlewis at lewis.org)
Date: Mon, 27 Oct 2003 11:02:28 -0500 (EST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027152636.GA31658@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.44.0310271055260.8137-100000@redhat1.mmaero.com>

On Mon, 27 Oct 2003, Leo Bicknell wrote:

> I'd like to ask a simple question of those on the list:
> 
>   Is there a technical reason to have a distinction between ASSIGNMENT
>   and ALLOCATION?

Are you talking about ASSIGNMENT|ALLOCATION by ARIN or in general?  When I
allocate IPs to an ISP customer, ARIN creates an ORG ID (i.e. we're INCC)  
for the holder of the allocation, allowing them to submit swips.  If ARIN
had to do this for every customer we assign (in the generic, not ARIN
meaning) IPs to, most of whom will never submit a swip, the number of ORG
IDs would skyrocket for no good reason.
 
I agree that assignment/allocation are a bit too non-descriptive and very 
easy to use confusingly (as I almost did above).  Maybe they should be 
swipable (allocation) and non-swipable (assignment) and then we wouldn't 
have to be careful about which of allocation|assignment we used.
 
----------------------------------------------------------------------
 Jon Lewis *jlewis at lewis.org*|  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |  
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From bicknell at ufp.org  Mon Oct 27 11:09:27 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 11:09:27 -0500
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
In-Reply-To: <r02000200-1028-5D70DC5C089611D8AC0B000393DB42B2@[64.81.244.40]>
References: <OF92C59B7B.4852A479-ON80256DCC.0054D20C-80256DCC.005544A0@radianz.com> <r02000200-1028-5D70DC5C089611D8AC0B000393DB42B2@[64.81.244.40]>
Message-ID: <20031027160927.GB33621@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 07:58:10AM -0800, David Conrad wrote:
> The obvious implication of this is that it pretty much guarantees the
> creation of a new and potentially much bigger swamp.

A new swamp, yes.  Bigger, I'm not so sure.

From http://www.cymru.com/BGP/robbgp01.html there are 132658 prefixes
(max, from the last month) in the table.  From
http://www.cymru.com/BGP/asncount01.html there are 16181 ASN's (max
from the last month) in the table.

If every ASN had a single IPv6 /32 the IPv6 table would be 12% of
the current IPv4 routing table.

So, while I don't mike Mr. Dillion's current proposal, I don't think
that something along the lines of "everyone with an asn and one or
more IPv4 blocks can receive one IPv6 block of appropriate size"
would be a bad thing.  Indeed, I'd rather see each ASN with it's
own /32 than see some get /48's from three providers and start
reannouncing them (which is a big part of the current IPv4 table
bloat).

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/d07b0dd0/attachment.sig>

From bicknell at ufp.org  Mon Oct 27 11:15:34 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 11:15:34 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.LNX.4.44.0310271055260.8137-100000@redhat1.mmaero.com>
References: <20031027152636.GA31658@ussenterprise.ufp.org> <Pine.LNX.4.44.0310271055260.8137-100000@redhat1.mmaero.com>
Message-ID: <20031027161534.GC33621@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 11:02:28AM -0500, jlewis at lewis.org wrote:
> Are you talking about ASSIGNMENT|ALLOCATION by ARIN or in general?  When I
> allocate IPs to an ISP customer, ARIN creates an ORG ID (i.e. we're INCC)  
> for the holder of the allocation, allowing them to submit swips.  If ARIN
> had to do this for every customer we assign (in the generic, not ARIN
> meaning) IPs to, most of whom will never submit a swip, the number of ORG
> IDs would skyrocket for no good reason.

I'm thinking a little more general, as there are a number of "under
the hood" details that would need to be worked out.

Basically I think all blocks should be the same.  If you submit a
swip, on that swip you can either mark it "simple" (that person has
it and can't do anything else with it), or "subdivideable", in which
case they get an org id and can swip parts of that block (perhaps
all simple, or perhaps they can still set simple and subdivideable).

Then, separate from this single policy for addresses given out would
be a fee structure based on something like the size of the block.
It could be based on the number of SWIP's (direct database cost),
but I don't like that as it may discourage people from SWIP'ing in
some cases.

Anyway, what I was really getting at is are there tehnical policy
reasons why one group can SWIP space, and one group can't SWIP space?
For instance, do we not trust "end users" (to use current terms) to
SWIP space if they later end up with a "customer"?  Or is it just a
way to charge "end users" a lower fee?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/71d8fb48/attachment.sig>

From Michael.Dillon at radianz.com  Mon Oct 27 11:17:54 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 27 Oct 2003 16:17:54 +0000
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
Message-ID: <OF32AC2948.2D9019E8-ON80256DCC.00583C7B-80256DCC.00598793@radianz.com>

>>>> It's not scarce and the vast majority of IPv4 LIRs will
>>>> be deploying IPv6 sometime. So why don't we just give every single
>>>> one of them an IPv6 /32 today. Instead of creating barriers to the
>>>> adoption

>The obvious implication of this is that it pretty much guarantees the
>creation of a new and potentially much bigger swamp.

Historically, the swamp was a large block in which random 
sized blocks were allocated to organizations on a first-come
first-served basis. There was no plan to the allocations so
that an end user would get a /24 right next to a /22 going
to an ISP followed by a /23 to another end user. When an ISP
needed more space they got a discontiguous block.

With IPv6 we are somewhat smarter. To begin with, all ISP
allocations are the same size (/32) and they all come out
of a /29 reservation. The ISP's allocation can grow 8 times
before we need to use discontiguous blocks. End users are
less likely to get an allocation from the registry because
with their /48 from their ISP they can build huge internal
networks and with IPv6 they can use a second /48 from another
ISP to assign additional addresses to every one of their
IPv6 hosts and have a functional form of multihomed connectivity.

Not to mention the fact that even if we waste the entire
block of IPv6 space that is earmarked for unicast use today, 
there is still tons of IPv6 space that hasn't been earmarked
for use where we could start over again and do it right. In
other words if we did create a swamp-like situation, we have
an IPv6 safety valve that we can use to bail out of the situation.

In any case, I'm only sugesting that we give out a free /32 from
a /29 reservation to every existing ISP member of ARIN. End users
would be encouraged to apply to their upstream ISPs for a set
of /48 allocations. If all ISPs have IPv6 addresses available, then
they should be able to assign /48s to any customers who want
space regardless of whether or not the ISP has deployed any IPv6
network infrastructure yet. This may seem a bit odd, but remember that
people can use IPv6 over IPv4 tunnels so end users can use IPv6
with IPv4 ISPs if they can get IPv6 addresses. They may connect
to a v6 tunnel broker or they may just run a v6 VPN for some 
internal purpose. It's our job to remove barriers to IPv6 deployment;
not to decide whether any particular use of IPv6 is allowed or not.

--Michael Dillon



From jromary at kane.jsouth.com  Mon Oct 27 11:18:55 2003
From: jromary at kane.jsouth.com (Jim Romary)
Date: Mon, 27 Oct 2003 09:18:55 -0700 (MST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027152636.GA31658@ussenterprise.ufp.org> from "Leo Bicknell" at Oct 27, 2003 10:26:36 AM
Message-ID: <200310271618.JAA16545@kane.jsouth.com>

Fees have never part of my calculus. I must stress that I use
the two terms only because those were the two that were used
in my history, and I don't know any better. Now that I am back
in the address mumble mumble game, I can see that the words have
have assumed great meaning and import. As the stakes rise in any
endeavor, constituent elements of the undertaking assume grander
stature. 

I agree that fees should not be part of this issue, though I
have had customers who have said "We paid Provider A for these
addresses. You need to route them". I wish no Providers charged
for address leasing as unanimity on this issue would decrease the
amount of reeducation needed. Confusion over the true meaing
behind RFC2050 is yet another point of confusion.

|
|I'd like to ask a simple question of those on the list:
|
|  Is there a technical reason to have a distinction between ASSIGNMENT
|  and ALLOCATION?
|
|  -or-
|
|  Is the distinction between ASSINGMENT and ALLOCATION a means to
|  implementing a fee structure?
|
|I ask, because if it is the latter, fee structures are not to be
|part of policy (this was made clear at the meeting by the BoT).
|
|--=20
|       Leo Bicknell - bicknell at ufp.org - CCIE 3440
|        PGP keys at http://www.ufp.org/~bicknell/
|Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
|


From owen at delong.com  Mon Oct 27 11:22:17 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 08:22:17 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <200310271331.GAA15675@kane.jsouth.com>
References: <200310271331.GAA15675@kane.jsouth.com>
Message-ID: <14150000.1067271737@odlaptop>

I have a number of ASSIGNMENTS which I fully expect are mine to take with
me when I switch providers.  That is because they are direct ASSIGNMENTS
from the RIR.  ASSIGNMENT vs. ALLOCATION is not what makes this distinction.
That distinction is handled by "Provider Assigned" and "Provider Independent"
space definitions.  Generally, Providers (LIRs) do not make Allocations,
but, in some cases, they do.  I know that when the LIR was part of my job
at Exodus, we had a number of customers to whom we Allocated space and they
submitted SWIPs for their customers to ARIN directly.  However, were they
to move, we fully expected all of that PA Allocation back.

RIRs issue PI space.  LIRs issue PA space.  [LR]IRs issue allocations to
entities which will divide that space up for customer use.  [LR]IRs issue
assignments to entities which will use that space for their own purposes.

I hope the above paragraph provides a sufficient definition to allow us to
at least agree on what these terms currently mean in the ARIN context.  If
we want to come up with new adjectives or whatever, I have no problem with
that, but, I'd like to start that definition from a common frame of reference
about what we are defining.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/9a1cb648/attachment.sig>

From owen at delong.com  Mon Oct 27 11:30:33 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 08:30:33 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027140958.GA27711@ussenterprise.ufp.org>
References: <OFD76C3BAB.7D514F96-ON80256DCC.003048BB-80256DCC.0030DBA2@radianz.com> <200310271331.GAA15675@kane.jsouth.com> <20031027140958.GA27711@ussenterprise.ufp.org>
Message-ID: <19320000.1067272233@odlaptop>

Further making Leo's point, he reversed his column headers and made other
mistakes in this table.

Assignment cannot be reassigned.  Allocation can be sub-allocated or
assigned.  So:

Assignment      Allocation
-------------   --------------
non-divisible   divisible

As to the property of portability, the best terms I've run into so far
are: "Provider Assigned" and "Provider Independent".  There is a rare
case of "Provider Allocated" which would apply to a non-portable allocation
from an upstream provider.

> There are short terms that work:
>
>      Assignment       Allocation
>      ------------     --------------
>      reassignable     non-reassignable
>      delegatable      non-delegatable
>      divisible        homogeneous

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/cb007d6f/attachment.sig>

From lee.howard at mci.com  Mon Oct 27 11:29:28 2003
From: lee.howard at mci.com (Lee Howard)
Date: Mon, 27 Oct 2003 11:29:28 -0500 (EST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OFD6575B87.3D57BB3E-ON80256DCC.00521592-80256DCC.0053785D@radianz.com>
Message-ID: <Pine.GSO.4.20.0310271120150.1740-100000@sun222-31.corp.us.uu.net>

On Mon, 27 Oct 2003 Michael.Dillon at radianz.com wrote:

> Date: Mon, 27 Oct 2003 15:11:42 +0000
> From: Michael.Dillon at radianz.com
> To: ppml at arin.net
> Subject: Re: [ppml] Allocation and reallocation
> 
[. . .]
> 
> For the next meeting in Vancouver, I intend to present
> a policy proposal that will completely erase the distinction
> between allocation and assignment as well as completely
> erase the notion that there are two classes of address blocks.
> I believe that a reasonable policy can clearly be expressed
> using classes of organization (end user, ISP) and specific
> characteristics attached to address blocks issued by ARIN.
> Clearly the ability to allocate or assign or delegate subsets
> of a block will be one of those characteristics.
> 
> Think clarity and simplicity.

Should ARIN harmonize with other RIRs towards the term "LIR"?

I note that APNIC uses the same language as ARIN:
http://www.apnic.net/info/faq/apnic_faq/using_address.html#1

I look forward to reading your proposal.

Lee



> 
> --Michael Dillon
> 
> 



From Michael.Dillon at radianz.com  Mon Oct 27 11:33:53 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 27 Oct 2003 16:33:53 +0000
Subject: [ppml] Follow on to 2003-4, and suggested change.
Message-ID: <OF79ADD38D.111CDF9E-ON80256DCC.0059CD2B-80256DCC.005AFE54@radianz.com>

>A large aspect of our business is running data centers.  Typically
>we drop off a 100Mbps FE, or 1000Mbps GE link to a customer who
>plugs in a number of layer 2 switches and installs many servers.

>As far as I can tell the best thing to do with these customers is
>assign a /64.  A shorter prefix would be a waste, as they own no
>layer 3 gear, so they would have no way to break it into separate
>lans anyway.  I suspect anyone who runs data centers will generally
>be assigning /64's in the data centers to customers.

I don't think this is consistent with IPv6 policy. Specifically, the 
policy says:

    Assignments are to be made in accordance with the existing guidelines 
    [RFC3177,RIRs-on-48], which are summarized here as:

    - /48 in the general case, except for very large subscribers

    - /64 when it is known that one and only one subnet is needed by 
design

I don't think you can say that one and only one subnet is needed by design 
because it is your
customer's network and not yours. If a customer asks you for an IPv6 
assignment then you would
have to ask the customer to agree to not *EVER* install a router or a 
firewall or a NAT
device otherwise you don't have a design rule to justify the /64.

The prudent thing to do here would be to assign a /48 because this is an 
endsite network
outside of your management control. They may assign a separate subnet with 
separate addresses
for managing their devices. They may set up a separate subnet with 
separate physical interfaces for
doing backups of their servers. They may deploy a firewall that needs a 
DMZ subnet.

There is no waste of addresses by doing this. Remember that IPv6 gives us 
340 undecillion, 282 decillion, 366 nonillion, 920 octillion,
938 septillion, 463 sextillion, 463 quintillion, 374 quadrillion,
607 trillion, 431 billion, 768 million, 211 thousand, 456 addresses
to use. That is an awful lot of room, unimaginably huge. The people
who have thought these things through carefully, think that it's ok
to use up an entire /48 for any network that might grow and change
in topology. For now, we should accept that and work with it. Save the
/64 allocations for cell-phones and PDAs were there is unlikely to be 
more than one subnet on the device. If there is any network infrastructure
beyond your demarc, including a layer 2 switch, then you probably cannot
predict whether or not they will someday need to subnet. Therefore, /48.

--Michael Dillon 




From jromary at kane.jsouth.com  Mon Oct 27 11:37:54 2003
From: jromary at kane.jsouth.com (Jim Romary)
Date: Mon, 27 Oct 2003 09:37:54 -0700 (MST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <14150000.1067271737@odlaptop> from "Owen DeLong" at Oct 27, 2003 08:22:17 AM
Message-ID: <200310271637.JAA16730@kane.jsouth.com>

|I have a number of ASSIGNMENTS which I fully expect are mine to take with
|me when I switch providers.  That is because they are direct ASSIGNMENTS
|from the RIR.  ASSIGNMENT vs. ALLOCATION is not what makes this distinction.
|That distinction is handled by "Provider Assigned" and "Provider Independent"
|space definitions.  Generally, Providers (LIRs) do not make Allocations,
|but, in some cases, they do.  I know that when the LIR was part of my job
|at Exodus, we had a number of customers to whom we Allocated space and they
|submitted SWIPs for their customers to ARIN directly.  However, were they
|to move, we fully expected all of that PA Allocation back.

I never used the term ALLOCATE for any Customer address space I gave out.
Not for the /22 to the wholesaler, nor for the /29 to the hosting client.
The party that needs to SWIP was also not controlling. In almost all
cases the large Customers knew who their customers were. We had no
clue, so relied on the Wholesalers with the large Assignments to SWIP.
It was my job to harass them to do so to get the provable utilization
up. 

I have never been given any space that I could, in turn, give out as "Provider 
Independent". 


From owen at delong.com  Mon Oct 27 11:44:27 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 08:44:27 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027152636.GA31658@ussenterprise.ufp.org>
References: <OFD6575B87.3D57BB3E-ON80256DCC.00521592-80256DCC.0053785D@radianz.com> <20031027152636.GA31658@ussenterprise.ufp.org>
Message-ID: <31700000.1067273067@odlaptop>

There are differences in the justifications required and other aspects of the process
for getting space between assignments and allocations.  (Believe me, I've been
through both processes).

End-user assignments are a much simpler process and that is how it should be.  A single
organization which can justify sufficient space and wants to multi-home should still
be expected to live up to the principals of address conservation, efficient utilization,
etc., but, there is no need for them to understand SWIP or RWHOIS.  There is no need
for them to deal with any of the sub-allocation or "re-assignment" (misnomer since
it's assignment and re-assignment is not allowed, but, re- distinguishes between
an LIR assignment (re-) and an RIR assignment).  End users receiving assignments
are not becoming LIRs.  Organizations receiving allocations are LIRs.

Owen


--On Monday, October 27, 2003 10:26:36 AM -0500 Leo Bicknell <bicknell at ufp.org> wrote:

>
> I'd like to ask a simple question of those on the list:
>
>   Is there a technical reason to have a distinction between ASSIGNMENT
>   and ALLOCATION?
>
>   -or-
>
>   Is the distinction between ASSINGMENT and ALLOCATION a means to
>   implementing a fee structure?
>
> I ask, because if it is the latter, fee structures are not to be
> part of policy (this was made clear at the meeting by the BoT).
>
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/f93029bd/attachment.sig>

From cscott at gaslightmedia.com  Mon Oct 27 11:49:30 2003
From: cscott at gaslightmedia.com (Charles Scott)
Date: Mon, 27 Oct 2003 11:49:30 -0500 (EST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027161534.GC33621@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.44.0310271141470.22893-100000@harbor.gaslightmedia.com>


Leo:
  The problem with not making a distinction between assignable space and 
end-user space is that it ignores the issue of determining appropriate 
utilization. The 80% and 25%/50% guidelines are that way because 
consumption of address space must be considered differently for 
assignable space vs end-user space. (Which is why I noted that 2003-10 was 
problematic in that it applied an issue related to end-user space to 
assignable space.)

Chuck Scott




On Mon, 27 Oct 2003, Leo Bicknell wrote:

> In a message written on Mon, Oct 27, 2003 at 11:02:28AM -0500, jlewis at lewis.org wrote:
> > Are you talking about ASSIGNMENT|ALLOCATION by ARIN or in general?  When I
> > allocate IPs to an ISP customer, ARIN creates an ORG ID (i.e. we're INCC)  
> > for the holder of the allocation, allowing them to submit swips.  If ARIN
> > had to do this for every customer we assign (in the generic, not ARIN
> > meaning) IPs to, most of whom will never submit a swip, the number of ORG
> > IDs would skyrocket for no good reason.
> 
> I'm thinking a little more general, as there are a number of "under
> the hood" details that would need to be worked out.
> 
> Basically I think all blocks should be the same.  If you submit a
> swip, on that swip you can either mark it "simple" (that person has
> it and can't do anything else with it), or "subdivideable", in which
> case they get an org id and can swip parts of that block (perhaps
> all simple, or perhaps they can still set simple and subdivideable).
> 
> Then, separate from this single policy for addresses given out would
> be a fee structure based on something like the size of the block.
> It could be based on the number of SWIP's (direct database cost),
> but I don't like that as it may discourage people from SWIP'ing in
> some cases.
> 
> Anyway, what I was really getting at is are there tehnical policy
> reasons why one group can SWIP space, and one group can't SWIP space?
> For instance, do we not trust "end users" (to use current terms) to
> SWIP space if they later end up with a "customer"?  Or is it just a
> way to charge "end users" a lower fee?
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> 



From Michael.Dillon at radianz.com  Mon Oct 27 11:51:34 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 27 Oct 2003 16:51:34 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OF8C92BBEA.656068F2-ON80256DCC.005B9E5B-80256DCC.005C9CB6@radianz.com>

>I have a number of ASSIGNMENTS which I fully expect are mine to take with
>me when I switch providers.

OK, this characteristic could be called portability and is distinct from
the ability to subdivide the space that you have been issued. In another
context I would make a distinction between borrowed space which has to
be returned and space that is issued in perpetuity. However that last
term doesn't work here because space is not owned, it is issued based
on the need to use IPv4 and presumably, the grant expires when your need
for IPv4 goes away.

>RIRs issue PI space.  LIRs issue PA space.  [LR]IRs issue allocations to
>entities which will divide that space up for customer use.  [LR]IRs issue
>assignments to entities which will use that space for their own purposes.

I'm really trying to avoid the terms PI and PA because I don't believe
that ARIN and RIPE define these terms the same way. In addition, they
are also too darn similar, i.e. two letter abbreviation starting with P.

You'll also note that I am trying to vary the terminology that I use, i.e. 
I mentioned "space that
you have been issued" and "the grant expires". I'm doing this on purpose 
because once
we find the essential distinctions, we will be able to do this and still 
avoid confusion. That's
because we won't be overloading the allocate/assign/register/issue terms 
with special meanings.
Instead we will directly say things like portable divisible blocks and the 
meaning will be clear.

--Michael Dillon




From owen at delong.com  Mon Oct 27 11:54:53 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 08:54:53 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
In-Reply-To: <OF32AC2948.2D9019E8-ON80256DCC.00583C7B-80256DCC.00598793@radianz.com>
References: <OF32AC2948.2D9019E8-ON80256DCC.00583C7B-80256DCC.00598793@radianz.com>
Message-ID: <44310000.1067273693@odlaptop>


> With IPv6 we are somewhat smarter. To begin with, all ISP
> allocations are the same size (/32) and they all come out
> of a /29 reservation. The ISP's allocation can grow 8 times
> before we need to use discontiguous blocks. End users are
> less likely to get an allocation from the registry because
> with their /48 from their ISP they can build huge internal
> networks and with IPv6 they can use a second /48 from another
> ISP to assign additional addresses to every one of their
> IPv6 hosts and have a functional form of multihomed connectivity.

I am confused by this statememt, and, it has been one of the things
on my list of "things I've heard about v6 that don't yet make
sense to me" for a while, so, I'm finally going to ask it here...

How is this a functional form of multi-homed connectivity?

If I have a box with two /128s assigned to it, how does it know
which one corresponds to the provider that is up and routing
packets and not to use the one that is down at the moment?

To me, the whole point of multihoming is reliability.  That means,
my packets get through as long as at least one provider is up and
has reachability to/from the peer I want to talk to.  Does v6 require
me to run a routing protocol on EVERY host in order to do local
address selection for sourcing new conversations?

Seriously, I'm not trying to stir the pot, I just don't understand
this yet, and, now I need to know to make useful contribution to the
discussion.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/0f33cf68/attachment.sig>

From HRyu at norlight.com  Mon Oct 27 11:55:27 2003
From: HRyu at norlight.com (Hyunseog Ryu)
Date: Mon, 27 Oct 2003 10:55:27 -0600
Subject: [ppml] Allocation and reallocation
Message-ID: <OF20B7BD11.FF6FEF90-ON86256DCC.005C27E6@norlight.com>






As I understand for assignment/allocation, it is as following.

1) Assignment : ISP lease IP address to their customer with following
conditions.
      a) no reassignment to customer's customer.
      b) IP address information management is responsible for ISP, not
customer.
            So customer doesn't have any control over it's information by
ARIN whois database.
            If customer needs to update that information, they need to
contact ISP, and ISP should update that information.
            So SWIP or RWHOIS information management is ISP's
responsibility.
      So in most case, if ISP give - lease in accurate term - to the end
user customer or enterprise customer, it will be assignment.

2) Allocation: ISP lease IP address to the customer with following
conditions.
      1) customer can lease the subset or whole set of IP address to other
customer, which is customer's customer.
      2) SWIP or RWHOIS record management is customer's responsibility, and
they should follow RFC2050 for reassignment , which is allocation in ARIN's
term.
      So in most case, if ISP lease the IP address to ISPs, it will be
allocation.
      As a part of SWIP/RWHOIS management, customer will receive org-id or
, I would say, maintainer-id from ARIN because of this reason,
            even if customer is not a member of ARIN.

That's my term definition for assignment/allocation from Hyun's dictionary,
I would say.



Hyun



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hyunseog Ryu / CCDA, MCSE, CCIE candidate(written test passed)
Senior Network Engineer/Applications Engineering
Norlight Telecommunications, Inc.
13935 Bishops Drive
Brookfield, WI 53005
Tel. +1.262.792.7965
Fax. +1.262.792.7733
email: hryu at norlight.com


|---------+---------------------------->
|         |           jlewis at lewis.org |
|         |           Sent by:         |
|         |           owner-ppml at arin.n|
|         |           et               |
|         |                            |
|         |                            |
|         |           10/27/2003 10:02 |
|         |           AM               |
|         |                            |
|---------+---------------------------->
  >--------------------------------------------------------------------------------------------------------------|
  |                                                                                                              |
  |       To:       Leo Bicknell <bicknell at ufp.org>                                                              |
  |       cc:       ppml at arin.net, (bcc: Hyunseog Ryu/Brookfield/Norlight)                                       |
  |       Fax to:                                                                                                |
  |       Subject:  Re: [ppml] Allocation and reallocation                                                       |
  >--------------------------------------------------------------------------------------------------------------|




On Mon, 27 Oct 2003, Leo Bicknell wrote:

> I'd like to ask a simple question of those on the list:
>
>   Is there a technical reason to have a distinction between ASSIGNMENT
>   and ALLOCATION?

Are you talking about ASSIGNMENT|ALLOCATION by ARIN or in general?  When I
allocate IPs to an ISP customer, ARIN creates an ORG ID (i.e. we're INCC)
for the holder of the allocation, allowing them to submit swips.  If ARIN
had to do this for every customer we assign (in the generic, not ARIN
meaning) IPs to, most of whom will never submit a swip, the number of ORG
IDs would skyrocket for no good reason.

I agree that assignment/allocation are a bit too non-descriptive and very
easy to use confusingly (as I almost did above).  Maybe they should be
swipable (allocation) and non-swipable (assignment) and then we wouldn't
have to be careful about which of allocation|assignment we used.

----------------------------------------------------------------------
 Jon Lewis *jlewis at lewis.org*|  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________







From bicknell at ufp.org  Mon Oct 27 11:56:48 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 11:56:48 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.LNX.4.44.0310271141470.22893-100000@harbor.gaslightmedia.com>
References: <20031027161534.GC33621@ussenterprise.ufp.org> <Pine.LNX.4.44.0310271141470.22893-100000@harbor.gaslightmedia.com>
Message-ID: <20031027165648.GC35805@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 11:49:30AM -0500, Charles Scott wrote:
>   The problem with not making a distinction between assignable space and 
> end-user space is that it ignores the issue of determining appropriate 
> utilization. The 80% and 25%/50% guidelines are that way because 
> consumption of address space must be considered differently for 
> assignable space vs end-user space. (Which is why I noted that 2003-10 was 
> problematic in that it applied an issue related to end-user space to 
> assignable space.)

A very good technical point.

There seems to be a lack of harmony though.  An "end user" who
receives space from their upstream must show the same 80% as their
upstream ISP (see http://www.arin.net/policy/ipv4.html#reassign).
An "end user" who goes directly to ARIN can use the 25%/50% rule.

Is there a reason to hold the same end user to different criteria
based on who they ask?  Could this issue be solved by making the
25%/50% rule apply to downstream customers of an ISP, or by making
"end users" who request from ARIN use the same 80% rule?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/a92cd9ee/attachment.sig>

From owen at delong.com  Mon Oct 27 11:58:58 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 08:58:58 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.GSO.4.20.0310271120150.1740-100000@sun222-31.corp.us.uu.net>
References: <Pine.GSO.4.20.0310271120150.1740-100000@sun222-31.corp.us.uu.net>
Message-ID: <50240000.1067273938@odlaptop>

Michael,
        If your proposal does what you claim it will do below, it would be a
bad policy indeed.  There are good reasons for end-user assignments to exist
and not be treated entirely the same as allocations to LIRs.  I would support
a proposal clarifying the terminology and replacing assignment/allocation
distinctions with terms that provided a better description of what is really
going on, although, I would propose that we should include a reference translation
of the historical meaning of the obsoleted terms for people reviewing the archives.

Owen


--On Monday, October 27, 2003 11:29:28 AM -0500 Lee Howard <lee.howard at mci.com> wrote:

> On Mon, 27 Oct 2003 Michael.Dillon at radianz.com wrote:
>
>> Date: Mon, 27 Oct 2003 15:11:42 +0000
>> From: Michael.Dillon at radianz.com
>> To: ppml at arin.net
>> Subject: Re: [ppml] Allocation and reallocation
>>
> [. . .]
>>
>> For the next meeting in Vancouver, I intend to present
>> a policy proposal that will completely erase the distinction
>> between allocation and assignment as well as completely
>> erase the notion that there are two classes of address blocks.
>> I believe that a reasonable policy can clearly be expressed
>> using classes of organization (end user, ISP) and specific
>> characteristics attached to address blocks issued by ARIN.
>> Clearly the ability to allocate or assign or delegate subsets
>> of a block will be one of those characteristics.
>>
>> Think clarity and simplicity.
>
> Should ARIN harmonize with other RIRs towards the term "LIR"?
>
> I note that APNIC uses the same language as ARIN:
> http://www.apnic.net/info/faq/apnic_faq/using_address.html#1
>
> I look forward to reading your proposal.
>
> Lee
>
>
>
>>
>> --Michael Dillon
>>
>>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/67a92a74/attachment.sig>

From owen at delong.com  Mon Oct 27 12:00:39 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 09:00:39 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <200310271637.JAA16730@kane.jsouth.com>
References: <200310271637.JAA16730@kane.jsouth.com>
Message-ID: <50640000.1067274039@odlaptop>

correct, LIRs do not give out PI space.  Only RIRs give out PI space.  However,
LIRs give out PA assignments (non-swippable) and PA allocations (swippable).
RIRs also give out PI assignments (end-user) and PI allocations (LIRs).

Owen


--On Monday, October 27, 2003 09:37:54 AM -0700 Jim Romary <jromary at kane.jsouth.com> wrote:

>| I have a number of ASSIGNMENTS which I fully expect are mine to take with
>| me when I switch providers.  That is because they are direct ASSIGNMENTS
>| from the RIR.  ASSIGNMENT vs. ALLOCATION is not what makes this distinction.
>| That distinction is handled by "Provider Assigned" and "Provider Independent"
>| space definitions.  Generally, Providers (LIRs) do not make Allocations,
>| but, in some cases, they do.  I know that when the LIR was part of my job
>| at Exodus, we had a number of customers to whom we Allocated space and they
>| submitted SWIPs for their customers to ARIN directly.  However, were they
>| to move, we fully expected all of that PA Allocation back.
>
> I never used the term ALLOCATE for any Customer address space I gave out.
> Not for the /22 to the wholesaler, nor for the /29 to the hosting client.
> The party that needs to SWIP was also not controlling. In almost all
> cases the large Customers knew who their customers were. We had no
> clue, so relied on the Wholesalers with the large Assignments to SWIP.
> It was my job to harass them to do so to get the provable utilization
> up.
>
> I have never been given any space that I could, in turn, give out as "Provider
> Independent".



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/bcfd830b/attachment.sig>

From owen at delong.com  Mon Oct 27 12:05:23 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 09:05:23 -0800
Subject: [ppml] Follow on to 2003-4, and suggested change.
In-Reply-To: <OF79ADD38D.111CDF9E-ON80256DCC.0059CD2B-80256DCC.005AFE54@radianz.com>
References: <OF79ADD38D.111CDF9E-ON80256DCC.0059CD2B-80256DCC.005AFE54@radianz.com>
Message-ID: <54080000.1067274323@odlaptop>

In that case, I would argue that DSL providers would face the same need to hand
out /48s to their customers.  Afterall, I am a residential ADSL subscriber with
multiple subnets and several routers at the end of my DSL connections.  THere
are enough people like me (and there would be more if most ADSL providers
didn't have such desperate need for anal cranectomies) that I do not think
you can safely say that all residential DSL customers should get a /64.

I agree with Leo that if the customer topology indicates no layer 3 routing
devices, the customer should receive a /64.  If they later decide to add
some layer 3 devices, they can (and should) renumber into a /48.

Owen


--On Monday, October 27, 2003 04:33:53 PM +0000 Michael.Dillon at radianz.com wrote:

>> A large aspect of our business is running data centers.  Typically
>> we drop off a 100Mbps FE, or 1000Mbps GE link to a customer who
>> plugs in a number of layer 2 switches and installs many servers.
>
>> As far as I can tell the best thing to do with these customers is
>> assign a /64.  A shorter prefix would be a waste, as they own no
>> layer 3 gear, so they would have no way to break it into separate
>> lans anyway.  I suspect anyone who runs data centers will generally
>> be assigning /64's in the data centers to customers.
>
> I don't think this is consistent with IPv6 policy. Specifically, the
> policy says:
>
>     Assignments are to be made in accordance with the existing guidelines
>     [RFC3177,RIRs-on-48], which are summarized here as:
>
>     - /48 in the general case, except for very large subscribers
>
>     - /64 when it is known that one and only one subnet is needed by
> design
>
> I don't think you can say that one and only one subnet is needed by design
> because it is your
> customer's network and not yours. If a customer asks you for an IPv6
> assignment then you would
> have to ask the customer to agree to not *EVER* install a router or a
> firewall or a NAT
> device otherwise you don't have a design rule to justify the /64.
>
> The prudent thing to do here would be to assign a /48 because this is an
> endsite network
> outside of your management control. They may assign a separate subnet with
> separate addresses
> for managing their devices. They may set up a separate subnet with
> separate physical interfaces for
> doing backups of their servers. They may deploy a firewall that needs a
> DMZ subnet.
>
> There is no waste of addresses by doing this. Remember that IPv6 gives us
> 340 undecillion, 282 decillion, 366 nonillion, 920 octillion,
> 938 septillion, 463 sextillion, 463 quintillion, 374 quadrillion,
> 607 trillion, 431 billion, 768 million, 211 thousand, 456 addresses
> to use. That is an awful lot of room, unimaginably huge. The people
> who have thought these things through carefully, think that it's ok
> to use up an entire /48 for any network that might grow and change
> in topology. For now, we should accept that and work with it. Save the
> /64 allocations for cell-phones and PDAs were there is unlikely to be
> more than one subnet on the device. If there is any network infrastructure
> beyond your demarc, including a layer 2 switch, then you probably cannot
> predict whether or not they will someday need to subnet. Therefore, /48.
>
> --Michael Dillon
>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/290187ce/attachment.sig>

From bicknell at ufp.org  Mon Oct 27 12:08:51 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 12:08:51 -0500
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
In-Reply-To: <44310000.1067273693@odlaptop>
References: <OF32AC2948.2D9019E8-ON80256DCC.00583C7B-80256DCC.00598793@radianz.com> <44310000.1067273693@odlaptop>
Message-ID: <20031027170851.GD35805@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 08:54:53AM -0800, Owen DeLong wrote:
> How is this a functional form of multi-homed connectivity?

Check out http://arneill-py.sacramento.ca.us/ipv6mh/.

Note, I think the newest drafts are now called MHAP, not ipv6mh anymore,
but the historical data is still on the other page.

Part of the problem is that it's not all quite standard yet.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/6adffa7f/attachment.sig>

From Michael.Dillon at radianz.com  Mon Oct 27 12:08:03 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Mon, 27 Oct 2003 17:08:03 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OF78092D57.04ADBA06-ON80256DCC.005DF0C1-80256DCC.005E1F20@radianz.com>

>The 80% and 25%/50% guidelines are that way because 
>consumption of address space must be considered differently for 
>assignable space vs end-user space. 

I think it's more useful to have separate guidelines
for end-users vs. ISPs. In other words to classify the 
organizations rather than the address blocks that they
have registered with ARIN.

--Michael Dillon




From michel at arneill-py.sacramento.ca.us  Mon Oct 27 12:13:29 2003
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Mon, 27 Oct 2003 09:13:29 -0800
Subject: [ppml] RE: [address-policy-wg] Is the time for conservation over?
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6D2@server2003.arneill-py.sacramento.ca.us>

> Andre Oppermann wrote:
> The problem with IPv6 is that it doesn't fix any problems. When
> IPv6 was engineered it was done with (from today's perspective)
> wrong assumptions about the goals to achieve. Think about
> multihoming for IPv6 which is currently not possible (except
> for ISPs). And much more stuff on the operational side.

Much agree with this.

Michel.


From owen at delong.com  Mon Oct 27 12:18:27 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 09:18:27 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OF8C92BBEA.656068F2-ON80256DCC.005B9E5B-80256DCC.005C9CB6@radianz.com>
References: <OF8C92BBEA.656068F2-ON80256DCC.005B9E5B-80256DCC.005C9CB6@radianz.com>
Message-ID: <61840000.1067275107@odlaptop>



--On Monday, October 27, 2003 04:51:34 PM +0000 Michael.Dillon at radianz.com wrote:

>> I have a number of ASSIGNMENTS which I fully expect are mine to take with
>> me when I switch providers.
>
> OK, this characteristic could be called portability and is distinct from
> the ability to subdivide the space that you have been issued. In another
> context I would make a distinction between borrowed space which has to
> be returned and space that is issued in perpetuity. However that last
> term doesn't work here because space is not owned, it is issued based
> on the need to use IPv4 and presumably, the grant expires when your need
> for IPv4 goes away.
>
Actually, I used the term in my case very specifically.  There are blocks
which I have been assigned by ARIN which I do not own.  There are blocks
which I was GIVEN prior to ARIN which I do own (whether you like it or
not, that is the case).  This was part of what Bill and I were talking about
WRT fees for maintenance not being the issue vs. the ARIN contract.

However, for the current discussion, this is a rathole which we can take up
off-list if you wish.

So:  we have I think agreed upon the following definitions:

Old Term        New Term
--------------  --------------------
assignment      non-divisible
allocation      divisible
PI              portable
PA              non-portable

The problem is, you are still overloading divisible.  For example, a non-divisible
assignment to an end user from ARIN can still be divided into subnets within the
organization, it just can't be divided up amongst multiple organizations.  You
are going to have a very hard time coming up with completely clean terms that are
short enough for everyday use.

However, I think the above pass comes closer and I am not opposed to the use
of the above terms going forward.  I will, however, still oppose any policy
that seeks to eliminate the process for non-divisible assignments to end
users or homogenize it with the process for divisible allocations to ISPs.
There are good reasons for the differences in the processes and the policy
is pretty clear on those differences and their reasoning.

Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/50aa69e1/attachment.sig>

From cscott at gaslightmedia.com  Mon Oct 27 12:24:37 2003
From: cscott at gaslightmedia.com (Charles Scott)
Date: Mon, 27 Oct 2003 12:24:37 -0500 (EST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027165648.GC35805@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.44.0310271208190.22893-100000@harbor.gaslightmedia.com>


Leo:
  I'm a bit confused by your response, which may in fact expose part of 
the problem.
  I don't see where in the policy referenced it imposes an 80% guideline
on the end-user who recieves space from an upstream ISP, and we here have
never used that guideline for our customers. Neither have we used that
guideline for space we assign internally for our own end-user
requirements--which is why when we use space for our own requirements, we
follow the 25%/50% guidelines for the block we assign for our own use but
consider that entire block as assigned out of the block we have from ARIN. 
  To summarize, if we have assigned 80% of an allocation from ARIN, we've
met the 80% guideline, even though no part of that may have more than 50%
utilization by the end-user, including no more that 50% utilzation for any
block we may have assigned for our own internal use. With this, we are
still in full compliance of ARIN policy.

Chuck Scott



On Mon, 27 Oct 2003, Leo Bicknell wrote:

> A very good technical point.
> 
> There seems to be a lack of harmony though.  An "end user" who
> receives space from their upstream must show the same 80% as their
> upstream ISP (see http://www.arin.net/policy/ipv4.html#reassign).
> An "end user" who goes directly to ARIN can use the 25%/50% rule.
> 
> Is there a reason to hold the same end user to different criteria
> based on who they ask?  Could this issue be solved by making the
> 25%/50% rule apply to downstream customers of an ISP, or by making
> "end users" who request from ARIN use the same 80% rule?
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> 



From owen at delong.com  Mon Oct 27 12:24:11 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 09:24:11 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027165648.GC35805@ussenterprise.ufp.org>
References: <20031027161534.GC33621@ussenterprise.ufp.org> <Pine.LNX.4.44.0310271141470.22893-100000@harbor.gaslightmedia.com> <20031027165648.GC35805@ussenterprise.ufp.org>
Message-ID: <65780000.1067275451@odlaptop>

The only place I found that reference, it referred to the "reassignment" information
for the assignments issued out of the suballocation.  That is, ARIN->LIR->subsidiaryLIR->
customer the subsidiary LIR was required to have the "reassignment" information for
the customers they had allocated to SWIPped (or in RWhois) prior to LIR issuing another
ALLOCATION to subsidiary LIR.

Hope that clarifies.

Owen


--On Monday, October 27, 2003 11:56:48 AM -0500 Leo Bicknell <bicknell at ufp.org> wrote:

> http://www.arin.net/policy/ipv4.html#reassign)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/5abbe8ea/attachment.sig>

From william at elan.net  Mon Oct 27 10:41:24 2003
From: william at elan.net (william at elan.net)
Date: Mon, 27 Oct 2003 07:41:24 -0800 (PST)
Subject: [ppml] Is the time for conservation over?
In-Reply-To: <OF8F78CFA5.6C3777BE-ON80256DCC.004AAE3B-80256DCC.004C6CBA@radianz.com>
Message-ID: <Pine.LNX.4.44.0310270732510.1280-100000@sokol.elan.net>

> In addition, I don't see any good reason to wait until LIRs come and ask
> for IPv6 space. It's not scarce and the vast majority of IPv4 LIRs will
> be deploying IPv6 sometime. So why don't we just give every single
> one of them an IPv6 /32 today.
I have a better idea. To futher facilitate deployment of IPv6 ARIN should 
provide any ISP that has requested IPv6 a rebate of $2000 to help with its
IPv6 network setup, half of this rebate should be given immedialy 
upon successfull completion of ARIN application and the rest when
ISP has successfully deployed 200 ipv6 sites as previously agreed
in that application.

:)

-- 
William Leibzon
Elan Networks
william at elan.net



From cscott at gaslightmedia.com  Mon Oct 27 12:32:01 2003
From: cscott at gaslightmedia.com (Charles Scott)
Date: Mon, 27 Oct 2003 12:32:01 -0500 (EST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OF78092D57.04ADBA06-ON80256DCC.005DF0C1-80256DCC.005E1F20@radianz.com>
Message-ID: <Pine.LNX.4.44.0310271226560.22893-100000@harbor.gaslightmedia.com>


Michael:
  No! What I'm saying is that we do have that right now--separate policies
for ISP's vs end-users. However, the difference is not in the
organization, but in what you're doing with the address block. If you're
assigning blocks out of it for end-user consumption it's one policy, if
you're consuming address space in the block as an end-user it's the other
policy. Both policies may very well apply to one organization if they do
both. I dare say, there are probably no ISP's that assign address space to
end-users but that don't consume space as an end-user themselves.

Chuck Scott



On Mon, 27 Oct 2003 Michael.Dillon at radianz.com wrote:

> >The 80% and 25%/50% guidelines are that way because 
> >consumption of address space must be considered differently for 
> >assignable space vs end-user space. 
> 
> I think it's more useful to have separate guidelines
> for end-users vs. ISPs. In other words to classify the 
> organizations rather than the address blocks that they
> have registered with ARIN.
> 
> --Michael Dillon
> 
> 



From Stacy_Taylor at icgcomm.com  Mon Oct 27 12:35:05 2003
From: Stacy_Taylor at icgcomm.com (Taylor, Stacy)
Date: Mon, 27 Oct 2003 10:35:05 -0700
Subject: [ppml] Allocation and reallocation
Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DAE4E5@denexg21.icgcomm.com>

Hi All,
The English language is inherently confusing.  Think of lie/lay,
affect/effect, who/whom.  It takes effort to utilize the language
appropriately. 

We the IP administrators are a very technical subset of a very technical
industry.  To expect that we would not employ jargon unintelligible to those
outside our focus, (including our VPs, NOCs, and salespeople), is
ridiculous.  Just because Merriam Webster states that the two terms are
synonymous does not signify they mean precisely the same thing.

These terms are entirely appropriate in their subtlety.  The ability to
further assign from an allocation is very subtle, but very important.

It seems to me that you are proposing to change the opus of ARIN policy
because you feel the terms Allocate and Assign are excessively alliterative.
This, to me, is not a valid reason.

Stacy "Turtleneck" Taylor
Speaking as a Private Individual


-----Original Message-----
From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com]
Sent: Monday, October 27, 2003 7:12 AM
To: ppml at arin.net
Subject: Re: [ppml] Allocation and reallocation


>There are short terms that work:
>
>Assignment       Allocation
>------------     --------------
>reassignable     non-reassignable
>delegatable      non-delegatable
>divisible        homogeneous

>Notice the words I suggest are antonyms, yet the words we use today are
>synonyms. 

Remember in my email message I suggested that the proper way
to distinguish address block with different properties was to use
an adjective rather than a verb or a noun? Leo's suggestions are
all adjectives.

I also think his perception about antonyms is right on the mark.

We have tried to change the English language by trying to
use two synonyms to represent two opposite characteristics
and we have failed.

To get back to the point, when an RIR or an ISP takes
a large address block and sets aside a smaller portion
of it for use by another organization, that action is
allocation or assignment or delegation or any other
similar English term.

The block which has been set aside carries with it
a set of properties. Which of these properties are
important enough to be enshrined in policy? Once we are
agreed on that, then how can we clearly express that
policy in plain English so that everyone can understand
the policy without needing an insider to explain it. Even though
the vast majority of people in the ARIN region speak English,
many of them do not speak it as their first language due 
to the large number of immigrants and the large French
and Spanish speaking populations in the region. We cannot
rely on making subtle distinctions with the language because
that only creates an overall negative impression of ARIN
and of the whole IP addressing arena.

For the next meeting in Vancouver, I intend to present
a policy proposal that will completely erase the distinction
between allocation and assignment as well as completely
erase the notion that there are two classes of address blocks.
I believe that a reasonable policy can clearly be expressed
using classes of organization (end user, ISP) and specific
characteristics attached to address blocks issued by ARIN.
Clearly the ability to allocate or assign or delegate subsets
of a block will be one of those characteristics.

Think clarity and simplicity.

--Michael Dillon



From owen at delong.com  Mon Oct 27 12:38:13 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 09:38:13 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <OF78092D57.04ADBA06-ON80256DCC.005DF0C1-80256DCC.005E1F20@radianz.com>
References: <OF78092D57.04ADBA06-ON80256DCC.005DF0C1-80256DCC.005E1F20@radianz.com>
Message-ID: <76610000.1067276293@odlaptop>

End users are not LIRs.  ISPs are.  This is how those blocks are classified
now.  That is the difference between Allocation and Assignment today.  ARIN
allocates to ISPs (LIRs) and Assigns to End users.  LIRs Allocate to client
ISPs (subsidiary LIRs) and assign to end users.  The blocks carry the distinction
of the organization to which they were either allocated or assigned.  The
distinction, however, is made at the organization level as you suggest.  There
is no change in what you proposed from what exists today.

Owen


--On Monday, October 27, 2003 05:08:03 PM +0000 Michael.Dillon at radianz.com wrote:

>> The 80% and 25%/50% guidelines are that way because
>> consumption of address space must be considered differently for
>> assignable space vs end-user space.
>
> I think it's more useful to have separate guidelines
> for end-users vs. ISPs. In other words to classify the
> organizations rather than the address blocks that they
> have registered with ARIN.
>
> --Michael Dillon
>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/69b24115/attachment.sig>

From michel at arneill-py.sacramento.ca.us  Mon Oct 27 12:39:57 2003
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Mon, 27 Oct 2003 09:39:57 -0800
Subject: [ppml] Is the time for conservation over?
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6D6@server2003.arneill-py.sacramento.ca.us>

> William Leibzon wrote:
> I have a better idea. To futher facilitate deployment of
> IPv6 ARIN should provide any ISP that has requested IPv6
> a rebate of $2000 to help with its IPv6 network setup,
> half of this rebate should be given immedialy upon
> successfull completion of ARIN application and the rest
> when ISP has successfully deployed 200 ipv6 sites as
> previously agreed in that application.

I like this! Make it $2M so the ISP can give $200K back to the
enterprise (me) to cover deployment cost and I'd deploy IPv6 right away.

Michel.



From owen at delong.com  Mon Oct 27 12:42:53 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 09:42:53 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.LNX.4.44.0310271226560.22893-100000@harbor.gaslightmedia.com>
References: <Pine.LNX.4.44.0310271226560.22893-100000@harbor.gaslightmedia.com>
Message-ID: <77570000.1067276573@odlaptop>

This is handled in the policy as it exists today.  The LIR can be it's own
customer for some of it's blocks.  If, for example, an LIR receives a /20
from ARIN, they need to allocate or assign 80% of it before they can get
more.  They can ASSIGN some of it to themselves for their infrastructure
as long as they meet the 50% utiliziation criteria for assignment on those
blocks. They can assign and allocate other parts of it to their customers.
When 80% has been allocated or assigned, they go back to ARIN and ask
for another allocation.

Really... This part of the policy is _NOT_ broken.  The terminology (which
is what started this debate) may be, but, the actual policy itself is not.

Owen


--On Monday, October 27, 2003 12:32:01 PM -0500 Charles Scott <cscott at gaslightmedia.com> wrote:

>
> Michael:
>   No! What I'm saying is that we do have that right now--separate policies
> for ISP's vs end-users. However, the difference is not in the
> organization, but in what you're doing with the address block. If you're
> assigning blocks out of it for end-user consumption it's one policy, if
> you're consuming address space in the block as an end-user it's the other
> policy. Both policies may very well apply to one organization if they do
> both. I dare say, there are probably no ISP's that assign address space to
> end-users but that don't consume space as an end-user themselves.
>
> Chuck Scott
>
>
>
> On Mon, 27 Oct 2003 Michael.Dillon at radianz.com wrote:
>
>> > The 80% and 25%/50% guidelines are that way because
>> > consumption of address space must be considered differently for
>> > assignable space vs end-user space.
>>
>> I think it's more useful to have separate guidelines
>> for end-users vs. ISPs. In other words to classify the
>> organizations rather than the address blocks that they
>> have registered with ARIN.
>>
>> --Michael Dillon
>>
>>
>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/dc99d569/attachment.sig>

From bicknell at ufp.org  Mon Oct 27 12:44:51 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 12:44:51 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.LNX.4.44.0310271208190.22893-100000@harbor.gaslightmedia.com>
References: <20031027165648.GC35805@ussenterprise.ufp.org> <Pine.LNX.4.44.0310271208190.22893-100000@harbor.gaslightmedia.com>
Message-ID: <20031027174451.GA39633@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 12:24:37PM -0500, Charles Scott wrote:
>   To summarize, if we have assigned 80% of an allocation from ARIN, we've
> met the 80% guideline, even though no part of that may have more than 50%
> utilization by the end-user, including no more that 50% utilzation for any
> block we may have assigned for our own internal use. With this, we are
> still in full compliance of ARIN policy.

We have been held to the 80% guideline before.  I remember having
to submit to ARIN (two allocations back, I think) host tables
(really, reverse DNS files) for customer blocks showing 80% usage.
That is, if we assigned a /24 to a customer they wanted to see 200
or so individual host names.  That may be because they felt we fell
under the "web host customer" guidelines which specifically references
back to a table.

Specifically, if you assign a block to your customer the policy says:

  3. Require your downstream customers to adhere to the following criteria:
   [snip]
     Customers must follow ARIN guidelines for ISPs

On the (relatively few) ARIN apps I've done for more space from an
ISP they seem to want the 80% to carry down into customer usage as
well.  If others are having a different experience that's very
interesting.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/32fe2a88/attachment.sig>

From Rob.Vinson at networktelephone.net  Mon Oct 27 13:01:21 2003
From: Rob.Vinson at networktelephone.net (Rob Vinson)
Date: Mon, 27 Oct 2003 12:01:21 -0600
Subject: [ppml] Allocation and reallocation
Message-ID: <F57026A9F900D411999000D0B73C4DF606F4EC29@pflnoczr.corp.com>


In a message written on Mon, Oct 27, 2003, Leo Bicknell wrote:
> On the (relatively few) ARIN apps I've done for more space from an ISP
they seem to want the 80% to carry down into customer usage as well

That has always been my take. I know whenever customers have asked me to
expand their /28 to a /27 (or whatever) - I ask them to show 80%
utilization. It's also in our AUP. Wrong or right, end user accountability
makes it easier for me to validate a new /20 request. 
___________________________________________
 
Rob V >>>  
rob.vinson at networktelephone.net





From cscott at gaslightmedia.com  Mon Oct 27 13:09:47 2003
From: cscott at gaslightmedia.com (Charles Scott)
Date: Mon, 27 Oct 2003 13:09:47 -0500 (EST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027174451.GA39633@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.44.0310271306150.22893-100000@harbor.gaslightmedia.com>


Leo:
  If you have been held to 80% utilization (80% of the addresses actually 
have hosts) for end-user blocks, then it would seem that there's a problem 
at ARIN. As such, if you feel this is still happening, we should get a 
clarification from ARIN personel regarding this. In fact, I belive I have 
such in my old E-Mail that I can possibly find.
  BTW, there is no separate policy for "Web host customers", only a 
requirement to report whether the hosting is IP or hostname based for 
"informational purposes".

Chuck Scott



On Mon, 27 Oct 2003, Leo Bicknell wrote:

> In a message written on Mon, Oct 27, 2003 at 12:24:37PM -0500, Charles Scott wrote:
> >   To summarize, if we have assigned 80% of an allocation from ARIN, we've
> > met the 80% guideline, even though no part of that may have more than 50%
> > utilization by the end-user, including no more that 50% utilzation for any
> > block we may have assigned for our own internal use. With this, we are
> > still in full compliance of ARIN policy.
> 
> We have been held to the 80% guideline before.  I remember having
> to submit to ARIN (two allocations back, I think) host tables
> (really, reverse DNS files) for customer blocks showing 80% usage.
> That is, if we assigned a /24 to a customer they wanted to see 200
> or so individual host names.  That may be because they felt we fell
> under the "web host customer" guidelines which specifically references
> back to a table.
> 



From owen at delong.com  Mon Oct 27 14:36:19 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 11:36:19 -0800
Subject: [ppml] Allocation and reallocation
In-Reply-To: <F57026A9F900D411999000D0B73C4DF606F4EC29@pflnoczr.corp.com>
References: <F57026A9F900D411999000D0B73C4DF606F4EC29@pflnoczr.corp.com>
Message-ID: <918096885.1067254579@dhcp157-233.corp.tellme.com>

End user accountability is absolutely required.  However, end users are
accountable to the end user policy and LIRs are accountable to the
ISP Allocation policy (which should probably be renamed LIR allocation
policy).

ARIN staff can correct me if I am wrong, but, as I read the policy on the
web site, that is the clear impression I get from it.

Owen

--On Monday, October 27, 2003 12:01 -0600 Rob Vinson 
<Rob.Vinson at networktelephone.net> wrote:

>
> In a message written on Mon, Oct 27, 2003, Leo Bicknell wrote:
>> On the (relatively few) ARIN apps I've done for more space from an ISP
> they seem to want the 80% to carry down into customer usage as well
>
> That has always been my take. I know whenever customers have asked me to
> expand their /28 to a /27 (or whatever) - I ask them to show 80%
> utilization. It's also in our AUP. Wrong or right, end user accountability
> makes it easier for me to validate a new /20 request.
> ___________________________________________
>
> Rob V >>>
> rob.vinson at networktelephone.net
>
>
>






From michel at arneill-py.sacramento.ca.us  Mon Oct 27 14:42:34 2003
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Mon, 27 Oct 2003 11:42:34 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6D7@server2003.arneill-py.sacramento.ca.us>

Leo,

> Leo Bicknell wrote:
> Check out http://arneill-py.sacramento.ca.us/ipv6mh/.
> Note, I think the newest drafts are now called MHAP, not ipv6mh
> anymore, but the historical data is still on the other page.
> Part of the problem is that it's not all quite standard yet.

And it will never be. I have abandoned the development of MHAP for
pragmatic reasons: my assessment is that it would never be a success
because IPv6 will never be a success. I closed the MHAP list last week,
the reason being that I joined the anti-v6 camp. I will post soon a
rationale for it, still polishing the text. Basically, a simple matter
of money: know when to take a loss and move on. This hurts me, but
putting my head in the sand leaving another part of my body exposed did
not look the best thing to do.

Consolidating with your other posts:

>> David Conrad wrote:
>> The obvious implication of this is that it pretty much guarantees
>> the creation of a new and potentially much bigger swamp.

> Leo Bicknell wrote:
> A new swamp, yes. Bigger, I'm not so sure.

I share David's concerns though. The potential for a much bigger and
much murkier swamp is here. To be detailed later, one of the reasons I
am moving away from v6 is that my assessment is indeed that the IPv6
soup will indeed be worse than the IPv4 one, see at the end of this
post.


> If every ASN had a single IPv6 /32 the IPv6 table would be 12%
> of the current IPv4 routing table.

This topic has been extensively discussed on ipv6mh in the past, and
it's half-true and half-false. The issue is that "If every ASN had a
single IPv6 /32" does not register. Large multihomers need either
multiple /32s or to announce subsets (such as /36) of their own /32,
which for all practical purposes does not change much in terms of number
of entries. There is potential for much more than 12%.

> I don't think that something along the lines of "everyone with an asn
> and one or more IPv4 blocks can receive one IPv6 block of appropriate
> size" would be a bad thing.  Indeed, I'd rather see each ASN with it's
> own /32 than see some get /48's from three providers and start
>  reannouncing them (which is a big part of the current IPv4 table
> bloat).

Pekka Savola has proposed something similar a year ago, it did not move
ahead on the grounds that it would trigger a land rush on ASNs and
precipitate the adoption of 32-bit ASNs for no real gain.

Note that in terms of what is being announced in the global IPv6 routing
table today, look at the bottom of this email, a snapshot I capture from
my own IPv6 BGP4+ feeds. Not only I see /48s but also /64s and anything
else you can imagine. Call it swamp, soup or anything you like it's here
already.


> I am going to strongly disagree on this point at this time. We
> don't know that there will /ever/ be a strong migration of users
> to IPv6. IPv6 may yet flop completely, be replaced by IPv8

I'm sure Jim Fleming will be pleased :-D

> or something before it ever reaches full deployment, or even
> always live side by side with IPv4.

I don't think that a complete flop is realistic. Too many people have
invested too much money for IPv6 to sink overnight. The most likely
scenario is that is will live side-by-side with IPv6 for some years, and
eventually share the same fate as ISDN: I Still Don't Need and be
replaced by something else, the ISDN equivalent of cable or DSL (but not
IPv8 please).

The cost of enabling IPv6 in a Californian enterprise today is US$600
one-time and $100/yr recurring support cost until IPv4 is removed. This
is an un-scientific median cost from a small set of my own diverse
customers, but can't be _that_ much of course. Where's my ROI?

As far as end-customer demand, save for a massive "Intel Inside" like TV
campaign, I don't see how it could happen either. I will develop this
later as well, but IPv6 situation in terms of marketing is somehow
similar to microprocessor vendors: almost nobody buys a CPU alone these
days, and almost nobody will buy IPv6 as a standalone product either.
For the general public, "IPv6 inside" is the way to market. Catch: it
ain't no cheap.


> Even if we assume everything migrates to IPv6, I see no reason
> why we should change IPv4 policy at all.

Agree.

Michel.


"Interesting" announcements gathered a few minutes ago:
(alternatively, look at Jeroen Massar's stuff)

This might not look like a lot, but there are not quite 500 IPv6 routes
today, we're already looking at 12% of prefixes being announced being
soup, and this is _without_ any kind of IPv6 PI.

cisco7507#sh bgp ipv6 unicast
[removed as-paths and peers to protect the innocent]

*> 2001:288:3B0::/44
*> 2001:3C8:9009::/48
*> 2001:3C8:E109::/48
*> 2001:448:3::/48
*> 2001:460:410::/48
*> 2001:470:108::/48
*> 2001:470:110::/48
*> 2001:470:112::/48
*> 2001:470:1F00:954::/64
*> 2001:478::/45
*> 2001:478:65::/48
*> 2001:500::/48
*> 2001:500:1::/48
*> 2001:530:DEAD::/64
*> 2001:530:DEAD:BEAD::/64
*> 2001:570::/48
*> 2001:608:1::/48
*> 2001:608:6::/48
*> 2001:610:140::/48
*> 2001:610:240::/42
*> 2001:618:A::/48
*> 2001:628:14F9::/48
*> 2001:630:50::/48
*> 2001:648:2::/48
*> 2001:648:202::/48
*> 2001:660:3006::/48
*> 2001:700:FFFF::/48
*> 2001:730:2::/48
*> 2001:770:80::/48
*> 2001:7B8:200::/48
*> 2001:7F8:1::/48
*> 2001:7F8:2::/48
*> 2001:7F8:4::/48
*> 2001:7F8:5::/48
*> 2001:7F8:B::/48
*> 2001:7F8:18::/48
*> 2001:1458:E000::/48
*> 2001:1578:100::/40
*> 2001:1578:200::/40
*> 2001:1578:400::/40
*> 2002:C2B1:D06E::/48
*> 2002:C8A2::/33
*> 2002:C8C6:4000::/34
*> 2002:C8CA:7000::/36
*> 3FFE:4::/48
*> 3FFE:B00:4050::/48
*> 3FFE:1200:3028::/48
*> 3FFE:2022:F000::/48
*> 3FFE:2500:310::/48
*> 3FFE:2501:100::/48
*> 3FFE:2900:1:15::/64
*> 3FFE:2900:3::/48
*> 3FFE:2B00:1003::/48
*> 3FFE:3600:18::/48
*> 3FFE:4005:A::/48
*> 3FFE:400B:6002::/48
*> 3FFE:400B:6006::/48
*> 3FFE:8034:10::/48
*> 3FFE:80B0:1002::/48
*> 3FFE:8150:2001::/48
*> 3FFE:81D0:104::/48



From bicknell at ufp.org  Mon Oct 27 14:58:41 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 14:58:41 -0500
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
In-Reply-To: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6D7@server2003.arneill-py.sacramento.ca.us>
References: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6D7@server2003.arneill-py.sacramento.ca.us>
Message-ID: <20031027195840.GB46152@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 11:42:34AM -0800, Michel Py wrote:
> This topic has been extensively discussed on ipv6mh in the past, and
> it's half-true and half-false. The issue is that "If every ASN had a
> single IPv6 /32" does not register. Large multihomers need either
> multiple /32s or to announce subsets (such as /36) of their own /32,
> which for all practical purposes does not change much in terms of number
> of entries. There is potential for much more than 12%.

Clearly 12% is best case.  However, I think worst case is about the
same as what we have today in IPv4.  There are people today who
announce multiple swap prefixes and the like not because they need
to, but because they won't take the effort to renumber into one
block.  Getting IPv6 "right enough" to prevent that will take out
a good chunk.  There will still be people who multihome with cut-outs
and multiple blocks and all that stuff, so the answer should be in
the middle.

> Note that in terms of what is being announced in the global IPv6 routing
> table today, look at the bottom of this email, a snapshot I capture from
> my own IPv6 BGP4+ feeds. Not only I see /48s but also /64s and anything
> else you can imagine. Call it swamp, soup or anything you like it's here
> already.

Using the existing table as a reference is an extremely bad idea.
Most of the people I know of who are playing with IPv6 right now
are doing just that, playing.  Many IPv6 networks are in research
and test mode.  That means the filtering practices are different
from an operational network.  It means people put up a /64 just to
see where it ends up.  I remember talking to Team Cymru about a "secure
IPv6 BGP template" with bogon lists and the like....no one seems to
have developed one yet.  So to take the current state of the IPv6
routing table and extrapolate that to the future of IPv6 is very
dangerous.

Note also, much of the junk you listed is 6bone space, which was done
as the rules were developed, so many things were put in place when
there were no rules.  It's all going away.

> > I am going to strongly disagree on this point at this time. We
> > don't know that there will /ever/ be a strong migration of users
> > to IPv6. IPv6 may yet flop completely, be replaced by IPv8
> 
> I'm sure Jim Fleming will be pleased :-D

This was pointed out to me off list.  I had no idea Jim Flemming had
introduced an IPv8 proposal.  I wanted to pick a hypothetical future
version.  Ah well.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/e3aab655/attachment.sig>

From bicknell at ufp.org  Mon Oct 27 15:17:53 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 15:17:53 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <F57026A9F900D411999000D0B73C4DF606F4EC29@pflnoczr.corp.com>
References: <F57026A9F900D411999000D0B73C4DF606F4EC29@pflnoczr.corp.com>
Message-ID: <20031027201753.GB47401@ussenterprise.ufp.org>

In a message written on Mon, Oct 27, 2003 at 12:01:21PM -0600, Rob Vinson wrote:
> That has always been my take. I know whenever customers have asked me to
> expand their /28 to a /27 (or whatever) - I ask them to show 80%
> utilization. It's also in our AUP. Wrong or right, end user accountability
> makes it easier for me to validate a new /20 request. 

Following up on Rob's 80%...some google found the following:

http://www.netsonic.net/ip-alloc-policy.php
http://www.stickdog.com/ippol.phtml
http://www.hostdepot.com/Company/Policies/IPAddress.asp
http://www.more.net/technical/netserv/tcpip/ipreq.html
http://www.imagina.com/support/ipjust/ipjustguidelines.html
http://www.coop.net/about_us/government/policy/addresses.php
http://www.onsitenj.com/dialup/faq/ip_allocation_policy.htm

It would seem a lot of ISP's out there are holding end-users to an
80% rule.  If that's wrong we need to fix something, because 
lots of people are getting the wrong idea.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/6d20d3da/attachment.sig>

From memsvcs at arin.net  Mon Oct 27 15:54:01 2003
From: memsvcs at arin.net (Member Services)
Date: Mon, 27 Oct 2003 15:54:01 -0500 (EST)
Subject: [ppml] NRO Memorandum of Understanding Signed
Message-ID: <Pine.GSO.4.51.0310271545240.20618@ops.arin.net>


After considering all comments received, the RIR Boards
developed a further revision of the NRO MoU.  They
subsequently directed their respective CEOs to sign
the document.

The RIR CEOs signed the NRO MoU during the ARIN members
meeting in Chicago at 0900 (CDT), 24 October 2003.

"The Number Resource Organization" document can be found
on the ARIN web site at:

     http://www.arin.net/library/rir-docs/

The RIR Boards in general and the ARIN Board of Trustees in
particular would like to stress that they will continue
working together with the community to refine the NRO's
functioning.

I would like to thank the community for their support in
this process.


Raymond A. Plzak
President & CEO
American Registry for Internet Numbers



From michel at arneill-py.sacramento.ca.us  Mon Oct 27 16:01:10 2003
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Mon, 27 Oct 2003 13:01:10 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6DF@server2003.arneill-py.sacramento.ca.us>

> Owen DeLong wrote:
> If I have a box with two /128s assigned to it, how does it
> know which one corresponds to the provider that is up and
> routing packets and not to use the one that is down at the
> moment?

It's called "magic", don't you know. It just happens, you don't have to
know how :-)

This is besides the point anyway. Save for small home/soho like setups,
the idea of having more than one address per host is not an option.
Imagine each host can have three addresses: triple firewall config,
triple access-list config, triple internal routing config, triple
problems. In large corporations I have talked to, only M$ appears to
think that multiple addresses per host are a serious option.


> To me, the whole point of multihoming is reliability. That means,
> my packets get through as long as at least one provider is up and
> has reachability to/from the peer I want to talk to.

That's only one feature of today's multihoming (which is tied to PI
addresses). The other two being provider independence (because
renumbering a large network is painful) and global load balancing
(because transporting traffic from Asia to North America in your own
network costs money, therefore you are much better off go to the right
location in the first place).


> Does v6 require me to run a routing protocol on EVERY host
> in order to do local address selection for sourcing new
> conversations?

There have been some proposals to the IETF, some of which suggesting
RIPNG as the routing protocol. Although they never had much momentum
Lord knows what the IETF can do.

Michel.



From michel at arneill-py.sacramento.ca.us  Mon Oct 27 16:46:00 2003
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Mon, 27 Oct 2003 13:46:00 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6E0@server2003.arneill-py.sacramento.ca.us>

Leo,


> Leo Bicknell wrote:
> Using the existing table as a reference is an extremely bad idea.

If used to extrapolate, I agree. But it does show behavior, and if we
can't get it clean now it does not look good in the future.


> Most of the people I know of who are playing with IPv6 right
> now are doing just that, playing. Many IPv6 networks are in
> research and test mode.

True.

> That means the filtering practices are different from an
> operational network. It means people put up a /64 just to
> see where it ends up.  

Disagree. I don't feed my routing crud to the global routing table and I
know lots of people that are in test mode that are very finicky about
doing it clean.


> I remember talking to Team Cymru about a "secure IPv6 BGP template"
> with bogon lists and the like....no one seems to have developed one
> yet.

It is being worked on; we are attempting to standardize the distribution
mechanism and the bogon list people have regrouped under one AS
(AS29467) and are leaning towards a unified bogon feed. Read:
http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt


> Note also, much of the junk you listed is 6bone space, which was
> done as the rules were developed, so many things were put in place
> when there were no rules.  It's all going away.

Much of? No, only 27%. 63% of the IPv6 junk is production space. The
6bone, contrary to what you say, has never been that bad.

Michel.



From cscott at gaslightmedia.com  Mon Oct 27 17:07:08 2003
From: cscott at gaslightmedia.com (Charles Scott)
Date: Mon, 27 Oct 2003 17:07:08 -0500 (EST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027201753.GB47401@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.44.0310271643110.6395-100000@harbor.gaslightmedia.com>



Leo:
  Note that most of these policies say that the end-user must have 
"efficiently utilized" 80% ...  I take this to mean that 80% of the space 
is deployed in the network, not that 80% of all possible addresses are 
assigned to hosts. I suppose then that I could have been causing trouble 
for no reason if one accepts that no ISP would hold a customer to having 
80% of their address space assigned to specific hosts (or broadcast 
addresses). If you look at it that way, a subnet that has 25% of the 
addresses in use currently and will have 50% in use in one year is being 
efficiently utilized and that entire sub-net is ticked off against the 80% 
utilization of the assignment. 
  RFC2050, which is the stated basis for the ARIN policy is pretty clear
(as mud) that the reccomendation end-users is the 25%/50% guideline and
that the 80% criteria only applies to reassignemnt. So, I can't see how
anyone would hold any end-user to 80% host utilization of a netblock.
What's left to the imagination is what the 25%/50% guideline means. Is 
that applied accross the board for the number of host addreses in use in 
the entire assignment, or is that per sub-net in use. If it's applied 
accross the entire assignment, then the H/D ratio would be a better 
indication of efficient utilization (only for end-user utilization of 
course). 

Chuck Scott




On Mon, 27 Oct 2003, Leo Bicknell wrote:

> In a message written on Mon, Oct 27, 2003 at 12:01:21PM -0600, Rob Vinson wrote:
> > That has always been my take. I know whenever customers have asked me to
> > expand their /28 to a /27 (or whatever) - I ask them to show 80%
> > utilization. It's also in our AUP. Wrong or right, end user accountability
> > makes it easier for me to validate a new /20 request. 
> 
> Following up on Rob's 80%...some google found the following:
> 
> http://www.netsonic.net/ip-alloc-policy.php
> http://www.stickdog.com/ippol.phtml
> http://www.hostdepot.com/Company/Policies/IPAddress.asp
> http://www.more.net/technical/netserv/tcpip/ipreq.html
> http://www.imagina.com/support/ipjust/ipjustguidelines.html
> http://www.coop.net/about_us/government/policy/addresses.php
> http://www.onsitenj.com/dialup/faq/ip_allocation_policy.htm
> 
> It would seem a lot of ISP's out there are holding end-users to an
> 80% rule.  If that's wrong we need to fix something, because 
> lots of people are getting the wrong idea.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> 



From owen at delong.com  Mon Oct 27 17:22:15 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 14:22:15 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation
 over? (fwd)
Message-ID: <2147483647.1067264535@dhcp157-233.corp.tellme.com>

OOPS... Meant to send to list.
(Thanks, Michael)

Owen


------------ Forwarded Message ------------
Date: Monday, October 27, 2003 12:18 -0800
From: Michel Py <michel at arneill-py.sacramento.ca.us>
To: Owen DeLong <owen at delong.com>
Subject: RE: [ppml] Re: [address-policy-wg] Is the time for conservation 
over?

Owen,

Did you intend to send this privately? Should go to the ML IMHO.

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com]
Sent: Monday, October 27, 2003 12:09 PM
To: Michel Py
Subject: RE: [ppml] Re: [address-policy-wg] Is the time for conservation
over?

> This topic has been extensively discussed on ipv6mh in the past, and
> it's half-true and half-false. The issue is that "If every ASN had a
> single IPv6 /32" does not register. Large multihomers need either
> multiple /32s or to announce subsets (such as /36) of their own /32,
> which for all practical purposes does not change much in terms of
number
> of entries. There is potential for much more than 12%.
>
This simply does not make sense.  Bear with me:

	If you have a /32, you have more addresses available within
	your autonomous system than ALL of the current IPv4 space
	combined.  Ergo, I propose that there is currently no single
	autonomous system that could in any way justify more than a
	/32 of space.  Heck, a /32 contains as many /64s as the entire
	IPv4 space contains hosts.  There's just no legitimate reason
	to issue any autonomous system (at least any in existence today)
	more than a /32.

	If you are a single autonomous system, then, you have one
routing
	policy.  If you have one routing policy, then, your routes can
	be aggregated as long as they are contiguous and bit-aligned.
	If you are given a contiguous bit-aligned /32, there is no
reason
	any "large multihomer" in existence today needs more than this
	to replace their current IPv4 space.

Perhaps I'm missing something in the (unnecessary) complexity of V6
addressing.  I'll admit my head is somewhat in the sand when it comes
to V6 because I just don't see it being relevant to me yet.  I suspect
it will eventually become relevant, but, date-creep seems to be a major
factor in when that will be.  As such, I suspect I have about the same
level of V6 understanding as the vast majority of the operational
community which is to say:

	We know it exists.

	We know it uses 128 bit addresses somehow.

	We know that the last 48 bits of the address is usually just
	the MAC address of the host and that some dynamic address
	assignment process is required (ala DHCP but more complicated).

	Some of us know that it's not TUBA.

That's about all we know.

>> I am going to strongly disagree on this point at this time. We
>> don't know that there will /ever/ be a strong migration of users
>> to IPv6. IPv6 may yet flop completely, be replaced by IPv8
>
> I'm sure Jim Fleming will be pleased :-D
>
I have confirmed with Leo that he picked 8 out of thin air and was
unaware of the Flemming history.  Think of it as IPvMumble rather
than as Flemming's V8.
> The cost of enabling IPv6 in a Californian enterprise today is US$600
> one-time and $100/yr recurring support cost until IPv4 is removed.
This
> is an un-scientific median cost from a small set of my own diverse
> customers, but can't be _that_ much of course. Where's my ROI?
>
That's only the cost of obtaining the addresses and keeping them.  The
cost of deployment is MUCH more significant in terms of man-hours
and equipment costs.

> As far as end-customer demand, save for a massive "Intel Inside" like
TV
> campaign, I don't see how it could happen either. I will develop this
> later as well, but IPv6 situation in terms of marketing is somehow
> similar to microprocessor vendors: almost nobody buys a CPU alone
these
> days, and almost nobody will buy IPv6 as a standalone product either.
> For the general public, "IPv6 inside" is the way to market. Catch: it
> ain't no cheap.
>
The only entities I've seen with a compelling desire to push IPv6 are
cellular phone companies (it's hard to address all cellphones in IPv4
space) and Micr0$0ft with their desire to provide an IPv6 only Teenager
platform.

Owen



---------- End Forwarded Message ----------






From bicknell at ufp.org  Mon Oct 27 17:26:11 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 27 Oct 2003 17:26:11 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.LNX.4.44.0310271643110.6395-100000@harbor.gaslightmedia.com>
References: <20031027201753.GB47401@ussenterprise.ufp.org> <Pine.LNX.4.44.0310271643110.6395-100000@harbor.gaslightmedia.com>
Message-ID: <20031027222611.GA55174@ussenterprise.ufp.org>


This all comes back to the reason I started this thread.  The policy
is not clear.  The policy needs to be made clear so we can't have
these arguments as to what it means.  An ISP shouldn't have to guess
what the requirements will be, or really even ask for clarification.
They should be spelled out clearly.

The problem is as soon as you try to clarify the policy two things
happen.  People think you're trying to change the policy (in this
case I don't want to change it, just make it clear) because today
there are multiple ways to view it, and there should only be one.
That represents change to the people who have the other (wrong?)
opinion.  The other is that many other people jump in expressly to
change the policy.

If the people who care about policy and have joined this list can't
agree on what it says how can we expect the average ARIN member or
staffer to get it right?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org


From owen at delong.com  Mon Oct 27 17:31:44 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 14:31:44 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation
 over?
In-Reply-To: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6DE@server2003.arneill-py.sacramento.ca.us>
References: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6DE@server2003.arneill-py.sa
 cramento.ca.us>
Message-ID: <2147483647.1067265104@dhcp157-233.corp.tellme.com>

Returning to list per Michael's request (and my original intent)...

--On Monday, October 27, 2003 12:36 -0800 Michel Py 
<michel at arneill-py.sacramento.ca.us> wrote:

> Owen,
>
> [I would rather post this to the ML]
>
>>> Michel Py wrote:
>>> This topic has been extensively discussed on ipv6mh in the past,
>>> and it's half-true and half-false. The issue is that "If every
>>> ASN had a single IPv6 /32" does not register. Large multihomers
>>> need either multiple /32s or to announce subsets (such as /36)
>>> of their own /32, which for all practical purposes does not
>>> change much in terms of number of entries. There is potential
>>> for much more than 12%.
>
>> Owen DeLong wrote:
>> This simply does not make sense.  Bear with me:
>> If you have a /32, you have more addresses available within
>> your autonomous system than ALL of the current IPv4 space
>> combined.  Ergo, I propose that there is currently no single
>> autonomous system that could in any way justify more than a
>> 32 of space.  Heck, a /32 contains as many /64s as the entire
>> IPv4 space contains hosts.  There's just no legitimate reason
>> to issue any autonomous system (at least any in existence today)
>> more than a /32.
>> If you are a single autonomous system, then, you have one routing
>> policy.  If you have one routing policy, then, your routes can
>> be aggregated as long as they are contiguous and bit-aligned.
>> If you are given a contiguous bit-aligned /32, there is no reason
>> any "large multihomer" in existence today needs more than this
>> to replace their current IPv4 space.
>> Perhaps I'm missing something in the (unnecessary) complexity of
>> V6 addressing.
>
> No, it has nothing to do with IPv6 and everything to do with
> geographical spread. If you are a multinational organization, you don't
> want to announce your address space in one piece. You have allocated
> some addresses to east coast, some to west coast, some to Europe, some
> to china, some to Australia, etc. So you announce more than one block to
> achieve global load balancing and avoid transporting traffic internally.
> Today, large organizations that would want to deploy IPv6 have only one
> option: lie to their RIRs pretending they are LIRs and obtain multiple
> /32s.
>
Sorry... If you want to do that, you have multiple autonomous systems.
The definition of an autonomous system is a collection of routes with
a consistent routing policy.  If you are announcing some from east and
some from west, etc. and don't want to provide a backbone between, then,
you are dealing with an autonomous system for east and an autonomous
system for west, etc.

This also assumes that the majority of large organizations don't want
to transport traffic internally (I don't know how true/false this assumption
is for various organizations).

I thought we had pretty well established that geographical allocation
policies are generally fairly broken.

>
> Indeed. I said "enabling", not "actually using".
>
Fair enough.

>
>> The only entities I've seen with a compelling desire to push
>> IPv6 are cellular phone companies (it's hard to address all
>> cellphones in IPv4 space) and Micr0$0ft with their desire to
>> provide an IPv6 only Teenager platform.
>
> Unfortunately it's legal, which means it probably won't work! Some
> parents would say that since teens would something illegal no matter
> what, it's better than they pirate mp3s instead of smoking pot and
> drinking underage while driving to the Saturday night disco where they
> have unprotected sex with another minor in a car.
> Sex, drugs, rock'n roll. Haven't you been a teen in a past life?
>
> Seriously, the main reason behind IPv6 in threedegrees is that is was
> the easiest way to do NAT traversal with Teredo. This has even been said
> semi-publicly both by Tony Hain and Christian Huitema.
>
I'm not convinced that is entirely true... I'm sure they could have tunneled
it all across port 80 (Micr0$0ft is getting very good at hiding the entire
IP stack inside HTTP(s), and it's an increasingly disturbing trend).


My point wasn't so much that 3degree was or was not worth-while, as, it
was the only non-cellular use of IPv6 I had noticed outside of the research
community.  Personally, I think 3degree (or any other application form
Micr0$0ft that requires V6) is a good reason to resist deploying V6.
I would be happy if Micr0$0ft wer to disappear tomorrow.

Owen



From owen at delong.com  Mon Oct 27 17:46:23 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 14:46:23 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation
 over?
In-Reply-To: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6DF@server2003.arneill-py.sacramento.ca.us>
References: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6DF@server2003.arneill-py.sa
 cramento.ca.us>
Message-ID: <2147483647.1067265983@dhcp157-233.corp.tellme.com>



--On Monday, October 27, 2003 13:01 -0800 Michel Py 
<michel at arneill-py.sacramento.ca.us> wrote:

>> Owen DeLong wrote:
>> If I have a box with two /128s assigned to it, how does it
>> know which one corresponds to the provider that is up and
>> routing packets and not to use the one that is down at the
>> moment?
>
> It's called "magic", don't you know. It just happens, you don't have to
> know how :-)
>
> This is besides the point anyway. Save for small home/soho like setups,
> the idea of having more than one address per host is not an option.
> Imagine each host can have three addresses: triple firewall config,
> triple access-list config, triple internal routing config, triple
> problems. In large corporations I have talked to, only M$ appears to
> think that multiple addresses per host are a serious option.
>
But, that appeared to be what people were saying was the solution for
V6 multihoming.  I'm just trying to figure out what it takes for V6
to have a reasonable (the router can parse it and route packets)
routing table _AND_ allow reasonable multihoming (at least as good
as what is achievable today).  I took the multi-address position from
someones paper on "how to do it" and didn't develop it myself.  I
have no religion either way.  If there is a single-address way to
do it, I'm all for that.  What is it?


>
>> To me, the whole point of multihoming is reliability. That means,
>> my packets get through as long as at least one provider is up and
>> has reachability to/from the peer I want to talk to.
>
> That's only one feature of today's multihoming (which is tied to PI
> addresses). The other two being provider independence (because
> renumbering a large network is painful) and global load balancing
> (because transporting traffic from Asia to North America in your own
> network costs money, therefore you are much better off go to the right
> location in the first place).
>
Renumbering a large network is painful in V4.  V6 was supposed to have
pretty much fixed that.  If it didn't, V6 needs more development work
until that is fixed.  Renumbering is a common occurrence for a variety
of reasons and we should develop tools to make it not painful.

As to GLB, you are not making sense to me.  Either you are using ANYCAST
(in the IPv4 sense of the word) where you have an autonomous system that
consists of a (set of) prefix(es) that are replicated in multiple locations
or you are using DNS hackery.  Any other form of GLB will still require
some level of redirection.  If you are getting redirected on application
setup (HTTP Redirect, for example), then, the end address doesn't matter
much and it doesn't matter how many ASNs are involved, either.  That's
not multi-homing, that's topologically diverse hosting.  If you're
dealing with anycast, then, since the prefix is the same and topological
metrics control which server gets the request, that's also not "multihoming"
in the traditional sense of the word.

However, in my opinion, multihoming in the traditional sense of the word,
a single AS attached to more than one upstream transit AS, is the harder
of the problems to solve, and, it is not clear to me how this works in
V6.

>
>> Does v6 require me to run a routing protocol on EVERY host
>> in order to do local address selection for sourcing new
>> conversations?
>
> There have been some proposals to the IETF, some of which suggesting
> RIPNG as the routing protocol. Although they never had much momentum
> Lord knows what the IETF can do.
>
This doesn't bode well for IPv6 being adopted any time soon.  It sounds
like there are still many real world operational problems that are
left as an exercise to the implementer.

Owen





From ron at aol.net  Mon Oct 27 19:16:50 2003
From: ron at aol.net (Ron da Silva)
Date: Mon, 27 Oct 2003 19:16:50 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027222611.GA55174@ussenterprise.ufp.org>
References: <20031027201753.GB47401@ussenterprise.ufp.org> <Pine.LNX.4.44.0310271643110.6395-100000@harbor.gaslightmedia.com> <20031027222611.GA55174@ussenterprise.ufp.org>
Message-ID: <20031028001650.GT8043@aol.net>

On Mon, Oct 27, 2003 at 05:26:11PM -0500, Leo Bicknell wrote:
> This all comes back to the reason I started this thread.  The policy
> is not clear.  The policy needs to be made clear so we can't have
> these arguments as to what it means.  An ISP shouldn't have to guess
> what the requirements will be, or really even ask for clarification.
> They should be spelled out clearly.
> 
> The problem is as soon as you try to clarify the policy two things
> happen.  People think you're trying to change the policy (in this
> case I don't want to change it, just make it clear) because today
> there are multiple ways to view it, and there should only be one.
> That represents change to the people who have the other (wrong?)
> opinion.  The other is that many other people jump in expressly to
> change the policy.
> 
> If the people who care about policy and have joined this list can't
> agree on what it says how can we expect the average ARIN member or
> staffer to get it right?

Very cyclic thread.  Perhaps if we had a glossary on the ARIN website
that can be referenced by all, then we will all have the same 
definitions (and thus the selection of terms is moot!).

-ron


From mury at goldengate.net  Mon Oct 27 19:31:25 2003
From: mury at goldengate.net (Mury)
Date: Mon, 27 Oct 2003 18:31:25 -0600 (CST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027222611.GA55174@ussenterprise.ufp.org>
Message-ID: <Pine.BSI.4.44.0310271818000.22717-100000@dew.goldengate.net>


I can't remember who proposed what, so forgive me for not giving
appropriate credit, but besides the generic argument wanting to leave
things as is, what are the arguments against something like the following:

"LIR" IPs (Currently assignable and allocatable - forgive the grammar/sp)
"END" user IPs (Currently assignments)

>From there you could use notation such as:

LIR(L) Space that has been further allocated from an ISP to an ISP
LIR(R) Space from a RIR to an ISP
END(L) Space from a LIR to an end user
END(R) Space from a RIR to an end user

This would be consistant with the current RIR/LIR language being used.  It
would also be easy to identify the properties and responsibities that go
hand and hand with being a LIR, such as you must swip your space and you
may further divide your space.

My two cents is that the usage requirements of space to an end user from
either a LIR or a RIR should be the same.  But, if you wanted to
distinguish a difference you could do so with the (L) and (R) syntax.
This of course is helpful in determining if the space is "portable..."
meaing assignments having been made from a RIR.

If that is viewed as messy, two fields could be used.  One being the type
of space (LIR or END), and the other being what the "upstream" entity is
(LIR or RIR).

Mury

On Mon, 27 Oct 2003, Leo Bicknell wrote:

>
> This all comes back to the reason I started this thread.  The policy
> is not clear.  The policy needs to be made clear so we can't have
> these arguments as to what it means.  An ISP shouldn't have to guess
> what the requirements will be, or really even ask for clarification.
> They should be spelled out clearly.
>
> The problem is as soon as you try to clarify the policy two things
> happen.  People think you're trying to change the policy (in this
> case I don't want to change it, just make it clear) because today
> there are multiple ways to view it, and there should only be one.
> That represents change to the people who have the other (wrong?)
> opinion.  The other is that many other people jump in expressly to
> change the policy.
>
> If the people who care about policy and have joined this list can't
> agree on what it says how can we expect the average ARIN member or
> staffer to get it right?
>
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>



From william at elan.net  Mon Oct 27 17:55:26 2003
From: william at elan.net (william at elan.net)
Date: Mon, 27 Oct 2003 14:55:26 -0800 (PST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.BSI.4.44.0310271818000.22717-100000@dew.goldengate.net>
Message-ID: <Pine.LNX.4.44.0310271441440.11797-100000@sokol.elan.net>


I did not want to get into this "wording" debate before, because I often 
do not use correct language as is, but seems to me Mury's terms here are 
the best ones so for mentioned, in particular we can easily replace 
"ALLOCATED" by "ASSIGNED TO LIR" or just "LIR IP Block" (no matter from 
if its assigned from RIR or from another LIR) and "ASSIGNED" can be
"ASSIGNED TO END-USER" or "END-User IP Block". I did not particularly like 
how he introduced who assigned the block, and still prefer indication if 
ip block is portable or not. So to me the following looks like the best if 
we want to find replacement for "ALLOCATION" and "ASSIGNMENT":

PORTABLE LIR IP BLOCK = ALLOCATED by ARIN to ISP
NON-PORTABLE LIR IP BLOCK = ALLOCATED from one ISP to another
PORTABLE END-USER IP BLOCK = ASSIGNED by ARIN directly to Organization
NON-PORTABLE END-USER IP BLOCK = ASSIGNED by ISP to end-user

With LIR defined as any organization that is making allocations or 
assignments of ip space.

On Mon, 27 Oct 2003, Mury wrote:

> 
> I can't remember who proposed what, so forgive me for not giving
> appropriate credit, but besides the generic argument wanting to leave
> things as is, what are the arguments against something like the following:
> 
> "LIR" IPs (Currently assignable and allocatable - forgive the grammar/sp)
> "END" user IPs (Currently assignments)
> 
> >From there you could use notation such as:
> 
> LIR(L) Space that has been further allocated from an ISP to an ISP
> LIR(R) Space from a RIR to an ISP
> END(L) Space from a LIR to an end user
> END(R) Space from a RIR to an end user
> 
> This would be consistant with the current RIR/LIR language being used.  It
> would also be easy to identify the properties and responsibities that go
> hand and hand with being a LIR, such as you must swip your space and you
> may further divide your space.
> 
> My two cents is that the usage requirements of space to an end user from
> either a LIR or a RIR should be the same.  But, if you wanted to
> distinguish a difference you could do so with the (L) and (R) syntax.
> This of course is helpful in determining if the space is "portable..."
> meaing assignments having been made from a RIR.
> 
> If that is viewed as messy, two fields could be used.  One being the type
> of space (LIR or END), and the other being what the "upstream" entity is
> (LIR or RIR).
> 
> Mury
> 
> On Mon, 27 Oct 2003, Leo Bicknell wrote:
> 
> >
> > This all comes back to the reason I started this thread.  The policy
> > is not clear.  The policy needs to be made clear so we can't have
> > these arguments as to what it means.  An ISP shouldn't have to guess
> > what the requirements will be, or really even ask for clarification.
> > They should be spelled out clearly.
> >
> > The problem is as soon as you try to clarify the policy two things
> > happen.  People think you're trying to change the policy (in this
> > case I don't want to change it, just make it clear) because today
> > there are multiple ways to view it, and there should only be one.
> > That represents change to the people who have the other (wrong?)
> > opinion.  The other is that many other people jump in expressly to
> > change the policy.
> >
> > If the people who care about policy and have joined this list can't
> > agree on what it says how can we expect the average ARIN member or
> > staffer to get it right?
> >
> > --
> >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> >         PGP keys at http://www.ufp.org/~bicknell/
> > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org



From jlewis at lewis.org  Mon Oct 27 20:10:42 2003
From: jlewis at lewis.org (jlewis at lewis.org)
Date: Mon, 27 Oct 2003 20:10:42 -0500 (EST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031027201753.GB47401@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.44.0310272005260.8137-100000@redhat1.mmaero.com>

On Mon, 27 Oct 2003, Leo Bicknell wrote:

> It would seem a lot of ISP's out there are holding end-users to an
> 80% rule.  If that's wrong we need to fix something, because 
> lots of people are getting the wrong idea.

It's my understanding that the 80% rule only applies to allocations.  i.e. 
When ARIN allocates space to an ISP, we're held to the 80% rule.  When we 
as an ISP allocate space to a smaller ISP, we hold them to the 80% rule.  
When we assign space to an end-user, we hold them to the 25%/50% rule.  

This is pretty much spelled out in RFC 2050.
 
----------------------------------------------------------------------
 Jon Lewis *jlewis at lewis.org*|  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |  
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From cjw at groovy.com  Mon Oct 27 20:21:57 2003
From: cjw at groovy.com (CJ Wittbrodt)
Date: Mon, 27 Oct 2003 17:21:57 -0800
Subject: [ppml] Allocation and reallocation 
In-Reply-To: Message from Owen DeLong <owen@delong.com> 
   of "Mon, 27 Oct 2003 08:22:17 PST." <14150000.1067271737@odlaptop> 
Message-ID: <200310280121.h9S1Lvs79870@duchess.groovy.com>


Owen,

    
    RIRs issue PI space.  LIRs issue PA space.  [LR]IRs issue allocations to
    entities which will divide that space up for customer use.  [LR]IRs issue
    assignments to entities which will use that space for their own purposes.
    
Not all LIRs (ISPs) issue allocations to entities which will divide
that space up for customer use.  They certainly may do that, but 
a lot of ISPs do not sell to other ISPs.  I know the networks I worked
on in the past didn't do that.  We made assignments to organizations
that were PA space and not subject to subdivision.  

---CJ


From michel at arneill-py.sacramento.ca.us  Mon Oct 27 23:03:12 2003
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Mon, 27 Oct 2003 20:03:12 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation over?
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6E1@server2003.arneill-py.sacramento.ca.us>

Owen,

>> Michel Py wrote:
>> No, it has nothing to do with IPv6 and everything to do with
>> geographical spread. If you are a multinational organization, you
don't
>> want to announce your address space in one piece. You have allocated
>> some addresses to east coast, some to west coast, some to Europe,
some
>> to china, some to Australia, etc. So you announce more than one block
to
>> achieve global load balancing and avoid transporting traffic
internally.
>> Today, large organizations that would want to deploy IPv6 have only
one
>> option: lie to their RIRs pretending they are LIRs and obtain
multiple
>> /32s.

> Owen DeLong wrote:
> Sorry... If you want to do that, you have multiple autonomous
> systems. The definition of an autonomous system is a collection
> of routes with a consistent routing policy.  If you are
> announcing some from east and some from west, etc. and don't
> want to provide a backbone between, then, you are dealing with
> an autonomous system for east and an autonomous system for west,
> etc.

I see your point. Let me ask you this: I am a multinational organization
(non-ISP). I have offices all over the world including in New York and
Hong Kong. In New York, I buy transit from ISP A and ISP B. In Hong
Kong, I buy transit from ISP C. (the reasons I don't buy transit from
ISP A in HK can be diverse: maybe ISP A's network in Asia stinks, maybe
they give me a good deal in the US but not in HK, etc). Should I need
multiple ASes for this? And even if you say so, convince me why I should
listen to you when a single AS is so simpler for me.


> This also assumes that the majority of large organizations don't
> want to transport traffic internally (I don't know how true/false
> this assumption is for various organizations).

Not when they can avoid it, this is a matter both of money and latency.
Back to the example above: I am a multinational organization (non-ISP).
I have offices all over the world including in New York and Hong Kong.
Imagine the case of a customer of ISP A that is in HK and that wants to
access my HK site. Regardless of the fact that I have different ASes or
not, if I don't announce the HK block longer than my global block, this
is doubly bad because a) the traffic from ISP A's customer in HK goes
all the way to NY on ISP A's backbone and comes back on my internal
network; very bad for latency; b) I also have to carry the traffic back
on my own network, which costs money. Conclusion: the only traffic one
wants to transport on the internal network is internal traffic.

Another topic:
In New York, I buy transit from ISP A and ISP B. In Hong Kong, I buy
transit from ISP C. I want to announce the specifics of the HK block in
both places (for redundancy; if ISP C in HK tanks but my internal
network and links are still up I can do the scenic routing mentioned
above; not good but okay as a backup). If announce the HK block with two
different ASes, I have an inconsistent AS issues (same block sourced by
different ASes).

How do you address this (in IPv4 for a start)?

As far as I know the only available way today is to announce longer
(specific) prefixes with the same AS, prepending it differently for
different blocks at different locations. What am I missing?


> As to GLB, you are not making sense to me.

Maybe by GLB we don't speak of the same thing. I'm not talking about
akamai-like things that trick DNS in one way or the other and do some
custom RTT measuring over UDP from their different hosting farms.

Keep in mind where this started: it would be easier to aggregate IPv6
than it is to aggregate v4. WRT what I wrote above, explain me why.


> [Teredo used as NAT traversal]
> I'm not convinced that is entirely true... I'm sure they could
> have tunneled it all across port 80 (Micr0$0ft is getting very
> good at hiding the entire IP stack inside HTTP(s), and it's an
> increasingly disturbing trend).

I hear your point, but in this case it is.


> [multi-address]
> But, that appeared to be what people were saying was the
> solution for V6 multihoming.

The same brilliant minds that never configured a router in their entire
life, that say that IPv6 renumbering is easy (see below) and that
designed IPv6 never thinking of it as a product that needed to be
deployed in the real world, ignoring basic market realities and the fact
that some pieces of it like multihoming are still missing.


> I'm just trying to figure out what it takes for V6 to have a
> reasonable (the router can parse it and route packets) routing
> table _AND_ allow reasonable multihoming (at least as good as
> what is achievable today).

Nothing is going to be as good as what we have today. MHAP does solve
the reasonable routing table, but at the cost of some added complexity.
No free lunch. One of the things that could have made MHAP worth the
trouble is that it provided not only a solution at the routing table
size but also other perks such as survivability of open sessions in any
failure mode, something that BGP is far from delivering.


> I took the multi-address position from someones paper on "how to
> do it" and didn't develop it myself. I have no religion either
> way.  If there is a single-address way to do it, I'm all for that.
> What is it?

Currently there is none; MHAP would have been the closest I could think
of. The problem of the multi-address solution is not that it's bad; it's
not. It's OK for certain types of setups such as home/soho, but not for
large setups. Early on the ipv6mh days we quickly came to the conclusion
that "THE" IPv6 multihoming solution did not exist; an assemblage of
different collaborative but distinct solutions targeted at different
multihoming needs was the best we hoped for.


> Renumbering a large network is painful in V4.  V6 was supposed
> to have pretty much fixed that.

Absolutely not. Given the current network management practices and
tools, renumbering an IPv6 network is _not_ significantly easier than an
IPv4 network.

> If it didn't, V6 needs more development work until that is fixed.
> Renumbering is a common occurrence for a variety of reasons and
> we should develop tools to make it not painful.

I agree, but IPv6 by itself is not one of these tools. The myth of IPv6
easy renumbering comes from two things: a) stateless autoconfig, which
was nice before we had DHCP, and easy support for multiple addresses per
interface, none of which are any kind of a breakthrough today. If you
have time, read:
http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-
01.txt


> However, in my opinion, multihoming in the traditional sense of the
> word, a single AS attached to more than one upstream transit AS, is
> the harder of the problems to solve, and, it is not clear to me how
> this works in V6.

It does not, because today one can't obtain portable address space that
could be announced to multiple transit ASes and announcing a PA block
you got from one upstream to another upstream does not register.


> This doesn't bode well for IPv6 being adopted any time soon. It
> sounds like there are still many real world operational problems
> that are left as an exercise to the implementer.

Indeed.

Michel.



From owen at delong.com  Tue Oct 28 01:17:32 2003
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Oct 2003 22:17:32 -0800
Subject: [ppml] Re: [address-policy-wg] Is the time for conservation
 over?
In-Reply-To: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6E1@server2003.arneill-py.sacramento.ca.us>
References: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6E1@server2003.arneill-py.sa
 cramento.ca.us>
Message-ID: <2147483647.1067293052@imac-en0.delong.sj.ca.us>

> I see your point. Let me ask you this: I am a multinational organization
> (non-ISP). I have offices all over the world including in New York and
> Hong Kong. In New York, I buy transit from ISP A and ISP B. In Hong
> Kong, I buy transit from ISP C. (the reasons I don't buy transit from
> ISP A in HK can be diverse: maybe ISP A's network in Asia stinks, maybe
> they give me a good deal in the US but not in HK, etc). Should I need
> multiple ASes for this? And even if you say so, convince me why I should
> listen to you when a single AS is so simpler for me.
>
Yes.  Because the RFC definition of an AS is a collection of routes with
a consistent policy.  The BGP definition of IBGP is that ALL border routers
within an autonomous system are connected via an IGP.  So, since you are
advertising two different route sets from two different disconnected places,
you have two autonomous systems by the BGP and RFC definitions of what an
autonomous system is.  It is not only not easier to do it with a single
AS, it actually doesn't work correctly and causes problems.  It does, in
some cases, work mostly, so you don't notice the problems except in rare
circumstances, but, you are definitely breaking things at least from an
internet standards, if not a pragmatic implementation perspective.


>
>> This also assumes that the majority of large organizations don't
>> want to transport traffic internally (I don't know how true/false
>> this assumption is for various organizations).
>
> Not when they can avoid it, this is a matter both of money and latency.

That's simply not necessarily true.  For example, if you are a multi-
national ISP with an OC-192 backbone, you probably don't want your packets
from Hong Kong to New York traversing random other providers' backbones.
If you are a multi-national corporation you may have reasons for preferring
to keep as much traffic on your own backbone as possible.  There are
different flavors of need and desire.  I understand that your situation
leads to you wanting to let others carry your traffic for you.  In other
situations, that cost is not necessarily the primary concern (or even
effected by this decision in some cases), and, latency may drive some
organizations to run their own backbone depending on their presence in
the places they need to be and the existing needed topology.

> Back to the example above: I am a multinational organization (non-ISP).
> I have offices all over the world including in New York and Hong Kong.
> Imagine the case of a customer of ISP A that is in HK and that wants to
> access my HK site. Regardless of the fact that I have different ASes or
> not, if I don't announce the HK block longer than my global block, this
> is doubly bad because a) the traffic from ISP A's customer in HK goes
> all the way to NY on ISP A's backbone and comes back on my internal
> network; very bad for latency; b) I also have to carry the traffic back
> on my own network, which costs money. Conclusion: the only traffic one
> wants to transport on the internal network is internal traffic.
>
If you have different ASs, they should have separate blocks.  There is
no advantage to a single block if it is not a single autonomous system.
It makes much more sense for you to have two smaller blocks than a single
larger block.  If ISP A wants to make them contiguous so that you could
aggregate them if you formed a single AS, that's fine.  If not, then,
that's fine too.  There's NO gain to it being an aggregateable prefix
if it doesn't meet the single AS test above.

> Another topic:
> In New York, I buy transit from ISP A and ISP B. In Hong Kong, I buy
> transit from ISP C. I want to announce the specifics of the HK block in
> both places (for redundancy; if ISP C in HK tanks but my internal
> network and links are still up I can do the scenic routing mentioned
> above; not good but okay as a backup). If announce the HK block with two
> different ASes, I have an inconsistent AS issues (same block sourced by
> different ASes).
>
Unless you have a backbone to carry that traffic, then announcing it for
redundancy doesn't work.  If you are a single contiguous AS announcing all
the same prefix(es) in all your EBGP peering points, then, you meet the
single AS test above.  If you want to use external connections to deliver
that traffic when they will work instead of your own backbone, then you
should create external tunnels between your border routers and run an IGP
across them, then run your IBGP on top of that.  You should not be
announcing different sets of routes from different locations.  You should
announce proper MEDs on the routes you do announce and announce the same
set of longer prefixes at each location.

> How do you address this (in IPv4 for a start)?
>
See above.

> As far as I know the only available way today is to announce longer
> (specific) prefixes with the same AS, prepending it differently for
> different blocks at different locations. What am I missing?
>
Prepending is an alternative ugly hack to MEDs which are the right way
to do this.  I realize most people use prepending because:

	1.	Most people don't understand MEDs
	2.	Most providers don't listen to MEDs because their customers
		don't tend to get them right.


>
>> As to GLB, you are not making sense to me.
>
> Maybe by GLB we don't speak of the same thing. I'm not talking about
> akamai-like things that trick DNS in one way or the other and do some
> custom RTT measuring over UDP from their different hosting farms.
>
Neither was I.

> Keep in mind where this started: it would be easier to aggregate IPv6
> than it is to aggregate v4. WRT what I wrote above, explain me why.
>
I didn't say that.  i said that there is no need for a single autonomous
system to have more addresses than a /32 would allow and I cannot imagine
a case where a single AS needs more than a /48 unless they are an ISP
with /32 customers.

>
>> [Teredo used as NAT traversal]
>> I'm not convinced that is entirely true... I'm sure they could
>> have tunneled it all across port 80 (Micr0$0ft is getting very
>> good at hiding the entire IP stack inside HTTP(s), and it's an
>> increasingly disturbing trend).
>
> I hear your point, but in this case it is.
>
I believe that.  Like I said, I'm sure Micr0$0ft will adapt and break the
internet protocol stack in any way they feel they need to in order to get
their application sold.  They have demonstrated a complete and total
disregard for standards in the past any time they became inconvenient.
For some reason, I think M$ is hoping that this will drive the 
implementation
of V6.  I don't know why M$ wants to drive V6, but, if they want it, it
may not be good for the internet.  (When was the last time M$ wanted
something that turned out to actually be good for the internet?)

>
>> [multi-address]
>> But, that appeared to be what people were saying was the
>> solution for V6 multihoming.
>
> The same brilliant minds that never configured a router in their entire
> life, that say that IPv6 renumbering is easy (see below) and that
> designed IPv6 never thinking of it as a product that needed to be
> deployed in the real world, ignoring basic market realities and the fact
> that some pieces of it like multihoming are still missing.
>
OK... So this gets me back to thinking V6 isn't ready for public consumption
and why waste time worrying about it until they get it ready.

>
>> I'm just trying to figure out what it takes for V6 to have a
>> reasonable (the router can parse it and route packets) routing
>> table _AND_ allow reasonable multihoming (at least as good as
>> what is achievable today).
>
> Nothing is going to be as good as what we have today. MHAP does solve
> the reasonable routing table, but at the cost of some added complexity.
> No free lunch. One of the things that could have made MHAP worth the
> trouble is that it provided not only a solution at the routing table
> size but also other perks such as survivability of open sessions in any
> failure mode, something that BGP is far from delivering.
>
That's absurd.  What we have today is largely broken and we should be
striving to fix that with V6.  If we can't do at least as well as we
do today, it will be an operational non-starter.  As to the rest, I
agree, if the convergence time is fast enough, which, from what I saw of
MHAP was UNLIKELY at best.

>
>> I took the multi-address position from someones paper on "how to
>> do it" and didn't develop it myself. I have no religion either
>> way.  If there is a single-address way to do it, I'm all for that.
>> What is it?
>
> Currently there is none; MHAP would have been the closest I could think
> of. The problem of the multi-address solution is not that it's bad; it's
> not. It's OK for certain types of setups such as home/soho, but not for
> large setups. Early on the ipv6mh days we quickly came to the conclusion
> that "THE" IPv6 multihoming solution did not exist; an assemblage of
> different collaborative but distinct solutions targeted at different
> multihoming needs was the best we hoped for.
>
I don't see why it's all that bad for large setups.  You simply end up
with 2 or more network addresses for each network.  This technology is
well understood in the v4 world.  Heck, I'm even looking at the possibility
of doing something like this (ugly hack, but all 1918 space so who cares)
on a collection of servers that absolutely positively have to be reachable
as long as they are up... Two physical interfaces each with a similar
prefix (say 10.1.1.n/24 and 10.1.101.n/24) and a related loopback address
of 10.1.202.n/32.  They'll all run Zebra to advertise the /32 to the
routers reachable by both Phy. interfaces, and, they'll have ip_forwarding
off in the host.  The routers will only advertise the /32s to the other
routers on those two networks.  (two sets of two routers, one on each
network and all connected to each other with  a point-to-point mesh).

DNS will resolve to the loopback address 10.1.202.n  (there will be 
alternate
names for reaching a particular PHY).  This is anycast style host connection
redundancy.  It could be made somewhat more pathological with redundant 
hosts
using anycast layered on top of this (multiple physical machines all 
posessing
the same 10.1.202.n address), but, that's not good for long session 
protocols,
just single-packet transactions.

>
>> Renumbering a large network is painful in V4.  V6 was supposed
>> to have pretty much fixed that.
>
> Absolutely not. Given the current network management practices and
> tools, renumbering an IPv6 network is _not_ significantly easier than an
> IPv4 network.
>
That's pretty unfortunate.

>> If it didn't, V6 needs more development work until that is fixed.
>> Renumbering is a common occurrence for a variety of reasons and
>> we should develop tools to make it not painful.
>
> I agree, but IPv6 by itself is not one of these tools. The myth of IPv6
> easy renumbering comes from two things: a) stateless autoconfig, which
> was nice before we had DHCP, and easy support for multiple addresses per
> interface, none of which are any kind of a breakthrough today. If you
> have time, read:
> http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-
> 01.txt
>
I dont, and, I thought V6 also provided for host-address assignment on the
address-server (DHCP replacement) being itself dynamic (this is not common
in todays world), and that V6 renumbering would be more like renumbering
an Appletalk network (I'm not defending Appletalk as a protocol, but, they
did have address assignment and renumbering pretty well down).


>
>> However, in my opinion, multihoming in the traditional sense of the
>> word, a single AS attached to more than one upstream transit AS, is
>> the harder of the problems to solve, and, it is not clear to me how
>> this works in V6.
>
> It does not, because today one can't obtain portable address space that
> could be announced to multiple transit ASes and announcing a PA block
> you got from one upstream to another upstream does not register.
>
Then V6 either needs to come up with an alternate solution or face
obsolescence before adoption.

>
>> This doesn't bode well for IPv6 being adopted any time soon. It
>> sounds like there are still many real world operational problems
>> that are left as an exercise to the implementer.

OK... At least I know where things stand a little better now.  I had higher
hopes.  There were some smart people working on this (and, at one time, many
of them actually were people with OP-EX).

Owen



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/66d18e8e/attachment.sig>

From Michael.Dillon at radianz.com  Tue Oct 28 04:56:55 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Tue, 28 Oct 2003 09:56:55 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OFB68D4D21.751C38A8-ON80256DCD.00366CE4-80256DCD.0036A671@radianz.com>

>This is handled in the policy as it exists today.

>Really... This part of the policy is _NOT_ broken.  The terminology 
(which
>is what started this debate) may be, but, the actual policy itself is 
not.

Are you sure?

Can you show me where in the current ARIN policy it is
clear that an ISP can assign a block to themselves
based on the 50% utilization requirement and then
count that block as 100% assigned for the purposes
of checking their allocation against the 80% utilization
rule?

--Michael Dillon





From Michael.Dillon at radianz.com  Tue Oct 28 07:14:08 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Tue, 28 Oct 2003 12:14:08 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OFDBB48E93.3A10A50F-ON80256DCD.0036BE55-80256DCD.00433697@radianz.com>

>  If you have been held to 80% utilization (80% of the addresses actually 

>have hosts) for end-user blocks, then it would seem that there's a 
problem 
>at ARIN. 

>As such, if you feel this is still happening, we should get a 
>clarification from ARIN personel regarding this. 

If the policies of ARIN are confusing and unclear (they are) then
it is likely that ARIN's processes and the actions of ARIN's
staff in analyzing applications will also be confusing and
inconsistent.

ARIN staff can address that internally by making a clear
and unambiguous process based on their understanding of the
policy but that doesn't help us. And, if the policy is 
confusing, their process could be wrong.

The solution is to have clear and unambiguous policy.
If that means we need to write clearer language for the
existing policy without changing the effect of the policy
then we should do so.

But ARIN staff can't clarify the policy by themselves.

--Michael Dillon




From bicknell at ufp.org  Tue Oct 28 14:04:52 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 28 Oct 2003 14:04:52 -0500
Subject: [address-policy-wg] Re: [ppml] Is the time for conservation over?
In-Reply-To: <3F9ED682.C58BEE5A@ix.netcom.com>
References: <OF8F78CFA5.6C3777BE-ON80256DCC.004AAE3B-80256DCC.004C6CBA@radianz.com> <20031027141558.GB27711@ussenterprise.ufp.org> <3F9ED682.C58BEE5A@ix.netcom.com>
Message-ID: <20031028190452.GA4009@ussenterprise.ufp.org>

In a message written on Tue, Oct 28, 2003 at 12:50:10PM -0800, Jeff Williams wrote:
>   I also am in agreement with Leo on this point as well.  IPv8 is already
> in significant deployment asia and elsewhere and is in some folks
> opinion, though I am sure not Michael's, a superior IP Protocol to
> IPv6, which has known Privacy problems.

This was already brought up on PPML, but since another list is copied
here I'll say it again.

I had _NO_ idea there was an IPv8 proposal out there.  I know nothing
about it, don't support it, and don't care.  s/IPv8/IPvFuture/ in my
message please, that was my only intention.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031028/cc753d1b/attachment.sig>

From William at zanet.co.za  Tue Oct 28 14:47:34 2003
From: William at zanet.co.za (William Stucke)
Date: Tue, 28 Oct 2003 21:47:34 +0200
Subject: [address-policy-wg] Re: [ppml] Is the time for conservation over?
In-Reply-To: <20031028190452.GA4009@ussenterprise.ufp.org>
Message-ID: <LPENICNLCKCKPNDPFKBAOEIGEKAA.William@zanet.co.za>

Leo Bicknell said: -

> I had _NO_ idea there was an IPv8 proposal out there.

There is *NOT*. Not a real one.

To quote Randy Bush in response to some 'discussion' of this subject a
couple of years ago at: -
http://www1.ietf.org/mail-archive/ietf/Current/msg12603.html

"write it off to loonies and sociopaths not taking their meds"

See also:
http://www.ripe.net/ripe/mail-archives/tld-wg/1998/msg00313.html

;-)

One particular individual has spent the last 5 years or so trying -
unsuccessfully - to persuade the rational world of the merits of his own
loony schemes - to the extent of inventing his own RFCs and bogus
announcements of deployment.

Ignore it, and him.

Regards,

William Stucke
ZAnet Internet Services (Pty) Ltd
+27 11 465 0700
William at zanet.co.za

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.504 / Virus Database: 302 - Release Date: 2003/07/24



From mury at goldengate.net  Tue Oct 28 15:16:05 2003
From: mury at goldengate.net (Mury)
Date: Tue, 28 Oct 2003 14:16:05 -0600 (CST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.LNX.4.44.0310271441440.11797-100000@sokol.elan.net>
Message-ID: <Pine.BSI.4.44.0310281409290.26007-100000@dew.goldengate.net>


I guess that depends on if you find it more helpful to spell out whether
the space is portable or not, or if it's more helpful to know where the
space came from.  If the consensus is that most people just need to know
if the space is portable than it is to know where to return it to or where
it came from then you could use the following notation:

RIR	Space held by a RIR
LIR(P)	Space allocated to a LIR from a RIR
LIR(N)	Space allocated to a LIR from another LIR
END(P)	Space assigned to an end user from a RIR
END(N)	Space assigned to an end user from a LIR

Regards,

Mury

On Mon, 27 Oct 2003 william at elan.net wrote:

>
> I did not want to get into this "wording" debate before, because I often
> do not use correct language as is, but seems to me Mury's terms here are
> the best ones so for mentioned, in particular we can easily replace
> "ALLOCATED" by "ASSIGNED TO LIR" or just "LIR IP Block" (no matter from
> if its assigned from RIR or from another LIR) and "ASSIGNED" can be
> "ASSIGNED TO END-USER" or "END-User IP Block". I did not particularly like
> how he introduced who assigned the block, and still prefer indication if
> ip block is portable or not. So to me the following looks like the best if
> we want to find replacement for "ALLOCATION" and "ASSIGNMENT":
>
> PORTABLE LIR IP BLOCK = ALLOCATED by ARIN to ISP
> NON-PORTABLE LIR IP BLOCK = ALLOCATED from one ISP to another
> PORTABLE END-USER IP BLOCK = ASSIGNED by ARIN directly to Organization
> NON-PORTABLE END-USER IP BLOCK = ASSIGNED by ISP to end-user
>
> With LIR defined as any organization that is making allocations or
> assignments of ip space.
>
> On Mon, 27 Oct 2003, Mury wrote:
>
> >
> > I can't remember who proposed what, so forgive me for not giving
> > appropriate credit, but besides the generic argument wanting to leave
> > things as is, what are the arguments against something like the following:
> >
> > "LIR" IPs (Currently assignable and allocatable - forgive the grammar/sp)
> > "END" user IPs (Currently assignments)
> >
> > >From there you could use notation such as:
> >
> > LIR(L) Space that has been further allocated from an ISP to an ISP
> > LIR(R) Space from a RIR to an ISP
> > END(L) Space from a LIR to an end user
> > END(R) Space from a RIR to an end user
> >
> > This would be consistant with the current RIR/LIR language being used.  It
> > would also be easy to identify the properties and responsibities that go
> > hand and hand with being a LIR, such as you must swip your space and you
> > may further divide your space.
> >
> > My two cents is that the usage requirements of space to an end user from
> > either a LIR or a RIR should be the same.  But, if you wanted to
> > distinguish a difference you could do so with the (L) and (R) syntax.
> > This of course is helpful in determining if the space is "portable..."
> > meaing assignments having been made from a RIR.
> >
> > If that is viewed as messy, two fields could be used.  One being the type
> > of space (LIR or END), and the other being what the "upstream" entity is
> > (LIR or RIR).
> >
> > Mury
> >
> > On Mon, 27 Oct 2003, Leo Bicknell wrote:
> >
> > >
> > > This all comes back to the reason I started this thread.  The policy
> > > is not clear.  The policy needs to be made clear so we can't have
> > > these arguments as to what it means.  An ISP shouldn't have to guess
> > > what the requirements will be, or really even ask for clarification.
> > > They should be spelled out clearly.
> > >
> > > The problem is as soon as you try to clarify the policy two things
> > > happen.  People think you're trying to change the policy (in this
> > > case I don't want to change it, just make it clear) because today
> > > there are multiple ways to view it, and there should only be one.
> > > That represents change to the people who have the other (wrong?)
> > > opinion.  The other is that many other people jump in expressly to
> > > change the policy.
> > >
> > > If the people who care about policy and have joined this list can't
> > > agree on what it says how can we expect the average ARIN member or
> > > staffer to get it right?
> > >
> > > --
> > >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> > >         PGP keys at http://www.ufp.org/~bicknell/
> > > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>



From bicknell at ufp.org  Tue Oct 28 15:54:38 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 28 Oct 2003 15:54:38 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.BSI.4.44.0310281409290.26007-100000@dew.goldengate.net>
References: <Pine.LNX.4.44.0310271441440.11797-100000@sokol.elan.net> <Pine.BSI.4.44.0310281409290.26007-100000@dew.goldengate.net>
Message-ID: <20031028205438.GA11682@ussenterprise.ufp.org>

In a message written on Tue, Oct 28, 2003 at 02:16:05PM -0600, Mury wrote:
> RIR	Space held by a RIR
> LIR(P)	Space allocated to a LIR from a RIR
> LIR(N)	Space allocated to a LIR from another LIR
> END(P)	Space assigned to an end user from a RIR
> END(N)	Space assigned to an end user from a LIR

Short, fully descriptive.  Not a bad idea.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org


From mury at goldengate.net  Tue Oct 28 18:48:02 2003
From: mury at goldengate.net (Mury)
Date: Tue, 28 Oct 2003 17:48:02 -0600 (CST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <20031028205438.GA11682@ussenterprise.ufp.org>
Message-ID: <Pine.BSI.4.44.0310281743520.26007-100000@dew.goldengate.net>


Like I mentioned before I have lost track of who started this conversation
and who has hinted at proposing something, and I don't want to step on any
toes.

Do any of those people want to write up a proposal with these ideas or
different ones of their own, or should I run with it?

Thanks.

Mury

On Tue, 28 Oct 2003, Leo Bicknell wrote:

> In a message written on Tue, Oct 28, 2003 at 02:16:05PM -0600, Mury wrote:
> > RIR	Space held by a RIR
> > LIR(P)	Space allocated to a LIR from a RIR
> > LIR(N)	Space allocated to a LIR from another LIR
> > END(P)	Space assigned to an end user from a RIR
> > END(N)	Space assigned to an end user from a LIR
>
> Short, fully descriptive.  Not a bad idea.
>
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>



From bicknell at ufp.org  Tue Oct 28 15:54:38 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 28 Oct 2003 15:54:38 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.BSI.4.44.0310281409290.26007-100000@dew.goldengate.net>
References: <Pine.LNX.4.44.0310271441440.11797-100000@sokol.elan.net> <Pine.BSI.4.44.0310281409290.26007-100000@dew.goldengate.net>
Message-ID: <20031028205438.GA11682@ussenterprise.ufp.org>

In a message written on Tue, Oct 28, 2003 at 02:16:05PM -0600, Mury wrote:
> RIR	Space held by a RIR
> LIR(P)	Space allocated to a LIR from a RIR
> LIR(N)	Space allocated to a LIR from another LIR
> END(P)	Space assigned to an end user from a RIR
> END(N)	Space assigned to an end user from a LIR

Short, fully descriptive.  Not a bad idea.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org


From bicknell at ufp.org  Tue Oct 28 19:26:13 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 28 Oct 2003 19:26:13 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.LNX.4.44.0310271141470.22893-100000@harbor.gaslightmedia.com>
References: <20031027161534.GC33621@ussenterprise.ufp.org> <Pine.LNX.4.44.0310271141470.22893-100000@harbor.gaslightmedia.com>
Message-ID: <20031029002613.GA21748@ussenterprise.ufp.org>


Since this was the first message to bring up the 80% vrs 25%/50% rule
I'll use it as a base for the reply.  I asked hostmaster at arin.net which
interpretation they use day to day, and if it had always been that way.
My original questions and the hostmaster reply:

] Hello,
] 
] > If an ISP receives an allocation from ARIN (say, a /16), and then
] > reassigns a subset of that space to a "end user" customer (say, a
] > /24), what usage criteria do they need to follow?
] >
] > In particular:
] >
] >    A) The customer must show 80% utilization of their /24.
] >
] >    B) The customer must show 25% immediately, 50% within one year.
] 
] B) is the correct answer
] 
] > Also, regardless of the answer to that question, has ARIN always
] > implemented the policy the same way, or has the answer changed (eg
] > been clarified) at some point in the past?
] 
] ARIN has always applied this principle, as per RFC2050 section 3.1

Based on this response, I suggest updating the text of section 3 under
http://www.arin.net/policy/ipv4.html#additional to read as follows
(lines changed indicated with a plus):

| 3. Require your downstream customers to adhere to the following criteria:
| 
+     * When the customer is a network operator:
| 
|         * Reassignment information for prior allocations must show that each
|           customer meets the 80% utilization criteria and must be available via
|           SWIP/RWhois prior to your issuing them additional space. Note: To
|           maintain the privacy of residential customers, the person's street
|           address and phone number will not be provided.
|         * Customers must follow ARIN guidelines for ISPs
| 
+      * When the customer is an end-user network:
+ 
+         * Customers should be documented to meet the end-user assignment
+           criteria set forth in the next section.
|         * Web host customers should report usage data in a form similar to
|           the chart shown above

I realize it's being a bit verbose, but it will eliminate any
confusion about which criteria to apply, which given my quick google
results earlier and my own personal experience is quite rampant.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031028/72d3d6cb/attachment.sig>

From Michael.Dillon at radianz.com  Wed Oct 29 04:59:28 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 29 Oct 2003 09:59:28 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OFBB15098B.BE38B80D-ON80256DCE.0036AD49-80256DCE.0036E244@radianz.com>

>Do any of those people want to write up a proposal with these ideas or
>different ones of their own, or should I run with it?

Given the amount of time between now and the next
ARIN meeting, I think it is best to leave the proposal
writing until later. And then I think we are better of
if a draft proposal gets discussed on the list well
before it becomes a formal ARIN policy proposal.

Otherwise we risk having too many variations on a
theme presented at the next meeting.

--Michael Dillon





From bicknell at ufp.org  Tue Oct 28 15:54:38 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 28 Oct 2003 15:54:38 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <Pine.BSI.4.44.0310281409290.26007-100000@dew.goldengate.net>
References: <Pine.LNX.4.44.0310271441440.11797-100000@sokol.elan.net> <Pine.BSI.4.44.0310281409290.26007-100000@dew.goldengate.net>
Message-ID: <20031028205438.GA11682@ussenterprise.ufp.org>

In a message written on Tue, Oct 28, 2003 at 02:16:05PM -0600, Mury wrote:
> RIR	Space held by a RIR
> LIR(P)	Space allocated to a LIR from a RIR
> LIR(N)	Space allocated to a LIR from another LIR
> END(P)	Space assigned to an end user from a RIR
> END(N)	Space assigned to an end user from a LIR

Short, fully descriptive.  Not a bad idea.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org


From Michael.Dillon at radianz.com  Wed Oct 29 04:59:28 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 29 Oct 2003 09:59:28 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OFBB15098B.BE38B80D-ON80256DCE.0036AD49-80256DCE.0036E244@radianz.com>

>Do any of those people want to write up a proposal with these ideas or
>different ones of their own, or should I run with it?

Given the amount of time between now and the next
ARIN meeting, I think it is best to leave the proposal
writing until later. And then I think we are better of
if a draft proposal gets discussed on the list well
before it becomes a formal ARIN policy proposal.

Otherwise we risk having too many variations on a
theme presented at the next meeting.

--Michael Dillon





From Michael.Dillon at radianz.com  Wed Oct 29 04:59:28 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Wed, 29 Oct 2003 09:59:28 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OFBB15098B.BE38B80D-ON80256DCE.0036AD49-80256DCE.0036E244@radianz.com>

>Do any of those people want to write up a proposal with these ideas or
>different ones of their own, or should I run with it?

Given the amount of time between now and the next
ARIN meeting, I think it is best to leave the proposal
writing until later. And then I think we are better of
if a draft proposal gets discussed on the list well
before it becomes a formal ARIN policy proposal.

Otherwise we risk having too many variations on a
theme presented at the next meeting.

--Michael Dillon





From michel at arneill-py.sacramento.ca.us  Wed Oct 29 13:28:25 2003
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Wed, 29 Oct 2003 10:28:25 -0800
Subject: [ppml] RE: [address-policy-wg] Re: Is the time for conservation over?
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6F2@server2003.arneill-py.sacramento.ca.us>

> Stephane Bortzmeyer wrote:
> For those who do not (yet) know him, be assured you can safely
> ignore all messages coming from Jeff Williams, known troll in
> the Internet governance issues.

Indeed. I have heard some rumors that Jeff Williams and Jim Fleming are
the same person. Or maybe there is a brotherhood of trolls.


> (And, as we know, IPv8 does not exist.)

I actually read it a while ago. I will not go as far as recommending
reading it, but I found it both hilarious and a somehow extensive list
of exactly what not to do :-)

Michel.




From michel at arneill-py.sacramento.ca.us  Wed Oct 29 13:28:25 2003
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Wed, 29 Oct 2003 10:28:25 -0800
Subject: [ppml] RE: [address-policy-wg] Re: Is the time for conservation over?
Message-ID: <DD7FE473A8C3C245ADA2A2FE1709D90B06C6F2@server2003.arneill-py.sacramento.ca.us>

> Stephane Bortzmeyer wrote:
> For those who do not (yet) know him, be assured you can safely
> ignore all messages coming from Jeff Williams, known troll in
> the Internet governance issues.

Indeed. I have heard some rumors that Jeff Williams and Jim Fleming are
the same person. Or maybe there is a brotherhood of trolls.


> (And, as we know, IPv8 does not exist.)

I actually read it a while ago. I will not go as far as recommending
reading it, but I found it both hilarious and a somehow extensive list
of exactly what not to do :-)

Michel.




From billd at cait.wustl.edu  Thu Oct 30 08:44:51 2003
From: billd at cait.wustl.edu (Bill Darte)
Date: Thu, 30 Oct 2003 07:44:51 -0600
Subject: [ppml] Allocation and reallocation
Message-ID: <DA8A7734F2B39240977D7883C732FF9B02D9C4@kronos.cait.wustl.edu>

Mury,

I too like the succinct manner in which Leo has identified address blocks
below.  It produces some clarity.  I do believe that this is information
that should be included in a glossary at ARIN.  Terminology and its
explanation is an educational issue, it seems to me, and not an address
policy issue.

Bill Darte
ARIN Advisory Council 

> -----Original Message-----
> From: Mury [mailto:mury at goldengate.net]
> Sent: Tuesday, October 28, 2003 5:48 PM
> To: Leo Bicknell
> Cc: ppml at arin.net
> Subject: Re: [ppml] Allocation and reallocation
> 
> 
> 
> Like I mentioned before I have lost track of who started this 
> conversation
> and who has hinted at proposing something, and I don't want 
> to step on any
> toes.
> 
> Do any of those people want to write up a proposal with these ideas or
> different ones of their own, or should I run with it?
> 
> Thanks.
> 
> Mury
> 
> On Tue, 28 Oct 2003, Leo Bicknell wrote:
> 
> > In a message written on Tue, Oct 28, 2003 at 02:16:05PM 
> -0600, Mury wrote:
> > > RIR	Space held by a RIR
> > > LIR(P)	Space allocated to a LIR from a RIR
> > > LIR(N)	Space allocated to a LIR from another LIR
> > > END(P)	Space assigned to an end user from a RIR
> > > END(N)	Space assigned to an end user from a LIR
> >
> > Short, fully descriptive.  Not a bad idea.
> >
> > --
> >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> >         PGP keys at http://www.ufp.org/~bicknell/
> > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
> >
> 


From bicknell at ufp.org  Thu Oct 30 10:03:49 2003
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 30 Oct 2003 10:03:49 -0500
Subject: [ppml] Allocation and reallocation
In-Reply-To: <DA8A7734F2B39240977D7883C732FF9B02D9C4@kronos.cait.wustl.edu>
References: <DA8A7734F2B39240977D7883C732FF9B02D9C4@kronos.cait.wustl.edu>
Message-ID: <20031030150349.GA87112@ussenterprise.ufp.org>

In a message written on Thu, Oct 30, 2003 at 07:44:51AM -0600, Bill Darte wrote:
> I too like the succinct manner in which Leo has identified address blocks
> below.  It produces some clarity.  I do believe that this is information
> that should be included in a glossary at ARIN.  Terminology and its
> explanation is an educational issue, it seems to me, and not an address
> policy issue.

Give Mury credit. :)  

I think there's probably a three step process here.  First we need
to agree on terms, and get a glossary written up.  Second, we need
to update the guidelines for writing a policy to reference the
glossary and use that to get everyone involved (policy writers, AC
reviewers, etc) to insist all new policy used the glossary defined
terms.  Third, we should look at existing policy and any that use
terms not in the glossary should have search-and-replace type changes
(or, perhaps have the term changes integrated into other changes).

While Mr. Dillion wants an overnight rewrite into a fully self-consistent
numbered and indexed policy I think that's a bit much to do in one
step.  However, I think the end point he wants to reach is a good
one, and we should support an iterative process to get them.


-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031030/57ff1f1e/attachment.sig>

From tchristell at springnet.net  Thu Oct 30 10:35:50 2003
From: tchristell at springnet.net (Todd Christell)
Date: Thu, 30 Oct 2003 09:35:50 -0600 (CST)
Subject: [ppml] Allocation and reallocation
In-Reply-To: <DA8A7734F2B39240977D7883C732FF9B02D9C4@kronos.cait.wustl.edu>
References: <DA8A7734F2B39240977D7883C732FF9B02D9C4@kronos.cait.wustl.edu>
Message-ID: <1877.66.119.1.68.1067528150.squirrel@profatus.springnet.net>

If this is a glossary that we are going to show our customers, I would
also include the definition of RIR and LIR.  We know, they don't.

tlc
-- 
Todd Christell
Network Manager
SpringNet
www.springnet.net
417.831.8688

> Mury,
>
> I too like the succinct manner in which Leo has identified address
> blocks below.  It produces some clarity.  I do believe that this is
> information that should be included in a glossary at ARIN.  Terminology
> and its explanation is an educational issue, it seems to me, and not an
> address policy issue.
>
> Bill Darte
> ARIN Advisory Council
>
>> -----Original Message-----
>> From: Mury [mailto:mury at goldengate.net]
>> Sent: Tuesday, October 28, 2003 5:48 PM
>> To: Leo Bicknell
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] Allocation and reallocation
>>
>>
>>
>> Like I mentioned before I have lost track of who started this
>> conversation
>> and who has hinted at proposing something, and I don't want
>> to step on any
>> toes.
>>
>> Do any of those people want to write up a proposal with these ideas or
>> different ones of their own, or should I run with it?
>>
>> Thanks.
>>
>> Mury
>>
>> On Tue, 28 Oct 2003, Leo Bicknell wrote:
>>
>> > In a message written on Tue, Oct 28, 2003 at 02:16:05PM
>> -0600, Mury wrote:
>> > > RIR	Space held by a RIR
>> > > LIR(P)	Space allocated to a LIR from a RIR
>> > > LIR(N)	Space allocated to a LIR from another LIR
>> > > END(P)	Space assigned to an end user from a RIR
>> > > END(N)	Space assigned to an end user from a LIR
>> >
>> > Short, fully descriptive.  Not a bad idea.
>> >
>> > --
>> >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>> >         PGP keys at http://www.ufp.org/~bicknell/
>> > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
>> >
>>





From Michael.Dillon at radianz.com  Thu Oct 30 10:40:30 2003
From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com)
Date: Thu, 30 Oct 2003 15:40:30 +0000
Subject: [ppml] Allocation and reallocation
Message-ID: <OFBEE6164D.3D5EC421-ON80256DCF.00549D35-80256DCF.00561B38@radianz.com>

>While Mr. Dillion wants an overnight rewrite into a fully self-consistent
>numbered and indexed policy I think that's a bit much to do in one
>step.  However, I think the end point he wants to reach is a good
>one, and we should support an iterative process to get them.

I've never suggested an overnight rewrite into a fully
self-consistent policy. However I have suggested an overnight
rewrite into a *NUMBERED* policy as an incremental step
towards a policy that is indexed and more self consistent.
Numbering the sentences and paragraphs in a policy is
not hard as long as you resist the temptation to fix up
the grammar and the language as you go along.

I would still like to see some rewriting of portions
of the policy to clarify the meaning and make it easier to
explain to outsiders, i.e. management in member companies.
This is the harder part and I wanted to begin it by
dealing with the whole issue of allocation, assignment,
and the properties of address blocks.

Along the way, recent discussion clearly showed that there
is some confusion regarding the definition of "utilization"
and the calculation of "utilization rates" but that can
easily be handled incrementally as a separate item.

There's no need to bundle together numbered sentences,
allocation/assignment rethink and clarification of 
utilization. History has shown that we are a lot more
successful in revising policy if we keep the focus fairly
narrow when we get down to writing a proposal.

--Michael Dillon