From bill at herrin.us  Mon Jun  1 00:25:45 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 1 Jun 2009 00:25:45 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com>
Message-ID: <3c3e3fca0905312125x56fccfa0n76c49406e6f67428@mail.gmail.com>

On Sun, May 31, 2009 at 1:19 AM, James Hess<mysidia at gmail.com> wrote:
> Why allocate ?/32s ?from a pool reserved for ?/32s?
> It would perhaps make more sense, as a matter of policy, that a
> special allocation strategy be utilized, ?that the ?/48s, ?/32s, and
> /24s ?are allocated from just one pool.

Hi James,

You'd think so, but no.

Here's the problem: at the BGP level you can't tell the difference
between a multihomed customer route and a traffic engineering route. A
route is a route is a route.

Now, if you filter distant routes from multihomed entities then you
get a rep for being unreliable since you sometimes can't reach those
folks while your competitors can. Hence you don't filter the routes,
multihomed entity or TE. The net result is that your gains from the
multihomed entity announcing only one primary route instead of two or
three are more than erased by the loss to unfilterable TE routes.

If you allocate /32's from a block that's only /32's and /48's from a
block that's only /48's then anything longer than a /32 in the /32
block is traffic engineering. There are no customer routes mixed in.
As a result, the traffic engineering is filterable in a practical way,
which means you can keep the local route count due to traffic
engineering down to a sensible level instead of having to propagate
everybody's TE routes throughout the world.

Look at the top entry on last Friday's CIDR report:

ASnum    NetsNow NetsAggr  NetGain   % Gain   Description
AS6389      4292      338     3954    92.1%   BELLSOUTH-NET-BLK -
                                              BellSouth.net Inc.

Bell south is announcing 4,292 routes into the BGP table which minus
the traffic engineering could be compressed into something close to
338 routes. But nobody can do the compression because it isn't
possible for someone other than Bell South to determine which of the
extra 3,954 routes are TE and which are multihomed customers.

If we could tell with certainty that the extra 3,954 routes were TE
then most nodes could just drop them with essentially no ill effects
to the network. Which according to
http://bill.herrin.us/network/bgpcost.html offers an annual systemic
cost savings of more than $20M. Just from this one example.


On Sun, May 31, 2009 at 8:49 PM, Joe Maimon<jmaimon at chl.com> wrote:
> Renumbering is something everyone should desire to avoid, regardless of how
> easy it is, and I would oppose any policy promoting that activity, so please
> clarify whether you were intending for renumbering to occur or not.

Hi Joe,

Here's the skinny on renumbering: it royally sucks. It isn't just the
direct cost. It takes hours after a renumbering event to get two-nines
recovery of connectivity and it takes months to get to five-nines.
Exceptional system architects can maintain connectivity with overlap
between the old and new numbers and clever policy-routing, but how
many admins are exceptional?

The reasons why renumbering is such a problem are many and varied but
you can understand 90% of it with two concepts, both of which fail
horribly during renumbering: gethostbyname and dns pinning.

Gethostbyname is by far the most common way code monkeys translate DNS
names into IP addresses. Even if you don't use it directly, it lurks
under the hood of most of the APIs you do use. It returns no
information about duration of validity, so nearly every software
developer who uses gethostbyname assumes that the mapping between name
and IP address is valid indefinitely, for whatever duration which the
developer cares to keep track of it. And 20+ years of applications
make that assumption.

DNS Pinning closes a general web browser vulnerability in client-side
scripting languages like javascript which could be made to scan then
interior of a firewalled network by rapidly changing a DNS to IP
address mapping. Greatly simplifying, after reaching a web site, DNS
Pinning prevents the web browser from trying any other IP address for
the site until after the browser is stopped and restarted. This means
that folks using your web server when you renumber won't be able to
reach it again until they close and restart their browsers.

This having been said, with adequate planning and adequate expertise,
renumbering does actually work for single-homed systems transitioning
from one ISP to the next. Where it doesn't work is for multihomed
systems recovering from a link failure. Multihoming recovery needs to
happen in seconds or minutes. Taking hours to get to 2-nines recovery
is unacceptable.

Unfortunately, the renumbering problem doesn't exist in a vacuum. The
only way to avoid renumbering is to always announce at least one route
of your own into the IPv6 BGP DFZ table. As previously mentioned, that
costs at least $10k per year. Absent an accounting system capable of
billing you and distributing the money to the 30k orgs whose resources
you're consuming just by announcing the route, that's more than $10k
of *other people's money.* People don't like it when you spend their
money. People are funny that way.

So, renumbering's role in policy ends up being a balance between three factors:

1. The cost of routes in the DFZ
2. Whether the given activity is practical without announcing a route
into the DFZ
3. Where it is practical, the cost of renumbering instead of
announcing a route into the DFZ

Answering your question directly, my plan assumes that single-homed
systems will renumber when they change ISPs, multihomed systems will
not and by the time you grow into the largest /24 allocation, you're
expected to release your first /48.

The rationale behind single and multihomed systems should be fairly
obvious. I would only add to it that in my ever so humble opinion
there is no entity in ARIN territory whose renumbering cost exceeds
$10k/year yet can't afford to add a DSL line and a tunnel provider.

The reasons for releasing the /48 but keeping the /32 before getting
the /24 are more subtle: How efficiently did you use that /32?
Efficiently enough that you're willing to renumber out of the /48
rather than try to squeeze more efficiency out of the /32.


> So please put a nail into the mantra of registries not being involved in
> routing.

Last year the IRTF RRG made an effort to catalog every way we could
conceive of routing in some future Internet with any prayer of it
working. See http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02
. As you read that draft, one thing that becomes real obvious real
fast is that addressing is routing is addressing.

Registries probably shouldn't try to micro-manage the routing system,
but the nature of the beast is that addressing policy sets the big
picture in which the individual routing decisions are made.


On Sun, May 31, 2009 at 2:42 PM, Kevin Loch<kloch at kl.net> wrote:
> This is called "sparse allocation" method and is what APNIC uses today.  It
> was one of the the justifications for giving each RIR blocks of /12
> instead of /23.  I would like to know why ARIN is not using this method.

Hi Kevin,

Sparse is a farce. It was a clever enough idea, but it ferociously
fragments the pool and it wipes out all the other possible levers for
restraining the table size in the vain hope that each AS will announce
one and only one route. We'd be well rid of it.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bill at herrin.us  Mon Jun  1 00:48:07 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 1 Jun 2009 00:48:07 -0400
Subject: [arin-ppml] Number of routes, IPv6 vrs IPv4.
In-Reply-To: <20090531161152.GB51278@ussenterprise.ufp.org>
References: <20090531161152.GB51278@ussenterprise.ufp.org>
Message-ID: <3c3e3fca0905312148q7583e30ek511e43e248fe0676@mail.gmail.com>

On Sun, May 31, 2009 at 12:11 PM, Leo Bicknell<bicknell at ufp.org> wrote:
> There as recently been a lot of press about the Cisco 6500 "Sup720-3B"
> platform. ?This platform uses TCAM
> (http://en.wikipedia.org/wiki/Content-addressable_memory#Ternary_CAMs) to
> hold routing information so that switching decisions can be made
> at high speed. ?This is fairly expensive memory. ?The reason this
> made press is there is only enough TCAM to hold 256,000 IPv4 routes,
> and the IPv4 routing table is now up in the 290,000 range. ?You can
> find lots of articles about how folks are choosing to throw away
> prefixes to fit in the TCAM limit.

Here's a great article for understanding exactly how TCAMs work. Once
you understand how they work, its fairly obvious why TCAMs are so
expensive compared to generic DRAM.

http://www.pagiamtzis.com/cam/camintro.html

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From michael.dillon at bt.com  Mon Jun  1 04:11:45 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Jun 2009 09:11:45 +0100
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <4A205494.40507@matthew.at>
Message-ID: <28E139F46D45AF49A31950F88C4974580161F2F7@E03MVZ2-UKDY.domain1.systemhost.net>


> Here it is, almost 20 years later, and the IPv6 answer isn't 
> nearly as attractive. And we wonder why people aren't 
> building neat new things with it.

You must have missed RFC 4193

--Michael Dillon


From michael.dillon at bt.com  Mon Jun  1 04:19:44 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Jun 2009 09:19:44 +0100
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <4A201655.14865.4AAC266@farmer.umn.edu>
Message-ID: <28E139F46D45AF49A31950F88C4974580161F327@E03MVZ2-UKDY.domain1.systemhost.net>


> We should use the IPv4 stewardship model for IPv6,  So I want 
> to the ask a more general question; "What is the right 
> stewardship model for IPv6?"  Does the same model work for 
> ISP/LIRs and End Users?

There is no simple answer. IPv6 Unicast /32s are somewhat
limited in supply which caused us to allow for assigning
/56s to residential users. We cannot afford to simply hand
out /32s to anyone who asks for one. It has to be limited
to those who are legitimately running a network service
which aggregates traffic from multiple /48 sites. 

Removing single points of failure tends to be very important
for such aggregation services and we know that BGP multihoming
is required to do this. Therefore BGP multihoming is a strong
indicator that an organisation is actually a service provider.
But there may be other tests that could be applied if the
provider is not currently doing BGP.

--Michael Dillon


From michael.dillon at bt.com  Mon Jun  1 04:41:40 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Jun 2009 09:41:40 +0100
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <20090530192029.GE27636@garry-thinkpad.arpnetworks.com>
Message-ID: <28E139F46D45AF49A31950F88C497458016C2040@E03MVZ2-UKDY.domain1.systemhost.net>

> It is not only between you and the transit provider.  It is 
> also between you and all the networks / network operators 
> that collectively make up the Internet. 

> This is why we are discussing the policy proposal ;)

And it is good to remember that the transit providers 
have veto power over this policy. If ARIN starts handing
out /32s too liberally, then the transit providers will
find other means to decide who qualifies for global
routing and will employ blacklists to ignore the 
too-liberal allocations made by ARIN.

We do not operate in a vacuum, and need to BALANCE
the needs of transit operators with all the other 
needs in order to come up with a balanced policy.

This particular proposal needs a rewrite before it
can be taken seriously.

--Michael Dillon


From michael.dillon at bt.com  Mon Jun  1 04:44:11 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Jun 2009 09:44:11 +0100
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <20090530195050.GA21698@vacation.karoshi.com.>
Message-ID: <28E139F46D45AF49A31950F88C497458016C2058@E03MVZ2-UKDY.domain1.systemhost.net>

> 	what upstream is that?

Your ISP or IPv6 tunnel provider.


>  once again, the limiting notion that
> 	there connectedness to "someone else" is a prerequiste 
> for using IP.
> 	uniqueness i can understand (someday you might want to 
> be connected,
> 	but now...)


You need to read RFC 4193. Plenty of addresses to choose 
from if you worry about someday being connected.

--Michael Dillon


From michael.dillon at bt.com  Mon Jun  1 05:44:31 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Jun 2009 10:44:31 +0100
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <0B9E9A28-D0F4-4CCA-A71D-7497A4BABF4D@delong.com>
Message-ID: <28E139F46D45AF49A31950F88C497458016C2216@E03MVZ2-UKDY.domain1.systemhost.net>

> If every current connected org on the planet that has 
> routable IPv4 space and an ASN in the active routing table 
> were to obtain their own portable IPv6 space and announce as 
> many as 10 routes, we would still have a smaller IPv6 routing 
> table than the current IPv4 routing table.

We still have the problem of the transition period where
everyone has to carry both the existing IPv4 routes and
the IPv6 routes. It is nice that the new IPv6 Internet holds
the promise of a smaller routing table, and therefore the
potential of a longer operational life for core routers,
but first we have to get there.

--Michael Dillon


From terry.l.davis at boeing.com  Mon Jun  1 09:12:12 2009
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 1 Jun 2009 06:12:12 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <20090529201502.GA6398@ussenterprise.ufp.org>
References: <4A1FFBE5.20807@arin.net>
	<20090529174253.GB94380@ussenterprise.ufp.org>
	<20090529185841.GA87992@gweep.net>
	<20090529201502.GA6398@ussenterprise.ufp.org>
Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5493@XCH-NW-CCR1V.nw.nos.boeing.com>

Leo

While I support this, I acknowledge that BGP can't support it.  A couple thoughts:
- To your point on not being able to support every residential user with a PI, maybe we need to look closer at the phone call routing system as they seem to be able to handle it.

- My home is dual-homed already.

Take care
Terry

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Leo Bicknell
> Sent: Friday, May 29, 2009 1:15 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
> 
> In a message written on Fri, May 29, 2009 at 02:58:41PM -0400, Joe Provo
> wrote:
> > I appreciate the intent, but what's the point of yet another
> > unenforcable clause?  Enterprises with multiple private BGP
> > relationships would qualifiy under this and be invisible.
> 
> ARIN actually has a long history of "enforcing" this, the current
> IPv4 criteria has a provision for multi-homed networks to get a
> allocation when single homed networks do not qualify.  I will leave
> staff to comment on how they enforce the criteria.
> 
> With IPv6 we will run out of routing slots before we run out of
> numbers.  Using the sign at the Chinese Buffet as an example:
> 
>   Take all you want, eat all you take.
> 
> Like it or not, the network can't take every residential user having
> their own PI block and routing it.  We don't have routers that can
> support 500 million routes.  We can make a big mess by handing
> things out willy nilly, but just like the dark days of the Internet
> passed the operators will fix it with draconian filtering policies
> that will do no one any good.  Making a mess the operators have to
> fix will create no good will, nor internet stability.
> 
> To that end, I can't support the proposal as written.  As one
> commenter asked, "what if my kids want an IPv6 network to play with
> in their garage?"  Well, we should find some way to accomodate that
> which doesn't require service providers worldwide to spend tens of
> thousands of dollars upgrading routers to hold the routes.
> 
> I realize ARIN does not dictate routing behavior.  However, I can
> tell you how this ends if we get it wrong.  If the table grows too
> fast operators will make their own decisions about "who is worthy".
> I suspect those decisions will be made along the lines of who has
> money to pay to route the prefixes.  If you're worried about your
> kids getting free IP's to play with the you should really worry
> about the $1,000 per month per prefix charge that will come to route
> it to limit table sale.
> 
> I offer up multi-homing as a bar that keeps the number of routes
> manageable.  I'm completely open to other proposals.  I think the 200
> site requirement as it stands now just doesn't work, there are lots of
> large ISP's, who can use a lot of addresses with far fewer than 200
> sites.  But to simply remove it and leave nothing doesn't do anyone any
> favors in the long term.
> 
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/


From terry.l.davis at boeing.com  Mon Jun  1 09:23:28 2009
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 1 Jun 2009 06:23:28 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com><4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>

Milton

Agreed a /56 might be appropriate.

Earlier Owen appropriately corrected me for comparing a /48 v6 allocation to a class B v4 allocation but he actually enforced the point I was going to make.  Even a /48 allocation for small business or individual use is a bit ridiculous given conventional IP network architectures.  But one of our problems is that since we don't have any truly large scale deployments (something at least into the 100K nodes size), we don't know what a real IPv6 network may consume.

Take care
Terry

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Milton L Mueller
> Sent: Saturday, May 30, 2009 2:49 PM
> To: Scott Leibrand; William Herrin
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] A modest proposal for IPv6 address allocations
> 
> 
> > -----Original Message-----
> > Not sure about all the details, but I like the fact
> > that we'd be able to do away with the ISP/end-user distinction, make it
> > easy to get a /48, and provide a simple growth path for the most common
> > cases...
> >
> > -Scott
> 
> Ditto.
> 
> But, let me express (uncharacteristically) some concern about overly
> liberal initial allocations. (e.g., why not a /56?) From the standpoint of
> developing countries, there is some legitimate concern about reproducing
> the land rush phase of IPv4 address allocations (oops, there goes 1/3 of
> the space....)
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From bjohnson at drtel.com  Mon Jun  1 09:23:37 2009
From: bjohnson at drtel.com (Brian Johnson)
Date: Mon, 1 Jun 2009 08:23:37 -0500
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F5493@XCH-NW-CCR1V.nw.nos.boeing.com>
References: <4A1FFBE5.20807@arin.net><20090529174253.GB94380@ussenterprise.ufp.org><20090529185841.GA87992@gweep.net><20090529201502.GA6398@ussenterprise.ufp.org>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5493@XCH-NW-CCR1V.nw.nos.boeing.com>
Message-ID: <29A54911243620478FF59F00EBB12F47017E3312@ex01.drtel.lan>

Terry,

Two points on the telephone system comparison.

 - Circuit switched networks are entirely different than packet based
networks when it comes to routing.
 - With the exception of LNP, the telephone numbering scheme is entirely
hierarchical limiting the number of routes needed.

On a side note, I'm sure that nobody wants the Internet to start to
resemble the telephone network. That would be a bad model. (I can hear
the regulators salivating at the idea.) Not that this isn't already
starting to happen (sigh). :-|

- Brian

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Davis, Terry L
> Sent: Monday, June 01, 2009 8:12 AM
> To: 'Leo Bicknell'; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
> 
> Leo
> 
> While I support this, I acknowledge that BGP can't support it.  A
> couple thoughts:
> - To your point on not being able to support every residential user
> with a PI, maybe we need to look closer at the phone call routing
> system as they seem to be able to handle it.
> 
> - My home is dual-homed already.
> 
> Take care
> Terry
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
> > Behalf Of Leo Bicknell
> > Sent: Friday, May 29, 2009 1:15 PM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
> >
> > In a message written on Fri, May 29, 2009 at 02:58:41PM -0400, Joe
> Provo
> > wrote:
> > > I appreciate the intent, but what's the point of yet another
> > > unenforcable clause?  Enterprises with multiple private BGP
> > > relationships would qualifiy under this and be invisible.
> >
> > ARIN actually has a long history of "enforcing" this, the current
> > IPv4 criteria has a provision for multi-homed networks to get a
> > allocation when single homed networks do not qualify.  I will leave
> > staff to comment on how they enforce the criteria.
> >
> > With IPv6 we will run out of routing slots before we run out of
> > numbers.  Using the sign at the Chinese Buffet as an example:
> >
> >   Take all you want, eat all you take.
> >
> > Like it or not, the network can't take every residential user having
> > their own PI block and routing it.  We don't have routers that can
> > support 500 million routes.  We can make a big mess by handing
> > things out willy nilly, but just like the dark days of the Internet
> > passed the operators will fix it with draconian filtering policies
> > that will do no one any good.  Making a mess the operators have to
> > fix will create no good will, nor internet stability.
> >
> > To that end, I can't support the proposal as written.  As one
> > commenter asked, "what if my kids want an IPv6 network to play with
> > in their garage?"  Well, we should find some way to accomodate that
> > which doesn't require service providers worldwide to spend tens of
> > thousands of dollars upgrading routers to hold the routes.
> >
> > I realize ARIN does not dictate routing behavior.  However, I can
> > tell you how this ends if we get it wrong.  If the table grows too
> > fast operators will make their own decisions about "who is worthy".
> > I suspect those decisions will be made along the lines of who has
> > money to pay to route the prefixes.  If you're worried about your
> > kids getting free IP's to play with the you should really worry
> > about the $1,000 per month per prefix charge that will come to route
> > it to limit table sale.
> >
> > I offer up multi-homing as a bar that keeps the number of routes
> > manageable.  I'm completely open to other proposals.  I think the
200
> > site requirement as it stands now just doesn't work, there are lots
> of
> > large ISP's, who can use a lot of addresses with far fewer than 200
> > sites.  But to simply remove it and leave nothing doesn't do anyone
> any
> > favors in the long term.
> >
> > --
> >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> >         PGP keys at http://www.ufp.org/~bicknell/
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From terry.l.davis at boeing.com  Mon Jun  1 09:33:06 2009
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 1 Jun 2009 06:33:06 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <20090531202811.GA4943@vacation.karoshi.com.>
References: <4A1FFBE5.20807@arin.net>
	<4A200639.4030209@rollernet.us><20090529160246.GA23729@gweep.net><200905311
	60653.GA1226@jeeves.rigozsaurus.com><F2478A1A-A36E-4A02-B2F7-6801E19821FF@pch.net><g3d49phy0l.fsf@nsa.vix.com>
	<20090531202811.GA4943@vacation.karoshi.com.>
Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5495@XCH-NW-CCR1V.nw.nos.boeing.com>

Paul

Agree absolutely!

I'm working with a couple different industry-wide consortiums on IPv6 planning and they may fit one of your models. 

Take care
Terry

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of bmanning at vacation.karoshi.com
> Sent: Sunday, May 31, 2009 1:28 PM
> To: Paul Vixie
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
> 
> On Sun, May 31, 2009 at 07:29:14PM +0000, Paul Vixie wrote:
> > tvest at pch.net (Tom Vest) writes:
> >
> > > If I remember correctly, creating a swamp only serves to constantly
> > > remind those who are stuck with it afterward that swamp creation was /
> is
> > > a very bad idea. Besides, if you have an idea of where/how one might
> > > build a more "solid foundation", persuading us now, up front might be
> a
> > > more effective way of bringing people around than intentionally
> degrading
> > > the only "ground" that's currently apparent.
> >
> > there are more than two visions (pure hierarchy and pure swamp).  for
> example:
> >
> > neighborhood or metro-area mesh networking where local cheap highspeed
> ISO-L2
> > is used to glue geographies together in a way that no telco or backbone
> net
> > is involved... would make better use of available glass and silicon than
> the
> > pure hierarchical model IETF CIDR gave us.  this sounds like a bad idea
> since
> > it would either mean a global swamp (everybody's /56 in the core) or
> monopoly
> > status for incumbants (everybody's /56 came from the same /32) or mass
> route
> > pollution (everybody's /56 becomes a metro-area cutout).
> >
> > but what if multihoming was automatic and universal and robust?  could a
> metro
> > or neighborhood get unrouteable / non-global IPv6 space for an ISO-L2
> overlay
> > made up of a hairball of private wireless, private wire, private fiber,
> and
> > automatically use those addresses when talking to reachable endpoints?
> (this
> > would require something better than RIPv2, so don't try it at home
> today!)
> >
> > or what if a metropolitan connectivity authority wanted to get an IPv6
> block
> > for all of its FTTH and mobile/wireless endpoints, and rather than
> buying
> > transit for this block, they set up a market of cooperating backbone
> operators
> > and consumers, doing IP-in-IP to deliver global reachability?  (this is
> like
> > what some 802 networks do today but wide area bridging does not scale
> well.)
> >
> > i'm not proposing either of these, not exactly.  i'm saying there ought
> to
> > be room in the RIR allocation policy framework for addressing models
> that
> > are not dreamt of by those who love swamps and those who fear swamps.
> > --
> > Paul Vixie
> > KI6YSY
> 
> 
> 	indeed there should be.
> 
> --bill
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From terry.l.davis at boeing.com  Mon Jun  1 09:42:18 2009
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 1 Jun 2009 06:42:18 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <29A54911243620478FF59F00EBB12F47017E3312@ex01.drtel.lan>
References: <4A1FFBE5.20807@arin.net><20090529174253.GB94380@ussenterprise.u
	fp.org><20090529185841.GA87992@gweep.net><20090529201502.GA6398@ussenterpri
	se.ufp.org>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5493@XCH-NW-CCR1V.nw.nos.boeing.com>
	<29A54911243620478FF59F00EBB12F47017E3312@ex01.drtel.lan>
Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5496@XCH-NW-CCR1V.nw.nos.boeing.com>

Brian

LNP appears to be the model that they are going to have to live with, at least within national boundaries.  

And no I sure do NOT want the ITU involved again but my point was that perhaps we need to try to think a bit outside of the box to solve our routing limitations.

Take care
Terry

> -----Original Message-----
> From: Brian Johnson [mailto:bjohnson at drtel.com]
> Sent: Monday, June 01, 2009 6:24 AM
> To: Davis, Terry L; Leo Bicknell; arin-ppml at arin.net
> Subject: RE: [arin-ppml] Policy Proposal: Open Access To IPv6
> 
> Terry,
> 
> Two points on the telephone system comparison.
> 
>  - Circuit switched networks are entirely different than packet based
> networks when it comes to routing.
>  - With the exception of LNP, the telephone numbering scheme is entirely
> hierarchical limiting the number of routes needed.
> 
> On a side note, I'm sure that nobody wants the Internet to start to
> resemble the telephone network. That would be a bad model. (I can hear
> the regulators salivating at the idea.) Not that this isn't already
> starting to happen (sigh). :-|
> 
> - Brian
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
> > Behalf Of Davis, Terry L
> > Sent: Monday, June 01, 2009 8:12 AM
> > To: 'Leo Bicknell'; arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
> >
> > Leo
> >
> > While I support this, I acknowledge that BGP can't support it.  A
> > couple thoughts:
> > - To your point on not being able to support every residential user
> > with a PI, maybe we need to look closer at the phone call routing
> > system as they seem to be able to handle it.
> >
> > - My home is dual-homed already.
> >
> > Take care
> > Terry
> >
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On
> > > Behalf Of Leo Bicknell
> > > Sent: Friday, May 29, 2009 1:15 PM
> > > To: arin-ppml at arin.net
> > > Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
> > >
> > > In a message written on Fri, May 29, 2009 at 02:58:41PM -0400, Joe
> > Provo
> > > wrote:
> > > > I appreciate the intent, but what's the point of yet another
> > > > unenforcable clause?  Enterprises with multiple private BGP
> > > > relationships would qualifiy under this and be invisible.
> > >
> > > ARIN actually has a long history of "enforcing" this, the current
> > > IPv4 criteria has a provision for multi-homed networks to get a
> > > allocation when single homed networks do not qualify.  I will leave
> > > staff to comment on how they enforce the criteria.
> > >
> > > With IPv6 we will run out of routing slots before we run out of
> > > numbers.  Using the sign at the Chinese Buffet as an example:
> > >
> > >   Take all you want, eat all you take.
> > >
> > > Like it or not, the network can't take every residential user having
> > > their own PI block and routing it.  We don't have routers that can
> > > support 500 million routes.  We can make a big mess by handing
> > > things out willy nilly, but just like the dark days of the Internet
> > > passed the operators will fix it with draconian filtering policies
> > > that will do no one any good.  Making a mess the operators have to
> > > fix will create no good will, nor internet stability.
> > >
> > > To that end, I can't support the proposal as written.  As one
> > > commenter asked, "what if my kids want an IPv6 network to play with
> > > in their garage?"  Well, we should find some way to accomodate that
> > > which doesn't require service providers worldwide to spend tens of
> > > thousands of dollars upgrading routers to hold the routes.
> > >
> > > I realize ARIN does not dictate routing behavior.  However, I can
> > > tell you how this ends if we get it wrong.  If the table grows too
> > > fast operators will make their own decisions about "who is worthy".
> > > I suspect those decisions will be made along the lines of who has
> > > money to pay to route the prefixes.  If you're worried about your
> > > kids getting free IP's to play with the you should really worry
> > > about the $1,000 per month per prefix charge that will come to route
> > > it to limit table sale.
> > >
> > > I offer up multi-homing as a bar that keeps the number of routes
> > > manageable.  I'm completely open to other proposals.  I think the
> 200
> > > site requirement as it stands now just doesn't work, there are lots
> > of
> > > large ISP's, who can use a lot of addresses with far fewer than 200
> > > sites.  But to simply remove it and leave nothing doesn't do anyone
> > any
> > > favors in the long term.
> > >
> > > --
> > >        Leo Bicknell - bicknell at ufp.org - CCIE 3440
> > >         PGP keys at http://www.ufp.org/~bicknell/
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.


From farmer at umn.edu  Mon Jun  1 10:12:34 2009
From: farmer at umn.edu (David Farmer)
Date: 01 Jun 2009 09:12:34 -0500
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F5493@XCH-NW-CCR1V.nw.nos.boeing.com>
References: <4A1FFBE5.20807@arin.net>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5493@XCH-NW-CCR1V.nw.nos.boeing.com>
Message-ID: <Gophermail.2.0.0906010912340.8059@vs-m.tc.umn.edu>

On Jun 1 2009, Davis, Terry L wrote:

>Leo
>
> While I support this, I acknowledge that BGP can't support it. A couple 
> thoughts:
> - To your point on not being able to support every residential user with 
> a PI, maybe we need to look closer at the phone call routing system as 
> they seem to be able to handle it.

The PSTN uses what is basically an Identifier-Locator split, and it is 
connection based so you only have to resolve the Identifier to the Locator 
once. And by the way it was nearly 100 year before the PSTN implemented 
number portability.

This is why people are looking a LISP and other Identifier-Locator split 
technologies. While I believe this is where the Internet needs to go in the 
medium to longer term; Right now, we need a model based on currently 
available and deployable technologies that will get IPv6 deployed. Then we 
can come back and implement IPv6 Identifier-Locator split technologies.

And FYI, there is currently no concept of equal to dual-homing in the 
Internet for the PSTN, you can have multiple out bound phone providers, in 
fact this is very common for large PBXes, but you currently can only number 
port a PSTN Identifier to a single provider to receive calls for an 
individual phone number.



From Wesley.E.George at sprint.com  Mon Jun  1 11:55:46 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Mon, 1 Jun 2009 10:55:46 -0500
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <C645FC9F.7496D%mksmith@adhost.com>
References: <4A1FFBE5.20807@arin.net> <C645FC9F.7496D%mksmith@adhost.com>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A7F1581505@PLSWM01C.ad.sprint.com>


-----Original Message-----
>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. Smith
>Sent: Friday, May 29, 2009 11:57 PM
>To: Member Services; arin-ppml at arin.net
>Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
>
>- There is at least one major transit provider that will accept nothing more
>specific than a /32.
>- If we continue to inhibit providers' ability to get a /32, they may have
>reachability issues.
>
>Mike

As one of the folks that personally oversaw the liberalization of the IPv6 route acceptance policy at what may still be classified as a major transit provider, I can say that IMO this is not a good basis for an argument in support of standardizing on allocating a /32 to more entities. If all of a major transit provider's customers expect to be able to route smaller blocks than that because, well, that's what they were assigned, they will either modify their policy or lose those customers.
We used to rigidly follow RFC 2772 back in the 6bone days. Customers came to us with legitimate reasons for accepting deaggregates, and we moved down to accepting a /48. At first, we tried to use the strict case listed at http://www.space.net/~gert/RIPE/ipv6-filters.html which keeps track of which blocks are being used for micro-allocations and eventually abandoned it in favor of the loose case because we couldn't keep up with the changes, and there were legitimate reasons for customers to announce deaggregates to us even if they had a /32. Yes, eventually that is going to create routing table bloat, but there's not many other ways to manage multiple sites allocated from the same /32 that aren't connected to each other except via the ISP. We do warn people that if they choose not to advertise an aggregate from at least one site, they may have reachability issues, but that reachability to networks beyond our own is not a guarantee because we don't control their routing policy.

I think maybe the bigger issue is the assumption (based on RFC3177) that each site or sub-allocation needs to be able to have a /48 allocated to it, and therefore multi-site locations automatically justify a /32 or larger so that they can allocate contiguously. I'm not aware of too many applications that will get anywhere NEAR allocating an entire /48's worth of hosts per site even with a lot of subnets. Beyond routing rules which may or may not exist in the DFZ, I certainly can't come up with many reasons why you would need something larger than /48 for a network that would have trouble meeting the current 200 sub-allocations requirement. Perhaps what we should be doing is simply expecting people to more efficiently use /48s. I'd like to hope that the IPv6 addressing debate has evolved a bit since 2001 when 3177 was written, but even if you still assume allocation of a /64 to each host, that's 64K hosts (aka a /16 of IPv4 space). As Bill Herrin pointed out in a previous mail, a /48 is 16 /52's or 256 /56's or 4096 /60's. Even the smallest of those sub-allocations gives you 16 subnets.

No, deaggregation of /48s doesn't solve the routing table bloat problem, it probably exacerbates it, but at least it uses addresses more efficiently. I'm hearing a scary amount of language akin to "we'll *never* run out of IPv6 addresses even if we use /32s like /24s". Echoes of the quote about 640K of RAM attributed to Bill Gates seem appropriate here. Yes, IPv6 has a mind-bogglingly large amount of space, and yes everyone who wants IPv6 space should be able to get it from some source. Giving everyone a /32 is not the way to solve the problem being presented (I think) by this policy proposal - that not everyone who wants IPv6 can get it today. I'd rather not be thought of as one of the folks that caused us to have to move to IPv8 (256 bit addresses) because we didn't use any care in allocating space or expecting people not to waste it simply because we couldn't get our heads around how big it was or was not.

Thanks,
Wes

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From dlw+arin at tellme.com  Mon Jun  1 11:52:40 2009
From: dlw+arin at tellme.com (David Williamson)
Date: Mon, 1 Jun 2009 08:52:40 -0700
Subject: [arin-ppml] Policy Proposal: Internet Assigned Numbers
	Authority (IANA) Policy for Allocation of ASN Blocks (ASNs)
	to Regional Internet Registries
In-Reply-To: <4A203F1F.8090002@gmail.com>
References: <4A1FFB11.9080101@arin.net>
	<12535BF9-2693-4480-88E1-ED7139A88B58@delong.com>
	<4A203F1F.8090002@gmail.com>
Message-ID: <20090601155240.GJ16587@shell02.cell.sv2.tellme.com>

I support the policy as written.  I think Owen has a great idea, but
the timeline is a problem for changes.  It would be possible to start a
new policy to correct this one with Owen's suggested changes, but let's
fast track this one *as is*.

I'd even support this as written if it was declared to be a Board
response to an emergency.  Unless there are compelling arguments in
dissent, this should simply move forward.

-David

On Fri, May 29, 2009 at 03:01:35PM -0500, Scott Leibrand wrote:
> One thing to keep in mind here is that, because this is a Global Policy, 
> and because of the extremely tight timeframe, we need to agree on the 
> text of the proposal right away, and make sure the same text gets put 
> forward in each region.  Even if everyone approves it their first time 
> around, and LACNIC approves it through their fast-track process (since 
> it'll be exactly a year until their next meeting), we're still looking 
> at sometime in 2010 before the policy can be ratified by the ASO-AC and 
> ICANN.  That will mean we will have several months (at least) of RIRs 
> being unable to get more 16-bit ASNs from the IANA before this policy 
> could go through and make it possible again.  I've heard some very good 
> arguments in the last week that the simpler we make the change, the less 
> likely we are to run into problems that cause delays in getting this 
> approved in time for it to be useful...
> 
> How important do you think it is to preserve the 16bit/32bit ASN 
> distinction past 1 Jan 2011?  Is it worth the increased risk of delay in 
> passing such a revised global policy?
> 
> (As you probably figured out from my comments above, I personally 
> support this policy.)
> 
> -Scott
> 
> Owen DeLong wrote:
> >While I do not support changing the RIR policy on the issuance of ASNs,
> >I do support this policy proposal.  I think that modifying the IANA->RIR
> >distribution rules to accommodate the needs of RIRs to better serve their
> >constituents makes sense. Further, having 16-bit ASNs trapped in the
> >IANA free pool because 32-bit ASNs are not being accepted by recipients
> >is absurd and poor stewardship. We should go ahead and issue 16-bit
> >ASNs until they run out.
> >
> >I would suggest that this proposal, rather than removing the distinction
> >in 2010 should be modified to extend the IANA->RIR duality until such
> >time as there are no more 16-bit ASN blocks in the IANA pool.
> >
> >Owen
> >
> >On May 29, 2009, at 8:11 AM, Member Services wrote:
> >
> >>ARIN received the following policy proposal and is posting it to the
> >>Public Policy Mailing List (PPML) in accordance with Policy Development
> >>Process.
> >>
> >>This proposal is in the first stage of the Policy Development Process.
> >>ARIN staff will perform the Clarity and Understanding step. Staff does
> >>not evaluate the proposal at this time, their goal is to make sure that
> >>they understand the proposal and believe the community will as well.
> >>Staff will report their results to the ARIN Advisory Council (AC) within
> >>10 days.
> >>
> >>The AC will review the proposal at their next regularly scheduled
> >>meeting (if the period before the next regularly scheduled meeting is
> >>less than 10 days, then the period may be extended to the subsequent
> >>regularly scheduled meeting). The AC will decide how to utilize the
> >>proposal and announce the decision to the PPML.
> >>
> >>In the meantime, the AC invites everyone to comment on the proposal on
> >>the PPML, particularly their support or non-support and the reasoning
> >>behind their opinion. Such participation contributes to a thorough
> >>vetting and provides important guidance to the AC in their 
> >>deliberations.
> >>
> >>The ARIN Policy Development Process can be found at:
> >>https://www.arin.net/policy/pdp.html
> >>
> >>Mailing list subscription information can be found
> >>at:https://www.arin.net/mailing_lists/
> >>
> >>Regards,
> >>
> >>Member Services
> >>American Registry for Internet Numbers (ARIN)
> >>
> >>
> >>## * ##
> >>
> >>
> >>Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for
> >>Allocation of ASN Blocks (ASNs) to Regional Internet Registries
> >>
> >>Proposal Originator: Stacy Hughes and Andrew de la Haye
> >>
> >>Proposal Version: 1.0
> >>
> >>Date: 29 May 2009
> >>
> >>Proposal type: modify
> >>
> >>Policy term: permanent
> >>
> >>Policy statement:
> >>
> >>Modification of NRPM section 10.3 extending the deadline for an
> >>undifferentiated ASN pool by 1 year to read:
> >>
> >>1. Allocation Principles
> >>
> >>IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the
> >>term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010,
> >>allocations of 16-bit and 32-bit only ASN blocks will be made separately
> >>and independent of each other [1].
> >>
> >>This means until 31 December 2010, RIRs can receive two separate ASN
> >>blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA
> >>under this policy. After this date, IANA and the RIRs will cease to make
> >>any distinction between 16-bit and 32-bit only ASNs, and will operate
> >>ASN allocations from an undifferentiated 32-bit ASN allocation pool.
> >>
> >>Rationale:
> >>
> >>a. Arguments supporting the proposal
> >>
> >>Due to operational issues external to the IANA/RIR policy process,
> >>32-bit only ASNs are not being issued by the RIRs at the anticipated
> >>rate. As it stands, RIRs will likely not be able to justify a new block
> >>of ASNs from the IANA after 31 December 2009 due to a glut of free 32
> >>bit only ASNs in the RIR?s pool. This leaves available, essential 16-bit
> >>ASNs stranded in the IANA free pool. This proposal seeks to remedy the
> >>potential problem by extending the deadline for differentiation by one
> >>year.
> >>
> >>With this proposal the policy will be aligned with the actual reality in
> >>regards to 32-bit ASN deployment and usage.
> >>
> >>The subject was raised during RIPE 58 and a presentation was made:
> >>http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf 
> >>
> >>
> >>The feedback in this session suggested that a global policy proposal
> >>should be developed and should be discussed.
> >>
> >>b. Arguments opposing the proposal
> >>
> >>Some may think that extending the previously set timeline can be
> >>perceived as some discouragement for the deployment of 32-bit ASNs. One
> >>counter argument to this is that RIRs and Internet community have some
> >>other mechanisms and activities to raise awareness for 32-bit ASN pool
> >>(via public presentations and trainings). These activities will continue
> >>while 16-bit ASN blocks are still allocated to RIRs by the IANA as they
> >>are available and they are needed.
> >>
> >>Timetable for implementation: Immediately upon ratification by ICANN 
> >>Board
> >>
> >>
> >>
> >>_______________________________________________
> >>PPML
> >>You are receiving this message because you are subscribed to
> >>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >>Unsubscribe or manage your mailing list subscription at:
> >>http://lists.arin.net/mailman/listinfo/arin-ppml
> >>Please contact info at arin.net if you experience any issues.
> >
> >_______________________________________________
> >PPML
> >You are receiving this message because you are subscribed to
> >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >Unsubscribe or manage your mailing list subscription at:
> >http://lists.arin.net/mailman/listinfo/arin-ppml
> >Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From scottleibrand at gmail.com  Mon Jun  1 12:19:51 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 1 Jun 2009 11:19:51 -0500
Subject: [arin-ppml] Policy Proposal: Internet Assigned Numbers
	Authority (IANA) Policy for Allocation of ASN Blocks (ASNs)
	to Regional Internet Registries
In-Reply-To: <20090601155240.GJ16587@shell02.cell.sv2.tellme.com>
References: <4A1FFB11.9080101@arin.net>
	<12535BF9-2693-4480-88E1-ED7139A88B58@delong.com>
	<4A203F1F.8090002@gmail.com>
	<20090601155240.GJ16587@shell02.cell.sv2.tellme.com>
Message-ID: <A691E402-48D7-45C2-968C-C326A6577138@gmail.com>

I agree, but I don't think there's any benefit to using our emergency  
process, as we'd just end up waiting on other RIRs. If we pass it this  
fall, and other RIRs do likewise, the policy supporters can focus  
their efforts on getting the ASO AC and ICANN to move quickly, and we  
should have something in early 2010.

-Scott

On Jun 1, 2009, at 10:52 AM, David Williamson <dlw+arin at tellme.com>  
wrote:

> I support the policy as written.  I think Owen has a great idea, but
> the timeline is a problem for changes.  It would be possible to  
> start a
> new policy to correct this one with Owen's suggested changes, but  
> let's
> fast track this one *as is*.
>
> I'd even support this as written if it was declared to be a Board
> response to an emergency.  Unless there are compelling arguments in
> dissent, this should simply move forward.
>
> -David
>
> On Fri, May 29, 2009 at 03:01:35PM -0500, Scott Leibrand wrote:
>> One thing to keep in mind here is that, because this is a Global  
>> Policy,
>> and because of the extremely tight timeframe, we need to agree on the
>> text of the proposal right away, and make sure the same text gets put
>> forward in each region.  Even if everyone approves it their first  
>> time
>> around, and LACNIC approves it through their fast-track process  
>> (since
>> it'll be exactly a year until their next meeting), we're still  
>> looking
>> at sometime in 2010 before the policy can be ratified by the ASO-AC  
>> and
>> ICANN.  That will mean we will have several months (at least) of RIRs
>> being unable to get more 16-bit ASNs from the IANA before this policy
>> could go through and make it possible again.  I've heard some very  
>> good
>> arguments in the last week that the simpler we make the change, the  
>> less
>> likely we are to run into problems that cause delays in getting this
>> approved in time for it to be useful...
>>
>> How important do you think it is to preserve the 16bit/32bit ASN
>> distinction past 1 Jan 2011?  Is it worth the increased risk of  
>> delay in
>> passing such a revised global policy?
>>
>> (As you probably figured out from my comments above, I personally
>> support this policy.)
>>
>> -Scott
>>
>> Owen DeLong wrote:
>>> While I do not support changing the RIR policy on the issuance of  
>>> ASNs,
>>> I do support this policy proposal.  I think that modifying the  
>>> IANA->RIR
>>> distribution rules to accommodate the needs of RIRs to better  
>>> serve their
>>> constituents makes sense. Further, having 16-bit ASNs trapped in the
>>> IANA free pool because 32-bit ASNs are not being accepted by  
>>> recipients
>>> is absurd and poor stewardship. We should go ahead and issue 16-bit
>>> ASNs until they run out.
>>>
>>> I would suggest that this proposal, rather than removing the  
>>> distinction
>>> in 2010 should be modified to extend the IANA->RIR duality until  
>>> such
>>> time as there are no more 16-bit ASN blocks in the IANA pool.
>>>
>>> Owen
>>>
>>> On May 29, 2009, at 8:11 AM, Member Services wrote:
>>>
>>>> ARIN received the following policy proposal and is posting it to  
>>>> the
>>>> Public Policy Mailing List (PPML) in accordance with Policy  
>>>> Development
>>>> Process.
>>>>
>>>> This proposal is in the first stage of the Policy Development  
>>>> Process.
>>>> ARIN staff will perform the Clarity and Understanding step. Staff  
>>>> does
>>>> not evaluate the proposal at this time, their goal is to make  
>>>> sure that
>>>> they understand the proposal and believe the community will as  
>>>> well.
>>>> Staff will report their results to the ARIN Advisory Council (AC)  
>>>> within
>>>> 10 days.
>>>>
>>>> The AC will review the proposal at their next regularly scheduled
>>>> meeting (if the period before the next regularly scheduled  
>>>> meeting is
>>>> less than 10 days, then the period may be extended to the  
>>>> subsequent
>>>> regularly scheduled meeting). The AC will decide how to utilize the
>>>> proposal and announce the decision to the PPML.
>>>>
>>>> In the meantime, the AC invites everyone to comment on the  
>>>> proposal on
>>>> the PPML, particularly their support or non-support and the  
>>>> reasoning
>>>> behind their opinion. Such participation contributes to a thorough
>>>> vetting and provides important guidance to the AC in their
>>>> deliberations.
>>>>
>>>> The ARIN Policy Development Process can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>>
>>>> Mailing list subscription information can be found
>>>> at:https://www.arin.net/mailing_lists/
>>>>
>>>> Regards,
>>>>
>>>> Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>>
>>>> ## * ##
>>>>
>>>>
>>>> Policy Proposal: Internet Assigned Numbers Authority (IANA)  
>>>> Policy for
>>>> Allocation of ASN Blocks (ASNs) to Regional Internet Registries
>>>>
>>>> Proposal Originator: Stacy Hughes and Andrew de la Haye
>>>>
>>>> Proposal Version: 1.0
>>>>
>>>> Date: 29 May 2009
>>>>
>>>> Proposal type: modify
>>>>
>>>> Policy term: permanent
>>>>
>>>> Policy statement:
>>>>
>>>> Modification of NRPM section 10.3 extending the deadline for an
>>>> undifferentiated ASN pool by 1 year to read:
>>>>
>>>> 1. Allocation Principles
>>>>
>>>> IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this  
>>>> document the
>>>> term "ASN block" refers to a set of 1024 ASNs. Until 31 December  
>>>> 2010,
>>>> allocations of 16-bit and 32-bit only ASN blocks will be made  
>>>> separately
>>>> and independent of each other [1].
>>>>
>>>> This means until 31 December 2010, RIRs can receive two separate  
>>>> ASN
>>>> blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the  
>>>> IANA
>>>> under this policy. After this date, IANA and the RIRs will cease  
>>>> to make
>>>> any distinction between 16-bit and 32-bit only ASNs, and will  
>>>> operate
>>>> ASN allocations from an undifferentiated 32-bit ASN allocation  
>>>> pool.
>>>>
>>>> Rationale:
>>>>
>>>> a. Arguments supporting the proposal
>>>>
>>>> Due to operational issues external to the IANA/RIR policy process,
>>>> 32-bit only ASNs are not being issued by the RIRs at the  
>>>> anticipated
>>>> rate. As it stands, RIRs will likely not be able to justify a new  
>>>> block
>>>> of ASNs from the IANA after 31 December 2009 due to a glut of  
>>>> free 32
>>>> bit only ASNs in the RIR?s pool. This leaves available, essent 
>>>> ial 16-bit
>>>> ASNs stranded in the IANA free pool. This proposal seeks to  
>>>> remedy the
>>>> potential problem by extending the deadline for differentiation  
>>>> by one
>>>> year.
>>>>
>>>> With this proposal the policy will be aligned with the actual  
>>>> reality in
>>>> regards to 32-bit ASN deployment and usage.
>>>>
>>>> The subject was raised during RIPE 58 and a presentation was made:
>>>> http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf
>>>>
>>>>
>>>> The feedback in this session suggested that a global policy  
>>>> proposal
>>>> should be developed and should be discussed.
>>>>
>>>> b. Arguments opposing the proposal
>>>>
>>>> Some may think that extending the previously set timeline can be
>>>> perceived as some discouragement for the deployment of 32-bit  
>>>> ASNs. One
>>>> counter argument to this is that RIRs and Internet community have  
>>>> some
>>>> other mechanisms and activities to raise awareness for 32-bit ASN  
>>>> pool
>>>> (via public presentations and trainings). These activities will  
>>>> continue
>>>> while 16-bit ASN blocks are still allocated to RIRs by the IANA  
>>>> as they
>>>> are available and they are needed.
>>>>
>>>> Timetable for implementation: Immediately upon ratification by  
>>>> ICANN
>>>> Board
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.


From info at arin.net  Mon Jun  1 13:53:14 2009
From: info at arin.net (Member Services)
Date: Mon, 01 Jun 2009 13:53:14 -0400
Subject: [arin-ppml] =?windows-1252?q?Call_for_Community_Consultation_=96_?=
 =?windows-1252?q?ARIN=92s_DNSSEC_Deployment_Plan?=
Message-ID: <4A24158A.4070305@arin.net>

ARIN has published a proposed plan for DNSSEC deployment and is seeking 
community review and comment. The document is available at 
https://www.arin.net/about_us/dnssec/.

Please submit your comments to the consult at arin.net. You can subscribe 
to the arin-consult mailing list at:
http://lists.arin.net/mailman/listinfo/arin-consult.

Discussion on consult at arin.net will close at noon EDT 16 June 2009.

Based on the feedback provided, ARIN will update the deployment plan as 
needed with deployment currently planned for 1 July 2009.

The ARIN Consultation and Suggestion Process documentation is available
at: https://www.arin.net/participate/acsp/index.html

All are welcome to participate.  Please address any process questions to 
info at arin.net.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)



From owen at delong.com  Mon Jun  1 15:23:27 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 1 Jun 2009 12:23:27 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <A4285FC9-5428-4E3A-9046-B252A40BC4BF@pch.net>
References: <F7EB0A7C707E39409A73CD0353242551A7F1580EDB@PLSWM01C.ad.sprint.com>	<2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com>
	<20090529212938.GA11989@ussenterprise.ufp.org>
	<4A205A75.10107@matthew.at>
	<A4285FC9-5428-4E3A-9046-B252A40BC4BF@pch.net>
Message-ID: <0029FD77-572D-4098-A5C5-E5796948244C@delong.com>

Let's run some realistic numbers into this "unsustainable growth" we  
keep hearing about...

There are, currently, about 32000 actively advertised ASNs
Source: (http://www.potaroo.net/tools/asn16 Figure 11)

The IPv4 routing table is currently somewhere around 285,000 routes  
for an average of
nearly 9 routes per prefix.  The IPv6 reality is much more likely to  
be closer to 3 routes
per prefix (in fact, the vast majority of end-user ASNs should be very  
close to 1 prefix
and the vast majority of ISPs will be reasonably close to that for  
ORIGINating routes,
but, will advertise prefixes from other end-users, obviously).

If we multiply 32000 by 3, we find that we have a 96,000 route IPv6  
BGP table if
we did nothing but convert all the current origin ASNs to IPv6 at an  
expected 3 prefixes
per origin ASN average.

Inevitably, we are going to have to change the routing paradigm, and,  
research is
being done into things like LISP and other ID/Locator separation  
mechanisms.
I think that these will be required for sustained growth, but, to get  
from where we
are now to a workable IPv6 deployment at or near the time of IPv4  
runout (where
workable is defined as IPv6 only users being connected to the internet  
without
being unable to reach vast portions of the currently accessible  
content), I think
it is necessary to move forward with more liberal prefix delegation  
policies
and get IPv6 better deployed.

It will probably take 10 years or more for the IPv6 routing table to  
approach
200k routes, and, by that time, it is likely that new routing  
paradigms will have
some operational experience and acceptance. It's also likely that  
routers will
be able to handle still larger tables by then.  TCAM might even be  
more cost
effective by that time.

IPv6 is not IPv4. We don't need to deal with all the prefix  
fragmentation that
occurred as a result of trying to squeeze IPv4 assignments/allocations  
to the
smallest fit in an effort to conserve IPv4 space.

Indeed, the thing that could drive the greatest bloat in IPv6 routing  
tables over
time is failing to relax allocation policies and creating multiple  
prefixes per
entity all over again.

Owen

On May 30, 2009, at 9:15 AM, Tom Vest wrote:

>
> On May 29, 2009, at 5:58 PM, Matthew Kaufman wrote:
>
>> Leo Bicknell wrote:
>>>
>>> The end user policy gives out /48's.  If we want folks to get a
>>> network they can play with in their garage, let's do it under the
>>> end user policy.  This policy proposal affects the ISP section,
>>> giving out /32's for the express purpose of assigning /48's to other
>>> entities.  Let's leave it for folks who are really ISP's, and really
>>> providing services to others.
>>>
>> Ah. "Folks who are really ISPs". This is as bad as the com-priv  
>> list in 1992... We *don't know* who is/will be "an ISP". A school  
>> district providing service to all its schools? A corporation with a  
>> dozen subsidiaries around the world? A guy in his garage who gives  
>> away free wireless to his neighborhood?
>>
>> Really there shouldn't even *be* a distinction. If you need a / 
>> whatever of IPv6 and can write a convincing letter to that effect,  
>> you should be able to get at least that much unique IPv6 space.  
>> Whether it can be routed now or in the future is really between you  
>> and whichever transit provider you choose *should you even need  
>> external connectivity*.
>
> Unfortunately, distinctions of some kind are unavoidable as long as  
> the carry capacity of the routing system is finite, and jointly  
> produced by independent routing services providers. If IPv6  
> allocation policies cause, or simply facilitate/accelerate the  
> unsustainable growth of routing system requirements, then some other  
> mechanism will have to emerge to mitigate that risk. IPv4 allocation  
> policies have provided a flexible, transparent, limiting effect on  
> the growth rate for routing requirements by making aggregation not  
> only possible, but commonplace. In order to make aggregation  
> *possible*, there must be some kind of eligibility test for  
> justifying an institution's claim to a "top-level" role in the  
> routing system, i.e., as an aggregator or an independent. In order  
> to make aggregation *likely*, it's prudent to define those  
> eligibility criteria in a way that aligns the aspiring top-level  
> routing system participant's incentives with the continued sustained  
> growth of the routing table -- e.g., with "needs" related criteria  
> that demonstrate that the entity has invested real money in real  
> factors (hardware, network capacity, etc.) that can generate value  
> only as long as routing works, and that would be at risk of becoming  
> worthless if the routing system becomes unmanageable or fails  
> altogether.
>
> Since independents are by definition non-aggregatable, there needs  
> to be some other (probably arbitrary) criterion to limit their  
> absolute numbers, e.g., a steep up-front fee. And in order for the  
> whole arrangement to be sustainable over time, there must be a  
> clear, fair, and widely accepted mobility path for customers to  
> become providers, or "independents", and vice versa. To be  
> sustainable, everybody must have a clear "out" -- one that is clear  
> both to insiders and outsiders.
> You don't want to be aggregated, fine, go make some investments that  
> demonstrate that you've got chips in the same routing services game  
> that the rest of us are playing, and you can get address resources  
> of your own under community-defined policies. You just need to be  
> independent? Fine, then pay this sizable, community-defined fee that  
> demonstrates that your need is of roughly the same magnitude as the  
> burden that "just need to be independents" like you impose on those  
> who are playing by the rules of routing system sustainability. Don't  
> want to pay that fee either? Okay, here are some operators that can  
> provide you with aggregatable address resources bundled with routing  
> services...
>
> Even if the quantity of usable IP addresses were literally infinite,  
> it would prudent to think hard before dumping needs-related  
> allocation criteria. Because if/when this arrangement is abandoned  
> at the point of IP address distribution, something similar will just  
> have to be recreated at the level of routing service provision.  
> Unfortunately, at that level there won't be an "out" for anybody --  
> there's no credible way to tell an aspiring new entrant "fine, just  
> go build your own global-scale IP transit system."
>
> We like to remind ourselves that routing decisions are the absolute  
> sole prerogative of individual operators, but there are some  
> circumstances in which that would likely be more of a problem than a  
> point of honor. To date, the inter-domain routing system has been a  
> global scale "cooperative undertaking" -- but the only material  
> difference between a "cooperative undertaking" and a "collusive  
> cartel" is the non-discriminatory, non-adversarial, openness of that  
> system to new players. Absolute sovereignty over routing decisions  
> has no downside as long as somebody else (e.g., the address  
> allocator) guarantees market openness. But if/when that ceases to be  
> true, you're on the hook. You don't like "distinctions" applied at  
> the level of address allocation, fine -- what kind of distinctions  
> are you going to impose on aspiring customers who want you to  
> announce their PI prefixes? What kind of distinctions do you expect  
> will be imposed on your announcements by upstream providers? How are  
> you going to justify your own routing service rationing criteria to  
> critics, because there are always critics...?
>
> TV
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From scottleibrand at gmail.com  Mon Jun  1 14:41:29 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 1 Jun 2009 13:41:29 -0500
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <A32F6C3E-4936-460F-A705-D4EDB86F5EC3@gmail.com>

FWIW, the IANA only got 1/8 of the IPv6 space. The IETF left the rest  
to future generations.

/56 makes a lot of sense for residential allocations, but not for  
assignments from ARIN. I think /48+ for end users with ASNs, and /32+  
for LIRs (anyone who reassigns /48s) is still the right way to go. IMO  
we just need to simplify our definitions a bit.

-Scott

On May 30, 2009, at 4:48 PM, Milton L Mueller <mueller at syr.edu> wrote:

>
>> -----Original Message-----
>> Not sure about all the details, but I like the fact
>> that we'd be able to do away with the ISP/end-user distinction,  
>> make it
>> easy to get a /48, and provide a simple growth path for the most  
>> common
>> cases...
>>
>> -Scott
>
> Ditto.
>
> But, let me express (uncharacteristically) some concern about overly  
> liberal initial allocations. (e.g., why not a /56?) From the  
> standpoint of developing countries, there is some legitimate concern  
> about reproducing the land rush phase of IPv4 address allocations  
> (oops, there goes 1/3 of the space....)


From info at arin.net  Mon Jun  1 15:37:12 2009
From: info at arin.net (Member Services)
Date: Mon, 01 Jun 2009 15:37:12 -0400
Subject: [arin-ppml] =?windows-1252?q?NRPM_2009=2E3_=96_New_Policy_Impleme?=
 =?windows-1252?q?nted_=28Transfers=29?=
Message-ID: <4A242DE8.1010105@arin.net>

A new version of the ARIN Number Resource Policy Manual (NRPM) has been
published to the ARIN website. NRPM version 2009.3 contains the
implementation for the following policy:

  ? 2009-1: Transfer Policy

At their meeting on 6 February 2009, the ARIN Board of Trustees adopted
2008-6: Emergency Transfer Policy for IPv4 Addresses. The Board delayed
implementation of 2008-6 pending the outcome of 2009-1.  2009-1 came
from the Board?s use of the Special Policy Action section of the ARIN
Policy Development Process. 2009-1 was first posted to Public Policy
Mailing List for discussion on 24 March 2009. It was presented at ARIN
XXIII in San Antonio. Based on the feedback from the community on the
PPML and at the Public Policy Meeting, the ARIN Advisory Council (AC)
created a revised version of 2009-1 and recommended their version to the
Board for adoption.

On 28 May 2009 the Board, based on the recommendation of the AC and
noting that the Policy Development Process had been followed, adopted
2009-1: Transfer Policy as amended by the AC. The Board directed staff
to implement the policy on 1 June 2009. The implementation of 2008-6 has
been replaced by 2009-1.

2009-1 will be presented at the next Public Policy Meeting for
reconsideration as required by the Policy Development Process (PDP Part
Two, Section 7.1).

NRPM version 2009.3 is effective 1 June 2009 and supersedes the previous
version. See the Change Log for information regarding revisions to the
manual.

For more information about transfers, please see the guidelines at:
https://www.arin.net/resources/request/transfers.html

The NRPM is available at: https://www.arin.net/policy/nrpm.html

The Change Log is available at:
https://www.arin.net/policy/nrpm_changelog.html

Draft policies and proposals are available at:
https://www.arin.net/policy/proposals/

The PDP is available at: https://www.arin.net/policy/pdp.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)






From owen at delong.com  Mon Jun  1 15:58:49 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 1 Jun 2009 12:58:49 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<6eb799ab0905302219x5b88055m7e17855b935eec3c@mail.gmail.com>
Message-ID: <9C5554B5-89EB-46C8-AD09-19D353DB4639@delong.com>


On May 30, 2009, at 10:19 PM, James Hess wrote:

> Why allocate  /32s  from a pool reserved for  /32s?
> It would perhaps make more sense, as a matter of policy, that a
> special allocation strategy be utilized,  that the  /48s,  /32s, and
> /24s  are allocated from just one pool.
>
> And that they be allocated in a manner  that maximizes the duration
> during which the 2nd/3rd allocation request would be contiguous with
> the earlier allocation.
>
>
> e.g.  A  /48  may be allocated,  but the  entire  /24 could be left
> "internally" reserved for as long as possible.
>
> So if/when a  recipient of  a  /48 allocation requests their next
> allocation, it would be preferred that the /32  will be a block that
> begins with, and contains the same address space as their /48,  in
> addition to the added space.
>
> And if a third allocation is requested, the /24 also,  would be chosen
> so as to overlap with and contain the /32.
>
>
> This has the benefit that they don't need a second advertisement, and
> never have a need to return addresses.
>
>
>
> If/when ARIN's  allocations of V6 space ever becomes so dense  that
> reserving the entire  /24  in advance  for recipients of /48s is no
> longer feasible,    it  should be the oldest-assigned  /48   that are
> first "blocked" from expanding contiguously to a /24,  followed by the
> oldest  /32 allocations.
>
This strategy presumes that ARIN is dividing the entire IPv6 address  
space
and not receiving things in /24 chunks from IANA.

Owen



From owen at delong.com  Mon Jun  1 16:01:47 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 1 Jun 2009 13:01:47 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <4A221744.40902@rollernet.us>
References: <4A1FFBE5.20807@arin.net> <4A21A8D6.6080909@rollernet.us>
	<A4F74AA7-68CE-472F-952A-A37E3E326000@delong.com>
	<4A221744.40902@rollernet.us>
Message-ID: <2D95C111-75F3-4AFE-86B4-6313F0C1376E@delong.com>


On May 30, 2009, at 10:36 PM, Seth Mattinen wrote:

> Owen DeLong wrote:
>>>
>>>> 2) Remove article 4 of section 6.5.1.1, ?be an existing, known  
>>>> ISP in
>>>> the ARIN region or have a plan for making at least 200 end-site
>>>> assignments to other organizations within 5 years? in its entirety.
>>>> Rationale: It is acknowledged that these concepts have been put  
>>>> before
>>>> the community in the past. However, with the wisdom of actual
>>>> operational experience, the necessity of promoting IPv6 adoption
>>>> throughout our region, and emerging native v6 only network  
>>>> models, it
>>>> becomes obvious that these modifications to the NRPM are necessary.
>>>> Removing the 200 end site requirement enables smaller, but no less
>>>> important and viable, networks access to IPv6. Removing the  
>>>> ?known ISP?
>>>> requirement enfranchises new, native v6 businesses that can drive
>>>> innovation and expansion in the Internet industry, as well as other
>>>> industries. Removing the requirement for a single aggregate  
>>>> announcement
>>>> benefits the NRPM itself, as it has been decided by the community  
>>>> that
>>>> it should not contain routing advice.
>>>
>>> I OPPOSE this change because "smaller, but no less important and
>>> viable, networks" can already apply for and obtain a /48 under
>>> existing policies.
>>>
>> Not as ISPs assigning /48s to end users, they cannot.
>>
>
> Then they should be able to qualify for a /32 with some kind of  
> plan. If
> 200 is a problem, maybe we reduce the requirement to 100 or something,
> not strike it out completely.
>
Without the number of sites, the distinction is still present.  An LIR  
is
planning to delegate prefixes to other sites while an end user does not.
End users cannot SWIP portions of their space.  LIRs can.  The fee
structure is also radically different.  As such, I think that the  
distinction is
well preserved without some arbitrary requirement about their business
plan and number of customers.

Owen



From owen at delong.com  Mon Jun  1 15:55:46 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 1 Jun 2009 12:55:46 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <20090531035641.GC22975@garry-thinkpad.arpnetworks.com>
References: <4A1FFBE5.20807@arin.net>
	<24c86a5f0905290925u6c90ae2cq6c9486f45b2340e2@mail.gmail.com>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5481@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A202F60.8000408@matthew.at>
	<20090530204053.GN27636@garry-thinkpad.arpnetworks.com>
	<4A21F0AD.1010809@matthew.at>
	<20090531035641.GC22975@garry-thinkpad.arpnetworks.com>
Message-ID: <A547571E-6B0F-45AB-9339-81D08A46B81E@delong.com>


On May 30, 2009, at 8:56 PM, Garry Dolley wrote:

> On Sat, May 30, 2009 at 07:51:25PM -0700, Matthew Kaufman wrote:
>> Garry Dolley wrote:
>>>
>>> There are not enough /32 subnets to give away to everyone.  There
>>> are as many /32 subnets in IPv6 as there are in IPv4.  Just in IPv4,
>>> the /32 subnet just held 1 address.  We are running out of IPv4, so
>>> by the same token, if we liberally give away /32's in IPv6, we'll
>>> face the same exhaustion.
>>
>> That doesn't follow. We're talking about /48s and single /32s, not  
>> giving
>> out 256-65535 /32s to the typical early entrant entities as was  
>> done with
>> IPv4.
>
> What part doesn't follow?  There are 4G IPv4 addresses (/32) and
> there are 4G IPv6 subnets of /32 in size.
>
His point is that the comparison in question is largely irrelevant since
an IPv4 /32 addresses a single node and an IPv6 /32 addresses an
entire mid-size ISP.

Owen



From leo.vegoda at icann.org  Mon Jun  1 16:29:54 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Mon, 1 Jun 2009 13:29:54 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <9C5554B5-89EB-46C8-AD09-19D353DB4639@delong.com>
Message-ID: <C6498852.29DC2%leo.vegoda@icann.org>

On 01/06/2009 12:58, "Owen DeLong" <owen at delong.com> wrote:

[...]

>> If/when ARIN's  allocations of V6 space ever becomes so dense  that
>> reserving the entire  /24  in advance  for recipients of /48s is no
>> longer feasible,    it  should be the oldest-assigned  /48   that are
>> first "blocked" from expanding contiguously to a /24,  followed by the
>> oldest  /32 allocations.
>> 
> This strategy presumes that ARIN is dividing the entire IPv6 address
> space
> and not receiving things in /24 chunks from IANA.

ARIN won't get anything longer than a /12 from IANA until y'all change the
policy to allow that.

Regards,

Leo Vegoda



From leo.vegoda at icann.org  Mon Jun  1 16:44:19 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Mon, 1 Jun 2009 13:44:19 -0700
Subject: [arin-ppml] [arin-announce] Policy Proposal: Open Access To IPv6
In-Reply-To: <20090531005311.GJ6380@garry-thinkpad.arpnetworks.com>
Message-ID: <C6498BB3.29DC8%leo.vegoda@icann.org>

On 30/05/2009 5:53, "Garry Dolley" <gdolley at arpnetworks.com> wrote:

[...]

>> Does the provider/end user distinction make things easier or does it make
>> things harder? I suspect the latter.
> 
> I think it makes it easier.  Because it doesn't make a distinction
> based on "need" but rather on subsequent assignments

That's just another way of defining need, only you define it to only exist
when the assignment is to another legal entity. Or I have misunderstood you.

I would choose a different definition.

Regards,

Leo Vegoda



From mueller at syr.edu  Mon Jun  1 17:56:34 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 1 Jun 2009 17:56:34 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <A32F6C3E-4936-460F-A705-D4EDB86F5EC3@gmail.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
	<A32F6C3E-4936-460F-A705-D4EDB86F5EC3@gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7D2D@SUEX07-MBX-04.ad.syr.edu>

Ah I see. The typical residences will need 4,722,366,482,869,640,000,000 addresses, whereas your typical ASN is more likely to need 1,208,925,819,614,620,000,000,000 right off the bat.  

> -----Original Message-----
> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
> Sent: Monday, June 01, 2009 2:41 PM
> To: Milton L Mueller
> Cc: William Herrin; arin-ppml at arin.net
> Subject: Re: [arin-ppml] A modest proposal for IPv6 address allocations
> 
> FWIW, the IANA only got 1/8 of the IPv6 space. The IETF left the rest
> to future generations.
> 
> /56 makes a lot of sense for residential allocations, but not for
> assignments from ARIN. I think /48+ for end users with ASNs, and /32+
> for LIRs (anyone who reassigns /48s) is still the right way to go. IMO
> we just need to simplify our definitions a bit.
> 
> -Scott
> 
> On May 30, 2009, at 4:48 PM, Milton L Mueller <mueller at syr.edu> wrote:
> 
> >
> >> -----Original Message-----
> >> Not sure about all the details, but I like the fact
> >> that we'd be able to do away with the ISP/end-user distinction,
> >> make it
> >> easy to get a /48, and provide a simple growth path for the most
> >> common
> >> cases...
> >>
> >> -Scott
> >
> > Ditto.
> >
> > But, let me express (uncharacteristically) some concern about overly
> > liberal initial allocations. (e.g., why not a /56?) From the
> > standpoint of developing countries, there is some legitimate concern
> > about reproducing the land rush phase of IPv4 address allocations
> > (oops, there goes 1/3 of the space....)


From michael at rancid.berkeley.edu  Mon Jun  1 17:58:56 2009
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Mon, 01 Jun 2009 14:58:56 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7D2D@SUEX07-MBX-04.ad.syr.edu>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>	<4A2184EA.7020708@gmail.com>	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>	<A32F6C3E-4936-460F-A705-D4EDB86F5EC3@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7D2D@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A244F20.2000608@rancid.berkeley.edu>

On 06/01/09 14:56, Milton L Mueller wrote:
> Ah I see. The typical residences will need 4,722,366,482,869,640,000,000 addresses, whereas your typical ASN is more likely to need 1,208,925,819,614,620,000,000,000 right off the bat.  

Comparing actual address numbers in a protocol that uses EUI64 seems
like an improper application of IPv4-centric thinking to me.

michael


From michael at rancid.berkeley.edu  Mon Jun  1 18:07:18 2009
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Mon, 01 Jun 2009 15:07:18 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <2D95C111-75F3-4AFE-86B4-6313F0C1376E@delong.com>
References: <4A1FFBE5.20807@arin.net>
	<4A21A8D6.6080909@rollernet.us>	<A4F74AA7-68CE-472F-952A-A37E3E326000@delong.com>	<4A221744.40902@rollernet.us>
	<2D95C111-75F3-4AFE-86B4-6313F0C1376E@delong.com>
Message-ID: <4A245116.2030901@rancid.berkeley.edu>

On 06/01/09 13:01, Owen DeLong wrote:

> Without the number of sites, the distinction is still present.  An LIR is
> planning to delegate prefixes to other sites while an end user does not.
> End users cannot SWIP portions of their space.  LIRs can.  The fee
> structure is also radically different.  As such, I think that the
> distinction is
> well preserved without some arbitrary requirement about their business
> plan and number of customers.

+1

I support the spirit of the policy, and I am not terribly opposed to it
as written.  Specifically:

o The 200 end-user requirement is not particularly onerous, but it also
doesn't mean much.  The simple notion that you are planning to assign
prefixes to customers, broadly defined, should be enough.

o I understand the desire to remove routing policy from the NRPM, but I
would also not like it to lead to rampant disaggregation.  Is it
possible to have some sort of statement that ARIN makes that aggregation
is a good thing and that ARIN will allocate space in such a way as to
make aggregation possible?  Yeah, I am basically pulling this out of my
a--, but I think it's worth considering something short of unenforceable
policy that, at the same time, indicates that we don't want to go all
the way to swamp.

o I am not opposed to adding a BGP multihoming requirement.

As I have said before, I think it's a good idea to provide carrots (in
this case, in the form of more liberalized policies) to encourage uptake
of IPv6.  ARIN has already made multiple public statements, sent
certified mail to CEOs, and strengthened the requirements for getting
IPv4 (all of which I support).  This is another way of saying "we're
serious."  That provides ammo for those of us who are pushing for IPv6
adoption in our organizations and larger communities.  Some of us in
universities are aware of the slowness of uptake in IPv6 in our own
institutions and our peers, and in the larger Internet.  We are making
progress (some of us even use IPv6 to post to PPML!), but we still need
what help we can get.

michael


From kloch at kl.net  Mon Jun  1 19:00:08 2009
From: kloch at kl.net (Kevin Loch)
Date: Mon, 01 Jun 2009 19:00:08 -0400
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <0029FD77-572D-4098-A5C5-E5796948244C@delong.com>
References: <F7EB0A7C707E39409A73CD0353242551A7F1580EDB@PLSWM01C.ad.sprint.com>	<2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com>	<20090529212938.GA11989@ussenterprise.ufp.org>	<4A205A75.10107@matthew.at>	<A4285FC9-5428-4E3A-9046-B252A40BC4BF@pch.net>
	<0029FD77-572D-4098-A5C5-E5796948244C@delong.com>
Message-ID: <4A245D78.8050505@kl.net>

Owen DeLong wrote:
> Let's run some realistic numbers into this "unsustainable growth" we 
> keep hearing about...
> 
> There are, currently, about 32000 actively advertised ASNs
> Source: (http://www.potaroo.net/tools/asn16 Figure 11)
> 
> The IPv4 routing table is currently somewhere around 285,000 routes for 
> an average of
> nearly 9 routes per prefix.  The IPv6 reality is much more likely to be 
> closer to 3 routes
> per prefix (in fact, the vast majority of end-user ASNs should be very 
> close to 1 prefix
> and the vast majority of ISPs will be reasonably close to that for 
> ORIGINating routes,
> but, will advertise prefixes from other end-users, obviously).

There are several factors responsible for the prefixes per ASN being
larger than the "ideal" 1.0 in IPv4:

slow-start RIR policies
mergers and acquisitions
announcement of more specifics (for whatever reason)

The contribution of slow-start RIR policies should be effectively
eliminated by the generous initial assignment sizes in IPv6.  The other
two factors will likely exist in IPv6 in similar proportions.

I looked at the list of observed more specifics from this URL:
http://www.cidr-report.org/as2.0/msprefix-list.html

which contains 240,289 prefixes.  That number is much higher than I
expected but yields 7.6 prefixes per ASN.

Thus excluding slow-start and mergers and acquisitions we could
still see 7.6 IPv6 prefixes per ASN if IPv6 were deployed and used to
the extent that IPv4 is.

- Kevin


From michael.dillon at bt.com  Tue Jun  2 05:31:54 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 2 Jun 2009 10:31:54 +0100
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7D2D@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <28E139F46D45AF49A31950F88C497458016C2EC0@E03MVZ2-UKDY.domain1.systemhost.net>


> Ah I see. The typical residences will need 
> 4,722,366,482,869,640,000,000 addresses, whereas your typical 
> ASN is more likely to need 1,208,925,819,614,620,000,000,000 
> right off the bat.  

No, no, no, no, no!

The typical residence can get by with 8 bits of 
subnetting hierarchy, in other words, a /56. 
But the IPv6 architecture really favors giving all
sites, including residences, 16 bits of subnetting
hierarchy, i.e. a /48. A typical ISP will receive
32 bits of subnetting hierarchy, i.e. a /32.

You calculate the number of bits by starting from
the premise that a subnet is assigned a /64 prefix.

There is no point in calculating the number of 
addresses in a prefix since this number is meaningless
in IPv6. For instance, a subnet may have hosts whose
address is randomly assigned and the /64 prefix allows
for this with an extremely low risk of address collisions.

The IPv6 address budget concerns itself with how many
bits of address are used up, not with some theoretical
number of unique combinations can be made with those bits.

Notice that I did not refer to "need". That's because
this is not about need, but about how the IPv6 addressing
architecture was designed to work. It is fundamentally
different from IPv6 and requires a change from IPv4 
thinking, in order to fully understand it.

--Michael Dillon


From jmaimon at chl.com  Tue Jun  2 06:58:50 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Tue, 02 Jun 2009 06:58:50 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <28E139F46D45AF49A31950F88C497458016C2EC0@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458016C2EC0@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A2505EA.6000507@chl.com>



michael.dillon at bt.com wrote:
>> Ah I see. The typical residences will need 
>> 4,722,366,482,869,640,000,000 addresses, whereas your typical 
>> ASN is more likely to need 1,208,925,819,614,620,000,000,000 
>> right off the bat.  
> 
> No, no, no, no, no!

Yes.

> It is fundamentally
> different from IPv6 and requires a change from IPv4 
> thinking, in order to fully understand it.
> 

No, its just a larger binary number.

More bits, less magic.

Every time the paradigm police come around, it gets smaller.

The part that appears to get people uneasy is that the orders of 
magnitude larger than ipv4 ipv6 is supposed to be keeps shrinking. 
Nobody is concerned that we will face exhaustion in our lifetime. Its 
the grandkids lifetime where the possibility now seems feasible.

Are you advocating for a system of addressing that you can believe will 
be measured in decades or centuries?

2000/3 has 500m /32 (32x the number of ipv4 /24)

Real utilization hasnt started yet and 72779 are allocated.

%0.014

http://portalipv6.lacnic.net/en/ipv6/statistics

Geoff Huston has a couple of excellent articles regarding this, we seem 
to keep revolving around the same thought track.

http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf

His number was 60 years.

Joe


From michael.dillon at bt.com  Tue Jun  2 07:22:34 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 2 Jun 2009 12:22:34 +0100
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A2505EA.6000507@chl.com>
Message-ID: <28E139F46D45AF49A31950F88C4974580171F01E@E03MVZ2-UKDY.domain1.systemhost.net>

> No, its just a larger binary number.

It's not a number, it is a 128 bit string.

> The part that appears to get people uneasy is that the orders 
> of magnitude larger than ipv4 ipv6 is supposed to be keeps shrinking. 
> Nobody is concerned that we will face exhaustion in our 
> lifetime. Its the grandkids lifetime where the possibility 
> now seems feasible.

First of all, this is not true that people are unconcerned.
People *ARE* concerned which is why policy proposal 2005-8 
was introduced <https://www.arin.net/policy/proposals/2005_8.html>
and why it was eventually adopted. For more detail on the
concerns raised see
<http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-
wed-ipv6-roundtable-report.pdf>

That said, ARIN's job is not to create the most perfect
system which will solve network addressing for all time.
If our grandchildren need to reinvent network protocols
to entirely replace IPv6 as the foundation of their 
Internet, that is their business. It is not our job to
create a problem-free future for our grandchildren,
because, without tough problems to solve, they would 
cease to be human.

> Geoff Huston has a couple of excellent articles regarding 
> this, we seem to keep revolving around the same thought track.
> 
> http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50
> -plenary-wed-ipv6-roundtable-report.pdf

Indeed! 
See reference above, in particular the policy proposal
which was ADOPTED by ARIN to address the issue and give
us around a hundred years before there is the possibility
that we will run out. Of course by then there will be
numerous other technical and social changes in the world
and perhaps we will need less IPv6 addresses. We simply
don't know and it is a waste of time to take any more
action today.

By all means, keep the issue in mind, because maybe in 
10 years we will need to address it by changing the
possibility of /56 to residential customers into a 
requirement. But the people, 10 years from now, who
look at this issue will be far better equipped than
we are to make a decision. They will have the benefit
of 10 years of experience with IPv6 deployment.

--Michael Dillon




From bicknell at ufp.org  Tue Jun  2 11:22:07 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 2 Jun 2009 11:22:07 -0400
Subject: [arin-ppml] What is a subnet?
Message-ID: <20090602152206.GA33435@ussenterprise.ufp.org>


What is a subnet?

I've had this discussion with a number of folks because IPv6 makes
us look at subnets differently than we do in IPv4.  Many of the
folks who designed IPv6 have urged us to think in terms of the
number of subnets necessary, rather than the number of hosts.  This
relatively simple concept becomes quite complex when it interacts
with policy, or staff operational procedures.

Looking at the usual sources is only partially helpful, for instance
the Wikipedia page (http://en.wikipedia.org/wiki/Subnetwork) is
littered with references to IPv4, even though there are subnets in
multiple protocols.

What are some properties of a subnet?

  1 It is not necessary to go through a router to reach other hosts on
    the subnet.
  2 Limit the propagation of broadcast traffic.
  3 Can be routed independently.
  4 Can be referenced independently (e.g. for filtering).
  5 It is a method for diving a larger block of address space to serve
    the needs of multiple smaller locations.

Some of these overlap with the properties of a (V)LAN.  For instance
(V)LAN's can be used to limit broadcast traffic at layer 2, as
opposed to layer 3, which may then require a separate subnet as it
is a separate LAN.

For this discussion I'm concerned with the case where folks are
using /64 subnets.  Yes, I realize that isn't strictly required,
but it is the interesting case.  With 2^64 hosts per subnet it is
possible to put every computer in the world today in a single subnet.
There is effectively no limit to the number of hosts in a subnet.

This is partially good news.  I'm sure folks who've been short on
IP space before have dones something like putting the 10.2.3.128/28
subnet on the same virtual LAN as the 10.2.3.160/28 subnet because
10.2.3.0/25 and 10.2.3.144/28 were both already taken.  This is
sort of a degenerate case of property #5 that should not occur in
IPv6.

Some things stay the same.  Sometimes subnetting is done so a link
can be independently routed (property #3), for instance to take
advantage of redundant paths.  A site with two T1's to it needs a
subnet at the site so it can be routed down either link.

However, some questions actually get harder.  Subnets have long
been used to limit broadcast broadcast traffic (property #2).
There's a lot of lore to this, I've met folks who are quite comfortable
running 4096 hosts in a subnet, and other folks who believe more
than 256 is asking for trouble.  With IPv4, there are other pressures
like the need to divide a larger block in #5, or an outright lack
of address space to make gigantic subnets.  Not so in IPv6.  Want
to put 50,000 machines in a subnet, no problem if you have a /64.

How does this interact with policy?  Well, in IPv4 we rely on host
counts:

Hosts      Subnet Size
5          /29
43         /26
230        /24

But in IPv6, the table looks a lot different:

Hosts      Subnet Size
5          /64
43         /64
230        /64

Indeed, asking how many hosts someone has really makes no sense.
We'd like to make policy that says something like:

If you need 0-64 subnets you should get a /56.
If you need 65-32768 subnets you should get a /48
If you need ....

But that sort of policy will require ARIN staff to know how to
evaluate a "subnet".  Which of the properties above counts?  Which
of these "justifications" is acceptable?

    - I believe more than 256 hosts in a broadcast domain is a bad idea,
      and I'm a university with 40,000 hosts, so I justify 157 subnets.

    - Every department needs to be a subnet so I can filter them separately.

    - Each customer must have its own subnet so there is no broadcast
      traffic between customers.

    - Every floor of the building needs a subnet because that is how we
      have always done it and it's easy to manage.

    - I have three groups that need independent DNS management, so I
      need three subnets so I can delegate DNS to them?

Indeed, it's easy to see folks trying to game the system, taken to
its extreme: We put every host in its own VLAN for security reasons,
and have 40,000 hosts, so we need 40,000 subnets.

What's the work item here?  Well, if we're going to make policy
based on subnets as opposed to hosts then we need to have some
agreement as to what constitutes a subnet so staff can apply a
consistent interpretation.  Ideally in my mind a subnet is something
that would be defined in the NRPM in a way we can all agree with
so we can make policy that uses the term and everyone understands
it.

Rather than break apart my message bit by bit as we all often do in
replies, let me ask you to reply in a simpler way.  Answer one simple
question: What is an IPv6 subnet to you?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090602/7f12a40a/attachment.sig>

From michael.dillon at bt.com  Tue Jun  2 12:10:30 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 2 Jun 2009 17:10:30 +0100
Subject: [arin-ppml] What is a subnet?
In-Reply-To: <20090602152206.GA33435@ussenterprise.ufp.org>
Message-ID: <28E139F46D45AF49A31950F88C4974580171F702@E03MVZ2-UKDY.domain1.systemhost.net>

> Indeed, asking how many hosts someone has really makes no sense.
> We'd like to make policy that says something like:
> 
> If you need 0-64 subnets you should get a /56.
> If you need 65-32768 subnets you should get a /48 If you need ....

By doing that, you lose the property of one-size-fits-all 
which facilitates standardisation of network architecture
and that standardisation is a real benefit to end user
customers. We already have allowed the assignment of 
/56 to residential customers, which doesn't really lose
this property assuming that everyone understands that
any application or equipment targeting residential 
customers needs to fit within a /56. It is very, very 
unusual for a residential customer to change to a 
business, and vice versa.

> But that sort of policy will require ARIN staff to know how 
> to evaluate a "subnet".  Which of the properties above 
> counts?  Which of these "justifications" is acceptable?
> 
>     - I believe more than 256 hosts in a broadcast domain is 
> a bad idea,
>       and I'm a university with 40,000 hosts, so I justify 
> 157 subnets.

If you actually implemented it that way and can show the
hardware receipts then it is justified. But people
don't design networks like that. First of all, there are
other reasons why one might assign a /64 per floor, aggregated
into a /56 per building with perhaps another level of
aggregation separating admin and educational facilities.
The dorms are a whole separate story because you can just
assign a /56 per room, and not worry about any other levels
of hierarchy.

>     - Every department needs to be a subnet so I can filter 
> them separately.

Departments would not be handled at the /64 level but at 
a higher level of aggregation, assuming that your addressing
hierarchy tracks the university's org structure.

>     - Every floor of the building needs a subnet because that 
> is how we
>       have always done it and it's easy to manage.

And you can go on adding devices ad infinitum without ever running
out of that /64. You'll need to allocate dynamic addresses to all
those people wearing computers who wander on and off the floor.

> Indeed, it's easy to see folks trying to game the system, 
> taken to its extreme: We put every host in its own VLAN for 
> security reasons, and have 40,000 hosts, so we need 40,000 subnets.

This is ridiculous technical design. It is hard to see a motive
for gaming the system. The means for gaming it involve unnatural
technical designs. Without means and motive, what does it matter
that there is an opportunity? It's like all those shop windows
in the street. Every pedestrian has an opportunity to smash
one of those windows, but they rarely do so. That's because bricks
and stones are in short supply, and there's generally no good
reason to smash a window.

> What's the work item here?

Nothing.

> Answer one simple
> question: What is an IPv6 subnet to you?

It's not just a /64 but also any number of /64s that are aggregated
under one prefix, whether /62 or /59 or whatever. In essence, it is
a section of the network that I would like to refer to with one
address, namely the prefix/mask. It could be one or more LANs, one
or more VLANs, or just some geographic area (building, campus).

--Michael Dillon


From RMoore at fnsky.com  Tue Jun  2 14:32:01 2009
From: RMoore at fnsky.com (Rodgers Moore)
Date: Tue, 2 Jun 2009 14:32:01 -0400
Subject: [arin-ppml] What is a subnet?
In-Reply-To: <28E139F46D45AF49A31950F88C4974580171F702@E03MVZ2-UKDY.domain1.systemhost.net>
References: <20090602152206.GA33435@ussenterprise.ufp.org>
	<28E139F46D45AF49A31950F88C4974580171F702@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <8EA9DEDC7319124EB668DCFCB99C05460EF72ED0@fnskyexch01.fnsky.com>

As to the ridiculous technical design... You should have been in my meeting on Monday with a certain government propeller head...exactly what they want to do.  Push layer 3 all the way to the edge, regardless of the protocol.

Rodgers Moore

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
Sent: Tuesday, June 02, 2009 12:11 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] What is a subnet?

> Indeed, asking how many hosts someone has really makes no sense.
> We'd like to make policy that says something like:
>
> If you need 0-64 subnets you should get a /56.
> If you need 65-32768 subnets you should get a /48 If you need ....

By doing that, you lose the property of one-size-fits-all
which facilitates standardisation of network architecture
and that standardisation is a real benefit to end user
customers. We already have allowed the assignment of
/56 to residential customers, which doesn't really lose
this property assuming that everyone understands that
any application or equipment targeting residential
customers needs to fit within a /56. It is very, very
unusual for a residential customer to change to a
business, and vice versa.

> But that sort of policy will require ARIN staff to know how
> to evaluate a "subnet".  Which of the properties above
> counts?  Which of these "justifications" is acceptable?
>
>     - I believe more than 256 hosts in a broadcast domain is
> a bad idea,
>       and I'm a university with 40,000 hosts, so I justify
> 157 subnets.

If you actually implemented it that way and can show the
hardware receipts then it is justified. But people
don't design networks like that. First of all, there are
other reasons why one might assign a /64 per floor, aggregated
into a /56 per building with perhaps another level of
aggregation separating admin and educational facilities.
The dorms are a whole separate story because you can just
assign a /56 per room, and not worry about any other levels
of hierarchy.

>     - Every department needs to be a subnet so I can filter
> them separately.

Departments would not be handled at the /64 level but at
a higher level of aggregation, assuming that your addressing
hierarchy tracks the university's org structure.

>     - Every floor of the building needs a subnet because that
> is how we
>       have always done it and it's easy to manage.

And you can go on adding devices ad infinitum without ever running
out of that /64. You'll need to allocate dynamic addresses to all
those people wearing computers who wander on and off the floor.

> Indeed, it's easy to see folks trying to game the system,
> taken to its extreme: We put every host in its own VLAN for
> security reasons, and have 40,000 hosts, so we need 40,000 subnets.

This is ridiculous technical design. It is hard to see a motive
for gaming the system. The means for gaming it involve unnatural
technical designs. Without means and motive, what does it matter
that there is an opportunity? It's like all those shop windows
in the street. Every pedestrian has an opportunity to smash
one of those windows, but they rarely do so. That's because bricks
and stones are in short supply, and there's generally no good
reason to smash a window.

> What's the work item here?

Nothing.

> Answer one simple
> question: What is an IPv6 subnet to you?

It's not just a /64 but also any number of /64s that are aggregated
under one prefix, whether /62 or /59 or whatever. In essence, it is
a section of the network that I would like to refer to with one
address, namely the prefix/mask. It could be one or more LANs, one
or more VLANs, or just some geographic area (building, campus).

--Michael Dillon
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From gdolley at arpnetworks.com  Tue Jun  2 16:58:05 2009
From: gdolley at arpnetworks.com (Garry Dolley)
Date: Tue, 2 Jun 2009 13:58:05 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A2505EA.6000507@chl.com>
References: <28E139F46D45AF49A31950F88C497458016C2EC0@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A2505EA.6000507@chl.com>
Message-ID: <20090602205805.GB9688@garry-thinkpad.arpnetworks.com>

On Tue, Jun 02, 2009 at 06:58:50AM -0400, Joe Maimon wrote:
>
>
> michael.dillon at bt.com wrote:
>>> Ah I see. The typical residences will need 4,722,366,482,869,640,000,000 
>>> addresses, whereas your typical ASN is more likely to need 
>>> 1,208,925,819,614,620,000,000,000 right off the bat.  
>> No, no, no, no, no!
>
> Yes.
>
>> It is fundamentally
>> different from IPv6 and requires a change from IPv4 thinking, in order to 
>> fully understand it.
>
> No, its just a larger binary number.
>
> More bits, less magic.

No, if you think IPv6 is just IPv4 with more bits, you need to read:

* RFC 4291, "IP Version 6 Addressing Architecture"
  http://tools.ietf.org/html/rfc4291

And it will help to know what the thoughts are on subnetting IPv6:

* 3177, "IAB/IESG Recommendations on IPv6 Address Allocations to
  Sites"
  http://tools.ietf.org/html/rfc3177

* 5375, "IPv6 Unicast Address Assignment Considerations"
  http://tools.ietf.org/html/rfc5375

-- 
Garry Dolley
ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181
Data center, VPS, and IP Transit solutions
Member Los Angeles County REACT, Unit 336 | WQGK336
Blog http://scie.nti.st


From jmaimon at chl.com  Tue Jun  2 17:32:39 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Tue, 02 Jun 2009 17:32:39 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <20090602205805.GB9688@garry-thinkpad.arpnetworks.com>
References: <28E139F46D45AF49A31950F88C497458016C2EC0@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A2505EA.6000507@chl.com>
	<20090602205805.GB9688@garry-thinkpad.arpnetworks.com>
Message-ID: <4A259A77.8060904@chl.com>



Garry Dolley wrote:
> On Tue, Jun 02, 2009 at 06:58:50AM -0400, Joe Maimon wrote:
>   
>> michael.dillon at bt.com wrote:
>>     
>>>> Ah I see. The typical residences will need 4,722,366,482,869,640,000,000 
>>>> addresses, whereas your typical ASN is more likely to need 
>>>> 1,208,925,819,614,620,000,000,000 right off the bat.  
>>>>         
>>> No, no, no, no, no!
>>>       
>> Yes.
>>
>>     
>>> It is fundamentally
>>> different from IPv6 and requires a change from IPv4 thinking, in order to 
>>> fully understand it.
>>>       
>> No, its just a larger binary number.
>>
>> More bits, less magic.
>>     
>
> No, if you think IPv6 is just IPv4 with more bits, you need to read:
>   
I think we can all agree on the fact that there is only one fundamental 
difference between 128 bit numberspace and 32bit.

96bits.

Just because you choose to do things with those 96bits that werent 
possible with ipv4 doesnt make ipv6 any more special.







From joelja at bogus.com  Tue Jun  2 18:34:51 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 02 Jun 2009 15:34:51 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com><4A2184EA.7020708@gmail.com>	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
Message-ID: <4A25A90B.5020804@bogus.com>



Davis, Terry L wrote:
> Milton
> 
> Agreed a /56 might be appropriate.
> 
> Earlier Owen appropriately corrected me for comparing a /48 v6
> allocation to a class B v4 allocation but he actually enforced the
> point I was going to make.  Even a /48 allocation for small business
> or individual use is a bit ridiculous given conventional IP network
> architectures.  But one of our problems is that since we don't have
> any truly large scale deployments (something at least into the 100K
> nodes size), we don't know what a real IPv6 network may consume.

Because you have not experienced one, does not mean that they do not exist.

With something like 10 years operational experience behind us we do not
have to treat a /48 assignment per end site as though it were
"ridiculous", it is not. you can to assign residential customers
something longer, fine, be aware they'll need more than a /64. It's
pretty easy (just as it is in v4) to use 16 bits at a large site for the
purposes of hierachical assignment, supernetting and so on.

The fact of the matter is we've lived with scarcity so long it's
considered normal. Scarcity results expensive and undesirable behavior.
We don't have the play that game (with v6) anymore and we shouldn't make
our customers do it either.

> Take care Terry
> 
>> -----Original Message----- From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller 
>> Sent: Saturday, May 30, 2009 2:49 PM To: Scott Leibrand; William
>> Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] A modest
>> proposal for IPv6 address allocations
>> 
>> 
>>> -----Original Message----- Not sure about all the details, but I
>>> like the fact that we'd be able to do away with the ISP/end-user
>>> distinction, make it easy to get a /48, and provide a simple
>>> growth path for the most common cases...
>>> 
>>> -Scott
>> Ditto.
>> 
>> But, let me express (uncharacteristically) some concern about
>> overly liberal initial allocations. (e.g., why not a /56?) From the
>> standpoint of developing countries, there is some legitimate
>> concern about reproducing the land rush phase of IPv4 address
>> allocations (oops, there goes 1/3 of the space....) 
>> _______________________________________________ PPML You are
>> receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or
>> manage your mailing list subscription at: 
>> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
>> info at arin.net if you experience any issues.
> _______________________________________________ PPML You are
> receiving this message because you are subscribed to the ARIN Public
> Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your
> mailing list subscription at: 
> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
> info at arin.net if you experience any issues.
> 


From bill at herrin.us  Wed Jun  3 13:56:36 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 3 Jun 2009 13:56:36 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
Message-ID: <3c3e3fca0906031056v1284040ao1d47765754dcf16a@mail.gmail.com>

Hi Folks,

Is there any interest in seeing this as a formal proposal after adding
in the various adjustments some of you have suggested?

Regards,
Bill Herrin


On Sat, May 30, 2009 at 3:05 PM, William Herrin<bill at herrin.us> wrote:
> So here's a crazy plan:
>
> A. The first IPv6 allocation from ARIN is always a /48. To justify it,
> you need to be multihomed. There are no other qualifications. The /48
> will be allocated from a pool from which only /48's are allocated.
>
> B. The second IPv6 allocation from ARIN is always a /32. To justify it
> you need to demonstrate that you've efficiently used the /48 for some
> reasonable definition of efficient, that you've implemented SWIP or
> RWHOIS for your downstream assignments and that you will run out of
> space in the /48 within one year. The /32 will be allocated from a
> pool reserved for allocating /32's.
>
> C. The third IPv6 allocation from ARIN is always a /24. To justify it
> you need to demonstrate that you've efficiently used the /32, that you
> will run out of space in the /32 within five years, and you have to
> first return the original /48 you were assigned. The /24 will be
> allocated from a pool reserved for allocating /24's.
>
> D. There is no fourth IPv6 allocation at this time. It is not
> presently possible to consume an entire /24 without atrocious waste.
>
> What are the consequences of this plan?
>
> 1. Efficient allocation of IP addresses. Orgs get what they need when
> they need it and not before without a great deal of guesswork about
> actual need.
>
> 2. Efficient utilization of BGP routing slots. No single multihomed
> org will ever announce more than 2 necessary routes.
>
> 3. Traffic engineering routes are trivially filterable since any route
> longer than the published allocation size can be presumed to be
> traffic engineering, not a downstream multihomed customer, thus you
> can filter distant small routes with confidence and ease.
>
> 4. No need to define the difference between ISP and not ISP. Everybody
> plays by the same rules.
>
> 5. No complicated analysis for the first allocation. You're either
> multihomed or you're not. If you're multihomed, you qualify.
>
> 6. For those who can live within the /48 there are distinct
> advantages: no swip or rwhois reporting and the generic end-user
> annual fee instead of the ISP annual fee. Once you're up to a /32, you
> pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize
> the /32 requests too closely either.




-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From michael.dillon at bt.com  Wed Jun  3 15:01:50 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 3 Jun 2009 20:01:50 +0100
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <3c3e3fca0906031056v1284040ao1d47765754dcf16a@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C4974580178068F@E03MVZ2-UKDY.domain1.systemhost.net>


No.

--Michael Dillon

> Is there any interest in seeing this as a formal proposal 
> after adding in the various adjustments some of you have suggested?
> 
> Regards,
> Bill Herrin
> 
> 
> On Sat, May 30, 2009 at 3:05 PM, William Herrin<bill at herrin.us> wrote:
> > So here's a crazy plan:
> >
> > A. The first IPv6 allocation from ARIN is always a /48. To 
> justify it, 
> > you need to be multihomed. There are no other 
> qualifications. The /48 
> > will be allocated from a pool from which only /48's are allocated.
> >
> > B. The second IPv6 allocation from ARIN is always a /32. To 
> justify it 
> > you need to demonstrate that you've efficiently used the 
> /48 for some 
> > reasonable definition of efficient, that you've implemented SWIP or 
> > RWHOIS for your downstream assignments and that you will run out of 
> > space in the /48 within one year. The /32 will be allocated from a 
> > pool reserved for allocating /32's.
> >
> > C. The third IPv6 allocation from ARIN is always a /24. To 
> justify it 
> > you need to demonstrate that you've efficiently used the 
> /32, that you 
> > will run out of space in the /32 within five years, and you have to 
> > first return the original /48 you were assigned. The /24 will be 
> > allocated from a pool reserved for allocating /24's.
> >
> > D. There is no fourth IPv6 allocation at this time. It is not 
> > presently possible to consume an entire /24 without atrocious waste.
> >
> > What are the consequences of this plan?
> >
> > 1. Efficient allocation of IP addresses. Orgs get what they 
> need when 
> > they need it and not before without a great deal of guesswork about 
> > actual need.
> >
> > 2. Efficient utilization of BGP routing slots. No single multihomed 
> > org will ever announce more than 2 necessary routes.
> >
> > 3. Traffic engineering routes are trivially filterable 
> since any route 
> > longer than the published allocation size can be presumed to be 
> > traffic engineering, not a downstream multihomed customer, thus you 
> > can filter distant small routes with confidence and ease.
> >
> > 4. No need to define the difference between ISP and not 
> ISP. Everybody 
> > plays by the same rules.
> >
> > 5. No complicated analysis for the first allocation. You're either 
> > multihomed or you're not. If you're multihomed, you qualify.
> >
> > 6. For those who can live within the /48 there are distinct
> > advantages: no swip or rwhois reporting and the generic end-user 
> > annual fee instead of the ISP annual fee. Once you're up to 
> a /32, you 
> > pay the ISP annual fee. As a result, ARIN doesn't have to 
> scrutinize 
> > the /32 requests too closely either.
> 
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: 
> <http://bill.herrin.us/> Falls Church, VA 22042-3004 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to 
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From owen at delong.com  Wed Jun  3 16:17:49 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Jun 2009 13:17:49 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <29A54911243620478FF59F00EBB12F47017E3312@ex01.drtel.lan>
References: <4A1FFBE5.20807@arin.net><20090529174253.GB94380@ussenterprise.ufp.org><20090529185841.GA87992@gweep.net><20090529201502.GA6398@ussenterprise.ufp.org>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5493@XCH-NW-CCR1V.nw.nos.boeing.com>
	<29A54911243620478FF59F00EBB12F47017E3312@ex01.drtel.lan>
Message-ID: <D332046C-1BEA-4B25-9A62-DEB8E89AF82B@delong.com>


On Jun 1, 2009, at 6:23 AM, Brian Johnson wrote:

> Terry,
>
> Two points on the telephone system comparison.
>
> - Circuit switched networks are entirely different than packet based
> networks when it comes to routing.
> - With the exception of LNP, the telephone numbering scheme is  
> entirely
> hierarchical limiting the number of routes needed.
>
A more accurate statement would be that prior to cell-phones and LNP
across disparate networks, the telephone numbering scheme WAS entirely
hierarchical, limiting the number of routes needed.

Today, the telephone number you dial is actually more akin to a domain
name which is looked up in the SS7 database to determine an actual
topological locator to which the call is routed.  These topological  
locators
remain 100% hierarchical limiting the routing required, and, this model
could actually serve as a good model for an ID/Locator split type of
internet routing.

> On a side note, I'm sure that nobody wants the Internet to start to
> resemble the telephone network. That would be a bad model. (I can hear
> the regulators salivating at the idea.) Not that this isn't already
> starting to happen (sigh). :-|
>
On one hand, I agree.  The over-regulated system of settlements and
forced exchange routing would be bad for the internet.  However, the
technical solution applied to make LNP possible is one where I think
the internet could at least learn a little.

Owen

> - Brian
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
>> Behalf Of Davis, Terry L
>> Sent: Monday, June 01, 2009 8:12 AM
>> To: 'Leo Bicknell'; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
>>
>> Leo
>>
>> While I support this, I acknowledge that BGP can't support it.  A
>> couple thoughts:
>> - To your point on not being able to support every residential user
>> with a PI, maybe we need to look closer at the phone call routing
>> system as they seem to be able to handle it.
>>
>> - My home is dual-homed already.
>>
>> Take care
>> Terry
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>> On
>>> Behalf Of Leo Bicknell
>>> Sent: Friday, May 29, 2009 1:15 PM
>>> To: arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] Policy Proposal: Open Access To IPv6
>>>
>>> In a message written on Fri, May 29, 2009 at 02:58:41PM -0400, Joe
>> Provo
>>> wrote:
>>>> I appreciate the intent, but what's the point of yet another
>>>> unenforcable clause?  Enterprises with multiple private BGP
>>>> relationships would qualifiy under this and be invisible.
>>>
>>> ARIN actually has a long history of "enforcing" this, the current
>>> IPv4 criteria has a provision for multi-homed networks to get a
>>> allocation when single homed networks do not qualify.  I will leave
>>> staff to comment on how they enforce the criteria.
>>>
>>> With IPv6 we will run out of routing slots before we run out of
>>> numbers.  Using the sign at the Chinese Buffet as an example:
>>>
>>>  Take all you want, eat all you take.
>>>
>>> Like it or not, the network can't take every residential user having
>>> their own PI block and routing it.  We don't have routers that can
>>> support 500 million routes.  We can make a big mess by handing
>>> things out willy nilly, but just like the dark days of the Internet
>>> passed the operators will fix it with draconian filtering policies
>>> that will do no one any good.  Making a mess the operators have to
>>> fix will create no good will, nor internet stability.
>>>
>>> To that end, I can't support the proposal as written.  As one
>>> commenter asked, "what if my kids want an IPv6 network to play with
>>> in their garage?"  Well, we should find some way to accomodate that
>>> which doesn't require service providers worldwide to spend tens of
>>> thousands of dollars upgrading routers to hold the routes.
>>>
>>> I realize ARIN does not dictate routing behavior.  However, I can
>>> tell you how this ends if we get it wrong.  If the table grows too
>>> fast operators will make their own decisions about "who is worthy".
>>> I suspect those decisions will be made along the lines of who has
>>> money to pay to route the prefixes.  If you're worried about your
>>> kids getting free IP's to play with the you should really worry
>>> about the $1,000 per month per prefix charge that will come to route
>>> it to limit table sale.
>>>
>>> I offer up multi-homing as a bar that keeps the number of routes
>>> manageable.  I'm completely open to other proposals.  I think the
> 200
>>> site requirement as it stands now just doesn't work, there are lots
>> of
>>> large ISP's, who can use a lot of addresses with far fewer than 200
>>> sites.  But to simply remove it and leave nothing doesn't do anyone
>> any
>>> favors in the long term.
>>>
>>> --
>>>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>>>        PGP keys at http://www.ufp.org/~bicknell/
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Wed Jun  3 16:35:40 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Jun 2009 13:35:40 -0700
Subject: [arin-ppml] Policy Proposal: Internet Assigned Numbers
	Authority (IANA) Policy for Allocation of ASN Blocks (ASNs)
	to Regional Internet Registries
In-Reply-To: <20090601155240.GJ16587@shell02.cell.sv2.tellme.com>
References: <4A1FFB11.9080101@arin.net>
	<12535BF9-2693-4480-88E1-ED7139A88B58@delong.com>
	<4A203F1F.8090002@gmail.com>
	<20090601155240.GJ16587@shell02.cell.sv2.tellme.com>
Message-ID: <1ABE56E0-28DB-474B-8ED3-517D57349987@delong.com>

I don't believe this has been submitted to any of the other RIRs
as yet, so, I think that the change I proposed would not slow it down.
In fact, I think it might actually help it get through faster.

Owen

On Jun 1, 2009, at 8:52 AM, David Williamson wrote:

> I support the policy as written.  I think Owen has a great idea, but
> the timeline is a problem for changes.  It would be possible to  
> start a
> new policy to correct this one with Owen's suggested changes, but  
> let's
> fast track this one *as is*.
>
> I'd even support this as written if it was declared to be a Board
> response to an emergency.  Unless there are compelling arguments in
> dissent, this should simply move forward.
>
> -David
>
> On Fri, May 29, 2009 at 03:01:35PM -0500, Scott Leibrand wrote:
>> One thing to keep in mind here is that, because this is a Global  
>> Policy,
>> and because of the extremely tight timeframe, we need to agree on the
>> text of the proposal right away, and make sure the same text gets put
>> forward in each region.  Even if everyone approves it their first  
>> time
>> around, and LACNIC approves it through their fast-track process  
>> (since
>> it'll be exactly a year until their next meeting), we're still  
>> looking
>> at sometime in 2010 before the policy can be ratified by the ASO-AC  
>> and
>> ICANN.  That will mean we will have several months (at least) of RIRs
>> being unable to get more 16-bit ASNs from the IANA before this policy
>> could go through and make it possible again.  I've heard some very  
>> good
>> arguments in the last week that the simpler we make the change, the  
>> less
>> likely we are to run into problems that cause delays in getting this
>> approved in time for it to be useful...
>>
>> How important do you think it is to preserve the 16bit/32bit ASN
>> distinction past 1 Jan 2011?  Is it worth the increased risk of  
>> delay in
>> passing such a revised global policy?
>>
>> (As you probably figured out from my comments above, I personally
>> support this policy.)
>>
>> -Scott
>>
>> Owen DeLong wrote:
>>> While I do not support changing the RIR policy on the issuance of  
>>> ASNs,
>>> I do support this policy proposal.  I think that modifying the  
>>> IANA->RIR
>>> distribution rules to accommodate the needs of RIRs to better  
>>> serve their
>>> constituents makes sense. Further, having 16-bit ASNs trapped in the
>>> IANA free pool because 32-bit ASNs are not being accepted by  
>>> recipients
>>> is absurd and poor stewardship. We should go ahead and issue 16-bit
>>> ASNs until they run out.
>>>
>>> I would suggest that this proposal, rather than removing the  
>>> distinction
>>> in 2010 should be modified to extend the IANA->RIR duality until  
>>> such
>>> time as there are no more 16-bit ASN blocks in the IANA pool.
>>>
>>> Owen
>>>
>>> On May 29, 2009, at 8:11 AM, Member Services wrote:
>>>
>>>> ARIN received the following policy proposal and is posting it to  
>>>> the
>>>> Public Policy Mailing List (PPML) in accordance with Policy  
>>>> Development
>>>> Process.
>>>>
>>>> This proposal is in the first stage of the Policy Development  
>>>> Process.
>>>> ARIN staff will perform the Clarity and Understanding step. Staff  
>>>> does
>>>> not evaluate the proposal at this time, their goal is to make  
>>>> sure that
>>>> they understand the proposal and believe the community will as  
>>>> well.
>>>> Staff will report their results to the ARIN Advisory Council (AC)  
>>>> within
>>>> 10 days.
>>>>
>>>> The AC will review the proposal at their next regularly scheduled
>>>> meeting (if the period before the next regularly scheduled  
>>>> meeting is
>>>> less than 10 days, then the period may be extended to the  
>>>> subsequent
>>>> regularly scheduled meeting). The AC will decide how to utilize the
>>>> proposal and announce the decision to the PPML.
>>>>
>>>> In the meantime, the AC invites everyone to comment on the  
>>>> proposal on
>>>> the PPML, particularly their support or non-support and the  
>>>> reasoning
>>>> behind their opinion. Such participation contributes to a thorough
>>>> vetting and provides important guidance to the AC in their
>>>> deliberations.
>>>>
>>>> The ARIN Policy Development Process can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>>
>>>> Mailing list subscription information can be found
>>>> at:https://www.arin.net/mailing_lists/
>>>>
>>>> Regards,
>>>>
>>>> Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>>
>>>> ## * ##
>>>>
>>>>
>>>> Policy Proposal: Internet Assigned Numbers Authority (IANA)  
>>>> Policy for
>>>> Allocation of ASN Blocks (ASNs) to Regional Internet Registries
>>>>
>>>> Proposal Originator: Stacy Hughes and Andrew de la Haye
>>>>
>>>> Proposal Version: 1.0
>>>>
>>>> Date: 29 May 2009
>>>>
>>>> Proposal type: modify
>>>>
>>>> Policy term: permanent
>>>>
>>>> Policy statement:
>>>>
>>>> Modification of NRPM section 10.3 extending the deadline for an
>>>> undifferentiated ASN pool by 1 year to read:
>>>>
>>>> 1. Allocation Principles
>>>>
>>>> IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this  
>>>> document the
>>>> term "ASN block" refers to a set of 1024 ASNs. Until 31 December  
>>>> 2010,
>>>> allocations of 16-bit and 32-bit only ASN blocks will be made  
>>>> separately
>>>> and independent of each other [1].
>>>>
>>>> This means until 31 December 2010, RIRs can receive two separate  
>>>> ASN
>>>> blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the  
>>>> IANA
>>>> under this policy. After this date, IANA and the RIRs will cease  
>>>> to make
>>>> any distinction between 16-bit and 32-bit only ASNs, and will  
>>>> operate
>>>> ASN allocations from an undifferentiated 32-bit ASN allocation  
>>>> pool.
>>>>
>>>> Rationale:
>>>>
>>>> a. Arguments supporting the proposal
>>>>
>>>> Due to operational issues external to the IANA/RIR policy process,
>>>> 32-bit only ASNs are not being issued by the RIRs at the  
>>>> anticipated
>>>> rate. As it stands, RIRs will likely not be able to justify a new  
>>>> block
>>>> of ASNs from the IANA after 31 December 2009 due to a glut of  
>>>> free 32
>>>> bit only ASNs in the RIR?s pool. This leaves available, essential  
>>>> 16-bit
>>>> ASNs stranded in the IANA free pool. This proposal seeks to  
>>>> remedy the
>>>> potential problem by extending the deadline for differentiation  
>>>> by one
>>>> year.
>>>>
>>>> With this proposal the policy will be aligned with the actual  
>>>> reality in
>>>> regards to 32-bit ASN deployment and usage.
>>>>
>>>> The subject was raised during RIPE 58 and a presentation was made:
>>>> http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf
>>>>
>>>>
>>>> The feedback in this session suggested that a global policy  
>>>> proposal
>>>> should be developed and should be discussed.
>>>>
>>>> b. Arguments opposing the proposal
>>>>
>>>> Some may think that extending the previously set timeline can be
>>>> perceived as some discouragement for the deployment of 32-bit  
>>>> ASNs. One
>>>> counter argument to this is that RIRs and Internet community have  
>>>> some
>>>> other mechanisms and activities to raise awareness for 32-bit ASN  
>>>> pool
>>>> (via public presentations and trainings). These activities will  
>>>> continue
>>>> while 16-bit ASN blocks are still allocated to RIRs by the IANA  
>>>> as they
>>>> are available and they are needed.
>>>>
>>>> Timetable for implementation: Immediately upon ratification by  
>>>> ICANN
>>>> Board
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.



From terry.l.davis at boeing.com  Wed Jun  3 16:45:18 2009
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Wed, 3 Jun 2009 13:45:18 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <D332046C-1BEA-4B25-9A62-DEB8E89AF82B@delong.com>
References: <4A1FFBE5.20807@arin.net><20090529174253.GB94380@ussenterprise.u
	fp.org><20090529185841.GA87992@gweep.net><20090529201502.GA6398@ussenterpri
	se.ufp.org>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5493@XCH-NW-CCR1V.nw.nos.boeing.com>
	<29A54911243620478FF59F00EBB12F47017E3312@ex01.drtel.lan>
	<D332046C-1BEA-4B25-9A62-DEB8E89AF82B@delong.com>
Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F54DB@XCH-NW-CCR1V.nw.nos.boeing.com>

Owen

Thanks, you made my point much clearer than I did.

Take care
Terry

===========================================================
> A more accurate statement would be that prior to cell-phones and LNP
> across disparate networks, the telephone numbering scheme WAS entirely
> hierarchical, limiting the number of routes needed.
> 
> Today, the telephone number you dial is actually more akin to a domain
> name which is looked up in the SS7 database to determine an actual
> topological locator to which the call is routed.  These topological
> locators
> remain 100% hierarchical limiting the routing required, and, this model
> could actually serve as a good model for an ID/Locator split type of
> internet routing.
> 
> > On a side note, I'm sure that nobody wants the Internet to start to
> > resemble the telephone network. That would be a bad model. (I can hear
> > the regulators salivating at the idea.) Not that this isn't already
> > starting to happen (sigh). :-|
> >
> On one hand, I agree.  The over-regulated system of settlements and
> forced exchange routing would be bad for the internet.  However, the
> technical solution applied to make LNP possible is one where I think
> the internet could at least learn a little.



From owen at delong.com  Wed Jun  3 16:46:04 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Jun 2009 13:46:04 -0700
Subject: [arin-ppml]
 =?windows-1252?q?Call_for_Community_Consultation_=96_?=
 =?windows-1252?q?ARIN=92s_DNSSEC_Deployment_Plan?=
In-Reply-To: <4A24158A.4070305@arin.net>
References: <4A24158A.4070305@arin.net>
Message-ID: <1C40CB80-0D1A-4249-AFB6-C67C0A17EF65@delong.com>

I would strongly encourage ARIN to work with ICANN/IANA to get the in- 
addr.arpa and ip6.arpa
TLDs signed and obtain a proper subordinate key/certificate for  
signing the ARIN zones within
those spaces.

It is utterly absurd that the RIRs and ICANN (a mere 6 bodies) cannot  
resolve such a trivial
issue amongst themselves.

Any signing of in-addr.arpa should also be made available to ip6.arpa  
at the same time.

Owen

On Jun 1, 2009, at 10:53 AM, Member Services wrote:

> ARIN has published a proposed plan for DNSSEC deployment and is  
> seeking community review and comment. The document is available at https://www.arin.net/about_us/dnssec/ 
> .
>
> Please submit your comments to the consult at arin.net. You can  
> subscribe to the arin-consult mailing list at:
> http://lists.arin.net/mailman/listinfo/arin-consult.
>
> Discussion on consult at arin.net will close at noon EDT 16 June 2009.
>
> Based on the feedback provided, ARIN will update the deployment plan  
> as needed with deployment currently planned for 1 July 2009.
>
> The ARIN Consultation and Suggestion Process documentation is  
> available
> at: https://www.arin.net/participate/acsp/index.html
>
> All are welcome to participate.  Please address any process  
> questions to info at arin.net.
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Wed Jun  3 16:58:52 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Jun 2009 13:58:52 -0700
Subject: [arin-ppml] Proposal to place a rational sunset on 2008-6/2009-1
Message-ID: <604C4D4D-2DFA-4167-B62D-F05497D063B2@delong.com>


TEMPLATE:   ARIN-POLICY-PROPOSAL-TEMPLATE-2.0

1. Policy Proposal Name: Sunset Clause for Liberalized Transfer Policy
2. Proposal Originator
          a.      name:		Owen DeLong
          b.      email:		owen at delong.com
          c.      telephone:	408-890-7992
          d.      organization:	Hurricane   Electric
3. Proposal Version: 1.0
4. Date:    03 June, 2009
5. Proposal type: delete
6. Policy term: permanent
7. Policy statement:

	Section 8.3, "Transfers to Specified Recipients", of the NRPM is
	deleted upon the effective date of this policy.

8. Rationale:

    When the community reached consensus in   support of 2008-6, it
contained a sunset clause.   In the process of developing 2009-1,
the sunset clause was removed. The effect of this policy proposal is
to restore the sunset clause while adopting a more rational date at
which to sunset the policy.

9.      Timetable for implementation:

		31 December, 2013
			or
		3 years after IANA issues the last /8s to the RIRs,
		whichever is later.

END OF TEMPLATE
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090603/fb6714e1/attachment.htm>

From owen at delong.com  Wed Jun  3 17:06:16 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Jun 2009 14:06:16 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <C6498852.29DC2%leo.vegoda@icann.org>
References: <C6498852.29DC2%leo.vegoda@icann.org>
Message-ID: <3A13F4CB-3A11-4C12-B948-DFBB30268624@delong.com>


On Jun 1, 2009, at 1:29 PM, Leo Vegoda wrote:

> On 01/06/2009 12:58, "Owen DeLong" <owen at delong.com> wrote:
>
> [...]
>
>>> If/when ARIN's  allocations of V6 space ever becomes so dense  that
>>> reserving the entire  /24  in advance  for recipients of /48s is no
>>> longer feasible,    it  should be the oldest-assigned  /48   that  
>>> are
>>> first "blocked" from expanding contiguously to a /24,  followed by  
>>> the
>>> oldest  /32 allocations.
>>>
>> This strategy presumes that ARIN is dividing the entire IPv6 address
>> space
>> and not receiving things in /24 chunks from IANA.
>
> ARIN won't get anything longer than a /12 from IANA until y'all  
> change the
> policy to allow that.
>
> Regards,
>
> Leo Vegoda

Yes... /12... /24 was a typo.

Owen



From owen at delong.com  Wed Jun  3 17:51:28 2009
From: owen at delong.com (Owen DeLong)
Date: Wed, 3 Jun 2009 14:51:28 -0700
Subject: [arin-ppml] Policy Proposal: Open Access To IPv6
In-Reply-To: <4A245D78.8050505@kl.net>
References: <F7EB0A7C707E39409A73CD0353242551A7F1580EDB@PLSWM01C.ad.sprint.com>	<2557049CDBC35B4EBD79CFACFEC045841B9F548B@XCH-NW-CCR1V.nw.nos.boeing.com>	<20090529212938.GA11989@ussenterprise.ufp.org>	<4A205A75.10107@matthew.at>	<A4285FC9-5428-4E3A-9046-B252A40BC4BF@pch.net>
	<0029FD77-572D-4098-A5C5-E5796948244C@delong.com>
	<4A245D78.8050505@kl.net>
Message-ID: <DE831A93-605D-4B75-939F-DC81CC28B27C@delong.com>

>
> Thus excluding slow-start and mergers and acquisitions we could
> still see 7.6 IPv6 prefixes per ASN if IPv6 were deployed and used to
> the extent that IPv4 is.

I'm not convinced that many of those are not the result of a  
multiplicative
effect between the other factors multiplied by slow-start.

In other words, say you need some portion of your network space to be
more specific as a result of some special project.  In IPv4, you  
assigned
that space to the project and if it needed to grow, likely you gave it  
an
additional prefix out of newer IPv4 which was likely from a new IPv4
assignment you received under slow-start.

In IPv6, you should be able to keep that more specific to a single
prefix in most cases.

Owen



From farmer at umn.edu  Wed Jun  3 18:53:59 2009
From: farmer at umn.edu (David Farmer)
Date: Wed, 03 Jun 2009 17:53:59 -0500
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
Message-ID: <4A26B8B7.22426.4B1F606@farmer.umn.edu>

I've mostly been sitting back and watching the discussion 
ensuing from the Open Access to IPv6 Proposal.

In much of the discussion I've seen a tension between two 
separate camps pushing the dominance of one of two 
properties Global Uniqueness vs Global Reachability.

Maintaining a scalable routing table is essential for Global 
Reachability, and given current technologies this is best 
insured by maintaining a routing hierarchy.  Multihoming 
seems to be the key discriminator if you should have a spot in 
that hierarchy or exist under another part of the hierarchy.  This 
is by and large the primary use that most people have for 
Global Unique IP addresses, in this case IPv6 addresses.

However, there are several uses that Global Reachability is not 
entirely necessary but Global Uniqueness is necessary or at 
least highly desirable.  I believe that the IPv6 address space is 
more than large enough to meet both needs, that's not the 
issue.  I believe the issue is one of assumptions made by 
some operators and most users too, that all Globally Unique 
IPv6 addresses should be or need to be Globally Reachable.

Now ULA (RFC 4193) exists and can probably meet some of 
these needs, but ULA is not quite the same as real Globally 
Unique IPv6 addresses, the primary differences are the RIRs 
and the Registries they provide, authoritative reverse DNS, 
and explicit uniqueness vs. the statistical uniqueness of ULA.

So currently ARIN assignes from two pools of IPv6 addresses 
one for IPv6 Allocations and IPv6 Assignments.  There are 
several other micro-allocation pools too, but I'll ignore those for 
now.  These two pools are split to allow for easy filter 
assumptions to be made, one /32 or less and the other /48 or 
less.  Further, I believe most people assume these two pools 
to be for Globally Reachable allocations and assignments.

What if we made the Global Reachability assumption explicit 
and created a separate pool without an explicit assumption of 
Globally Reachability.

In this way we could create policies which reinforce the routing 
hierarchy for the pools that explicitly have the Global 
Reachability.  While at the same time, we can provide the full 
benefit of Global Uniqueness to those that don't necessarily 
need that Global Reachability.  Creating a separate pool for 
this later purpose allows network operators to easily filter 
blocks that don't necessarily require Global Reachability if they 
so desire.

There should be more that enough IPv6 address space to 
allow this even if everyone had two /48s one from the Global 
Reachability pools, either an allocation from a LIR or an 
assignment direct from ARIN and a separate NON-Globally 
Reachable assignment.  (I know, I need a better name for it, 
but right now it is the idea that is important).

This isn't fully fleshed out, but if people like the idea I'll work on 
it.  If we can really get an ID/Locator split going in the future the 
distinction my be come a mute point, or maybe this new pool is 
used for those that need IDs and the Global Reachability 
Allocations become Locators.  But for now I think this could 
work as a way to make both camps happy.

What do you think?

===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From bicknell at ufp.org  Wed Jun  3 20:45:59 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 3 Jun 2009 20:45:59 -0400
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
In-Reply-To: <4A26B8B7.22426.4B1F606@farmer.umn.edu>
References: <4A26B8B7.22426.4B1F606@farmer.umn.edu>
Message-ID: <20090604004558.GA81977@ussenterprise.ufp.org>

In a message written on Wed, Jun 03, 2009 at 05:53:59PM -0500, David Farmer wrote:
> What if we made the Global Reachability assumption explicit 
> and created a separate pool without an explicit assumption of 
> Globally Reachability.

http://tools.ietf.org/id/draft-ietf-ipv6-ula-central-01.txt

(I don't know if that was the last/latest draft.)

I believe you idea is roughly the "ULA Central" idea.  The idea was a
separate address pool (FC00::/7) that would be assigned by IANA (which
of course may delegate to the RIR's, or create a new central entity, or
any number of things) and bits would be given out as globally unique
prefixes that are not expected to appear in the global internet routing
table.  That is, ISP's would filter FC00::/7 on the commodity internet.

The community was not in favor of this idea several years ago, but times
may have changed.

http://www.ripe.net/ripe/policies/proposals/2007-05.html
http://archive.apnic.net/policy/proposals/prop-048-v001.html
http://www.afrinic.net/docs/policies/afpol-v6ula200704.htm

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090603/43fb60a4/attachment.sig>

From farmer at umn.edu  Thu Jun  4 00:13:08 2009
From: farmer at umn.edu (David Farmer)
Date: Wed, 03 Jun 2009 23:13:08 -0500
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
In-Reply-To: <20090604004558.GA81977@ussenterprise.ufp.org>
References: <4A26B8B7.22426.4B1F606@farmer.umn.edu>,
	<20090604004558.GA81977@ussenterprise.ufp.org>
Message-ID: <4A270384.13632.FD6998@farmer.umn.edu>

I was aware of Central ULA, but I don't think it ever really 
progressed.  While close its not exactly the same thing as I'm 
talking about; it uses pseudo random assignment like regular 
ULA.  The draft hand waves the DNS operations issues, and 
since it uses pseudo random assignment I'm not really sure 
how your going to make the DNS delegations work.  The draft 
also envisions, different Registry operations that is typical from 
an RIR, while I'm sure ARIN or any other RIR could do it.

As I said, even regular ULA can meet some of the use cases.  
SixXS has a registry for regular ULA, but again that is not the 
same thing either, and at least violates the spirit of the RFC 
4193. 

http://www.sixxs.net/tools/grh/ula/

Anyway, ARIN already does Micro-allocations for Internal 
Infrastructure.  Which is much more like what I'm talking about 
than ULA.  A normal Unicast block with a published range that 
network operators can apply a routing policy to if they are 
inclined to.  However, what I'm talking about isn't necessarily 
for internal.  Its just not necessarily intended to be part of the 
mythical global route table.

I believe this is a way to have our cake and eat it too.  We can 
have both a policy that reinforces the routing hierarchy and that 
provides addresses for those that are willing to exist outside it.


On 3 Jun 2009 Leo Bicknell wrote:

> In a message written on Wed, Jun 03, 2009 at 05:53:59PM -0500, David
> Farmer wrote: > What if we made the Global Reachability assumption
> explicit > and created a separate pool without an explicit assumption
> of > Globally Reachability.
> 
> http://tools.ietf.org/id/draft-ietf-ipv6-ula-central-01.txt
> 
> (I don't know if that was the last/latest draft.)
> 
> I believe you idea is roughly the "ULA Central" idea.  The idea was a
> separate address pool (FC00::/7) that would be assigned by IANA (which
> of course may delegate to the RIR's, or create a new central entity,
> or any number of things) and bits would be given out as globally
> unique prefixes that are not expected to appear in the global internet
> routing table.  That is, ISP's would filter FC00::/7 on the commodity
> internet.
> 
> The community was not in favor of this idea several years ago, but
> times may have changed.
> 
> http://www.ripe.net/ripe/policies/proposals/2007-05.html
> http://archive.apnic.net/policy/proposals/prop-048-v001.html
> http://www.afrinic.net/docs/policies/afpol-v6ula200704.htm
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> 



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From randy at psg.com  Thu Jun  4 01:12:08 2009
From: randy at psg.com (Randy Bush)
Date: Thu, 04 Jun 2009 14:12:08 +0900
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
In-Reply-To: <4A270384.13632.FD6998@farmer.umn.edu>
References: <4A26B8B7.22426.4B1F606@farmer.umn.edu>
Message-ID: <m2zlcoinvb.wl%randy@psg.com>

> I was aware of Central ULA, but I don't think it ever really 
> progressed.  While close its not exactly the same thing as I'm 
> talking about; it uses pseudo random assignment like regular 
> ULA.  The draft hand waves the DNS operations issues, and 
> since it uses pseudo random assignment I'm not really sure 
> how your going to make the DNS delegations work.  The draft 
> also envisions, different Registry operations that is typical from 
> an RIR, while I'm sure ARIN or any other RIR could do it.
> 
> As I said, even regular ULA can meet some of the use cases.  
> SixXS has a registry for regular ULA, but again that is not the 
> same thing either, and at least violates the spirit of the RFC 
> 4193. 
> 
> http://www.sixxs.net/tools/grh/ula/
> 
> Anyway, ARIN already does Micro-allocations for Internal 
> Infrastructure.  Which is much more like what I'm talking about 
> than ULA.  A normal Unicast block with a published range that 
> network operators can apply a routing policy to if they are 
> inclined to.  However, what I'm talking about isn't necessarily 
> for internal.  Its just not necessarily intended to be part of the 
> mythical global route table.
> 
> I believe this is a way to have our cake and eat it too.  We can 
> have both a policy that reinforces the routing hierarchy and that 
> provides addresses for those that are willing to exist outside it.

i am always amused that the same people who sing ipv6 is effectively
infinite advocate this ula crap.  have they learned nothing from rfc1918
space messes and difficulties?

this is ipv6.  if someone needs space, you better have an exceedingly
good reason not to give them vanilla unicast ipv6 space.

randy


From scottleibrand at gmail.com  Thu Jun  4 02:49:07 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 4 Jun 2009 01:49:07 -0500
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
In-Reply-To: <4A270384.13632.FD6998@farmer.umn.edu>
References: <4A26B8B7.22426.4B1F606@farmer.umn.edu>,
	<20090604004558.GA81977@ussenterprise.ufp.org>
	<4A270384.13632.FD6998@farmer.umn.edu>
Message-ID: <478AC5A9-9DAB-4FB9-A6B8-7BF47F597012@gmail.com>

There was a more recent (and IMO better) version of this called ULA  
Global. IIRC, it was a lot closer to what you are describing than ULA  
Cental was.

-Scott

On Jun 3, 2009, at 11:13 PM, "David Farmer" <farmer at umn.edu> wrote:

> I was aware of Central ULA, but I don't think it ever really
> progressed.  While close its not exactly the same thing as I'm
> talking about; it uses pseudo random assignment like regular
> ULA.  The draft hand waves the DNS operations issues, and
> since it uses pseudo random assignment I'm not really sure
> how your going to make the DNS delegations work.  The draft
> also envisions, different Registry operations that is typical from
> an RIR, while I'm sure ARIN or any other RIR could do it.
>
> As I said, even regular ULA can meet some of the use cases.
> SixXS has a registry for regular ULA, but again that is not the
> same thing either, and at least violates the spirit of the RFC
> 4193.
>
> http://www.sixxs.net/tools/grh/ula/
>
> Anyway, ARIN already does Micro-allocations for Internal
> Infrastructure.  Which is much more like what I'm talking about
> than ULA.  A normal Unicast block with a published range that
> network operators can apply a routing policy to if they are
> inclined to.  However, what I'm talking about isn't necessarily
> for internal.  Its just not necessarily intended to be part of the
> mythical global route table.
>
> I believe this is a way to have our cake and eat it too.  We can
> have both a policy that reinforces the routing hierarchy and that
> provides addresses for those that are willing to exist outside it.
>
>
> On 3 Jun 2009 Leo Bicknell wrote:
>
>> In a message written on Wed, Jun 03, 2009 at 05:53:59PM -0500, David
>> Farmer wrote: > What if we made the Global Reachability assumption
>> explicit > and created a separate pool without an explicit assumption
>> of > Globally Reachability.
>>
>> http://tools.ietf.org/id/draft-ietf-ipv6-ula-central-01.txt
>>
>> (I don't know if that was the last/latest draft.)
>>
>> I believe you idea is roughly the "ULA Central" idea.  The idea was a
>> separate address pool (FC00::/7) that would be assigned by IANA  
>> (which
>> of course may delegate to the RIR's, or create a new central entity,
>> or any number of things) and bits would be given out as globally
>> unique prefixes that are not expected to appear in the global  
>> internet
>> routing table.  That is, ISP's would filter FC00::/7 on the commodity
>> internet.
>>
>> The community was not in favor of this idea several years ago, but
>> times may have changed.
>>
>> http://www.ripe.net/ripe/policies/proposals/2007-05.html
>> http://archive.apnic.net/policy/proposals/prop-048-v001.html
>> http://www.afrinic.net/docs/policies/afpol-v6ula200704.htm
>>
>> -- 
>>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>>        PGP keys at http://www.ufp.org/~bicknell/
>>
>
>
>
> ===============================================
> David Farmer                                      Email:farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota               Phone: 612-626-0815
> 2218 University Ave SE               Cell: 612-812-9952
> Minneapolis, MN 55414-3029           FAX: 612-626-1818
> ===============================================
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From vixie at isc.org  Thu Jun  4 03:04:28 2009
From: vixie at isc.org (Paul Vixie)
Date: Thu, 04 Jun 2009 07:04:28 +0000
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
In-Reply-To: <478AC5A9-9DAB-4FB9-A6B8-7BF47F597012@gmail.com> (Scott
	Leibrand's message of "Thu\, 4 Jun 2009 01\:49\:07 -0500")
References: <4A26B8B7.22426.4B1F606@farmer.umn.edu>
	<20090604004558.GA81977@ussenterprise.ufp.org>
	<4A270384.13632.FD6998@farmer.umn.edu>
	<478AC5A9-9DAB-4FB9-A6B8-7BF47F597012@gmail.com>
Message-ID: <g3iqjch43n.fsf@nsa.vix.com>

scottleibrand at gmail.com (Scott Leibrand) writes:

> There was a more recent (and IMO better) version of this called ULA
> Global. IIRC, it was a lot closer to what you are describing than ULA
> Cental was.
>
> -Scott

Noting that the URL changed to <http://nsa.vix.com/~vixie/ula-global.txt>
and that my purported co-authors do not actually support this proposal.

In case it seems odd that IPv6 would need anything scoped in this way, the
purpose is to make it easy to keep this crud out of the DFZ while still
permitting metro and neighborhood level experiments in "DFZ bypass."
-- 
Paul Vixie
KI6YSY


From randy at psg.com  Thu Jun  4 03:24:25 2009
From: randy at psg.com (Randy Bush)
Date: Thu, 04 Jun 2009 16:24:25 +0900
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
In-Reply-To: <g3iqjch43n.fsf@nsa.vix.com>
References: <4A26B8B7.22426.4B1F606@farmer.umn.edu>
	<20090604004558.GA81977@ussenterprise.ufp.org>
	<4A270384.13632.FD6998@farmer.umn.edu>
	<478AC5A9-9DAB-4FB9-A6B8-7BF47F597012@gmail.com>
	<g3iqjch43n.fsf@nsa.vix.com>
Message-ID: <m2iqjcihqu.wl%randy@psg.com>

> In case it seems odd that IPv6 would need anything scoped in this way, the
> purpose is to make it easy to keep this crud out of the DFZ

like it's easy to keep 1918 out of the dfz


From gdolley at arpnetworks.com  Thu Jun  4 04:51:01 2009
From: gdolley at arpnetworks.com (Garry Dolley)
Date: Thu, 4 Jun 2009 01:51:01 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <3c3e3fca0906031056v1284040ao1d47765754dcf16a@mail.gmail.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<3c3e3fca0906031056v1284040ao1d47765754dcf16a@mail.gmail.com>
Message-ID: <20090604085101.GA2882@garry-thinkpad.arpnetworks.com>

On Wed, Jun 03, 2009 at 01:56:36PM -0400, William Herrin wrote:
> Hi Folks,
> 
> Is there any interest in seeing this as a formal proposal after adding
> in the various adjustments some of you have suggested?

No

-- 
Garry Dolley
ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181
Data center, VPS, and IP Transit solutions
Member Los Angeles County REACT, Unit 336 | WQGK336
Blog http://scie.nti.st


From marla.azinger at frontiercorp.com  Thu Jun  4 10:00:35 2009
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Thu, 4 Jun 2009 10:00:35 -0400
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
In-Reply-To: <m2iqjcihqu.wl%randy@psg.com>
References: <4A26B8B7.22426.4B1F606@farmer.umn.edu>
	<20090604004558.GA81977@ussenterprise.ufp.org>
	<4A270384.13632.FD6998@farmer.umn.edu>
	<478AC5A9-9DAB-4FB9-A6B8-7BF47F597012@gmail.com>
	<g3iqjch43n.fsf@nsa.vix.com> <m2iqjcihqu.wl%randy@psg.com>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F10484DA01540@ROCH-EXCH1.corp.pvt>

And that fear of leak in the dfz is why it didnt go anywhere at IETF.  Last time it was debated there were more concerned about leak than the possible benefit users would have.

~Marla

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Randy Bush
Sent: Thursday, June 04, 2009 12:24 AM
To: Paul Vixie
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Global Uniqueness vs Global Reachability

> In case it seems odd that IPv6 would need anything scoped in this way,
> the purpose is to make it easy to keep this crud out of the DFZ

like it's easy to keep 1918 out of the dfz _______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From farmer at umn.edu  Thu Jun  4 10:21:46 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 04 Jun 2009 09:21:46 -0500
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
In-Reply-To: <g3iqjch43n.fsf@nsa.vix.com>
References: <4A26B8B7.22426.4B1F606@farmer.umn.edu>,
	<478AC5A9-9DAB-4FB9-A6B8-7BF47F597012@gmail.com> (Scott Leibrand's
	message of "Thu\, 4 Jun 2009 01\:49\:07 -0500"),
	<g3iqjch43n.fsf@nsa.vix.com>
Message-ID: <4A27922A.4369.32AA498@farmer.umn.edu>

On 4 Jun 2009 Paul Vixie wrote:

> scottleibrand at gmail.com (Scott Leibrand) writes:
> 
> > There was a more recent (and IMO better) version of this called ULA
> > Global. IIRC, it was a lot closer to what you are describing than
> > ULA Cental was.
> >
> > -Scott
> 
> Noting that the URL changed to
> <http://nsa.vix.com/~vixie/ula-global.txt> and that my purported
> co-authors do not actually support this proposal.
> 
> In case it seems odd that IPv6 would need anything scoped in this way,
> the purpose is to make it easy to keep this crud out of the DFZ while
> still permitting metro and neighborhood level experiments in "DFZ
> bypass." -- Paul Vixie KI6YSY

Well I have to say I wasn't realy aware of this draft.  While I 
think this is much better than ULA-Central, it still claims to be 
something other than regular Unicast address space with a 
easily defined routing policy scoping it out of the mythical 
global route table

One example from the draft;

"5.5 IANA and all RIR/LIRs are encouraged to avoid allocating 
aligned blocks of address space under this specification, in 
order to specifically discourage aggregation and wide area 
routing of such address space."

I think I have to go with Randy on this one, if someone 
wants/needs unicast IPv6 address space they should be able 
to get it unless we have a really good reason not to give it to 
them.  

All I'm suggesting is that we can provide it in a way that easily 
allows a coordinated routing policy regarding assignments 
outside an aggregated routing hierarchy.

If people are wary about trying something like this, since we 
are working within ARIN's policy process and within ARIN's 
registry services contracts, we could back stop this whole thing 
by allowing ARIN to withdraw all assignments of this type with 
a 5 year notice or something like that.  If people are worried 
about it turning into a mess, we can try to provide a way 
mitigate that risk.  This is something well with in ARIN's and the 
other RIRs perveiw to manage IP address assignments and 
allocations, and would be much harder to for the IETF to make 
happen.

Today aggregated hierarchical routing is the best way to make 
the Internet work.  However, if that hammer remains the only 
tool in the Internet tool box, then everything will look like nails.


===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From info at arin.net  Thu Jun  4 11:21:46 2009
From: info at arin.net (Member Services)
Date: Thu, 04 Jun 2009 11:21:46 -0400
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized Transfer
	Policy
Message-ID: <4A27E68A.9050707@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at:https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: Sunset Clause for Liberalized Transfer Policy

Proposal Originator: Owen DeLong

Proposal Version: 1.0

Date: 4 June 2009

Proposal type: delete

Policy term: permanent

Policy statement:

Section 8.3, "Transfers to Specified Recipients", of the NRPM is
deleted upon the effective date of this policy.

Rationale:

When the community reached consensus in   support of 2008-6, it
contained a sunset clause.   In the process of developing 2009-1,
the sunset clause was removed. The effect of this policy proposal is
to restore the sunset clause while adopting a more rational date at
which to sunset the policy.

Timetable for implementation:

31 December, 2013
or
3 years after IANA issues the last /8s to the RIRs,
whichever is later.






From lear at cisco.com  Thu Jun  4 11:55:21 2009
From: lear at cisco.com (Eliot Lear)
Date: Thu, 04 Jun 2009 17:55:21 +0200
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <4A27E68A.9050707@arin.net>
References: <4A27E68A.9050707@arin.net>
Message-ID: <4A27EE69.9020201@cisco.com>

While I appreciate the desire for certainty by assigning a date certain 
to when a transfer policy will end, I don't think we should establish 
such a date until we have seen the effects of the transfer policy (if 
any).  What we need now is data not more policy.

Eliot

On 6/4/09 5:21 PM, Member Services wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
>
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.
>
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
>
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Policy Proposal Name: Sunset Clause for Liberalized Transfer Policy
>
> Proposal Originator: Owen DeLong
>
> Proposal Version: 1.0
>
> Date: 4 June 2009
>
> Proposal type: delete
>
> Policy term: permanent
>
> Policy statement:
>
> Section 8.3, "Transfers to Specified Recipients", of the NRPM is
> deleted upon the effective date of this policy.
>
> Rationale:
>
> When the community reached consensus in   support of 2008-6, it
> contained a sunset clause.   In the process of developing 2009-1,
> the sunset clause was removed. The effect of this policy proposal is
> to restore the sunset clause while adopting a more rational date at
> which to sunset the policy.
>
> Timetable for implementation:
>
> 31 December, 2013
> or
> 3 years after IANA issues the last /8s to the RIRs,
> whichever is later.
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



From kkargel at polartel.com  Thu Jun  4 13:19:52 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 4 Jun 2009 12:19:52 -0500
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
	Transfer Policy
In-Reply-To: <4A27EE69.9020201@cisco.com>
References: <4A27E68A.9050707@arin.net> <4A27EE69.9020201@cisco.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Eliot Lear
> Sent: Thursday, June 04, 2009 10:55 AM
> To: Member Services
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
> Transfer Policy
> 
> While I appreciate the desire for certainty by assigning a date certain
> to when a transfer policy will end, I don't think we should establish
> such a date until we have seen the effects of the transfer policy (if
> any).  What we need now is data not more policy.
> 
> Eliot

I think the reason for the sunset is precisely that we have no idea what
will happen and some folks want to know that there will be an enforced audit
and examination in the future.  Having a sunset date will ensure that the
issue is reviewed when the sunset date approaches.  The lack of data is
actually a driver for this proposal.

> 
> On 6/4/09 5:21 PM, Member Services wrote:
> > ARIN received the following policy proposal and is posting it to the
> > Public Policy Mailing List (PPML) in accordance with Policy Development
> > Process.
> >
> > This proposal is in the first stage of the Policy Development Process.
> > ARIN staff will perform the Clarity and Understanding step. Staff does
> > not evaluate the proposal at this time, their goal is to make sure that
> > they understand the proposal and believe the community will as well.
> > Staff will report their results to the ARIN Advisory Council (AC) within
> > 10 days.
> >
> > The AC will review the proposal at their next regularly scheduled
> > meeting (if the period before the next regularly scheduled meeting is
> > less than 10 days, then the period may be extended to the subsequent
> > regularly scheduled meeting). The AC will decide how to utilize the
> > proposal and announce the decision to the PPML.
> >
> > In the meantime, the AC invites everyone to comment on the proposal on
> > the PPML, particularly their support or non-support and the reasoning
> > behind their opinion. Such participation contributes to a thorough
> > vetting and provides important guidance to the AC in their
> deliberations.
> >
> > The ARIN Policy Development Process can be found at:
> > https://www.arin.net/policy/pdp.html
> >
> > Mailing list subscription information can be found
> > at:https://www.arin.net/mailing_lists/
> >
> > Regards,
> >
> > Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Policy Proposal Name: Sunset Clause for Liberalized Transfer Policy
> >
> > Proposal Originator: Owen DeLong
> >
> > Proposal Version: 1.0
> >
> > Date: 4 June 2009
> >
> > Proposal type: delete
> >
> > Policy term: permanent
> >
> > Policy statement:
> >
> > Section 8.3, "Transfers to Specified Recipients", of the NRPM is
> > deleted upon the effective date of this policy.
> >
> > Rationale:
> >
> > When the community reached consensus in   support of 2008-6, it
> > contained a sunset clause.   In the process of developing 2009-1,
> > the sunset clause was removed. The effect of this policy proposal is
> > to restore the sunset clause while adopting a more rational date at
> > which to sunset the policy.
> >
> > Timetable for implementation:
> >
> > 31 December, 2013
> > or
> > 3 years after IANA issues the last /8s to the RIRs,
> > whichever is later.
> >
> >
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090604/35509320/attachment.bin>

From petelists at templin.org  Thu Jun  4 13:34:42 2009
From: petelists at templin.org (Pete Templin)
Date: Thu, 04 Jun 2009 12:34:42 -0500
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <4A27E68A.9050707@arin.net>
References: <4A27E68A.9050707@arin.net>
Message-ID: <4A2805B2.3040801@templin.org>

Member Services wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
> 
> Policy Proposal Name: Sunset Clause for Liberalized Transfer Policy
> 
> Rationale:
> 
> When the community reached consensus in   support of 2008-6, it
> contained a sunset clause.   In the process of developing 2009-1,
> the sunset clause was removed. The effect of this policy proposal is
> to restore the sunset clause while adopting a more rational date at
> which to sunset the policy.
> 
> Timetable for implementation:
> 
> 31 December, 2013
> or
> 3 years after IANA issues the last /8s to the RIRs,
> whichever is later.

If you'd like a rational date at which to sunset the policy, you might 
want to tune up this timetable language significantly.  It's going to be 
a long, long time before IANA issues the last /8s to the RIRs.

I'm opposed to this policy as written, and I'm opposed to this policy as 
intended.  Three years covers roughly five cycles of Public Policy 
Meetings plus a partial cycle for implementation.  Let's collect data 
and implement new policy as guided by that data in a timeframe and 
manner that's right for the ARIN region and the Internet as a whole.

Pete


From mueller at syr.edu  Thu Jun  4 14:40:03 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 4 Jun 2009 14:40:03 -0400
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>
References: <4A27E68A.9050707@arin.net> <4A27EE69.9020201@cisco.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>

> Having a sunset date will ensure that the issue is reviewed when the sunset date approaches.  The lack 
> of data is actually a driver for this proposal.

I disagree with Kevin and oppose Owen's proposal. The sunset is inherently arbitrary and therefore potentially disruptive. As was established long ago in list discussions, it is mainly supported by people who don't want there to be a transfer policy in the first place. 

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 


From sethm at rollernet.us  Thu Jun  4 14:45:20 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 04 Jun 2009 11:45:20 -0700
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
References: <4A27E68A.9050707@arin.net>
	<4A27EE69.9020201@cisco.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>
	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A281640.6000603@rollernet.us>

Milton L Mueller wrote:
>> Having a sunset date will ensure that the issue is reviewed when the sunset date approaches.  The lack 
>> of data is actually a driver for this proposal.
> 
> I disagree with Kevin and oppose Owen's proposal. The sunset is inherently arbitrary and therefore potentially disruptive. As was established long ago in list discussions, it is mainly supported by people who don't want there to be a transfer policy in the first place. 
> 

One could also say the sunset is a compromise between the two extremes.
Arbitrary transfers are also arbitrary.

~Seth


From ipgoddess.arin at gmail.com  Thu Jun  4 14:48:05 2009
From: ipgoddess.arin at gmail.com (Stacy Hughes)
Date: Thu, 4 Jun 2009 11:48:05 -0700
Subject: [arin-ppml] Policy Proposal: Internet Assigned Numbers
	Authority (IANA) Policy for Allocation of ASN Blocks (ASNs)
	to Regional Internet Registries
In-Reply-To: <1ABE56E0-28DB-474B-8ED3-517D57349987@delong.com>
References: <4A1FFB11.9080101@arin.net>
	<12535BF9-2693-4480-88E1-ED7139A88B58@delong.com>
	<4A203F1F.8090002@gmail.com>
	<20090601155240.GJ16587@shell02.cell.sv2.tellme.com>
	<1ABE56E0-28DB-474B-8ED3-517D57349987@delong.com>
Message-ID: <24c86a5f0906041148n5bfd63d3yd23a60471741eb16@mail.gmail.com>

It has already been submitted in the RIPE and APNIC regions with the
language I submitted here.Stacy

On Wed, Jun 3, 2009 at 1:35 PM, Owen DeLong <owen at delong.com> wrote:

> I don't believe this has been submitted to any of the other RIRs
> as yet, so, I think that the change I proposed would not slow it down.
> In fact, I think it might actually help it get through faster.
>
> Owen
>
>
> On Jun 1, 2009, at 8:52 AM, David Williamson wrote:
>
>  I support the policy as written.  I think Owen has a great idea, but
>> the timeline is a problem for changes.  It would be possible to start a
>> new policy to correct this one with Owen's suggested changes, but let's
>> fast track this one *as is*.
>>
>> I'd even support this as written if it was declared to be a Board
>> response to an emergency.  Unless there are compelling arguments in
>> dissent, this should simply move forward.
>>
>> -David
>>
>> On Fri, May 29, 2009 at 03:01:35PM -0500, Scott Leibrand wrote:
>>
>>> One thing to keep in mind here is that, because this is a Global Policy,
>>> and because of the extremely tight timeframe, we need to agree on the
>>> text of the proposal right away, and make sure the same text gets put
>>> forward in each region.  Even if everyone approves it their first time
>>> around, and LACNIC approves it through their fast-track process (since
>>> it'll be exactly a year until their next meeting), we're still looking
>>> at sometime in 2010 before the policy can be ratified by the ASO-AC and
>>> ICANN.  That will mean we will have several months (at least) of RIRs
>>> being unable to get more 16-bit ASNs from the IANA before this policy
>>> could go through and make it possible again.  I've heard some very good
>>> arguments in the last week that the simpler we make the change, the less
>>> likely we are to run into problems that cause delays in getting this
>>> approved in time for it to be useful...
>>>
>>> How important do you think it is to preserve the 16bit/32bit ASN
>>> distinction past 1 Jan 2011?  Is it worth the increased risk of delay in
>>> passing such a revised global policy?
>>>
>>> (As you probably figured out from my comments above, I personally
>>> support this policy.)
>>>
>>> -Scott
>>>
>>> Owen DeLong wrote:
>>>
>>>> While I do not support changing the RIR policy on the issuance of ASNs,
>>>> I do support this policy proposal.  I think that modifying the IANA->RIR
>>>> distribution rules to accommodate the needs of RIRs to better serve
>>>> their
>>>> constituents makes sense. Further, having 16-bit ASNs trapped in the
>>>> IANA free pool because 32-bit ASNs are not being accepted by recipients
>>>> is absurd and poor stewardship. We should go ahead and issue 16-bit
>>>> ASNs until they run out.
>>>>
>>>> I would suggest that this proposal, rather than removing the distinction
>>>> in 2010 should be modified to extend the IANA->RIR duality until such
>>>> time as there are no more 16-bit ASN blocks in the IANA pool.
>>>>
>>>> Owen
>>>>
>>>> On May 29, 2009, at 8:11 AM, Member Services wrote:
>>>>
>>>>  ARIN received the following policy proposal and is posting it to the
>>>>> Public Policy Mailing List (PPML) in accordance with Policy Development
>>>>> Process.
>>>>>
>>>>> This proposal is in the first stage of the Policy Development Process.
>>>>> ARIN staff will perform the Clarity and Understanding step. Staff does
>>>>> not evaluate the proposal at this time, their goal is to make sure that
>>>>> they understand the proposal and believe the community will as well.
>>>>> Staff will report their results to the ARIN Advisory Council (AC)
>>>>> within
>>>>> 10 days.
>>>>>
>>>>> The AC will review the proposal at their next regularly scheduled
>>>>> meeting (if the period before the next regularly scheduled meeting is
>>>>> less than 10 days, then the period may be extended to the subsequent
>>>>> regularly scheduled meeting). The AC will decide how to utilize the
>>>>> proposal and announce the decision to the PPML.
>>>>>
>>>>> In the meantime, the AC invites everyone to comment on the proposal on
>>>>> the PPML, particularly their support or non-support and the reasoning
>>>>> behind their opinion. Such participation contributes to a thorough
>>>>> vetting and provides important guidance to the AC in their
>>>>> deliberations.
>>>>>
>>>>> The ARIN Policy Development Process can be found at:
>>>>> https://www.arin.net/policy/pdp.html
>>>>>
>>>>> Mailing list subscription information can be found
>>>>> at:https://www.arin.net/mailing_lists/
>>>>>
>>>>> Regards,
>>>>>
>>>>> Member Services
>>>>> American Registry for Internet Numbers (ARIN)
>>>>>
>>>>>
>>>>> ## * ##
>>>>>
>>>>>
>>>>> Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for
>>>>> Allocation of ASN Blocks (ASNs) to Regional Internet Registries
>>>>>
>>>>> Proposal Originator: Stacy Hughes and Andrew de la Haye
>>>>>
>>>>> Proposal Version: 1.0
>>>>>
>>>>> Date: 29 May 2009
>>>>>
>>>>> Proposal type: modify
>>>>>
>>>>> Policy term: permanent
>>>>>
>>>>> Policy statement:
>>>>>
>>>>> Modification of NRPM section 10.3 extending the deadline for an
>>>>> undifferentiated ASN pool by 1 year to read:
>>>>>
>>>>> 1. Allocation Principles
>>>>>
>>>>> IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document
>>>>> the
>>>>> term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010,
>>>>> allocations of 16-bit and 32-bit only ASN blocks will be made
>>>>> separately
>>>>> and independent of each other [1].
>>>>>
>>>>> This means until 31 December 2010, RIRs can receive two separate ASN
>>>>> blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA
>>>>> under this policy. After this date, IANA and the RIRs will cease to
>>>>> make
>>>>> any distinction between 16-bit and 32-bit only ASNs, and will operate
>>>>> ASN allocations from an undifferentiated 32-bit ASN allocation pool.
>>>>>
>>>>> Rationale:
>>>>>
>>>>> a. Arguments supporting the proposal
>>>>>
>>>>> Due to operational issues external to the IANA/RIR policy process,
>>>>> 32-bit only ASNs are not being issued by the RIRs at the anticipated
>>>>> rate. As it stands, RIRs will likely not be able to justify a new block
>>>>> of ASNs from the IANA after 31 December 2009 due to a glut of free 32
>>>>> bit only ASNs in the RIR?s pool. This leaves available, essential
>>>>> 16-bit
>>>>> ASNs stranded in the IANA free pool. This proposal seeks to remedy the
>>>>> potential problem by extending the deadline for differentiation by one
>>>>> year.
>>>>>
>>>>> With this proposal the policy will be aligned with the actual reality
>>>>> in
>>>>> regards to 32-bit ASN deployment and usage.
>>>>>
>>>>> The subject was raised during RIPE 58 and a presentation was made:
>>>>>
>>>>> http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf
>>>>>
>>>>>
>>>>> The feedback in this session suggested that a global policy proposal
>>>>> should be developed and should be discussed.
>>>>>
>>>>> b. Arguments opposing the proposal
>>>>>
>>>>> Some may think that extending the previously set timeline can be
>>>>> perceived as some discouragement for the deployment of 32-bit ASNs. One
>>>>> counter argument to this is that RIRs and Internet community have some
>>>>> other mechanisms and activities to raise awareness for 32-bit ASN pool
>>>>> (via public presentations and trainings). These activities will
>>>>> continue
>>>>> while 16-bit ASN blocks are still allocated to RIRs by the IANA as they
>>>>> are available and they are needed.
>>>>>
>>>>> Timetable for implementation: Immediately upon ratification by ICANN
>>>>> Board
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PPML
>>>>> You are receiving this message because you are subscribed to
>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>>> Please contact info at arin.net if you experience any issues.
>>>>>
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090604/20872f01/attachment.htm>

From mueller at syr.edu  Thu Jun  4 14:48:44 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 4 Jun 2009 14:48:44 -0400
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <4A281640.6000603@rollernet.us>
References: <4A27E68A.9050707@arin.net>	<4A27EE69.9020201@cisco.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>
	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
	<4A281640.6000603@rollernet.us>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A12@SUEX07-MBX-04.ad.syr.edu>

> One could also say the sunset is a compromise between the two 
> extremes. 

it's the kind of compromise that cuts the baby in half. 
if folks can demonstrate real problems with transfers they should have no trouble re-opening the issue. 

> Arbitrary transfers are also arbitrary.

unassailable verbal logic (as are all tautologies), but I honestly don't get your point.

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 



From mueller at syr.edu  Thu Jun  4 14:49:33 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 4 Jun 2009 14:49:33 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <28E139F46D45AF49A31950F88C4974580178068F@E03MVZ2-UKDY.domain1.systemhost.net>
References: <3c3e3fca0906031056v1284040ao1d47765754dcf16a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C4974580178068F@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A13@SUEX07-MBX-04.ad.syr.edu>

Yes.


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
> Sent: Wednesday, June 03, 2009 3:02 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] A modest proposal for IPv6 address 
> allocations
> 
> 
> No.
> 
> --Michael Dillon
> 
> > Is there any interest in seeing this as a formal proposal 
> > after adding in the various adjustments some of you have suggested?
> > 
> > Regards,
> > Bill Herrin
> > 
> > 
> > On Sat, May 30, 2009 at 3:05 PM, William 
> Herrin<bill at herrin.us> wrote:
> > > So here's a crazy plan:
> > >
> > > A. The first IPv6 allocation from ARIN is always a /48. To 
> > justify it, 
> > > you need to be multihomed. There are no other 
> > qualifications. The /48 
> > > will be allocated from a pool from which only /48's are allocated.
> > >
> > > B. The second IPv6 allocation from ARIN is always a /32. To 
> > justify it 
> > > you need to demonstrate that you've efficiently used the 
> > /48 for some 
> > > reasonable definition of efficient, that you've 
> implemented SWIP or 
> > > RWHOIS for your downstream assignments and that you will 
> run out of 
> > > space in the /48 within one year. The /32 will be 
> allocated from a 
> > > pool reserved for allocating /32's.
> > >
> > > C. The third IPv6 allocation from ARIN is always a /24. To 
> > justify it 
> > > you need to demonstrate that you've efficiently used the 
> > /32, that you 
> > > will run out of space in the /32 within five years, and 
> you have to 
> > > first return the original /48 you were assigned. The /24 will be 
> > > allocated from a pool reserved for allocating /24's.
> > >
> > > D. There is no fourth IPv6 allocation at this time. It is not 
> > > presently possible to consume an entire /24 without 
> atrocious waste.
> > >
> > > What are the consequences of this plan?
> > >
> > > 1. Efficient allocation of IP addresses. Orgs get what they 
> > need when 
> > > they need it and not before without a great deal of 
> guesswork about 
> > > actual need.
> > >
> > > 2. Efficient utilization of BGP routing slots. No single 
> multihomed 
> > > org will ever announce more than 2 necessary routes.
> > >
> > > 3. Traffic engineering routes are trivially filterable 
> > since any route 
> > > longer than the published allocation size can be presumed to be 
> > > traffic engineering, not a downstream multihomed 
> customer, thus you 
> > > can filter distant small routes with confidence and ease.
> > >
> > > 4. No need to define the difference between ISP and not 
> > ISP. Everybody 
> > > plays by the same rules.
> > >
> > > 5. No complicated analysis for the first allocation. 
> You're either 
> > > multihomed or you're not. If you're multihomed, you qualify.
> > >
> > > 6. For those who can live within the /48 there are distinct
> > > advantages: no swip or rwhois reporting and the generic end-user 
> > > annual fee instead of the ISP annual fee. Once you're up to 
> > a /32, you 
> > > pay the ISP annual fee. As a result, ARIN doesn't have to 
> > scrutinize 
> > > the /32 requests too closely either.
> > 
> > 
> > 
> > 
> > --
> > William D. Herrin ................ herrin at dirtside.com  
> bill at herrin.us
> > 3005 Crane Dr. ...................... Web: 
> > <http://bill.herrin.us/> Falls Church, VA 22042-3004 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to 
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 

From kkargel at polartel.com  Thu Jun  4 14:54:45 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Thu, 4 Jun 2009 13:54:45 -0500
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
	Transfer Policy
In-Reply-To: <4A281640.6000603@rollernet.us>
References: <4A27E68A.9050707@arin.net><4A27EE69.9020201@cisco.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail><75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
	<4A281640.6000603@rollernet.us>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B298@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Seth Mattinen
> Sent: Thursday, June 04, 2009 1:45 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
> Transfer Policy
> 
> Milton L Mueller wrote:
> >> Having a sunset date will ensure that the issue is reviewed when the
> sunset date approaches.  The lack
> >> of data is actually a driver for this proposal.
> >
> > I disagree with Kevin and oppose Owen's proposal. The sunset is
> inherently arbitrary and therefore potentially disruptive. As was
> established long ago in list discussions, it is mainly supported by people
> who don't want there to be a transfer policy in the first place.
> >
I didn't mean to imply I support the proposal, I am undecided, I was just
commenting on the justification.

> 
> One could also say the sunset is a compromise between the two extremes.
> Arbitrary transfers are also arbitrary.
> 
> ~Seth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090604/c17a0216/attachment.bin>

From Matthew.Wilder at telus.com  Thu Jun  4 15:04:30 2009
From: Matthew.Wilder at telus.com (Matthew Wilder)
Date: Thu, 4 Jun 2009 13:04:30 -0600
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A13@SUEX07-MBX-04.ad.syr.edu>
References: <3c3e3fca0906031056v1284040ao1d47765754dcf16a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C4974580178068F@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D77B220A13@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <DE229826F48ABD4CBF754E5AA6CFC14B1DE263FD41@WP40044.corp.ads>

No, I am not interested in this proposal.

This could be a catastrophic policy when paired with the ambiguity of 6.5.2.1 (Subsequent [IPv6] Allocation Criteria).  This section states:

"Subsequent allocation will be provided when an organization (ISP/LIR) satisfies the evaluation threshold of past address utilization in terms of the number of sites in units of /56 assignments."

If the majority of sites receive /48 assignments, I can only assume that would imply a 100% utilization of /56 assignments within that /48.  That in turn implies that any time you assign any subnet to a site (could be /40, maybe even /32) then that address block is 100% utilized as far as this criteria is concerned.  

Adding the proposed policy into the mix with 6.5.2.1 could help a lot of organizations to get a /24 mighty fast.  I doubt that is the intention of the proposal, but any proposal needs to take loopholes and abuses into consideration.

Regards,
Matthew Wilder

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
Sent: Thursday, June 04, 2009 11:50 AM
To: ppml at arin.net
Subject: Re: [arin-ppml] A modest proposal for IPv6 address allocations

Yes.


> -----Original Message-----
> From: arin-ppml-bounces at arin.net
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
> Sent: Wednesday, June 03, 2009 3:02 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] A modest proposal for IPv6 address 
> allocations
> 
> 
> No.
> 
> --Michael Dillon
> 
> > Is there any interest in seeing this as a formal proposal after 
> > adding in the various adjustments some of you have suggested?
> > 
> > Regards,
> > Bill Herrin
> > 
> > 
> > On Sat, May 30, 2009 at 3:05 PM, William
> Herrin<bill at herrin.us> wrote:
> > > So here's a crazy plan:
> > >
> > > A. The first IPv6 allocation from ARIN is always a /48. To
> > justify it,
> > > you need to be multihomed. There are no other
> > qualifications. The /48
> > > will be allocated from a pool from which only /48's are allocated.
> > >
> > > B. The second IPv6 allocation from ARIN is always a /32. To
> > justify it
> > > you need to demonstrate that you've efficiently used the
> > /48 for some
> > > reasonable definition of efficient, that you've
> implemented SWIP or
> > > RWHOIS for your downstream assignments and that you will
> run out of
> > > space in the /48 within one year. The /32 will be
> allocated from a
> > > pool reserved for allocating /32's.
> > >
> > > C. The third IPv6 allocation from ARIN is always a /24. To
> > justify it
> > > you need to demonstrate that you've efficiently used the
> > /32, that you
> > > will run out of space in the /32 within five years, and
> you have to
> > > first return the original /48 you were assigned. The /24 will be 
> > > allocated from a pool reserved for allocating /24's.
> > >
> > > D. There is no fourth IPv6 allocation at this time. It is not 
> > > presently possible to consume an entire /24 without
> atrocious waste.
> > >
> > > What are the consequences of this plan?
> > >
> > > 1. Efficient allocation of IP addresses. Orgs get what they
> > need when
> > > they need it and not before without a great deal of
> guesswork about
> > > actual need.
> > >
> > > 2. Efficient utilization of BGP routing slots. No single
> multihomed
> > > org will ever announce more than 2 necessary routes.
> > >
> > > 3. Traffic engineering routes are trivially filterable
> > since any route
> > > longer than the published allocation size can be presumed to be 
> > > traffic engineering, not a downstream multihomed
> customer, thus you
> > > can filter distant small routes with confidence and ease.
> > >
> > > 4. No need to define the difference between ISP and not
> > ISP. Everybody
> > > plays by the same rules.
> > >
> > > 5. No complicated analysis for the first allocation. 
> You're either
> > > multihomed or you're not. If you're multihomed, you qualify.
> > >
> > > 6. For those who can live within the /48 there are distinct
> > > advantages: no swip or rwhois reporting and the generic end-user 
> > > annual fee instead of the ISP annual fee. Once you're up to
> > a /32, you
> > > pay the ISP annual fee. As a result, ARIN doesn't have to
> > scrutinize
> > > the /32 requests too closely either.
> > 
> > 
> > 
> > 
> > --
> > William D. Herrin ................ herrin at dirtside.com
> bill at herrin.us
> > 3005 Crane Dr. ...................... Web: 
> > <http://bill.herrin.us/> Falls Church, VA 22042-3004 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the 
> > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From ipgoddess.arin at gmail.com  Thu Jun  4 15:13:28 2009
From: ipgoddess.arin at gmail.com (Stacy Hughes)
Date: Thu, 4 Jun 2009 12:13:28 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A25A90B.5020804@bogus.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A25A90B.5020804@bogus.com>
Message-ID: <24c86a5f0906041213u6b82dce6r6f480f4a4e6bcac9@mail.gmail.com>

Joel wrote:
The fact of the matter is we've lived with scarcity so long it's
considered normal. Scarcity results expensive and undesirable behavior.
We don't have the play that game (with v6) anymore and we shouldn't make
our customers do it either.

Thank you, Joel - you've hit the nail on the head.Stacy

On Tue, Jun 2, 2009 at 3:34 PM, Joel Jaeggli <joelja at bogus.com> wrote:

>
>
> Davis, Terry L wrote:
> > Milton
> >
> > Agreed a /56 might be appropriate.
> >
> > Earlier Owen appropriately corrected me for comparing a /48 v6
> > allocation to a class B v4 allocation but he actually enforced the
> > point I was going to make.  Even a /48 allocation for small business
> > or individual use is a bit ridiculous given conventional IP network
> > architectures.  But one of our problems is that since we don't have
> > any truly large scale deployments (something at least into the 100K
> > nodes size), we don't know what a real IPv6 network may consume.
>
> Because you have not experienced one, does not mean that they do not exist.
>
> With something like 10 years operational experience behind us we do not
> have to treat a /48 assignment per end site as though it were
> "ridiculous", it is not. you can to assign residential customers
> something longer, fine, be aware they'll need more than a /64. It's
> pretty easy (just as it is in v4) to use 16 bits at a large site for the
> purposes of hierachical assignment, supernetting and so on.
>
> The fact of the matter is we've lived with scarcity so long it's
> considered normal. Scarcity results expensive and undesirable behavior.
> We don't have the play that game (with v6) anymore and we shouldn't make
> our customers do it either.
>
> > Take care Terry
> >
> >> -----Original Message----- From: arin-ppml-bounces at arin.net
> >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
> >> Sent: Saturday, May 30, 2009 2:49 PM To: Scott Leibrand; William
> >> Herrin Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] A modest
> >> proposal for IPv6 address allocations
> >>
> >>
> >>> -----Original Message----- Not sure about all the details, but I
> >>> like the fact that we'd be able to do away with the ISP/end-user
> >>> distinction, make it easy to get a /48, and provide a simple
> >>> growth path for the most common cases...
> >>>
> >>> -Scott
> >> Ditto.
> >>
> >> But, let me express (uncharacteristically) some concern about
> >> overly liberal initial allocations. (e.g., why not a /56?) From the
> >> standpoint of developing countries, there is some legitimate
> >> concern about reproducing the land rush phase of IPv4 address
> >> allocations (oops, there goes 1/3 of the space....)
> >> _______________________________________________ PPML You are
> >> receiving this message because you are subscribed to the ARIN
> >> Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or
> >> manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
> >> info at arin.net if you experience any issues.
> > _______________________________________________ PPML You are
> > receiving this message because you are subscribed to the ARIN Public
> > Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your
> > mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml Please contact
> > info at arin.net if you experience any issues.
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090604/bd4a294e/attachment.htm>

From sethm at rollernet.us  Thu Jun  4 16:15:48 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 04 Jun 2009 13:15:48 -0700
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A12@SUEX07-MBX-04.ad.syr.edu>
References: <4A27E68A.9050707@arin.net>	<4A27EE69.9020201@cisco.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
	<4A281640.6000603@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D77B220A12@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A282B74.3050807@rollernet.us>

Milton L Mueller wrote:
>> One could also say the sunset is a compromise between the two 
>> extremes. 
> 
> it's the kind of compromise that cuts the baby in half. 
> if folks can demonstrate real problems with transfers they should have no trouble re-opening the issue. 
> 
>> Arbitrary transfers are also arbitrary.
> 
> unassailable verbal logic (as are all tautologies), but I honestly don't get your point.
> 

You said a sunset was arbitrary; I'm saying 2009-1 was arbitrary too. I
also stopped reading the long thread it generated after a while of all
the back and forth, so maybe I missed something.

~Seth


From matthew at matthew.at  Thu Jun  4 16:17:50 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 04 Jun 2009 13:17:50 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A25A90B.5020804@bogus.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com><4A2184EA.7020708@gmail.com>	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A25A90B.5020804@bogus.com>
Message-ID: <4A282BEE.1050403@matthew.at>

Joel Jaeggli wrote:
>
> The fact of the matter is we've lived with scarcity so long it's
> considered normal. Scarcity results expensive and undesirable behavior.
> We don't have the play that game (with v6) anymore and we shouldn't make
> our customers do it either.
>   
This statement is not only accurate, but it applies equally well to the 
unreasonably high price of IPv6 space allocations.

Matthew Kaufman


From dogwallah at gmail.com  Thu Jun  4 16:55:08 2009
From: dogwallah at gmail.com (McTim)
Date: Thu, 4 Jun 2009 23:55:08 +0300
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A282BEE.1050403@matthew.at>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A25A90B.5020804@bogus.com> <4A282BEE.1050403@matthew.at>
Message-ID: <f65fb55e0906041355y2d0fe4c5u9712c366059086d9@mail.gmail.com>

On 6/4/09, Matthew Kaufman <matthew at matthew.at> wrote:
> >
> >
>  This statement is not only accurate, but it applies equally well to the
> unreasonably high price of IPv6 space allocations.

What's unreasonable about free (If you have v4 resources), or 75%
discount if you don't have any v4 (this year).

My reading of https://www.arin.net/fees/fee_schedule.html is that a
/32 will set you back a whopping $562.50.  Perhaps I've missed
something.

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


From farmer at umn.edu  Thu Jun  4 17:33:38 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 04 Jun 2009 16:33:38 -0500
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
	Transfer Policy
In-Reply-To: <4A27E68A.9050707@arin.net>
References: <4A27E68A.9050707@arin.net>
Message-ID: <4A27F762.30192.4B60CF6@farmer.umn.edu>

I am of mixed mind on this proposal.  I support this or a very similar proposal 
progressing to Draft Policy and being presented at ARIN XXIV this fall for 
discussion and consideration.  However, my current opinion is the transfer 
policy is better off without a sunset clause.  That said, I'm not strongly 
opposed to a sunset clause and don't think a well crafted Sunset Clause with 
a thoughtfully selected date to be a great detriment either.  

Let me explain in more detail;

2009-1 was initiated through the Emergency PDP clause of the PDP, and I 
believe this was correct for the board to do as this issue has progressed to 
the point where urgent action is necessary.  As such 2009-1 will be 
presented for review at ARIN XXIV this fall as well.  Therefore, I believe it is 
prudent and proper to present the counter proposal for the primary point of 
contention arising from the 2009-1 at the meeting as well.  In this way if the 
community's consensus were to be that a Sunset Clause should be restored 
another policy meeting cycle would not be necessary to implement the 
communities consensus.  

IPv4 exhaustion and the Transfer Policy debate are the most important 
issues that ARIN has dealt with since it was created by far.  Furthermore, 
2009-1 is the first time an emergency policy process has been used.  
Honestly, it is only the most important issues, which will always have some 
controversy surrounding them, that warrant the use of emergency powers.  
Therefore, it is very important how we settle the controversy surrounding 
emergencies, even if it has to be done after the fact because of the urgent 
nature of an emergency situation.    

Therefore, I ask all of us that support 2009-1 as it written, without the Sunset 
Clause, to think about being in the minority position of the next very 
important very urgent issue that results in a use of emergency powers and 
how you would like to see that controversy settled.

In that case, and in this one too, I would like the minority position to have the 
opportunity to fully express their opinion and directly place their best counter 
proposal in front of the community for discussion and consideration.  This is 
especially important when emergency powers are used, the emergency PDP 
changes the order from the normal process to having the full discussion and 
consideration after the policy is adopted.

So to summarize, I support this proposal moving forward to Draft Policy and 
to be brought to ARIN XXIV for discussion and consideration, while I do not 
support the ultimate policy objective of the proposal.  One way or another the 
removal of the Sunset Clause as part of 2009-1 is going to be discussed at 
ARIN XXIV.  I simply suggest we take the issue head-on through this 
proposal.

David Farmer

On 4 Jun 2009 Member Services wrote:

> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy
> Development Process.

...

> ## * ##
> 
> 
> Policy Proposal Name: Sunset Clause for Liberalized Transfer Policy
> 
> Proposal Originator: Owen DeLong
> 
> Proposal Version: 1.0
> 
> Date: 4 June 2009
> 
> Proposal type: delete
> 
> Policy term: permanent
> 
> Policy statement:
> 
> Section 8.3, "Transfers to Specified Recipients", of the NRPM is
> deleted upon the effective date of this policy.
> 
> Rationale:
> 
> When the community reached consensus in   support of 2008-6, it
> contained a sunset clause.   In the process of developing 2009-1, the
> sunset clause was removed. The effect of this policy proposal is to
> restore the sunset clause while adopting a more rational date at which
> to sunset the policy.
> 
> Timetable for implementation:
> 
> 31 December, 2013
> or
> 3 years after IANA issues the last /8s to the RIRs,
> whichever is later.
> 


===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From randy at psg.com  Thu Jun  4 19:01:49 2009
From: randy at psg.com (Randy Bush)
Date: Fri, 05 Jun 2009 08:01:49 +0900
Subject: [arin-ppml] Global Uniqueness vs Global Reachability
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F10484DA01540@ROCH-EXCH1.corp.pvt>
References: <4A26B8B7.22426.4B1F606@farmer.umn.edu>
	<20090604004558.GA81977@ussenterprise.ufp.org>
	<4A270384.13632.FD6998@farmer.umn.edu>
	<478AC5A9-9DAB-4FB9-A6B8-7BF47F597012@gmail.com>
	<g3iqjch43n.fsf@nsa.vix.com> <m2iqjcihqu.wl%randy@psg.com>
	<2E2FECEBAE57CC4BAACDE67638305F10484DA01540@ROCH-EXCH1.corp.pvt>
Message-ID: <m24ouviowy.wl%randy@psg.com>

> And that fear of leak in the dfz is why it didnt go anywhere at IETF.
> Last time it was debated there were more concerned about leak than the
> possible benefit users would have.

benefit to users?  nice rhetoric.  just use ipv6, damn it.

randy


From owen at delong.com  Thu Jun  4 19:32:24 2009
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Jun 2009 16:32:24 -0700
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
	Transfer Policy
In-Reply-To: <4A282B74.3050807@rollernet.us>
References: <4A27E68A.9050707@arin.net>	<4A27EE69.9020201@cisco.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
	<4A281640.6000603@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D77B220A12@SUEX07-MBX-04.ad.syr.edu>
	<4A282B74.3050807@rollernet.us>
Message-ID: <1B67EE63-FCF6-48ED-87E4-98B613D57B88@delong.com>

>
> You said a sunset was arbitrary; I'm saying 2009-1 was arbitrary  
> too. I
> also stopped reading the long thread it generated after a while of all
> the back and forth, so maybe I missed something.
>

2008-6 received community consensus and contained a sunset clause
with the anticipation that the BoT would not cause 2008-6 to take effect
until much closer to IANA exhaustion.

As a result of the board deciding on immediate implementation and the
creation of 2009-1 as an emergency policy by the BoT (and a great deal
of controversy that ensued), the decision was made to remove the sunset
included in 2008-6 from 2009-1 and to replace the language supplied
with 2008-6 using instead the language from 2009-1 as updated by the
advisory council.

While the advisory council removed the most egregious
changes introduced in the original 2009-1, they retained the removal
of the sunset clause because the 2008-6 sunset clause was specified
in terms of a date which no longer made sense.

This proposal is an effort to restore the original intent which gained
community consensus in 2008-6 and place a sunset on the policy.
It is true that the majority of people who support the sunset clause
are those of us who believe that a liberalized transfer policy probably
isn't in the community's best interest.  However, many of us supported
2008-6 in part because we felt the experiment may well be necessary
for a limited time. Nonetheless, that support depended on the fact that
absent clear community consensus to continue the policy, it would
be automatically retired.

The AC was not left with great alternatives when it came to the sunset
clause in 2008-6 and our discussion of 2009-1.  We could either remove
it (which we did), revise it (which did not have broad support and even
less agreement on what to change it to), or preserve it as is (which all
felt was far too early as a result of the unanticipated immediate
implementation by the board).

However, there was not a great deal of public input into whether to
retain the sunset clause or not, so, this policy proposal is an effort
to get that input.

Owen



From matthew at matthew.at  Thu Jun  4 19:47:35 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 04 Jun 2009 16:47:35 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <f65fb55e0906041355y2d0fe4c5u9712c366059086d9@mail.gmail.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>	<4A2184EA.7020708@gmail.com>	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>	<4A25A90B.5020804@bogus.com>
	<4A282BEE.1050403@matthew.at>
	<f65fb55e0906041355y2d0fe4c5u9712c366059086d9@mail.gmail.com>
Message-ID: <4A285D17.7060209@matthew.at>

McTim wrote:
>
> What's unreasonable about free (If you have v4 resources), or 75%
> discount if you don't have any v4 (this year).
>
> My reading of https://www.arin.net/fees/fee_schedule.html is that a
> /32 will set you back a whopping $562.50.  Perhaps I've missed
> something.
>
>   
Yes, you've missed something. That the cost of running a near-automated 
system for allocating address space is several orders of magnitude 
higher than $562.50/year, and certainly won't be going *up* over time as 
IPv6 rates will.

Matthew Kaufman


From matthew at matthew.at  Thu Jun  4 20:26:38 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 04 Jun 2009 17:26:38 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A285D17.7060209@matthew.at>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>	<4A2184EA.7020708@gmail.com>	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>	<4A25A90B.5020804@bogus.com>	<4A282BEE.1050403@matthew.at>	<f65fb55e0906041355y2d0fe4c5u9712c366059086d9@mail.gmail.com>
	<4A285D17.7060209@matthew.at>
Message-ID: <4A28663E.8090707@matthew.at>

Matthew Kaufman wrote:
> McTim wrote:
>>
>> What's unreasonable about free (If you have v4 resources), or 75%
>> discount if you don't have any v4 (this year).
>>
>> My reading of https://www.arin.net/fees/fee_schedule.html is that a
>> /32 will set you back a whopping $562.50.  Perhaps I've missed
>> something.
>>
>>   
> Yes, you've missed something. That the cost of running a 
> near-automated system for allocating address space is several orders 
> of magnitude higher than $562.50/year, and certainly won't be going 
> *up* over time as IPv6 rates will.
Lower, of course I meant.

The real point being that the cost of doing an allocation takes someone 
a short time to review the application for sanity. The cost of keeping 
an allocation in the database is about the cost of running the whois 
server and its backing database(s) on an ongoing basis, which is a lot 
lower than an ongoing $562-2250/year.

Why we've all bought into the illusion that ARIN and ICANN really need 
this much money to function, I don't know. Perhaps they do for IPv4 
allocations, where there's a lot less space and a lot more complaining, 
but IPv6 is just too easy for it to really cost this much.

Matthew Kaufman

Matthew Kaufman


From jmaimon at chl.com  Thu Jun  4 20:33:26 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 04 Jun 2009 20:33:26 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A25A90B.5020804@bogus.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com><4A2184EA.7020708@gmail.com>	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A25A90B.5020804@bogus.com>
Message-ID: <4A2867D6.5080802@chl.com>



Joel Jaeggli wrote:

> 
> The fact of the matter is we've lived with scarcity so long it's
> considered normal. Scarcity results expensive and undesirable behavior.
> We don't have the play that game (with v6) anymore and we shouldn't make
> our customers do it either.

While quite true, that doesnt mean we should go overboard in the 
opposite direction. That could have the ironic effect of causing the 
much later users to deal with similar scarcity issues as ones we have now.

Furthermore, global DFZ routing slots are not only still scarce (and 
expected to continue to be even more so), they are cumulatively 
expensive as well.

Giving all and sundry numerically indistinguishable space prevents 
practical filtering for those who would want to.

/32 with 65k /48 customers produces the result that while the customer 
will just about never need more, any SP that enjoys success will likely 
need more prefixes.

The prefixes that the SP gets are the ones going into the DFZ.

How many /48 customers will justify more space for an SP after initial 
allocation of /32?

How many /56?

As it stands, what SP should assign to customers are what they can use 
to justify more space, assuming they have no objections to obtaining it.

This applies equally to v4 as v6.

Joe













From sethm at rollernet.us  Thu Jun  4 20:34:44 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 04 Jun 2009 17:34:44 -0700
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <4A27E68A.9050707@arin.net>
References: <4A27E68A.9050707@arin.net>
Message-ID: <4A286824.2040809@rollernet.us>

Member Services wrote:
> 
> Policy Proposal Name: Sunset Clause for Liberalized Transfer Policy
> 
> Proposal Originator: Owen DeLong
> 
> Proposal Version: 1.0
> 
> Date: 4 June 2009
> 
> Proposal type: delete
> 
> Policy term: permanent
> 
> Policy statement:
> 
> Section 8.3, "Transfers to Specified Recipients", of the NRPM is
> deleted upon the effective date of this policy.
> 
> Rationale:
> 
> When the community reached consensus in   support of 2008-6, it
> contained a sunset clause.   In the process of developing 2009-1,
> the sunset clause was removed. The effect of this policy proposal is
> to restore the sunset clause while adopting a more rational date at
> which to sunset the policy.
> 
> Timetable for implementation:
> 
> 31 December, 2013
> or
> 3 years after IANA issues the last /8s to the RIRs,
> whichever is later.
> 


I SUPPORT this proposal.

~Seth


From jmaimon at chl.com  Thu Jun  4 20:37:22 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 04 Jun 2009 20:37:22 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <DE229826F48ABD4CBF754E5AA6CFC14B1DE263FD41@WP40044.corp.ads>
References: <3c3e3fca0906031056v1284040ao1d47765754dcf16a@mail.gmail.com>	<28E139F46D45AF49A31950F88C4974580178068F@E03MVZ2-UKDY.domain1.systemhost.net>	<75822E125BCB994F8446858C4B19F0D77B220A13@SUEX07-MBX-04.ad.syr.edu>
	<DE229826F48ABD4CBF754E5AA6CFC14B1DE263FD41@WP40044.corp.ads>
Message-ID: <4A2868C2.9060107@chl.com>



Matthew Wilder wrote:
> No, I am not interested in this proposal.

I think a proposal should be formulated, if for the only reason that we 
are already debating it.

> 
> This could be a catastrophic policy when paired with the ambiguity of 6.5.2.1 (Subsequent [IPv6] Allocation Criteria).  This section states:
> 
> "Subsequent allocation will be provided when an organization (ISP/LIR) satisfies the evaluation threshold of past address utilization in terms of the number of sites in units of /56 assignments."
> 
> If the majority of sites receive /48 assignments, I can only assume that would imply a 100% utilization of /56 assignments within that /48.  That in turn implies that any time you assign any subnet to a site (could be /40, maybe even /32) then that address block is 100% utilized as far as this criteria is concerned.  

This is a problem whether or not such a proposal exists, because if you 
can justify your utilization quicker with /48 per customer, you would be 
neglecting your own interests not to do so.


> 
> Adding the proposed policy into the mix with 6.5.2.1 could help a lot of organizations to get a /24 mighty fast.  I doubt that is the intention of the proposal, but any proposal needs to take loopholes and abuses into consideration.
> 
> Regards,
> Matthew Wilder
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller
> Sent: Thursday, June 04, 2009 11:50 AM
> To: ppml at arin.net
> Subject: Re: [arin-ppml] A modest proposal for IPv6 address allocations
> 
> Yes.
> 
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com
>> Sent: Wednesday, June 03, 2009 3:02 PM
>> To: ppml at arin.net
>> Subject: Re: [arin-ppml] A modest proposal for IPv6 address 
>> allocations
>>
>>
>> No.
>>
>> --Michael Dillon
>>
>>> Is there any interest in seeing this as a formal proposal after 
>>> adding in the various adjustments some of you have suggested?
>>>
>>> Regards,
>>> Bill Herrin
>>>
>>>
>>> On Sat, May 30, 2009 at 3:05 PM, William
>> Herrin<bill at herrin.us> wrote:
>>>> So here's a crazy plan:
>>>>
>>>> A. The first IPv6 allocation from ARIN is always a /48. To
>>> justify it,
>>>> you need to be multihomed. There are no other
>>> qualifications. The /48
>>>> will be allocated from a pool from which only /48's are allocated.
>>>>
>>>> B. The second IPv6 allocation from ARIN is always a /32. To
>>> justify it
>>>> you need to demonstrate that you've efficiently used the
>>> /48 for some
>>>> reasonable definition of efficient, that you've
>> implemented SWIP or
>>>> RWHOIS for your downstream assignments and that you will
>> run out of
>>>> space in the /48 within one year. The /32 will be
>> allocated from a
>>>> pool reserved for allocating /32's.
>>>>
>>>> C. The third IPv6 allocation from ARIN is always a /24. To
>>> justify it
>>>> you need to demonstrate that you've efficiently used the
>>> /32, that you
>>>> will run out of space in the /32 within five years, and
>> you have to
>>>> first return the original /48 you were assigned. The /24 will be 
>>>> allocated from a pool reserved for allocating /24's.
>>>>
>>>> D. There is no fourth IPv6 allocation at this time. It is not 
>>>> presently possible to consume an entire /24 without
>> atrocious waste.
>>>> What are the consequences of this plan?
>>>>
>>>> 1. Efficient allocation of IP addresses. Orgs get what they
>>> need when
>>>> they need it and not before without a great deal of
>> guesswork about
>>>> actual need.
>>>>
>>>> 2. Efficient utilization of BGP routing slots. No single
>> multihomed
>>>> org will ever announce more than 2 necessary routes.
>>>>
>>>> 3. Traffic engineering routes are trivially filterable
>>> since any route
>>>> longer than the published allocation size can be presumed to be 
>>>> traffic engineering, not a downstream multihomed
>> customer, thus you
>>>> can filter distant small routes with confidence and ease.
>>>>
>>>> 4. No need to define the difference between ISP and not
>>> ISP. Everybody
>>>> plays by the same rules.
>>>>
>>>> 5. No complicated analysis for the first allocation. 
>> You're either
>>>> multihomed or you're not. If you're multihomed, you qualify.
>>>>
>>>> 6. For those who can live within the /48 there are distinct
>>>> advantages: no swip or rwhois reporting and the generic end-user 
>>>> annual fee instead of the ISP annual fee. Once you're up to
>>> a /32, you
>>>> pay the ISP annual fee. As a result, ARIN doesn't have to
>>> scrutinize
>>>> the /32 requests too closely either.
>>>
>>>
>>>
>>> --
>>> William D. Herrin ................ herrin at dirtside.com
>> bill at herrin.us
>>> 3005 Crane Dr. ...................... Web: 
>>> <http://bill.herrin.us/> Falls Church, VA 22042-3004 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to the 
>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN 
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 


From mysidia at gmail.com  Thu Jun  4 20:34:34 2009
From: mysidia at gmail.com (James Hess)
Date: Thu, 4 Jun 2009 19:34:34 -0500
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <24c86a5f0906041213u6b82dce6r6f480f4a4e6bcac9@mail.gmail.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A25A90B.5020804@bogus.com>
	<24c86a5f0906041213u6b82dce6r6f480f4a4e6bcac9@mail.gmail.com>
Message-ID: <6eb799ab0906041734l31d8b35dtbd9d10259d3fd32@mail.gmail.com>

On Thu, Jun 4, 2009 at 2:13 PM, Stacy Hughes<ipgoddess.arin at gmail.com> wrote:
> Joel wrote:
> The fact of the matter is we've lived with scarcity so long it's
> considered normal. Scarcity results expensive and undesirable behavior.
> We don't have the play that game (with v6) anymore and we shouldn't make
> our customers do it either.

Abundance can also lead to expensive and undesirable behavior called
atrocious waste  which eventually leads to scarcity if  appropriate
constraints aren't utilized.

IPv6 is abundant, but it's not abundant enough  that the same scarcity
problem can't accidentally be created as with V4.

It's a  salient and justified fear, given the experience with IPv4.
Consider what happens if the expoential internet rate of growth over
the next 30 years expands in the manner it has in the past 30 years.

It's conceivable there could be a quintillion internet hosts before 2020.

And with V6, many of those would consume an end site.   If 1% of those
quintillion is a logically  end site that gets a /56, that's
13% of the IP space.

Also, a forgeone conclusion is major new uses of IP addresses; it's
the reason end sites get a /56,   so they can have multiple subnets.

It's conceivable V6 users could want more,  some may even be giving
end sites a /48  instead of a /56 or /64.
There must be some specialized app that really burns IPs for this


Well, there aren't enough  IPs  in the IPv6  address space  to assign
1% of those   10000000000000000 end sites  each a  /48,  so you have
exhaustion in that case.

--
-J


From spiffnolee at yahoo.com  Thu Jun  4 21:45:01 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Thu, 4 Jun 2009 18:45:01 -0700 (PDT)
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A28663E.8090707@matthew.at>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A25A90B.5020804@bogus.com> <4A282BEE.1050403@matthew.at>
	<f65fb55e0906041355y2d0fe4c5u9712c366059086d9@mail.gmail.com>
	<4A285D17.7060209@matthew.at> <4A28663E.8090707@matthew.at>
Message-ID: <355357.85112.qm@web63308.mail.re1.yahoo.com>



> The real point being that the cost of doing an allocation takes someone a short 
> time to review the application for sanity. The cost of keeping an allocation in 
> the database is about the cost of running the whois server and its backing 
> database(s) on an ongoing basis, which is a lot lower than an ongoing 
> $562-2250/year.

ARIN does a great deal more than maintaining a single instance of a whois server.
For instance, there are redundant servers.   IN-ADDR. and IP6.ARPA, redundantly.
There's research and development into improving the system (RPKI, DNSsec, for
instance).  There's educational work around IPv6.
There's this wonderful mailing list, which has recently broken all records for activity.
Since there is so much room for debate, there are the public policy meetings, and
paying attention to what the other RIRs are doing, and reaching out to people who
wonder what this IP stuff is and what it has to do with DNS or DRM.  There's
evolution of the website, and facilitating a public policy process that allows people
in the community to elect representatives to oversee and facilitate the policies, the
process, and the organization.  There's the threat of litigation if ARIN does 
something poorly, and members of organizations like the ITU who think they could
do it better.

And still, when we ask the members for guidance, we hear either indifference [1]
or that fees should be higher [2].

So I start to wonder, why are ARIN's fees so low?

> Why we've all bought into the illusion that ARIN and ICANN really need this much 
> money to function, I don't know. Perhaps they do for IPv4 allocations, where 
> there's a lot less space and a lot more complaining, but IPv6 is just too easy 
> for it to really cost this much.

We don't really know how much IPv6 will cost.  I don't imagine many of ARIN's 
expenses will decrease under IPv6.  If there were no more debate about allocation
policies, and nobody else had any interest in us (politically or litigiously), and 
technology were fairly static, then we might just do periodic tech refreshes and be
fine.  I imagine all of those things will continue for a while, though, and ARIN will
need to be financially solvent through the transition.[3]


Lee,
not-the-Treasurer


[1]
The thread on ARIN-discuss a while back: http://lists.arin.net/pipermail/arin-discuss/2009-April/001154.html

[2]
https://www.arin.net/participate/meetings/reports/ARIN_XXIII/mem_transcript.html#anchor_13
Search for where MR. CURRAN says, "I have a question that actually the Board 
tasked me with asking" and read from there.

[3] ARIN publishes its current budget and Annual Reports at https://www.arin.net/about_us/corp_docs.html

> 
> Matthew Kaufman
> 
> Matthew Kaufman
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



      



From petelists at templin.org  Thu Jun  4 22:45:05 2009
From: petelists at templin.org (Pete Templin)
Date: Thu, 04 Jun 2009 21:45:05 -0500
Subject: [arin-ppml] Policy Proposal: Sunset Clause for
 Liberalized	Transfer Policy
In-Reply-To: <1B67EE63-FCF6-48ED-87E4-98B613D57B88@delong.com>
References: <4A27E68A.9050707@arin.net>	<4A27EE69.9020201@cisco.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>	<4A281640.6000603@rollernet.us>	<75822E125BCB994F8446858C4B19F0D77B220A12@SUEX07-MBX-04.ad.syr.edu>	<4A282B74.3050807@rollernet.us>
	<1B67EE63-FCF6-48ED-87E4-98B613D57B88@delong.com>
Message-ID: <4A2886B1.7070808@templin.org>

Owen DeLong wrote:

> However, there was not a great deal of public input into whether to
> retain the sunset clause or not, so, this policy proposal is an effort
> to get that input.

And in the off-chance that my smart-aleck reply is lost in the the 
sauce, your wording NEEDS further clarification.  As it's written, the 
sun won't set until IANA is down to its last /8s of IPv6 space, and 
that's a long, long time away.

Pete



From jhg at omsys.com  Thu Jun  4 23:30:46 2009
From: jhg at omsys.com (Jeremy H. Griffith)
Date: Thu, 04 Jun 2009 20:30:46 -0700
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
	Transfer Policy
In-Reply-To: <4A27E68A.9050707@arin.net>
References: <4A27E68A.9050707@arin.net>
Message-ID: <i34h2511b8vrt4m8nqd2q1n2o3drji50jq@4ax.com>

On Thu, 04 Jun 2009 11:21:46 -0400, Member Services 
<info at arin.net> wrote:

>Timetable for implementation:
>
>31 December, 2013
>or
>3 years after IANA issues the last /8s to the RIRs,
>whichever is later.

I SUPPORT this proposal, provided that the language 
for the second condition is clarified to:

  3 years after IANA issues the last IPv4 /8s to the RIRs,

That's obviously the intent, but it doesn't say so.
So on the face of it, that would be the last /8 of
IPv6 or even IPv32... a few hundred years from now.  ;-)

--JHG <jhg at omsys.com>


From mysidia at gmail.com  Fri Jun  5 00:05:15 2009
From: mysidia at gmail.com (James Hess)
Date: Thu, 4 Jun 2009 23:05:15 -0500
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
	Transfer Policy
In-Reply-To: <i34h2511b8vrt4m8nqd2q1n2o3drji50jq@4ax.com>
References: <4A27E68A.9050707@arin.net>
	<i34h2511b8vrt4m8nqd2q1n2o3drji50jq@4ax.com>
Message-ID: <6eb799ab0906042105t360db6a9la7bfcda204f932fe@mail.gmail.com>

On Thu, Jun 4, 2009 at 10:30 PM, Jeremy H. Griffith<jhg at omsys.com> wrote:
[snip]

Would suggest just leaving it at  "31 December, 2013" Removing "3
years after IANA issues the last /8s to the RIRs, whichever is later."
  Because it seems like a bad idea to have a policy that tries to
automatically  make changes to the NRPM based on a dynamic event.

The arrival of a certain date is fairly unambiguous,  at most there
could be arguments about what timezone the change is measured in, and,
e.g. if a transfer request initiated 15 seconds after the sunset in
timezone X has to be rejected or not,  and if transfer requests that
were pending at the time also have to be rejected.

But IANA is an entity ARIN doesn't control; the exact moment the final
/8 is handed out might not be clear,  and advance warning may not be
available for actual planning and the review the Sunset is meant to
generate...



altogether.    It's just too vague and ambgiuous.
IANA might decide not to hand out what someone considers  "the last
/8", for some reason, e.g. they may decide to keep the final /8  to
make emergency or transitional assignments from later.   And there are
too many possibilities for the determination getting challenged.

e.g.  IANA allocates all the /8s  it plans to allocate,  someone will argue
that since IANA hasn't allocated  0.0.0.0/8  or other /8s it holds reserved,
that  there are some /8s that remain.



--
-J


From joelja at bogus.com  Fri Jun  5 02:46:12 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Thu, 04 Jun 2009 23:46:12 -0700
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <6eb799ab0906041734l31d8b35dtbd9d10259d3fd32@mail.gmail.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>	<4A2184EA.7020708@gmail.com>	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>	<4A25A90B.5020804@bogus.com>	<24c86a5f0906041213u6b82dce6r6f480f4a4e6bcac9@mail.gmail.com>
	<6eb799ab0906041734l31d8b35dtbd9d10259d3fd32@mail.gmail.com>
Message-ID: <4A28BF34.2060100@bogus.com>

James Hess wrote:
> IPv6 is abundant, but it's not abundant enough  that the same scarcity
> problem can't accidentally be created as with V4.

Good stewardship is why we're on this mailing list. We know that if you
give out a longer prefix than the number of subnets that someone will in
fact need over the sourse of their use of that prefix, that they have to
come back for more. That is the world we live in today. We pay a
signficant price for it in the size of both our interior, and dfz
routing tables, and in the onerousness of the allocation regime that we
live under. The same scarcity problem as v4 is rather hard to create, it
hard after-all to create a circumstance where you have to renumber out
of subnet because you ran out of addresses, all the other reasons to do
so still apply but 10^19 is frankly enough for now.

The IPNG working group saw clearly that while cidr would alleviate the
immediate pressure that there are costs associated with small (and
fragmented allocations) that are both local (I pay them when I manage
space) and collective (we all pay them due to fragementation).

> It's a  salient and justified fear, given the experience with IPv4.
> Consider what happens if the expoential internet rate of growth over
> the next 30 years expands in the manner it has in the past 30 years.
> 
> It's conceivable there could be a quintillion internet hosts before 2020.

10^18 is a lot of hosts . sticking to orders of magnitude, that's 10^8
per person in 10 years...

> And with V6, many of those would consume an end site.   If 1% of those
> quintillion is a logically  end site that gets a /56, that's
> 13% of the IP space.

1% of 10^18 is 10^16 so hey only a million end sites per person no big deal.

> Also, a forgeone conclusion is major new uses of IP addresses; it's
> the reason end sites get a /56,   so they can have multiple subnets.

If you consider nat translation the semantic equivalent if subdividing
your assigned v4 /32  and imposing a layer-3 boundry then in fact they
all subnet today so you don't exactly have to looking very far for an
application for subnetting.

> It's conceivable V6 users could want more,  some may even be giving
> end sites a /48  instead of a /56 or /64.
> There must be some specialized app that really burns IPs for this
> 
> 
> Well, there aren't enough  IPs  in the IPv6  address space  to assign
> 1% of those   10000000000000000 end sites  each a  /48,  so you have
> exhaustion in that case.

since your premise is flawed your conclusion is kind of hard to refute.

> --
> -J
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 


From michael.dillon at bt.com  Fri Jun  5 04:36:12 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 5 Jun 2009 09:36:12 +0100
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A282BEE.1050403@matthew.at>
Message-ID: <28E139F46D45AF49A31950F88C497458017E2326@E03MVZ2-UKDY.domain1.systemhost.net>

> This statement is not only accurate, but it applies equally 
> well to the unreasonably high price of IPv6 space allocations.

ARIN's fees are set by the ARIN membership and are generally
at a level needed to sustain ARIN as a stable organisation
but no more. If you are an ARIN member and don't like the
fee schedule, then you should go to the arin-discuss list
and raise the issue with your fellow members.

However, if you are just a member of the public interested
in influencing ARIN policy, then please note that you do
not have any say in ARIN's fee schedule. There ain't no 
such thing as a free lunch. If you don't cross my palm
with silver, then you're not worth my time. That free
advice was worth every penny I paid for it. Etc.

--Michael Dillon


From michael.dillon at bt.com  Fri Jun  5 04:51:11 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 5 Jun 2009 09:51:11 +0100
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <6eb799ab0906041734l31d8b35dtbd9d10259d3fd32@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C497458017E236C@E03MVZ2-UKDY.domain1.systemhost.net>

> IPv6 is abundant, but it's not abundant enough  that the same 
> scarcity problem can't accidentally be created as with V4.

Yes, IPv6 really is abundant enough that we cannot create the
same scarcity problem as we had with v4. You simply don't understand
the numbers involved if you believe otherwise.

> It's a  salient and justified fear, given the experience with IPv4.
> Consider what happens if the expoential internet rate of 
> growth over the next 30 years expands in the manner it has in 
> the past 30 years.

There's a little thing called the carrying capacity of the planet
that needs to be taken into consideration. IPv6 has enough addresses
to supply the needs of the entire planet, and the population can't
grow much bigger than it already has.

> It's conceivable there could be a quintillion internet hosts 
> before 2020.
> 
> And with V6, many of those would consume an end site.

You seriously misunderstand how big the world is, and how IPv6
works. Most Internet hosts will not consume and end site. On
a planet with 5 billion people, it is unlikely that there will
be more than 5 billion endsites.

> There must be some specialized app that really burns IPs for this

You haven't justified any of your claims. The only thing that will
burn up is the strawman that you have created.

--Michael Dillon


From bmanning at vacation.karoshi.com  Fri Jun  5 04:56:04 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 5 Jun 2009 08:56:04 +0000
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <28E139F46D45AF49A31950F88C497458017E236C@E03MVZ2-UKDY.domain1.systemhost.net>
References: <6eb799ab0906041734l31d8b35dtbd9d10259d3fd32@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458017E236C@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20090605085604.GA4646@vacation.karoshi.com.>

On Fri, Jun 05, 2009 at 09:51:11AM +0100, michael.dillon at bt.com wrote:


	Yo Michael, when you quote somebody, please provide
	attribution.


> > It's conceivable there could be a quintillion internet hosts 
> > before 2020.
> > 
> > And with V6, many of those would consume an end site.
> 
> You seriously misunderstand how big the world is, and how IPv6
> works. Most Internet hosts will not consume and end site. On
> a planet with 5 billion people, it is unlikely that there will
> be more than 5 billion endsites.
> 
> --Michael Dillon

	why do you think that address consumption is related to
	the number of people?  as a referent, check out the 
	"Internet of Things" ((IOT)) stuff.

--bill


From michael.dillon at bt.com  Fri Jun  5 06:19:36 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 5 Jun 2009 11:19:36 +0100
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <20090605085604.GA4646@vacation.karoshi.com.>
Message-ID: <28E139F46D45AF49A31950F88C497458017E25ED@E03MVZ2-UKDY.domain1.systemhost.net>

> 	why do you think that address consumption is related to
> 	the number of people?  as a referent, check out the 
> 	"Internet of Things" ((IOT)) stuff.

The number of end-sites is roughly related to the number
of people, i.e. with a population of 5 billion, there are
unlikely to be more than 5 billion endsites. At any given
site there could be hundreds of thousands of devices/things
but that won't consume any more prefixes than a single PC.
We don't count IPv6 addresses, we count subnets and
endsite allocations.

Anything like a business premises or a cellphone tower
is a piece of infrastructure that serves a large number
of people, therefore it is hard to see how the number 
of these sites could be any significant proportion of 
the total population. 

--Michael Dillon


From bmanning at vacation.karoshi.com  Fri Jun  5 06:52:36 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 5 Jun 2009 10:52:36 +0000
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <28E139F46D45AF49A31950F88C497458017E25ED@E03MVZ2-UKDY.domain1.systemhost.net>
References: <20090605085604.GA4646@vacation.karoshi.com.>
	<28E139F46D45AF49A31950F88C497458017E25ED@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <20090605105236.GA5124@vacation.karoshi.com.>

 again Michael, please reconsider yoru bad habit of removing attribution.
 do that, and I might reconsider top posting.
 


On Fri, Jun 05, 2009 at 11:19:36AM +0100, michael.dillon at bt.com wrote:
> > 	why do you think that address consumption is related to
> > 	the number of people?  as a referent, check out the 
> > 	"Internet of Things" ((IOT)) stuff.
> 
> The number of end-sites is roughly related to the number
> of people, i.e. with a population of 5 billion, there are
> unlikely to be more than 5 billion endsites. 

	you keep saying that.  on what basis to you make that 
	claim. 


> At any given
> site there could be hundreds of thousands of devices/things
> but that won't consume any more prefixes than a single PC.

	and your reason for this claim is....


> We don't count IPv6 addresses, we count subnets and
> endsite allocations.

	ok... "We" count IPv6 prefixes.  like the prefix
	that is only the top 64bits of the total 128bit
	address.  Or are you coming up with a novel definition
	of "prefix" here

> Anything like a business premises or a cellphone tower
> is a piece of infrastructure that serves a large number
> of people, therefore it is hard to see how the number 
> of these sites could be any significant proportion of 
> the total population. 

	assume.. as a thought experiment, that you have a car.
	the car has the brand - YUGO -...  but I'd be willing to
	wager that the YUGO car company outsources most of the 
	parts production to others.  As an assembled thing, your
	YUGO might get an IPv6 prefix assigned to it so that 
	your car can talk to the road sensors, toll road counters,
	the police vehicles etc.  are you ok with that?

	Now Bill Manning also says (remember to include attribution
	in your replies...) that it is likely that the SLIPSHOD
	brake company has is brake subassemblies in your YUGO.
	It has no desire or requirement to talk to the rest of 
	your car, but it does want to track where all its brake
	subassemblies  are, when the inevitable recall occurs.

	So the SLIPSHOD brake company has given its subassemblies 
	their own IPv6 addresses/prefix to each subassembly.  Hum...
	What just happened?  The car unit and its various components
	have multiple prefixes assigned, perhaps based on manufacturing
	sources.   As you decompose the car into its assemblies and 
	subassemblies, you just might find discontigious and overlaping
	IPv6 subnets.

	Bill Manning sez (remember to include attribution in your
	replies) that this is just one possible example of how the
	IOT is only marginally related/associated with the number
	of humans.

> 
> --Michael Dillon

--bill (who leaves Michaels attributions in place)


From michael.dillon at bt.com  Fri Jun  5 07:01:40 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 5 Jun 2009 12:01:40 +0100
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <20090605105236.GA5124@vacation.karoshi.com.>
Message-ID: <28E139F46D45AF49A31950F88C497458017E26EF@E03MVZ2-UKDY.domain1.systemhost.net>

>    that it is likely that the SLIPSHOD
> 	brake company has is brake subassemblies in your YUGO.
> 	It has no desire or requirement to talk to the rest of 
> 	your car, but it does want to track where all its brake
> 	subassemblies  are, when the inevitable recall occurs.
> 
> 	So the SLIPSHOD brake company has given its subassemblies 
> 	their own IPv6 addresses/prefix to each subassembly.  Hum...
> 	What just happened? 

SLIPSHOD just did a dumb thing. They assumed that just because
a device has an IP address, it also has IP connectivity, and
that connectivity allows this device to communicate to the 
mothership. In fact, this problem is already solved with
databases, recordkeeping processes, and the occasional RFID
tag in the factory.

> that this is just one possible example of how the
> 	IOT is only marginally related/associated with the number
> 	of humans.

Anybody can repurpose IPv6 addresses to use as numeric tags
for things. But that doesn't mean that those things will
be able to use the addresses to communicate. Like my cellphone,
for instance. It has a UK phone number, but when I travel to
the USA, it uses a US phone number assigned by the US
cellular operator in order to communicate. I never see that
number, but it is there under the hood and it is what enables
the voice packets to get from point A to point B. 

--Michael Dillon

(who talks about ideas and not about the people who 
own them, or claim to own them)



From schnizlein at isoc.org  Fri Jun  5 09:04:15 2009
From: schnizlein at isoc.org (John Schnizlein)
Date: Fri, 5 Jun 2009 09:04:15 -0400
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
	Transfer Policy
In-Reply-To: <1B67EE63-FCF6-48ED-87E4-98B613D57B88@delong.com>
References: <4A27E68A.9050707@arin.net>	<4A27EE69.9020201@cisco.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
	<4A281640.6000603@rollernet.us>
	<75822E125BCB994F8446858C4B19F0D77B220A12@SUEX07-MBX-04.ad.syr.edu>
	<4A282B74.3050807@rollernet.us>
	<1B67EE63-FCF6-48ED-87E4-98B613D57B88@delong.com>
Message-ID: <8ED81170-2550-4BC5-9F94-9CC72120FFA9@isoc.org>


On 2009Jun4, at 7:32 PM, Owen DeLong wrote:
>
> This proposal is an effort to restore the original intent which gained
> community consensus in 2008-6 and place a sunset on the policy.
> ...
>
> However, there was not a great deal of public input into whether to
> retain the sunset clause or not, so, this policy proposal is an effort
> to get that input.

There was a survey (which looks like public input to me).  It is  
possible that opinions have changed, but that survey when many people  
wer engaged in the discussion of transfer policy should probably have  
more weight than a few responses on the list now.

On 2009Apr7, at 12:06 PM, John Schnizlein wrote:
> ...
>
> On the subject of sunset (expiration of the policy) there was
> contention with 44.5% in favor and 55.5% against.

John


From tedm at ipinc.net  Fri Jun  5 12:59:11 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Jun 2009 09:59:11 -0700
Subject: [arin-ppml] Policy Proposal: Sunset Clause for
 Liberalized	Transfer Policy
In-Reply-To: <8ED81170-2550-4BC5-9F94-9CC72120FFA9@isoc.org>
References: <4A27E68A.9050707@arin.net>	<4A27EE69.9020201@cisco.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>	<4A281640.6000603@rollernet.us>	<75822E125BCB994F8446858C4B19F0D77B220A12@SUEX07-MBX-04.ad.syr.edu>	<4A282B74.3050807@rollernet.us>	<1B67EE63-FCF6-48ED-87E4-98B613D57B88@delong.com>
	<8ED81170-2550-4BC5-9F94-9CC72120FFA9@isoc.org>
Message-ID: <4A294EDF.7090108@ipinc.net>

John Schnizlein wrote:
> 
> There was a survey (which looks like public input to me).  It is 
> possible that opinions have changed, but that survey when many people 
> wer engaged in the discussion of transfer policy should probably have 
> more weight than a few responses on the list now.
> 

I disagree.  The survey is dated and people's opinions could have changed.

Your argument is kind of like the US should have a Republican President
in the White House today because there were 2 surveys taken in 2000
and 2004 and a Republican president was selected then.

Ted


From tedm at ipinc.net  Fri Jun  5 13:01:21 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Jun 2009 10:01:21 -0700
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <4A2805B2.3040801@templin.org>
References: <4A27E68A.9050707@arin.net> <4A2805B2.3040801@templin.org>
Message-ID: <4A294F61.6050809@ipinc.net>

Pete Templin wrote:
> 
> If you'd like a rational date at which to sunset the policy, you might 
> want to tune up this timetable language significantly.  It's going to be 
> a long, long time 

your opinion, only.

> before IANA issues the last /8s to the RIRs.
> 

There is plenty of time before the sunset clause comes into effect for
an additional policy proposal to be put in that extends the sunset
clause date.

Ted


From tedm at ipinc.net  Fri Jun  5 13:23:55 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Jun 2009 10:23:55 -0700
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
References: <4A27E68A.9050707@arin.net>
	<4A27EE69.9020201@cisco.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>
	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A2954AB.7060008@ipinc.net>

Milton L Mueller wrote:
>> Having a sunset date will ensure that the issue is reviewed when the sunset date approaches.  The lack 
>> of data is actually a driver for this proposal.
> 
> I disagree with Kevin and oppose Owen's proposal. The sunset is inherently arbitrary and therefore potentially disruptive. As was established long ago in list discussions, it is mainly supported by people who don't want there to be a transfer policy in the first place. 
> 

Comments like these do nothing to help heal the wounds caused
by the action of removing the sunset, and merely serve to insult people 
who take a much more considered view of the transfer situation.

We had a minority of people who wanted an unrestricted transfer policy.

We also had a minority of people who absolutely opposed a transfer policy.

And we had a minority of people willing to have a RESTRICTED transfer 
policy.

As a result of this, while each of the groups wanted something, only the 
group opposed to a transfer policy was getting what they wanted - ie: 
continuation of the status quo.

Basically what happened here is the minority who were pro-transfer 
managed to pull a con job on the minority of people who wanted a 
transfer policy with restrictions, by dangling the sunset clause.  In 
that way people such as yourself were able to create a majority of 
people to support the transfer policy WITH a sunset clause, to get it 
made policy.

Then once the minority who wanted an unrestricted transfer policy in 
place got what they wanted, they turned around and pulled down the pants 
of the group who wanted a restriction on the transfer policy - and 
deleted the sunset clause.

Now you have the unmitigated gall to claim that the group who wanted a 
sunsetted transfer policy really didn't want that, in reality they 
wanted an unrestricted transfer policy all along.

Speak for yourself, Milton.  I was in the compromise group precisely 
because the transfer policy had a sunset.  My opinion has not changed 
just because you pulled my pants down and got the restriction removed.

I'm sure you and the rest of the unrestricted transfer people are 
laughing up your sleeve and patting yourself on the back at how smart 
you are.  Fine, you won this round.  Crow about it and make yourself 
feel good.

But, here is the cost - people like you have pretty much polarized the 
policy proposal process.  You got want you wanted today, at the cost of 
much future progress on policy proposals.  In the future, only very 
non-controversial proposals are going to pass, because neither
side is going to be willing to compromise with the other side on the 
controversial ones.

So the next time a policy proposal YOU want to pass comes up, you better 
darn well hope it's not controversial in the least - because if it is, 
your not going to get it.

If you want to unpolarize the process then I suggest you be silent on 
the attempt to re institute the sunset clause.  You got what you wanted, 
that should be enough.  No need to grind the people into the ground who 
are trying to heal the wound.

Ted


From info at arin.net  Fri Jun  5 13:36:18 2009
From: info at arin.net (Member Services)
Date: Fri, 05 Jun 2009 13:36:18 -0400
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
Message-ID: <4A295792.3040807@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at:https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


1. Policy Proposal Name: A Modest Proposal for an Alternate IPv6
Allocation Process

2. Proposal Originator: William Herrin

3. Proposal Version: 1.0

4. Date: 5 June 2009

5. Proposal type: new

6. Policy term: See 6.11.7 below.

7. Policy statement:

Add section 6.11 as follows:

6.11 Alternate IPv6 allocation process

Section 6.11 offers an alternative to the address assignment process
laid out in sections 6.5 and 6.10. Except where explicitly mentioned,
no elements of the process here are binding on the process in those
sections and vice versa.

6.11.1 ARIN pools used for allocation.

ARIN shall reserve 3 pools of IPv6 addresses for the purpose of
address allocation under section 6.11.

The first pool shall be used solely for making /48 allocations. ARIN
will make no larger or smaller allocations from this pool.

The second pool shall be used solely for making /32 allocations. ARIN
will make no larger or smaller allocations from this pool.

The third pool shall be used solely for making /24 allocations. ARIN
will make no larger or smaller allocations from this pool.

ARIN shall publish the locations of these pool such that folks
operating routers in the Internet Default-Free Zone can filter route
announcements based on these published sizes if they so choose.


6.11.2 Initial allocation

6.11.2.1 Initial allocation criteria

To qualify for an initial allocation of IPv6 address space, an
organization must:

a. Be multihomed in the ARIN region with at least two different
Internet Service Providers, both of whom agree to propagate the
organization's IPv6 prefix into the Internet Default-Free Zone.

b. Have already obtained an Autonomous System Number.

c. Do not already hold a /48 or shorter IPv6 allocation from ARIN
under any current or prior policy.

d. If requesting a /32, hold at least a /18 of IPv4 addresses

e. If requesting a /32, have implemented either SWIP or RWHOIS for all
IPv4 allocations /28 or shorter.

6.11.2.2 Initial allocation size

If requested, a /32 from the pool reserved for assigning /32's.
Otherwise a /48 from the pool reserved for assigning /48's.


6.11.3 Extra /32 allocation

Organizations which hold a /48 from ARIN are eligible for an
additional /32 allocation from the pool reserved for /32 allocations
if they:

a. Demonstrate that they continue to meet the qualifications for the
/48 assignment.

b. Do not already hold a /32 or shorter allocation from ARIN under any
current or prior policy.

c. Plan to provide IPv6 service such that they will run out of space
in the /48 within one year of making the second application.

d. Have implemented either SWIP or RWHOIS for all downstream
allocations shorter than /64.

e. Agree to return all ARIN allocations longer than /33 except for one
/48 allocation to ARIN within one year of receiving the /32
allocation. Although 6.11.2 permits only one /48 allocation to an
organization (hence no need to return anything), they may hold more
than one due to mergers, acquisitions, policy changes, etc. These
extras must be removed from the DFZ BGP table and returned to ARIN
once a /32 is assigned.


6.11.4 Extra /24 allocation

Organizations which hold a /32 from ARIN are eligible for an
additional /24 allocation from the pool reserved for /24 allocations
if they:

a. Demonstrate that they continue to meet the qualifications for the
/32 assignment.

b. Do not already hold a /24 or shorter allocation from ARIN under any
current or prior policy.

c. Plan to provide downstream IPv6 service with address space such
that they will run out of space within the /32 within two years of
making the third application.

d. Return all /33 or longer allocations to ARIN prior to making the
/24 application.

e. Agree to return all allocations longer than /25 except for one /32
allocation to ARIN within one year of receiving the /24 allocation.


6.11.5 Additional allocations

No additional allocation beyond the single /24 is contemplated for a
single organization at this time. No known usage pattern could require
more than a /24 of IPv6 address space without egregious waste.


6.11.6 Advice to multihomed users

ARIN advises multihomed end-users that section 6.11 has been
intentionally crafted to enable folks operating routers in the
Internet Default-Free Zone to filter out route announcements longer
than /48 within the /48 pool, longer than /32 within the /32 pool and
longer than /24 within the /24 pool. Accordingly, it is probable that
addresses assigned by an ISP instead of by ARIN will only be usable
with that one ISP.


6.11.7 Policy term and re-evaluation

Three years from policy implementation, ARIN staff and the ARIN
advisory council shall separately review the efficacy of address
allocations made under both section 6.11 and sections 6.5 plus 6.10.
Each shall recommend to the ARIN Board of Trustees that either 6.11 or
both 6.5 and 6.10 be struck from the NRPM. The board shall review the
recommendations and either strike section 6.11, strike both sections
6.5 and 6.10, or take no action, retaining both policies.



8. Rationale:

The IPv6 allocation policy under section 6.5 makes a number of
unproven assumptions about how IPv6 will work.

Unproven: we can make a reasonable guess about how many IPv6 subnets
an organization will need at the outset when they first request IP
addresses. When in all of human history has this ever proven true of
any resource?

Unproven: with sparse allocation, we can allow organizations to expand
by just changing their subnet mask so that they don't have to announce
additional routes into the DFZ. This claim is questionable. With
sparse allocation, we either consume much larger blocks that what we
assign (so why not just assign the larger block?) or else we don't
consume them in which case the org either has to renumber to expand or
he has to announce a second route. Worse, because routes of various
sizes are all scattered inside the same address pool, its impractical
to detect or filter out the traffic engineering routes.

Unproven: we can force organizations not to disaggregate for traffic
engineering purposes. Neither any of our experience with IPv4 nor any
of the research in the IRTF Routing Research Group suggests that this
is even remotely practical so long as BGP or any similar system rules
the roost.

Unproven: all non-ISPs can be reasonably expected to get their address
space from ISPs instead of from ARIN. We can certainly operate that
way, but it could prove deadly to the routing table. Any organization
mutlihomed between two ISPs will need to announce that route via BGP,
regardless of where they get the address space from. We have knobs and
dials in the routers that let us easily filter disagregates from
distant announcements, but we don't dare do so if there is a
possibility that one of those disaggregates is a multihomed customer
rather than traffic engineering.

Benefits of this proposal:

A. Efficient allocation of IP addresses. Orgs get what they need when
they need it and not before without a great deal of guesswork trying
to define that need.

B. Efficient utilization of BGP routing slots. Few multihomed orgs
will ever announce more than two unfilterable routes.

C. Traffic engineering routes are trivially filterable. Any route
longer than the published allocation size can be presumed to be
traffic engineering, not a downstream multihomed customer, thus you
can filter distant small routes with confidence and ease.

D. Fair. No need to define the difference between ISP and not ISP.
Everybody plays by the same rules.

E. No complicated analysis for the first allocation. You're either
multihomed or you're not. If you're multihomed, you qualify.

F. For those who can live within the /48 there are distinct
advantages: no swip or rwhois reporting and the generic end-user
annual fee instead of the ISP annual fee. Once you're up to a /32, you
pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize
the /32 requests too closely either.

G. No disruption to the prior IPv6 allocation policy until this new
one proves itself.


FAQ

Q. Isn't this classful addressing all over again?

A. Yes, with a twist. Now you have to fully use a class C before you
can get a class B and fully use a class B before you can get a class
A. And by the way, there are potentially 16 million class A's, not a
mere 200.

Classful addressing had a lot of virtues with respect to route
filtering and management. We had to abandon it because there weren't
enough B's for everyone who needed more than one C and there weren't
enough A's period. With IPv6, we don't have that problem. Not yet and
maybe not ever. Perhaps we can have our cake and eat it too.


Q. Why prevent single-homed users from getting ARIN addresses?

A. Any IPv6 allocation from ARIN must be announced into the Internet
DFZ via BGP in order to use it on the Internet. That costs a lot of
money, more than $10k per year according to
http://bill.herrin.us/network/bgpcost.html   Worse, it spends other
people's money: no practical system exists for recovering the cost of
a consumed routing slot from the folks who announced the route.

If you don't get an allocation from ARIN then you have to renumber in
order to change ISPs. That can cost a lot of money too. Sometimes far
more than $10k. But it spends only your money, not somebody else's.

Finally there's the technical consideration: regardless of who assigns
the addresses, a multihomed system must announce a route into the DFZ.
That's the way BGP works and we're stuck with it for at least another
decade. So why not let the multihomed org get his IP addresses from
ARIN? By contrast, a single-homed system works just fine with its
addresses aggregated inside the shorter route announced by its ISP.


Q. If it's so expensive to announce routes into the DFZ, why not use
something better than BGP?

A. Last year the IRTF Routing Research Group compiled an exhaustive
study attempting to identify the possible ways to improve the routing
system. A draft of the results is at
http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While
there are many promising ideas for how to replace BGP with something
that scales better, we're at least a decade away and probably more
from any significant deployment of a BGP replacement.


Q. Is it really true that multihoming requires announcing a route via BGP?

A. The short answer is yes, its true. The long answer is more complicated.

Folks have tried very hard to devise multi-vendor multihomed systems
which don't rely on BGP. Some even work OK for networks containing no
Internet servers.

The only non-BGP approach that has ever come close to success for a
system that hosts Internet servers is dynamically changing DNS records
to favor the currently working Internet connection. "Close" is a
relative term here. Such network architectures are enormously complex
and they don't work for a useful definition of "work." The DNS
protocol itself supports quick changes but the applications which use
it often don't. It takes hours to achieve two-nines recovery from an
address change in the DNS and it takes months to achieve five-nines
recovery. Web browsers, for example, don't immediately recover. Search
google for "DNS Pinning."


Q. Why allocate the /48's from a pool only for /48's, /32's from a /32
pool, etc.? Why not allocate from just one pool?

A. If all assignments in a particular pool are /32 and all multihomed
entities get their IP addresses directly from ARIN then any route in
the /32 pool which is longer than /32 is a traffic engineering route.
As a router operator you can filter and discard a traffic engineering
routes if you find they give you insufficient benefit. The routes you
filter don't cost you any money; only the routes you keep carry a
price tag.

You can only filter if you're sure they're traffic engineering
routes... If they're downstream customer routes and you filter them,
there goes the Internet. Or at least there goes your part of it. See
customers. See customers run... straight to your competitor. Setting
up the distinct pools makes it practical to know for certain that the
routes you're filtering are only for TE.


Q. Why make folks return all but one /48 to get a /32 and all but one
/32 to get a /24?

A. Without the address scarcity issue which drives IPv4 policy, the
primary criteria for IPv6 addressing policy is suppressing the route
count in the IPv6 DFZ. Such a criteria is not well served if an
organization holds dozens of discontiguous address spaces as a result
of acquisitions, mergers and the like. With the return policy in
place, organizations will generally only announce one or two primary
routes, routes necessary for the correct operation of the Internet.
Any other announced routes will be for traffic engineering. Because of
the segregated pools from which the allocations come, those traffic
engineering routes can be filtered by anyone who gains insufficient
advantage from them without harming the Internet as a whole.

The return policy does require some renumbering activity. However,
with only modest planning on the registrant's part, the policy is
flexible enough to allow that renumbering to occur over a long period
of time so that both cost and disruption are minimized. In many cases,
customer churn can be expected to take care of much of the renumbering
activity all by itself.


Q. What if the first allocation from the /48 is a /48?

A. RFC 3177 recommends that downstream customers receive a /48
assignment by default. Obviously there's a mismatch here if the ARIN
allocation is also a /48.

The short version is that RFC 3177 is not the gospel truth. It's based
on the IPv6 allocation model embodied in ARIN policy section 6.5 where
we try very hard to assign all the addresses you'll ever need up front
so that you only ever use one routing slot. This proposal attempts to
slow-start IPv6 allocations instead, while still maintaining the
principle of suppressing the routing table size. With a /48 allocation
under this proposal, consider implementing a slow start for your
downstream customers as well: Give them a /60 initially, add a /56
when they need it and add a /52 when they run out of the /56. There
are 16 /52's in your /48, or 4000 /60's. Plenty to get started. And a
/60 is 16 /64 subnets. That's an internal LAN, a DMZ and 14 more
subnets.


Q. What happens when organizations merge or split?

A. Entities which merge will want to renumber out of and return one of
the allocations so that they don't run into grief when they go to get
the next larger allocation from ARIN. If done gradually, this should
be a minor hardship.

Entities which split have a bigger problem since only one of them can
keep the addresses. To a large extent, that problem already exists and
is a pain in the rump for IPv4 operations today. This policy doesn't
solve it but it doesn't make it a whole lot worse either. Because
disaggregates are expected to be filtered, this IPv6 policy does gives
us a slightly better guarantee that the rest of us won't get stuck
with the check (in the form of routing slot consumption) when an ISP
goes bankrupt and gets split up.


Q. Why allow folks announcing IPv4 /18's to jump straight to a /32?

A. We're not really starting from scratch here and there are plenty of
IPv6 addresses. Why make extra useless work for large ISPs who -are-
going to use more than a /48? There are far fewer than 30k orgs
holding /18s. How much grief should we cause them in order to save at
most one whole /25?


Q. Why not just replace section 6.5 instead of running this allocation
system in parallel?

A. The most experienced user of IPv6 still has only a fraction of the
experience that we have with IPv4. Yet the network operating model
proposed by the IETF is radically different than the IPv4 model. The
author believes that the IETF recommendation is based on an errant
operating model, but he respects those who believe otherwise. The
author also believes that competition is a good thing and history
backs up this claim. Since little long term harm can come from briefly
running both systems in parallel, allowing them to compete directly
will result in the selection of the superior system.


Q. You've covered multihomed and single-homed. What about IPv6
addresses for uses which will not be connected to the Internet at all?

A. "ULA Central" or an idea like it is not addressed in this policy
proposal. If desired, it should probably be implemented in a separate,
parallel policy. The author observes that all of 2002:0a00::/24 is
available for your offline use and there are plenty of others if you
don't like that one.


Implementation notes:

Initially, ARIN may want to use sparse allocation inside each of the
three reserved pools until the policies are re-evaluated in three
years. That way if section 6.11 is retired in favor of section 6.5,
the 6.11 assignments may be able to grow by changing the netmask as
intended in section 6.5. If 6.11 is retained, sparse allocation should
cease.

Because IPv6 addresses are plentiful and the largest possible
allocation under this policy is /24, the author recommends against
explicit criteria for efficiency at this time. Instead, ARIN should
consider selecting a fee schedule for /48, /32 and /24 allocations
which discourages asking for more addresses than are really needed.
Something along the lines of $100, $10k and $100k per year
respectively might do nicely.

Under this proposal there is no difference whatsoever between an
allocation and an assignment. The two words should be treated as
synonyms.


9. Timetable for implementation: immediate; re-evaluate in 3 years




From lear at cisco.com  Fri Jun  5 13:53:47 2009
From: lear at cisco.com (Eliot Lear)
Date: Fri, 05 Jun 2009 19:53:47 +0200
Subject: [arin-ppml] Policy Proposal: Sunset Clause for
 Liberalized	Transfer Policy
In-Reply-To: <4A294EDF.7090108@ipinc.net>
References: <4A27E68A.9050707@arin.net>	<4A27EE69.9020201@cisco.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>	<4A281640.6000603@rollernet.us>	<75822E125BCB994F8446858C4B19F0D77B220A12@SUEX07-MBX-04.ad.syr.edu>	<4A282B74.3050807@rollernet.us>	<1B67EE63-FCF6-48ED-87E4-98B613D57B88@delong.com>	<8ED81170-2550-4BC5-9F94-9CC72120FFA9@isoc.org>
	<4A294EDF.7090108@ipinc.net>
Message-ID: <4A295BAB.1090700@cisco.com>

On 6/5/09 6:59 PM, Ted Mittelstaedt wrote:
>
> I disagree.  The survey is dated and people's opinions could have 
> changed.

Ok, but since April?

Eliot



From tedm at ipinc.net  Fri Jun  5 14:06:32 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Jun 2009 11:06:32 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A295792.3040807@arin.net>
References: <4A295792.3040807@arin.net>
Message-ID: <4A295EA8.1060103@ipinc.net>

I have a comment/question on this..

It appears the central rationale for this policy assumes that most 
people are going to want to filter incoming BGP announcements, 
presumably because the BGP table is going to grow rapidly and they will 
otherwise run out of ram in their routers.  Is this assumption realistic?

VISA and MasterCard corporation have devised systems that can handle
hundreds of millions of non-contiguous credit card numbers coming in for 
approvals, from every corner of the globe.  I therefore have an 
extremely difficult time believing that it is impossible to build a 
router that cannot handle, say, 10 or 20 million BGP routes.  I also 
have a difficult time believing that this cannot be done for the $50K to
$100K that Cisco and Juniper seem to think they can charge for a
fully-optioned BGP router.

Today I can walk into the discount store and by a brand new PC with 2GB 
of ram for under $350.  Yet, Cisco and Juniper are still including as
standard ram amounts, miserable, paltry amounts far smaller than that.

My gut feeling here is that the router vendors could EASILY and CHEAPLY
and QUICKLY greatly expand the capacity of their products IF demand 
called for it - thus removing the need for filtering.

Is this an accurate assessment?  Or is there really some reason that a
router cannot be built with more ram than a half gig?

Ted


Member Services wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.
> 
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> 1. Policy Proposal Name: A Modest Proposal for an Alternate IPv6
> Allocation Process
> 
> 2. Proposal Originator: William Herrin
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 5 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: See 6.11.7 below.
> 
> 7. Policy statement:
> 
> Add section 6.11 as follows:
> 
> 6.11 Alternate IPv6 allocation process
> 
> Section 6.11 offers an alternative to the address assignment process
> laid out in sections 6.5 and 6.10. Except where explicitly mentioned,
> no elements of the process here are binding on the process in those
> sections and vice versa.
> 
> 6.11.1 ARIN pools used for allocation.
> 
> ARIN shall reserve 3 pools of IPv6 addresses for the purpose of
> address allocation under section 6.11.
> 
> The first pool shall be used solely for making /48 allocations. ARIN
> will make no larger or smaller allocations from this pool.
> 
> The second pool shall be used solely for making /32 allocations. ARIN
> will make no larger or smaller allocations from this pool.
> 
> The third pool shall be used solely for making /24 allocations. ARIN
> will make no larger or smaller allocations from this pool.
> 
> ARIN shall publish the locations of these pool such that folks
> operating routers in the Internet Default-Free Zone can filter route
> announcements based on these published sizes if they so choose.
> 
> 
> 6.11.2 Initial allocation
> 
> 6.11.2.1 Initial allocation criteria
> 
> To qualify for an initial allocation of IPv6 address space, an
> organization must:
> 
> a. Be multihomed in the ARIN region with at least two different
> Internet Service Providers, both of whom agree to propagate the
> organization's IPv6 prefix into the Internet Default-Free Zone.
> 
> b. Have already obtained an Autonomous System Number.
> 
> c. Do not already hold a /48 or shorter IPv6 allocation from ARIN
> under any current or prior policy.
> 
> d. If requesting a /32, hold at least a /18 of IPv4 addresses
> 
> e. If requesting a /32, have implemented either SWIP or RWHOIS for all
> IPv4 allocations /28 or shorter.
> 
> 6.11.2.2 Initial allocation size
> 
> If requested, a /32 from the pool reserved for assigning /32's.
> Otherwise a /48 from the pool reserved for assigning /48's.
> 
> 
> 6.11.3 Extra /32 allocation
> 
> Organizations which hold a /48 from ARIN are eligible for an
> additional /32 allocation from the pool reserved for /32 allocations
> if they:
> 
> a. Demonstrate that they continue to meet the qualifications for the
> /48 assignment.
> 
> b. Do not already hold a /32 or shorter allocation from ARIN under any
> current or prior policy.
> 
> c. Plan to provide IPv6 service such that they will run out of space
> in the /48 within one year of making the second application.
> 
> d. Have implemented either SWIP or RWHOIS for all downstream
> allocations shorter than /64.
> 
> e. Agree to return all ARIN allocations longer than /33 except for one
> /48 allocation to ARIN within one year of receiving the /32
> allocation. Although 6.11.2 permits only one /48 allocation to an
> organization (hence no need to return anything), they may hold more
> than one due to mergers, acquisitions, policy changes, etc. These
> extras must be removed from the DFZ BGP table and returned to ARIN
> once a /32 is assigned.
> 
> 
> 6.11.4 Extra /24 allocation
> 
> Organizations which hold a /32 from ARIN are eligible for an
> additional /24 allocation from the pool reserved for /24 allocations
> if they:
> 
> a. Demonstrate that they continue to meet the qualifications for the
> /32 assignment.
> 
> b. Do not already hold a /24 or shorter allocation from ARIN under any
> current or prior policy.
> 
> c. Plan to provide downstream IPv6 service with address space such
> that they will run out of space within the /32 within two years of
> making the third application.
> 
> d. Return all /33 or longer allocations to ARIN prior to making the
> /24 application.
> 
> e. Agree to return all allocations longer than /25 except for one /32
> allocation to ARIN within one year of receiving the /24 allocation.
> 
> 
> 6.11.5 Additional allocations
> 
> No additional allocation beyond the single /24 is contemplated for a
> single organization at this time. No known usage pattern could require
> more than a /24 of IPv6 address space without egregious waste.
> 
> 
> 6.11.6 Advice to multihomed users
> 
> ARIN advises multihomed end-users that section 6.11 has been
> intentionally crafted to enable folks operating routers in the
> Internet Default-Free Zone to filter out route announcements longer
> than /48 within the /48 pool, longer than /32 within the /32 pool and
> longer than /24 within the /24 pool. Accordingly, it is probable that
> addresses assigned by an ISP instead of by ARIN will only be usable
> with that one ISP.
> 
> 
> 6.11.7 Policy term and re-evaluation
> 
> Three years from policy implementation, ARIN staff and the ARIN
> advisory council shall separately review the efficacy of address
> allocations made under both section 6.11 and sections 6.5 plus 6.10.
> Each shall recommend to the ARIN Board of Trustees that either 6.11 or
> both 6.5 and 6.10 be struck from the NRPM. The board shall review the
> recommendations and either strike section 6.11, strike both sections
> 6.5 and 6.10, or take no action, retaining both policies.
> 
> 
> 
> 8. Rationale:
> 
> The IPv6 allocation policy under section 6.5 makes a number of
> unproven assumptions about how IPv6 will work.
> 
> Unproven: we can make a reasonable guess about how many IPv6 subnets
> an organization will need at the outset when they first request IP
> addresses. When in all of human history has this ever proven true of
> any resource?
> 
> Unproven: with sparse allocation, we can allow organizations to expand
> by just changing their subnet mask so that they don't have to announce
> additional routes into the DFZ. This claim is questionable. With
> sparse allocation, we either consume much larger blocks that what we
> assign (so why not just assign the larger block?) or else we don't
> consume them in which case the org either has to renumber to expand or
> he has to announce a second route. Worse, because routes of various
> sizes are all scattered inside the same address pool, its impractical
> to detect or filter out the traffic engineering routes.
> 
> Unproven: we can force organizations not to disaggregate for traffic
> engineering purposes. Neither any of our experience with IPv4 nor any
> of the research in the IRTF Routing Research Group suggests that this
> is even remotely practical so long as BGP or any similar system rules
> the roost.
> 
> Unproven: all non-ISPs can be reasonably expected to get their address
> space from ISPs instead of from ARIN. We can certainly operate that
> way, but it could prove deadly to the routing table. Any organization
> mutlihomed between two ISPs will need to announce that route via BGP,
> regardless of where they get the address space from. We have knobs and
> dials in the routers that let us easily filter disagregates from
> distant announcements, but we don't dare do so if there is a
> possibility that one of those disaggregates is a multihomed customer
> rather than traffic engineering.
> 
> Benefits of this proposal:
> 
> A. Efficient allocation of IP addresses. Orgs get what they need when
> they need it and not before without a great deal of guesswork trying
> to define that need.
> 
> B. Efficient utilization of BGP routing slots. Few multihomed orgs
> will ever announce more than two unfilterable routes.
> 
> C. Traffic engineering routes are trivially filterable. Any route
> longer than the published allocation size can be presumed to be
> traffic engineering, not a downstream multihomed customer, thus you
> can filter distant small routes with confidence and ease.
> 
> D. Fair. No need to define the difference between ISP and not ISP.
> Everybody plays by the same rules.
> 
> E. No complicated analysis for the first allocation. You're either
> multihomed or you're not. If you're multihomed, you qualify.
> 
> F. For those who can live within the /48 there are distinct
> advantages: no swip or rwhois reporting and the generic end-user
> annual fee instead of the ISP annual fee. Once you're up to a /32, you
> pay the ISP annual fee. As a result, ARIN doesn't have to scrutinize
> the /32 requests too closely either.
> 
> G. No disruption to the prior IPv6 allocation policy until this new
> one proves itself.
> 
> 
> FAQ
> 
> Q. Isn't this classful addressing all over again?
> 
> A. Yes, with a twist. Now you have to fully use a class C before you
> can get a class B and fully use a class B before you can get a class
> A. And by the way, there are potentially 16 million class A's, not a
> mere 200.
> 
> Classful addressing had a lot of virtues with respect to route
> filtering and management. We had to abandon it because there weren't
> enough B's for everyone who needed more than one C and there weren't
> enough A's period. With IPv6, we don't have that problem. Not yet and
> maybe not ever. Perhaps we can have our cake and eat it too.
> 
> 
> Q. Why prevent single-homed users from getting ARIN addresses?
> 
> A. Any IPv6 allocation from ARIN must be announced into the Internet
> DFZ via BGP in order to use it on the Internet. That costs a lot of
> money, more than $10k per year according to
> http://bill.herrin.us/network/bgpcost.html   Worse, it spends other
> people's money: no practical system exists for recovering the cost of
> a consumed routing slot from the folks who announced the route.
> 
> If you don't get an allocation from ARIN then you have to renumber in
> order to change ISPs. That can cost a lot of money too. Sometimes far
> more than $10k. But it spends only your money, not somebody else's.
> 
> Finally there's the technical consideration: regardless of who assigns
> the addresses, a multihomed system must announce a route into the DFZ.
> That's the way BGP works and we're stuck with it for at least another
> decade. So why not let the multihomed org get his IP addresses from
> ARIN? By contrast, a single-homed system works just fine with its
> addresses aggregated inside the shorter route announced by its ISP.
> 
> 
> Q. If it's so expensive to announce routes into the DFZ, why not use
> something better than BGP?
> 
> A. Last year the IRTF Routing Research Group compiled an exhaustive
> study attempting to identify the possible ways to improve the routing
> system. A draft of the results is at
> http://tools.ietf.org/html/draft-irtf-rrg-recommendation-02 . While
> there are many promising ideas for how to replace BGP with something
> that scales better, we're at least a decade away and probably more
> from any significant deployment of a BGP replacement.
> 
> 
> Q. Is it really true that multihoming requires announcing a route via BGP?
> 
> A. The short answer is yes, its true. The long answer is more complicated.
> 
> Folks have tried very hard to devise multi-vendor multihomed systems
> which don't rely on BGP. Some even work OK for networks containing no
> Internet servers.
> 
> The only non-BGP approach that has ever come close to success for a
> system that hosts Internet servers is dynamically changing DNS records
> to favor the currently working Internet connection. "Close" is a
> relative term here. Such network architectures are enormously complex
> and they don't work for a useful definition of "work." The DNS
> protocol itself supports quick changes but the applications which use
> it often don't. It takes hours to achieve two-nines recovery from an
> address change in the DNS and it takes months to achieve five-nines
> recovery. Web browsers, for example, don't immediately recover. Search
> google for "DNS Pinning."
> 
> 
> Q. Why allocate the /48's from a pool only for /48's, /32's from a /32
> pool, etc.? Why not allocate from just one pool?
> 
> A. If all assignments in a particular pool are /32 and all multihomed
> entities get their IP addresses directly from ARIN then any route in
> the /32 pool which is longer than /32 is a traffic engineering route.
> As a router operator you can filter and discard a traffic engineering
> routes if you find they give you insufficient benefit. The routes you
> filter don't cost you any money; only the routes you keep carry a
> price tag.
> 
> You can only filter if you're sure they're traffic engineering
> routes... If they're downstream customer routes and you filter them,
> there goes the Internet. Or at least there goes your part of it. See
> customers. See customers run... straight to your competitor. Setting
> up the distinct pools makes it practical to know for certain that the
> routes you're filtering are only for TE.
> 
> 
> Q. Why make folks return all but one /48 to get a /32 and all but one
> /32 to get a /24?
> 
> A. Without the address scarcity issue which drives IPv4 policy, the
> primary criteria for IPv6 addressing policy is suppressing the route
> count in the IPv6 DFZ. Such a criteria is not well served if an
> organization holds dozens of discontiguous address spaces as a result
> of acquisitions, mergers and the like. With the return policy in
> place, organizations will generally only announce one or two primary
> routes, routes necessary for the correct operation of the Internet.
> Any other announced routes will be for traffic engineering. Because of
> the segregated pools from which the allocations come, those traffic
> engineering routes can be filtered by anyone who gains insufficient
> advantage from them without harming the Internet as a whole.
> 
> The return policy does require some renumbering activity. However,
> with only modest planning on the registrant's part, the policy is
> flexible enough to allow that renumbering to occur over a long period
> of time so that both cost and disruption are minimized. In many cases,
> customer churn can be expected to take care of much of the renumbering
> activity all by itself.
> 
> 
> Q. What if the first allocation from the /48 is a /48?
> 
> A. RFC 3177 recommends that downstream customers receive a /48
> assignment by default. Obviously there's a mismatch here if the ARIN
> allocation is also a /48.
> 
> The short version is that RFC 3177 is not the gospel truth. It's based
> on the IPv6 allocation model embodied in ARIN policy section 6.5 where
> we try very hard to assign all the addresses you'll ever need up front
> so that you only ever use one routing slot. This proposal attempts to
> slow-start IPv6 allocations instead, while still maintaining the
> principle of suppressing the routing table size. With a /48 allocation
> under this proposal, consider implementing a slow start for your
> downstream customers as well: Give them a /60 initially, add a /56
> when they need it and add a /52 when they run out of the /56. There
> are 16 /52's in your /48, or 4000 /60's. Plenty to get started. And a
> /60 is 16 /64 subnets. That's an internal LAN, a DMZ and 14 more
> subnets.
> 
> 
> Q. What happens when organizations merge or split?
> 
> A. Entities which merge will want to renumber out of and return one of
> the allocations so that they don't run into grief when they go to get
> the next larger allocation from ARIN. If done gradually, this should
> be a minor hardship.
> 
> Entities which split have a bigger problem since only one of them can
> keep the addresses. To a large extent, that problem already exists and
> is a pain in the rump for IPv4 operations today. This policy doesn't
> solve it but it doesn't make it a whole lot worse either. Because
> disaggregates are expected to be filtered, this IPv6 policy does gives
> us a slightly better guarantee that the rest of us won't get stuck
> with the check (in the form of routing slot consumption) when an ISP
> goes bankrupt and gets split up.
> 
> 
> Q. Why allow folks announcing IPv4 /18's to jump straight to a /32?
> 
> A. We're not really starting from scratch here and there are plenty of
> IPv6 addresses. Why make extra useless work for large ISPs who -are-
> going to use more than a /48? There are far fewer than 30k orgs
> holding /18s. How much grief should we cause them in order to save at
> most one whole /25?
> 
> 
> Q. Why not just replace section 6.5 instead of running this allocation
> system in parallel?
> 
> A. The most experienced user of IPv6 still has only a fraction of the
> experience that we have with IPv4. Yet the network operating model
> proposed by the IETF is radically different than the IPv4 model. The
> author believes that the IETF recommendation is based on an errant
> operating model, but he respects those who believe otherwise. The
> author also believes that competition is a good thing and history
> backs up this claim. Since little long term harm can come from briefly
> running both systems in parallel, allowing them to compete directly
> will result in the selection of the superior system.
> 
> 
> Q. You've covered multihomed and single-homed. What about IPv6
> addresses for uses which will not be connected to the Internet at all?
> 
> A. "ULA Central" or an idea like it is not addressed in this policy
> proposal. If desired, it should probably be implemented in a separate,
> parallel policy. The author observes that all of 2002:0a00::/24 is
> available for your offline use and there are plenty of others if you
> don't like that one.
> 
> 
> Implementation notes:
> 
> Initially, ARIN may want to use sparse allocation inside each of the
> three reserved pools until the policies are re-evaluated in three
> years. That way if section 6.11 is retired in favor of section 6.5,
> the 6.11 assignments may be able to grow by changing the netmask as
> intended in section 6.5. If 6.11 is retained, sparse allocation should
> cease.
> 
> Because IPv6 addresses are plentiful and the largest possible
> allocation under this policy is /24, the author recommends against
> explicit criteria for efficiency at this time. Instead, ARIN should
> consider selecting a fee schedule for /48, /32 and /24 allocations
> which discourages asking for more addresses than are really needed.
> Something along the lines of $100, $10k and $100k per year
> respectively might do nicely.
> 
> Under this proposal there is no difference whatsoever between an
> allocation and an assignment. The two words should be treated as
> synonyms.
> 
> 
> 9. Timetable for implementation: immediate; re-evaluate in 3 years
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From lear at cisco.com  Fri Jun  5 14:26:15 2009
From: lear at cisco.com (Eliot Lear)
Date: Fri, 05 Jun 2009 20:26:15 +0200
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A295792.3040807@arin.net>
References: <4A295792.3040807@arin.net>
Message-ID: <4A296347.6040608@cisco.com>


This proposal states the following regarding sparse allocation:

> Unproven: with sparse allocation, we can allow organizations to expand
> by just changing their subnet mask so that they don't have to announce
> additional routes into the DFZ. This claim is questionable. With
> sparse allocation, we either consume much larger blocks that what we
> assign (so why not just assign the larger block?) or else we don't
> consume them in which case the org either has to renumber to expand or
> he has to announce a second route. Worse, because routes of various
> sizes are all scattered inside the same address pool, its impractical
> to detect or filter out the traffic engineering routes.

To start with, the reason users want sparse allocation is so that they 
do not have to undertake a (presumably) large renumbering exercise.  Any 
policy that requires additional renumber will encourage use of ULAs tied 
to NAT.  It is already difficult to argue against those who want to 
insulate themselves from renumbering events with ULAs.  This policy 
would be the nail in the coffin for those of us who like globally unique 
and routed addresses.

And so the question: should ARIN be encouraging use of ULAs *instead* of 
globally routable address space?

Eliot



From sethm at rollernet.us  Fri Jun  5 14:32:23 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 05 Jun 2009 11:32:23 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A295EA8.1060103@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
Message-ID: <4A2964B7.9030400@rollernet.us>

Ted Mittelstaedt wrote:
> I have a comment/question on this..
> 
> It appears the central rationale for this policy assumes that most
> people are going to want to filter incoming BGP announcements,
> presumably because the BGP table is going to grow rapidly and they will
> otherwise run out of ram in their routers.  Is this assumption realistic?
> 
> VISA and MasterCard corporation have devised systems that can handle
> hundreds of millions of non-contiguous credit card numbers coming in for
> approvals, from every corner of the globe.  I therefore have an
> extremely difficult time believing that it is impossible to build a
> router that cannot handle, say, 10 or 20 million BGP routes.  I also
> have a difficult time believing that this cannot be done for the $50K to
> $100K that Cisco and Juniper seem to think they can charge for a
> fully-optioned BGP router.
> 
> Today I can walk into the discount store and by a brand new PC with 2GB
> of ram for under $350.  Yet, Cisco and Juniper are still including as
> standard ram amounts, miserable, paltry amounts far smaller than that.
> 

Two points:

1) On software platforms you're right. Last week I wanted to buy a 512
MB upgrade for a 2811. It uses DDR 266 unbuffered ECC; old stuff. Cisco
wanted $2,400 for it. They balked at me not wanting to buy their
official RAM, claiming warranty voiding, etc. I said there's no way in
hell I'm paying that much for old RAM so I bought some cheap-ass
Kingston for $26 that works just as well.

2) On hardware platforms TCAM is not DRAM.

~Seth


From sethm at rollernet.us  Fri Jun  5 14:36:43 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 05 Jun 2009 11:36:43 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A296347.6040608@cisco.com>
References: <4A295792.3040807@arin.net> <4A296347.6040608@cisco.com>
Message-ID: <4A2965BB.4020908@rollernet.us>

Eliot Lear wrote:
> 
> This proposal states the following regarding sparse allocation:
> 
>> Unproven: with sparse allocation, we can allow organizations to expand
>> by just changing their subnet mask so that they don't have to announce
>> additional routes into the DFZ. This claim is questionable. With
>> sparse allocation, we either consume much larger blocks that what we
>> assign (so why not just assign the larger block?) or else we don't
>> consume them in which case the org either has to renumber to expand or
>> he has to announce a second route. Worse, because routes of various
>> sizes are all scattered inside the same address pool, its impractical
>> to detect or filter out the traffic engineering routes.
> 
> To start with, the reason users want sparse allocation is so that they
> do not have to undertake a (presumably) large renumbering exercise.  Any
> policy that requires additional renumber will encourage use of ULAs tied
> to NAT.  It is already difficult to argue against those who want to
> insulate themselves from renumbering events with ULAs.  This policy
> would be the nail in the coffin for those of us who like globally unique
> and routed addresses.
> 
> And so the question: should ARIN be encouraging use of ULAs *instead* of
> globally routable address space?
> 

I'd always been told one of the bonuses of IPv6 is that everyone can get
globally routable address space. There might be some backlash if policy
tries to change that.

~Seth


From bicknell at ufp.org  Fri Jun  5 15:04:52 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 5 Jun 2009 15:04:52 -0400
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
	IPv6 Allocation Process
In-Reply-To: <4A295EA8.1060103@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
Message-ID: <20090605190452.GB63688@ussenterprise.ufp.org>

In a message written on Fri, Jun 05, 2009 at 11:06:32AM -0700, Ted Mittelstaedt wrote:
> Is this an accurate assessment?  Or is there really some reason that a
> router cannot be built with more ram than a half gig?

It is not an accurate assessment.

Plenty of routers have more than half a gig of ram.  Cisco 7301's
and 7200's with NPE-G[12]'s take 1G.  GSR's take 4G.  Juniper M20's
have 2G in them, and they are an old platform!

The memory to store BGP tables is not a huge problem.  There is a wall
at 4G, in that some of the router OS's aren't 64 bit; but quite frankly
even a very busy peering router is unlikely to be using more than around
1.5G for BGP information.  "Show ip bgp sum" on your favorite Cisco will
tell you in the header block how much DRAM you are using.

The problem is that those BGP routes (the RIB, routing information base)
have to be distilled into the set of forwarding routes.  You've done
this manually, route xyz comes from providers a, b and c, we like b, the
next hop is from a static route which points to the far end of connected
interface foo, so xyz->foo.  That distilled information is generally
called the FIB (forwarding information base).

Now consider a core router with 10 10GE interfaces (100Gbits/sec through
the box).  DRAM does not have enough bandwidth to look up that packet
rate of routes in the FIB, and even if it did the latency to do the
lookup would cause you to buffer hundreds of megabytes of data on the
line cards.  It just can't be done with off the shelf parts.

Folks build things with off the shelf parts, look at Vyatta for an
example.  You'll see how far "standard PC's" can be pushed.  It's a long
way, but not even remotely close to what core boxes need.

So virtually all vendors use something called TCAM.  Conceptually think
of it as hash memory. Rather than telling the memory you want address
1234 and getting back a value, you tell the memory you want the
corresponding pair to 10.0.0.0/8 and get back a value.  It's also
blisteringly fast, way faster than DRAM.

Here's some good summaries:

http://www.enterprisenetworkingplanet.com/nethub/article.php/3527301
http://en.wikipedia.org/wiki/Content-addressable_memory#Ternary_CAMs

Of course, this is also only part of the story.  It's not good enough to
look up the route and forward; you also need to look up things like
filters to see if the packet should be filtered, or ARP entries, or MPLS
lables.  Many boxes have multiple fast TCAM's and SRAM banks connected
by custom designed hardware ASICs to be able to do this at line rate.

This comes back to why some boxes are DRAM limited.  If you only have
enough TCAM to store, say, 256k distilled routes, why would you put
enough DRAM on the box to store 20 million routes?

Anyway, this isn't a router architecture list.  Google TCAM, join
Cisco-nsp or Juniper-nsp, and/or have your hardware vendor send out
an engineer.  While I'm not sure I would say in all instances these
large boxes are offered at a fair price, it's also not the case
that $100 of DDR2-800 would fix the problem.  There are real,
serious, expensive engineering challenges moving more than a couple
of Gigabits per second.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090605/cfc53a5f/attachment.sig>

From tedm at ipinc.net  Fri Jun  5 15:27:56 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Jun 2009 12:27:56 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A2964B7.9030400@rollernet.us>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<4A2964B7.9030400@rollernet.us>
Message-ID: <4A2971BC.1050704@ipinc.net>

Seth Mattinen wrote:
> Ted Mittelstaedt wrote:
>> I have a comment/question on this..
>>
>> It appears the central rationale for this policy assumes that most
>> people are going to want to filter incoming BGP announcements,
>> presumably because the BGP table is going to grow rapidly and they will
>> otherwise run out of ram in their routers.  Is this assumption realistic?
>>
>> VISA and MasterCard corporation have devised systems that can handle
>> hundreds of millions of non-contiguous credit card numbers coming in for
>> approvals, from every corner of the globe.  I therefore have an
>> extremely difficult time believing that it is impossible to build a
>> router that cannot handle, say, 10 or 20 million BGP routes.  I also
>> have a difficult time believing that this cannot be done for the $50K to
>> $100K that Cisco and Juniper seem to think they can charge for a
>> fully-optioned BGP router.
>>
>> Today I can walk into the discount store and by a brand new PC with 2GB
>> of ram for under $350.  Yet, Cisco and Juniper are still including as
>> standard ram amounts, miserable, paltry amounts far smaller than that.
>>
> 
> Two points:
> 
> 1) On software platforms you're right. Last week I wanted to buy a 512
> MB upgrade for a 2811. It uses DDR 266 unbuffered ECC; old stuff. Cisco
> wanted $2,400 for it. They balked at me not wanting to buy their
> official RAM, claiming warranty voiding, etc. I said there's no way in
> hell I'm paying that much for old RAM so I bought some cheap-ass
> Kingston for $26 that works just as well.
> 
> 2) On hardware platforms TCAM is not DRAM.
> 

That is purely due to volume

Years ago, 8MB dram units were common, 512MB units were rare and
very very expensive.  Then software bloated and the increased
volume dropped the price of the ram.

Obviously, both Cisco and Juniper want to keep unit prices high
since they make better margins that way.  But, if the BGP table
did bloat to tremendous levels and both those companies continued to
select esoteric and expensive parts to use so as to keep their unit
costs high, they would just be opening the door to the Linux-based
companies (like Imagestream) who are waiting in the wings.  Cisco
is well aware of this, it is after all no surprise that they recently
reorganized their Linksys purchase and pulled all the high-end
linux-based routers (ie: rv082, rvs1000, etc.) out of that brand.
They wanted to quash that trend quickly.

If TCAM remains a niche product, the router companies would abandon it
if they were required to produce routers with many many gigabytes of
ram, and super-fast processors.

Remember the winmodem/hardware modem war?  Remember the 
software/hardware AC97 soundcard chip war?  In both of those wars
the supposition was that the winmodem and the software sound chips
were inferior to the hardware devices since the host CPU was loaded
down too much.  Both those wars were lost in favor of the software
parts because of host CPU speed advances.

20 years from today, we will have hardware so fast that everything
implemented in a hardware asic on a router today will be easily
possible to duplicate in software.

Ted



From Wesley.E.George at sprint.com  Fri Jun  5 15:32:20 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Fri, 5 Jun 2009 14:32:20 -0500
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A295EA8.1060103@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A7F183D2E8@PLSWM01C.ad.sprint.com>

Ted Mittelstaedt wrote:
>VISA and MasterCard corporation have devised systems that can handle
>hundreds of millions of non-contiguous credit card numbers coming in for
>Approvals, from every corner of the globe.  I therefore have an
>extremely difficult time believing that it is impossible to build a
>router that cannot handle, say, 10 or 20 million BGP routes.  I also
>have a difficult time believing that this cannot be done for the $50K to
>$100K that Cisco and Juniper seem to think they can charge for a
>fully-optioned BGP router.
___

I'd love to see an IETF draft on how this technology is applicable, because I'm failing to follow your logic as to how VISA/MC are in any way related to global routing infrastructure. As far as I can tell, they are good at building a database that can rapidly validate lots of fixed-length numbers (which, I might add are rigidly hierarchical through ISO standards and therefore easier to break up the namespace to do efficient searches).

Leo Bicknell wrote:
>Anyway, this isn't a router architecture list.  Google TCAM, join
>Cisco-nsp or Juniper-nsp, and/or have your hardware vendor send out
>an engineer.  While I'm not sure I would say in all instances these
>large boxes are offered at a fair price, it's also not the case
>that $100 of DDR2-800 would fix the problem.  There are real,
>serious, expensive engineering challenges moving more than a couple
>of Gigabits per second.

+1
You're certainly entitled to your opinion, but it's simply not helpful to this discussion to try to blame another deep pocketed, greedy corporation for preventing everyone's refrigerator from getting a /32. This isn't a giant conspiracy. IPv6 route scale is a hard problem to solve, and it *IS* a reality for every major ISP, even if you put aside debates about the relative scarcity or lack thereof of the address space that exists in IPv6.

For what it's worth, I am against this proposal as written. I think it has some good ideas, but I don't support the linking to existing IPv4 address allocations, nor do I like the idea of having significant amounts of renumbering triggered every time a given block size is exhausted. However, some of the other requirements might make sense in making the "Open access to IPv6" policy more palatable.

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From tedm at ipinc.net  Fri Jun  5 15:55:05 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Jun 2009 12:55:05 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <20090605190452.GB63688@ussenterprise.ufp.org>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<20090605190452.GB63688@ussenterprise.ufp.org>
Message-ID: <4A297819.3040905@ipinc.net>

Leo Bicknell wrote:
> In a message written on Fri, Jun 05, 2009 at 11:06:32AM -0700, Ted Mittelstaedt wrote:
>> Is this an accurate assessment?  Or is there really some reason that a
>> router cannot be built with more ram than a half gig?
> 
> It is not an accurate assessment.
> 

   There are real,
> serious, expensive engineering challenges moving more than a couple
> of Gigabits per second.
> 

Right, but those challenges ALSO exist to do things like, for example,
run Windows 7 with acceptable speed.  Heck they also exist to run Vista
at an acceptable speed.

Remember Moore's Law here.  Back in 1999 I was still writing a column 
for a local technology mag and I had the temerity to go against it and 
predict that CPU chips would top out at 2Ghz clock speed in the coming
decade.  I'll not make that mistake again.  (although I did correctly
predict multiprocessor computers would be common in the consumer realm)


Ted


From Wesley.E.George at sprint.com  Fri Jun  5 15:54:44 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Fri, 5 Jun 2009 14:54:44 -0500
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A2971BC.1050704@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<4A2964B7.9030400@rollernet.us> <4A2971BC.1050704@ipinc.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A7F183D350@PLSWM01C.ad.sprint.com>

> Ted Mittelstaedt wrote:
<snip> both those companies continued to select esoteric and expensive parts to use so as to keep their unit
costs high, they would just be opening the door to the Linux-based companies (like Imagestream) who are waiting in the wings.  Cisco is well aware of this, it is after all no surprise that they recently reorganized their Linksys purchase and pulled all the high-end linux-based routers (ie: rv082, rvs1000, etc.) out of that brand.

And I suppose the 100mpg carburetor would have been right around the corner if Big Oil hadn't killed it too? There's a name for esoteric and expensive parts. It's called cutting edge. Someone has to invent the stuff and implement it before it commoditizes and gets cheap. I'm not going to say that the router vendors in question are not milking more profit out of some of their hardware, but you're going way far out into tinfoil-hat land with a lot of this thread so far.

<snip>
20 years from today, we will have hardware so fast that everything
implemented in a hardware asic on a router today will be easily
possible to duplicate in software.

Yes, and in 20 years we'll be fondly looking back on the bad old days when data rates were still measured in Gigabits per second and you had to carry your computer around (gasp). Every person on the planet will have a 1 Terabit/sec wireless connection to the chip in your head, meaning that the core will be handling amounts of data that we probably don't have an SI prefix for yet. And sorry, that will still probably require hardware-based acceleration. It's simply not possible to get the same performance out of general purpose hardware and software running on top of it than by purpose built hardware. That may change in the future, but what I'm concerned with is not the size of the routing table in 20 years. I'm concerned that the routing table will grow faster than our ability to innovate new technology to deal with it, or worse, that it will continue to cost too much, and require upgrades every few months instead of every few years. You want to complain about the cost of memory? The unobtanium technology necessary to keep up with a routing table growing exponentially will make that pale by comparison.

Please stop trying to discuss core router architecture on this list. You want to get involved in the discussion about what the internet routing infrastructure might look like in 20 years? http://www.irtf.org/charter?gtype=rg&group=rrg is the perfect list for that.

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From bill at herrin.us  Fri Jun  5 16:04:02 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Jun 2009 16:04:02 -0400
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
	IPv6 Allocation Process
In-Reply-To: <4A295EA8.1060103@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
Message-ID: <3c3e3fca0906051304m45bf382ev1ff01c5102c7faee@mail.gmail.com>

On Fri, Jun 5, 2009 at 2:06 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
> Today I can walk into the discount store and by a brand new PC with 2GB of
> ram for under $350.  Yet, Cisco and Juniper are still including as
> standard ram amounts, miserable, paltry amounts far smaller than that.
>
> My gut feeling here is that the router vendors could EASILY and CHEAPLY
> and QUICKLY greatly expand the capacity of their products IF demand called
> for it - thus removing the need for filtering.
>
> Is this an accurate assessment?  Or is there really some reason that a
> router cannot be built with more ram than a half gig?

Hi Ted,

Without going into great technical detail, building a router that
handles 10M routes is less like building a PC with 8 gigs of DRAM and
more like building a PC with an 8 gig CPU cache.

You can buy a Cisco 2800 series router with 1 gig of DRAM that will
happily handle north of 2M BGP routes. As long as your traffic is in
the sub-100mbps range and you don't mind waiting 10 minutes for it to
process the BGP table changes after a nearby link failure.

This will work because at the lower routing speeds I can afford to
wait for multiple CPU cache fills as the processor wanders down the
log-n FIB trie to find the correct next hop for the destination
address.

At gigabit plus speeds, I either have to parallelize that so that I'm
doing dozens of lookups on dozens of CPUs and dozens of parallel banks
of DRAM, or else I have to stuff the FIB entries in a very expensive
TCAM instead of using DRAM.

If you're interested in the technical detail, the best article I've
found about TCAMs is: http://www.pagiamtzis.com/cam/camintro.html


On Fri, Jun 5, 2009 at 2:26 PM, Eliot Lear<lear at cisco.com> wrote:
> Any policy that requires additional renumber will encourage use of
> ULAs tied to NAT.  It is already difficult to argue against those
> who want to insulate themselves from renumbering events with
> ULAs. This policy would be the nail
> in the coffin for those of us who like globally unique and routed addresses.

Hi Eliot,

For better or for worse, I suspect that's a done deal. The Enterprise
Security folks like NAT because it fails closed. They'll use it quite
regardless of how the renumbering issue plays out.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From tedm at ipinc.net  Fri Jun  5 16:20:26 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Jun 2009 13:20:26 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <3c3e3fca0906051304m45bf382ev1ff01c5102c7faee@mail.gmail.com>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<3c3e3fca0906051304m45bf382ev1ff01c5102c7faee@mail.gmail.com>
Message-ID: <4A297E0A.6010906@ipinc.net>

William Herrin wrote:
> On Fri, Jun 5, 2009 at 2:06 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
>> Today I can walk into the discount store and by a brand new PC with 2GB of
>> ram for under $350.  Yet, Cisco and Juniper are still including as
>> standard ram amounts, miserable, paltry amounts far smaller than that.
>>
>> My gut feeling here is that the router vendors could EASILY and CHEAPLY
>> and QUICKLY greatly expand the capacity of their products IF demand called
>> for it - thus removing the need for filtering.
>>
>> Is this an accurate assessment?  Or is there really some reason that a
>> router cannot be built with more ram than a half gig?
> 
> Hi Ted,
> 
> Without going into great technical detail, building a router that
> handles 10M routes is less like building a PC with 8 gigs of DRAM and
> more like building a PC with an 8 gig CPU cache.
> 
> You can buy a Cisco 2800 series router with 1 gig of DRAM that will
> happily handle north of 2M BGP routes. As long as your traffic is in
> the sub-100mbps range and you don't mind waiting 10 minutes for it to
> process the BGP table changes after a nearby link failure.
> 

Hey, this isn't anything that these people can't handle!  ;-)

http://news.cnet.com/2100-1006_3-6085568.html

> This will work because at the lower routing speeds I can afford to
> wait for multiple CPU cache fills as the processor wanders down the
> log-n FIB trie to find the correct next hop for the destination
> address.
> 
> At gigabit plus speeds, I either have to parallelize that so that I'm
> doing dozens of lookups on dozens of CPUs and dozens of parallel banks
> of DRAM, or else I have to stuff the FIB entries in a very expensive
> TCAM instead of using DRAM.
> 
> If you're interested in the technical detail, the best article I've
> found about TCAMs is: http://www.pagiamtzis.com/cam/camintro.html
> 

I know about it, but your talking today's technology, the issue the 
policy proposal is addressing (bad pun, I know) is in the future - since
today, the IPv6 routing table is small.

I guess I'm asking do you think router speed increases have hit a 
plateau?  That over the next 10 years we won't see anything much faster?

Ted


From Wesley.E.George at sprint.com  Fri Jun  5 16:23:47 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Fri, 5 Jun 2009 15:23:47 -0500
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A297819.3040905@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<20090605190452.GB63688@ussenterprise.ufp.org>
	<4A297819.3040905@ipinc.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A7F183D3AB@PLSWM01C.ad.sprint.com>

Ted Mittelstaedt wrote:
Right, but those challenges ALSO exist to do things like, for example,
run Windows 7 with acceptable speed.  Heck they also exist to run Vista
at an acceptable speed.

Remember Moore's Law here.



There was a large debate in the IEEE HSSG (those responsible for the 100GE standard), and one of the notable parts was Sun Microsystems (and others), who fought hard for a 40GE standard because they believed that it would be too long before standard server technology would be capable of high enough sustained throughput to really take advantage of 100Gbps network interfaces. My guess is that they're fairly familiar with Moore's law over at Sun.

By comparison, there are multiple routers that are capable of throughput in the terabit range, today. Could you build a PC that was capable of that level of throughput? Yup, but it'd start looking (and costing) an awful lot like a router.

Running Windows quickly is not a valid comparison. Yes, at some point core routers may have to offload management of the routing table to a big bladecenter full of processors and RAM, but that still won't fix the need for them to actually know what to do with the packets as they come through, which is all done in hardware at the speeds required. Might a technology advance make that a moot point? Yes, but until that happens, I have to assume it won't (or it won't happen fast enough) in order to ensure that I can continue operating my network at a reasonable cost.
Yes, some of the ideas in this proposal might get us there. I didn't say I was totally against it, just some parts of it.

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From tedm at ipinc.net  Fri Jun  5 16:30:00 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Jun 2009 13:30:00 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A7F183D350@PLSWM01C.ad.sprint.com>
References: <4A295792.3040807@arin.net>
	<4A295EA8.1060103@ipinc.net>	<4A2964B7.9030400@rollernet.us>
	<4A2971BC.1050704@ipinc.net>
	<F7EB0A7C707E39409A73CD0353242551A7F183D350@PLSWM01C.ad.sprint.com>
Message-ID: <4A298048.3000107@ipinc.net>

George, Wes E [NTK] wrote:
>> Ted Mittelstaedt wrote:

> <snip>
> 20 years from today, we will have hardware so fast that everything
> implemented in a hardware asic on a router today will be easily
> possible to duplicate in software.
> 
> Yes, and in 20 years we'll be fondly looking back on the bad old days when data rates were still measured in Gigabits per second and you had to carry your computer around (gasp). 

That might also happen, of course.

  > Please stop trying to discuss core router architecture on this list.

Well, that then is pretty much exactly what this policy proposal is 
doing, and you have already registered your opposition to it, so I
guess we know the real reason you don't like it, now.

I will point out though that ARIN's entire allocation policy is pretty 
much determined due to router hardware limitations.  You can claim that 
ARIN's policies should ignore router limitations all you want, but 
that's obviously a pipe dream, currently.

Ted


From tedm at ipinc.net  Fri Jun  5 16:41:07 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Jun 2009 13:41:07 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A7F183D3AB@PLSWM01C.ad.sprint.com>
References: <4A295792.3040807@arin.net>
	<4A295EA8.1060103@ipinc.net>	<20090605190452.GB63688@ussenterprise.ufp.org>
	<4A297819.3040905@ipinc.net>
	<F7EB0A7C707E39409A73CD0353242551A7F183D3AB@PLSWM01C.ad.sprint.com>
Message-ID: <4A2982E3.50307@ipinc.net>

George, Wes E [NTK] wrote:


> but until that happens, I have to assume it won't (or it won't happen fast enough) in order to ensure that I can continue operating my network at a reasonable cost

OK, well go back to my original question, then.  I asked if router 
advances would eliminate the need for filtering (or limiting the table)

Your basically saying that they aren't going to.   Yet, your against
the parts of the policy (predefining a block size) that are essential
to being able to define a block, which is needed for filtering.  So,
should I take this to mean that you think heavy filtering (like this 
policy appears to assume) isn't the
answer to table bloat, but rather, limiting the table size? ie: limiting
the number of allocated prefixes?


Ted


From bicknell at ufp.org  Fri Jun  5 16:50:41 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 5 Jun 2009 16:50:41 -0400
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
	IPv6 Allocation Process
In-Reply-To: <4A297819.3040905@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<20090605190452.GB63688@ussenterprise.ufp.org>
	<4A297819.3040905@ipinc.net>
Message-ID: <20090605205040.GA74144@ussenterprise.ufp.org>

In a message written on Fri, Jun 05, 2009 at 12:55:05PM -0700, Ted Mittelstaedt wrote:
>   There are real,
> >serious, expensive engineering challenges moving more than a couple
> >of Gigabits per second.
> 
> Right, but those challenges ALSO exist to do things like, for example,
> run Windows 7 with acceptable speed.  Heck they also exist to run Vista
> at an acceptable speed.

There is a lot less overlap in those challenges than you think.

The market for Windows 7 is probably a billion PC's.  The market
for core routers might be 10,000.  Might be 1,000.

http://www.vyatta.com/downloads/datasheets/vyatta_2500_datasheet.pdf

4Gbps of hardware based forwarding in a 1RU form factor, available
with support for under $5k.

10 years ago, when a 7513 was still a useful box, it barely did
4Gbps in a chassis that cost $500,000.  An OC-12 based backbone was
"big".  I'd say moores law has done well.

Today the standard customer handoff is a GigE, bigger than the
backbone link in a 7513's day.  A core router is expected to move
400Gbps, and that takes custom hardware and costs $2M.

Until we reach the point where consumer bandwidth growth levels,
the boxes need to get bigger at the same rate moores law makes them
cheaper, which keeps the cost constant; but the throughput keeps
going up.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090605/9a76dbad/attachment.sig>

From lar at mwtcorp.net  Fri Jun  5 16:31:00 2009
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Fri, 05 Jun 2009 14:31:00 -0600
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A7F183D2E8@PLSWM01C.ad.sprint.com>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<F7EB0A7C707E39409A73CD0353242551A7F183D2E8@PLSWM01C.ad.sprint.com>
Message-ID: <web-1008034@be1.mail.trib.com>

My analysis of an IPV6 deployment, for my company, is "painful and 
expensive". There are still
hurdles in the mixed IPV4-IPV6 environment for VOIP and "tons" of work to 
learn to design and
deploy an efficient IPV6 WAN.
  
I am a small ISP that is geographically spread out. Lots of grass, small 
number of people. I feed
other yet smaller ISP's. I had planned on assigning each one a /48  and 
dangle the carrot that
as long as I was their provider they would never have to renumber.
They will still resist but I think I can nudge them along.

A /32 will probably last me for many years, maybe for ever. A /48 will not.

I have been forced to renumber IPV4 4 times in the past 12 years. The last 
one took two years to fully implement.
I have lost customers every time.

I had tentatively planned on starting deployment in spring of 2010. (A lot 
of engineering remains
to be done.) This proposal raises the spector of being forced to renumber at 
some point in the future.
If adopted this is a deal breaker as far as implimenting IPV6 for the next 
few years. I will whip IPV4
as long as it looks like it can crawl. Sorry just the truth.


Larry Ash
Network Administrator
Mountain West Telephone
400 East 1st St.
Casper, WY 82601


From Wesley.E.George at sprint.com  Fri Jun  5 16:45:04 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Fri, 5 Jun 2009 15:45:04 -0500
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A298048.3000107@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<4A2964B7.9030400@rollernet.us> <4A2971BC.1050704@ipinc.net>
	<F7EB0A7C707E39409A73CD0353242551A7F183D350@PLSWM01C.ad.sprint.com>
	<4A298048.3000107@ipinc.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A7F183D3DE@PLSWM01C.ad.sprint.com>


>> Ted Mittelstaedt wrote:

  > Please stop trying to discuss core router architecture on this list.

Well, that then is pretty much exactly what this policy proposal is
doing, and you have already registered your opposition to it, so I
guess we know the real reason you don't like it, now.

I will point out though that ARIN's entire allocation policy is pretty
much determined due to router hardware limitations.  You can claim that
ARIN's policies should ignore router limitations all you want, but
that's obviously a pipe dream, currently.


I never said that ARIN's policies should ignore router limitations. Quite the contrary. My request to stop discussing it stemmed from the fact that this debate seems to ignore several posts that attempt to explain why router hardware limitations are what they are after folks continue to pose variations of the "how hard could it be to build a cheap router that does 20M routes?" question, or dismiss the concerns about routing table bloat with a vague reference to "the future of computer and routing architecture". That particular "discussion" of router architecture is not helpful.

Wes

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From Wesley.E.George at sprint.com  Fri Jun  5 17:08:13 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Fri, 5 Jun 2009 16:08:13 -0500
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A2982E3.50307@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<20090605190452.GB63688@ussenterprise.ufp.org>
	<4A297819.3040905@ipinc.net>
	<F7EB0A7C707E39409A73CD0353242551A7F183D3AB@PLSWM01C.ad.sprint.com>
	<4A2982E3.50307@ipinc.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A7F183D420@PLSWM01C.ad.sprint.com>


This isn't exclusively a policy problem to solve any more than it is just a technology problem to solve.
To be honest, I don't know what the answer is, short of something much more revolutionary like a location/ID split for IPs, or some as yet to be invented method of reducing the DFZ routing table.
However, I don't think that this policy nor the "open access" policy is the correct solution as they are currently written. I would love to be able to do this type of filtering, but I know it will likely not happen because renumbering is a pain, and there will always be some exception that will force a reduction in the filters and blow the routing table up anyway. I would also love for deus ex machina to come along and solve the problem through excellent application of magic technology, but I have to be practical there too. So, I'm stuck with having to continue operating under the concept that there is scarcity in the IPv6 world. Even though it's not IP address scarcity, it does exist, and there are multiple tools in our box to help manage it. This likely means that there will be some folks out there that will have to settle for getting a PD allocation from their upstream that is aggregated before it hits the DFZ, and that others might not get a /32 just because they want one. It might also mean that ISPs will have to do careful filtering of blocks so that they don't blow up the table or blackhole stuff they didn't want to. It's not a pretty picture either way.

Wes

-----Original Message-----
From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
Sent: Friday, June 05, 2009 4:41 PM
To: George, Wes E [NTK]
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate IPv6 Allocation Process

George, Wes E [NTK] wrote:


> but until that happens, I have to assume it won't (or it won't happen fast enough) in order to ensure that I can continue operating my network at a reasonable cost

OK, well go back to my original question, then.  I asked if router
advances would eliminate the need for filtering (or limiting the table)

Your basically saying that they aren't going to.   Yet, your against
the parts of the policy (predefining a block size) that are essential
to being able to define a block, which is needed for filtering.  So,
should I take this to mean that you think heavy filtering (like this
policy appears to assume) isn't the
answer to table bloat, but rather, limiting the table size? ie: limiting
the number of allocated prefixes?


Ted


This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From mueller at syr.edu  Fri Jun  5 17:17:19 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 5 Jun 2009 17:17:19 -0400
Subject: [arin-ppml] Policy Proposal: Sunset Clause for Liberalized
 Transfer Policy
In-Reply-To: <4A2954AB.7060008@ipinc.net>
References: <4A27E68A.9050707@arin.net> <4A27EE69.9020201@cisco.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B297@mail>
	<75822E125BCB994F8446858C4B19F0D77B220A0F@SUEX07-MBX-04.ad.syr.edu>
	<4A2954AB.7060008@ipinc.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A21@SUEX07-MBX-04.ad.syr.edu>

> -----Original Message-----
> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] 
> I was in the compromise group precisely 
> because the transfer policy had a sunset.  My opinion has not changed 
> just because you pulled my pants down and got the restriction removed.
> 
> I'm sure you and the rest of the unrestricted transfer people are 
> laughing up your sleeve and patting yourself on the back at how smart 
> you are.  

No, but I am giggling at the level of influence you are assigning to me.

I had nothing to do with the 2008-6 policy, sunset or no sunset. Talk to Bill Darte about that one. I pretty much tuned out after 2008-2 got bogged down and thought 2008-6 was bogus. I didn't even follow its progress. When 2009-1 removed the sunset, I started paying attention again (how could one not?). I supported its removal retrospectively, because a sunset is not a compromise but a way of crippling the functioning of a transfer market in advance. But I promise I didn't pull any of those long marionette strings that extend from my office to the ARIN Board room....

.....at least, not this time, heh, heh. 

> But, here is the cost - people like you have pretty much 
> polarized the policy proposal process.  

this is a (polarizing) personal attack, not a policy argument. 
Can we stick to substance, please?

 

From gdolley at arpnetworks.com  Fri Jun  5 17:21:32 2009
From: gdolley at arpnetworks.com (Garry Dolley)
Date: Fri, 5 Jun 2009 14:21:32 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an	Alternate
	IPv6 Allocation Process
In-Reply-To: <4A295EA8.1060103@ipinc.net>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
Message-ID: <20090605212132.GB966@garry-thinkpad.arpnetworks.com>

On Fri, Jun 05, 2009 at 11:06:32AM -0700, Ted Mittelstaedt wrote:
> I have a comment/question on this..
>
> It appears the central rationale for this policy assumes that most people 
> are going to want to filter incoming BGP announcements, presumably because 
> the BGP table is going to grow rapidly and they will otherwise run out of 
> ram in their routers.  Is this assumption realistic?

Very realistic.

> VISA and MasterCard corporation have devised systems that can handle
> hundreds of millions of non-contiguous credit card numbers coming in for 
> approvals, from every corner of the globe.  I therefore have an extremely 
> difficult time believing that it is impossible to build a router that 
> cannot handle, say, 10 or 20 million BGP routes.  I also have a difficult 
> time believing that this cannot be done for the $50K to
> $100K that Cisco and Juniper seem to think they can charge for a
> fully-optioned BGP router.

I have no data on the number of credit card transactions that get
processed per second.

But on modern Cisco hardware, we expect forwarding rates of at *least*
15 Mpps.  SUP720-3BXL advertises 400 Mpps in a 6509 chassis and a
720 Gbps backplane.

Software algorithms (that use regular RAM) can't achieve these
numbers.  The most I've seen is around 2-3 Mpps using very modern
hardware with FreeBSD.

> Today I can walk into the discount store and by a brand new PC with 2GB of 
> ram for under $350.  Yet, Cisco and Juniper are still including as
> standard ram amounts, miserable, paltry amounts far smaller than that.

Yes, but when we talk about # of routes supported in BGP on Cisco
hardware, we want those routes to be hardware accelerated.  This
requires TCAM, not RAM.  

This link was recently posted and is quite good:
http://www.pagiamtzis.com/cam/camintro.html

You can see why TCAM is much more expensive than RAM.

I can easily do millions of routes on my OpenBSD software router,
but the performance of this router is not sufficient for the core of
my network.  I need a hardware router.

-- 
Garry Dolley
ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181
Data center, VPS, and IP Transit solutions
Member Los Angeles County REACT, Unit 336 | WQGK336
Blog http://scie.nti.st


From mueller at syr.edu  Fri Jun  5 17:49:15 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 5 Jun 2009 17:49:15 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <4A28663E.8090707@matthew.at>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A25A90B.5020804@bogus.com>	<4A282BEE.1050403@matthew.at>
	<f65fb55e0906041355y2d0fe4c5u9712c366059086d9@mail.gmail.com>
	<4A285D17.7060209@matthew.at> <4A28663E.8090707@matthew.at>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A23@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> Matthew Kaufman wrote:
> >>   
> > Yes, you've missed something. That the cost of running a 
> > near-automated system for allocating address space is 
> > several orders of magnitude [lower] than $562.50/year, 
> > and certainly won't be going *up* over time as IPv6 rates will.
> 
> The real point being that the cost of doing an allocation 
> takes someone a short time to review the application for sanity. The cost 
> of keeping an allocation in the database is about the cost of running the whois 
> server and its backing database(s) on an ongoing basis, which 
> is a lot lower than an ongoing $562-2250/year.
>
> Why we've all bought into the illusion that ARIN and ICANN 
> really need this much money to function, I don't know. 

I've been looking at this. It's an interesting problem. There is an unresolved and little-discussed tension between the use of fees as an encouragement to conserve the address space, and the use of fees as methods for recovering the costs of RIR services.

If all we're paying for is the support of ARIN or other RIRs, then the block size an org is allocated rarely has any relationship to the costs imposed. But if fees don't get bigger with bigger allocations, then what's to stop a land rush that could in fact lead to wasteful overconsumption of the v6 address space? 

--MM

From dogwallah at gmail.com  Fri Jun  5 17:53:51 2009
From: dogwallah at gmail.com (McTim)
Date: Sat, 6 Jun 2009 00:53:51 +0300
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A23@SUEX07-MBX-04.ad.syr.edu>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A25A90B.5020804@bogus.com> <4A282BEE.1050403@matthew.at>
	<f65fb55e0906041355y2d0fe4c5u9712c366059086d9@mail.gmail.com>
	<4A285D17.7060209@matthew.at> <4A28663E.8090707@matthew.at>
	<75822E125BCB994F8446858C4B19F0D77B220A23@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <f65fb55e0906051453k5976469fp3ed6fae6307a4436@mail.gmail.com>

On 6/6/09, Milton L Mueller <mueller at syr.edu> wrote:
>
<snip>
>  If all we're paying for is the support of ARIN or other RIRs, then the block size an org is allocated rarely has any relationship to the costs imposed. But if fees don't get bigger with bigger allocations, then what's to stop a land rush that could in fact lead to wasteful overconsumption of the v6 address space?

allocating based on need.

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


From joelja at bogus.com  Fri Jun  5 17:56:53 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 05 Jun 2009 14:56:53 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an	Alternate
 IPv6 Allocation Process
In-Reply-To: <20090605212132.GB966@garry-thinkpad.arpnetworks.com>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<20090605212132.GB966@garry-thinkpad.arpnetworks.com>
Message-ID: <4A2994A5.5070804@bogus.com>


Garry Dolley wrote:
> On Fri, Jun 05, 2009 at 11:06:32AM -0700, Ted Mittelstaedt wrote:

>> Today I can walk into the discount store and by a brand new PC with 2GB of 
>> ram for under $350.  Yet, Cisco and Juniper are still including as
>> standard ram amounts, miserable, paltry amounts far smaller than that.

Rib and fib are obviously different if related problems, the rib into
the fib generation is itself not a trivial exercise now or in the future.

> Yes, but when we talk about # of routes supported in BGP on Cisco
> hardware, we want those routes to be hardware accelerated.  This
> requires TCAM, not RAM.  

Actually it doesn't require TCAM, TCAM is one realization as to how to
implement it. Plenty of platforms don't in fact implement it that way,
to pick one example at random Juniper mx switches which use somewhat
exotic and rather fast ddram...

This thing to note is that vendors and their customers are mindful of
table growth and so far it has be bounded within what's possible with
the approaches we currently have or have come up with. This was true
when we were at 10k routes, and it's still true at 300k.

> This link was recently posted and is quite good:
> http://www.pagiamtzis.com/cam/camintro.html
> 
> You can see why TCAM is much more expensive than RAM.
> 
> I can easily do millions of routes on my OpenBSD software router,

Actually it's possbile but it turns out to not be either easy or that
usable. the ability to stick 7-10 million paths in your rib doesn't mean
that quagga or xorp or your choice of routing daemon will stuff them in
the kernel routing table in a timely fashion, and each v4 fib entry in
your kernel is 128 bytes so the size of that data structure and the fact
that it's in a hash table rather than a trie is an issue.

> but the performance of this router is not sufficient for the core of
> my network.  I need a hardware router.

reading material:

ietf raws report
http://tools.ietf.org/html/rfc4984

nanog 39 fib bof
http://www.nanog.org/meetings/nanog39/abstracts.php?pt=MjY4Jm5hbm9nMzk=&nm=nanog39


From mueller at syr.edu  Fri Jun  5 18:09:40 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 5 Jun 2009 18:09:40 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <f65fb55e0906051453k5976469fp3ed6fae6307a4436@mail.gmail.com>
References: <3c3e3fca0905301205n7c5ca83dpce067386bd491add@mail.gmail.com>
	<4A2184EA.7020708@gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7CE5@SUEX07-MBX-04.ad.syr.edu>
	<2557049CDBC35B4EBD79CFACFEC045841B9F5494@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A25A90B.5020804@bogus.com> <4A282BEE.1050403@matthew.at>
	<f65fb55e0906041355y2d0fe4c5u9712c366059086d9@mail.gmail.com>
	<4A285D17.7060209@matthew.at> <4A28663E.8090707@matthew.at>
	<75822E125BCB994F8446858C4B19F0D77B220A23@SUEX07-MBX-04.ad.syr.edu>
	<f65fb55e0906051453k5976469fp3ed6fae6307a4436@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A24@SUEX07-MBX-04.ad.syr.edu>

> 
> allocating based on need.
> 
> -- 
> Cheers,
> McTim

Perhaps. But "need" is subjective (as the old Hummer ads said).
Refer back to Leo Bicknell's post about how you define a "subnet" a few days back. Lots of games can be played with that. 
To eliminate the games, you standardize, but that has its own problems. RFC 3177 has already decided that every cellphone "needs" 18,446,744,073,709,500,000 host addresses. That, patently, isn't true; many thousands of trillions of addresses will be wasted because end sites don't need them. 
Making finer distinctions requires massive investments in organizational overhead: reviews, monitoring, etc. It might be better to calibrate cost with consumption in some way. That might make people conserve properly. But that has its own problems, too. 

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 

> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there."  Jon Postel
> 

From michael.dillon at bt.com  Fri Jun  5 18:39:15 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 5 Jun 2009 23:39:15 +0100
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
	IPv6 Allocation Process
In-Reply-To: <4A295792.3040807@arin.net>
Message-ID: <28E139F46D45AF49A31950F88C4974580183E227@E03MVZ2-UKDY.domain1.systemhost.net>


> 1. Policy Proposal Name: A Modest Proposal for an Alternate 
> IPv6 Allocation Process

This is the wrong direction for us to be going with ARIN
policy. Even if you take out the parts which are ARIN
operational guidelines, not policy, it is way too complex
and it is disturbing to see the distinction between ISP
and non-ISP allocations being blurred like this.

Not to mention that the complexity raises new barriers
to getting IPv6 addresses which is not the way we should
be heading.

--Michael Dillon


From joelja at bogus.com  Fri Jun  5 18:42:40 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Fri, 05 Jun 2009 15:42:40 -0700
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A7F183D2E8@PLSWM01C.ad.sprint.com>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<F7EB0A7C707E39409A73CD0353242551A7F183D2E8@PLSWM01C.ad.sprint.com>
Message-ID: <4A299F60.5060305@bogus.com>

George, Wes E [NTK] wrote:
> IPv6 route scale is a
> hard problem to solve, and it *IS* a reality for every major ISP,
> even if you put aside debates about the relative scarcity or lack
> thereof of the address space that exists in IPv6.

To be clear the ipv6 route table scalability issue is effectively the
same as the v4 only with bigger numbers. anyone who thinks v4 dfz growth
in a post-exhaustion world isn't a problem  should revist the last
decades worth of nanog presentations in v4 routing scalability.


From michael.dillon at bt.com  Fri Jun  5 18:45:15 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 5 Jun 2009 23:45:15 +0100
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an
	AlternateIPv6 Allocation Process
In-Reply-To: <20090605190452.GB63688@ussenterprise.ufp.org>
Message-ID: <28E139F46D45AF49A31950F88C4974580183E228@E03MVZ2-UKDY.domain1.systemhost.net>

> So virtually all vendors use something called TCAM.  

If only TCAM were common as sliced bread and cheap
like borshch.

You can implement TCAM on FPGA hardware, and there are
FPGA boards available for PCs. It would be interesting
if someone wrote some software to use a TCAM in some
open source db software like PostgreSQL. If a benchmark
with TCAM showed a big enough improvement over non-TCAM
that might be the motivation for more widespread production
of TCAM for PCs, which in turn would drive down the prices
of TCAM overall.

--Michael Dillon


From michael.dillon at bt.com  Fri Jun  5 19:01:12 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sat, 6 Jun 2009 00:01:12 +0100
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A24@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <28E139F46D45AF49A31950F88C4974580183E229@E03MVZ2-UKDY.domain1.systemhost.net>

> To eliminate the games, you standardize, but that has its own 
> problems. RFC 3177 has already decided that every cellphone 
> "needs" 18,446,744,073,709,500,000 host addresses. That, 
> patently, isn't true; many thousands of trillions of 
> addresses will be wasted because end sites don't need them. 

You should eliminate your games. That is patently not true.
RFC 3177 says: 

   It is not obvious, however, that all edge networks are likely to be
   recursively subnetted; a single PC in a home or a telephone in a
   mobile cellular network, for example, may or may not interface to a
   subnetted local network.  When a network number is delegated to a
   place that will not require subnetting, therefore, it might be
   acceptable for an ISP to give a single 64-bit prefix - perhaps shared
   among the dial-in connections to the same ISP router.  However this
   decision may be taken in the knowledge that there is objectively no
   shortage of /48s, and the expectation that personal, home networks
   will become the norm. 

Then later:

   Mobile networks, such as vehicles or mobile phones with an
   additional network interface (such as bluetooth or 802.11b)
   should receive a static /64 prefix to allow the connection of
   multiple devices through one subnet.

It never talks about huge numbers of host addresses. And it
does reference RFC 2374 which explains how interface ids are 
constructed which makes it clear that the minimum subnet 
size is a /64. No addresses are wasted. Some bit combinations
are never used but that is not waste, since neither IPv4 or
IPv6 is architected in a way that all bit combinations could
be used for endpoint addresses.

> Making finer distinctions requires massive investments in 
> organizational overhead: reviews, monitoring, etc.

Precisely the justification for having standard prefix lengths
of /64, /48 and /32 in the first place. It massively cuts 
down the overhead of having to make fine grained measurements
of subnet size, carefully mete out small address blocks, and
then restructure everything when some part of the network 
outgrows its address allocation. IPv4 wastes money, but IPv6
leverages a much longer bitstring to cut out that waste in
overhead, monitoring, reviewing and restructuring the network
to accomodate growth.

--Michael Dillon


From steve at ibctech.ca  Fri Jun  5 20:08:51 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 05 Jun 2009 20:08:51 -0400
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
 IPv6 Allocation Process
In-Reply-To: <4A295792.3040807@arin.net>
References: <4A295792.3040807@arin.net>
Message-ID: <4A29B393.80006@ibctech.ca>

Member Services wrote:

> 1. Policy Proposal Name: A Modest Proposal for an Alternate IPv6
> Allocation Process

FWIW, I oppose this policy.

I firmly believe that in no way should any IPv6 allocation/assignment
considerations be related whatsoever to IPv4.

It is not fair, and it is not practical.

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090605/bd75af51/attachment.bin>

From bill at herrin.us  Fri Jun  5 21:20:01 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Jun 2009 21:20:01 -0400
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an Alternate
	IPv6 Allocation Process
In-Reply-To: <web-1008034@be1.mail.trib.com>
References: <4A295792.3040807@arin.net> <4A295EA8.1060103@ipinc.net>
	<F7EB0A7C707E39409A73CD0353242551A7F183D2E8@PLSWM01C.ad.sprint.com>
	<web-1008034@be1.mail.trib.com>
Message-ID: <3c3e3fca0906051820o5bd9a23bi2da17fd120feb500@mail.gmail.com>

On Fri, Jun 5, 2009 at 8:08 PM, Steve Bertrand<steve at ibctech.ca> wrote:
>> 1. Policy Proposal Name: A Modest Proposal for an Alternate IPv6
>> Allocation Process
>
> FWIW, I oppose this policy.
>
> I firmly believe that in no way should any IPv6 allocation/assignment
> considerations be related whatsoever to IPv4.
> It is not fair, and it is not practical.

Hi Steve,

Would you support the proposal if the lines allowing large IPv4
holders to skip the /48 level and go straight to /32 were removed?
That's the only place IPv4 is mentioned. Would you remove them
entirely and make everyone start with a /48 or would you replace them
with some other criteria that was not tied to IPv4 specifically?


On Fri, Jun 5, 2009 at 4:31 PM, <lar at mwtcorp.net> wrote:
> This proposal raises the spector of being forced to renumber at
> some point in the future.
> If adopted this is a deal breaker as far as implimenting IPV6 for the next
> few years.

Hi Larry,

As an ISP you probably already hold a /18 of IPv4 space. As a result,
you would be qualified for a /32 immediately under the proposed
policy. You would later be qualified for an additional /24 *without*
returning the /32 or renumbering any of your customers. Nothing in the
policy would ever require you to renumber out of either the /32 or the
/24.

If you bought another ISP's assets with another /32, you would have to
renumber those acquisition customers into your /32 in order to later
get the /24.

Does that affect your opinion any? Or would you still be opposed
because of the requirement to renumber out of space you acquired
through acquisitions?



On Fri, Jun 5, 2009 at 4:20 PM, Ted Mittelstaedt<tedm at ipinc.net> wrote:
> I guess I'm asking do you think router speed increases have hit a plateau?
>  That over the next 10 years we won't see anything much faster?

Hi Ted,

No, we haven't plateaued. Router capacity is increasing and while I
haven't collected the data to prove a trend as a companion to my bgp
cost piece, I'm pretty sure the cost per announced prefix is slowly
coming down. However, the route count is increasing faster than the
cost per route is falling, so the overhead cost of the system as a
whole is going up.

> OK, well go back to my original question, then.  I asked if router advances
> would eliminate the need for filtering (or limiting the table)

Eventually. That's what the IRTF RRG is all about: identifying those
advances. But it won't happen in a useful time frame for a 2009
discussion of IPv6 address policy.


On Fri, Jun 5, 2009 at 6:39 PM, <michael.dillon at bt.com> wrote:
> it is disturbing to see the distinction between ISP
> and non-ISP allocations being blurred like this.

Michael,

Blurred nothing. I kicked the it to curb. This proposal makes no
distinction whatsoever between ISPs and anyone else. And eliminating
preferential treatment based on a frequently artificial distinction
doesn't disturb me at all.


> Not to mention that the complexity raises new barriers
> to getting IPv6 addresses which is not the way we should
> be heading.

What complexity? You're multihomed? You qualify. Done.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From vixie at isc.org  Fri Jun  5 22:52:44 2009
From: vixie at isc.org (Paul Vixie)
Date: Sat, 06 Jun 2009 02:52:44 +0000
Subject: [arin-ppml] [arin-council] Returning Legacy Space to IANA.
	Attorney client communcation.
In-Reply-To: <20090606004337.GA87863@ussenterprise.ufp.org> (Leo Bicknell's
	message of "Fri\, 5 Jun 2009 20\:43\:37 -0400")
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
Message-ID: <g31vpygjk3.fsf@nsa.vix.com>

note that i'm speaking about confidential matters even though staff has
informed me that not every AC member has signed the NDA.  please sign and
return these agreements.

bicknell at ufp.org (Leo Bicknell) writes:

> There is likely a lower percentage of folks in the ARIN region who have
> thought about the issue and/or consider it hoarding than in the rest of
> the world.

if we're now talking about the appearance of hoarding by the rest of the
world then i'm able to join that discussion.  if on the other hand we're
still talking about presumed actual hoarding by the "reasonable person"
standard then i'd have to object to the premise of any/all questions.

> I belive the concept of laches applies here.  If ARIN had gotten a
> majority of legacy holders under contract, and worked with a large number
> of the most over-IP'ed to return part of their allocation (e.g.  what
> happened with Sandford) then ARIN might have a leg to stand on that what
> is left is part of the ARIN system.  However, ARIN chose not to actively
                                                    ^^^^^^^
> engage the legacy folks for going on 10 years, has contracted only a
> small percentage (by absolute number), and right sized a miniscule amount
> of the allocations.

perhaps you will feel that i'm still using language too precisely, but i've
been on the board going on five years and i watched ARIN carefully before
that and i can find no record of a "choice" being made on this topic.  if
what you really mean is "it was a hairball and ARIN couldn't figure out how
to get a grip on it" then i think the rest of your conclusion falls apart:
that is, ARIN's standing to assert its regional authority over these
regional allocations remains intact.  this isn't like a right of way that
one can lose property rights for if one fails to post a sign and periodically
restrict access, or losing trademark by failing to protect it coherently.

> It seems to me that if we want to make the argument that another
> RIR is not being a good stweard by abandoning needs-based allocations
> and thus should not be rewarded that the same argument can be turned
                        ^^^^^^^^^^
> against us.  By not requiring good stewardship (in a modern definition)
> of legacy holders ARIN should not be rewarded.

since this was never about rewards, i can't follow this reasoning at all.
RFC 2050 is pretty clear on all this.  the ability for some RIRs to adopt
policies which are incompatible with RFC 2050 is now being tested, and i
expect that the test will succeed, i.e., that RFC 2050 can be thrown
overboard at will, without direct recourse by NRO or IANA or ICANN or other
RIRs.  if this occurs, then a policy of "automatic return to IANA" means
that once any RIR abandons RFC 2050 then all RIRs have effectively done so
as soon as the IANA pool is depleted.  i am not comfortable with this as
a natural progression of events, no matter what arguments about fairness
or what global accusations of hoarding are brought to bear.

furthermore, ARIN is a 501(C)(6) nonprofit tax exempt business league.  at
<http://www.irs.gov/charities/nonprofits/article/0,,id=96107,00.html> i
find this text:

	... generally ... an entire industry ... within a geographic area.

so at a structural level, this organization is supposed to put its region
first if there is ever a direct conflict between this region and other
regions.  this does NOT argue for an actual policy of hoarding -- because
if the internet can grow in our region but in no other region then our
entire industry within our geographical area will also suffer.  this DOES
argue for policies which may run the risk of being called hoarding by the
rest of the world, even if we know a more complete truth.

>...
> 004/8	Level 3 Communications, Inc.	1992-12		LEGACY
>
> From this perspective I see nothing to indicate that 4/8 is in the ARIN
> region.

i do.  we're carrying WHOIS for it.  and if Level(3) wants to change the
4.IN-ADDR.ARPA addresses, we're who they'll talk to to get that done.  and
their world headquarters is in our region.  however, this example is not a
good one for another reason: if a full /8 comes back to an RIR, it's then
sent back to IANA.  (ARIN has already done this at least once.)  but if you
were to pick a longer-prefixed example, even its IN-ADDR would be inside a
block that's delegated to ARIN (or some RIR), and so it would be an even
worse example.  ARIN is the only party with anything that could be called
standing for legacy addresses in our region.  and ARIN would not hoard, by
its own definitions or in a way that caused the industry's growth to be
limited by address shortages, even if those shortages weren't in our region,
since such shortages would affect industry growth even within our region.

in san antonio, jcurran described the return-to-IANA policy for recovered
space as a "land grab".  i am surprised that we're still discussing it, but
perhaps the sense of the room changed after i left for the airport.  and in
case anyone here wonders why i'm wading into an issue on the AC list rather
than just lurking, it's because of my intense interest in the fiduciary
impact of any policy work in this area.
-- 
Paul Vixie
Chairman
ARIN BoT


From randy at psg.com  Fri Jun  5 23:10:20 2009
From: randy at psg.com (Randy Bush)
Date: Sat, 06 Jun 2009 12:10:20 +0900
Subject: [arin-ppml] [arin-council] Returning Legacy Space to
	IANA.	Attorney client communcation.
In-Reply-To: <g31vpygjk3.fsf@nsa.vix.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com>
Message-ID: <m24ouunjkz.wl%randy@psg.com>

> in san antonio, jcurran described the return-to-IANA policy for
> recovered space as a "land grab".

it isn't.  it is a test by lacnic to show that the arin region is run by
self-serving imperialist yanquis.

they believe, rightly or wrongly, that the us military will return,
under a deal made with arin, a large amount of ipv4 space in return for
the blocking of an amazing amount of ipv6 space.  lacnic, and others,
believe that, should this occur, that ipv4 space should be shared by
all.

so this proposal is a litmus test.  you are failing.

> and in case anyone here wonders why i'm wading into an issue on the AC
> list rather than just lurking

i think it's just the chair thinkinhg their opinion is so important that
a layering violation is warranted.

and this is not the AC list.

randy


From jcurran at istaff.org  Fri Jun  5 23:58:19 2009
From: jcurran at istaff.org (John Curran)
Date: Fri, 5 Jun 2009 23:58:19 -0400
Subject: [arin-ppml] [arin-council] Returning Legacy Space to	IANA.
	Attorney client communcation.
In-Reply-To: <m24ouunjkz.wl%randy@psg.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
Message-ID: <495EEB8C-DE28-426F-8582-295C2B475AD2@istaff.org>

On Jun 5, 2009, at 11:10 PM, Randy Bush wrote:

>> in san antonio, jcurran described the return-to-IANA policy for
>> recovered space as a "land grab".
>
> it isn't.  it is a test by lacnic to show that the arin region is  
> run by
> self-serving imperialist yanquis.

Since I'm being quoted out of context, this looks to be timely place
to respond.  I was one of the RIR Board members involved in drafting
the earliest version of this proposal, and I said to the AC the same
thing I said to my coauthors at the time, i.e. this proposal may not
get any actual usage, since the probability of large amounts of IPv4
returned space is low, and it's going to look like a "land grab" to
the very folks we're trying to entice to return unused IPv4 space.

> they believe, rightly or wrongly, that the us military will return,
> under a deal made with arin, a large amount of ipv4 space in return  
> for
> the blocking of an amazing amount of ipv6 space.  lacnic, and others,
> believe that, should this occur, that ipv4 space should be shared by
> all.
>
> so this proposal is a litmus test.  you are failing.

It certainly wasn't designed as a litmus test, it was written to
address a perceived theoretical inequality issue handling returned
IPv4 space. The real question that arises from this sort of policy
are whether it's actually appropriate to release space if there are
RIR's who have departed from need-based allocation and/or established
markets for monetization of these resources...

/John
John Curran
Acting President and CEO
ARIN




From scottleibrand at gmail.com  Sat Jun  6 00:47:33 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 05 Jun 2009 23:47:33 -0500
Subject: [arin-ppml] Another possible way forward on 2009-3
Message-ID: <4A29F4E5.3060203@gmail.com>

While attending the recent AfriNIC and especially LACNIC meetings the 
last couple weeks, I was struck by some
the discussions of the Global Policy Proposal for the Allocation of IPv4 
Blocks to Regional Internet Registries (our 2009-3).  Those discussions 
finally made it clear to me that one of the reasons 2009-3 is such a 
difficult policy to get consensus on is that the original policy, as 
proposed, is a global policy proposal that has some local policy 
aspects, namely that requires each RIR to return reclaimed space.  
Ideally, global policies are supposed to maintain a clean separation 
from local policies: global policy is supposed to only govern the 
relationship between the IANA and the RIRs, and local policy defines 
what the RIR can do internally.

As a side effect of the blurring of global and local policy in the 
current revision of 2009-3, we (and most of the other RIRs) are having 
an interesting debate about exactly which space should be covered by the 
policy (such as legacy vs. non-legacy), and some people are 
uncomfortable even with a legacy-only requirement.  So, as a result of a 
suggestion on the floor at LACNIC, and in an attempt to restore the 
proper separation between global and local policy, I drafted the 
following text for the 2nd paragraph of section A:

"Each RIR through their respective chosen policies and strategies may 
recover IPv4 address space which is under their administration and 
designate any such space for return to the IANA. Each RIR shall at 
quarterly intervals return any such designated address space to the IANA 
in aggregated blocks of /24 or larger, for inclusion in the recovered 
IPv4 pool."

Thoughts?

-Scott

P.S.  I also think we need to have a full public policy debate on what 
our chosen policies should be to designate recovered address space for 
return to IANA, but I think that is a separate local policy issue, and 
therefore deserves its own thread and eventually its own policy proposal.


From vixie at isc.org  Sat Jun  6 09:51:51 2009
From: vixie at isc.org (Paul Vixie)
Date: Sat, 06 Jun 2009 13:51:51 +0000
Subject: [arin-ppml] my apologies
Message-ID: <86726.1244296311@nsa.vix.com>

last night i sent mail to ppml that was meant for an internal arin list.
i plead jet lag; at the end of the full wakeful day following a transition
from utc+8 to utc-7 one set of e-mail headers looks much like another.
---
paul vixie
chairman
arin bot



From mueller at syr.edu  Sat Jun  6 14:20:21 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Sat, 6 Jun 2009 14:20:21 -0400
Subject: [arin-ppml] A modest proposal for IPv6 address allocations
In-Reply-To: <28E139F46D45AF49A31950F88C4974580183E229@E03MVZ2-UKDY.domain1.systemhost.net>
References: <75822E125BCB994F8446858C4B19F0D77B220A24@SUEX07-MBX-04.ad.syr.edu>
	<28E139F46D45AF49A31950F88C4974580183E229@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7E23@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of michael.dillon at bt.com
> 
> It never talks about huge numbers of host addresses. And it
> does reference RFC 2374 which explains how interface ids are
> constructed which makes it clear that the minimum subnet
> size is a /64. 

Yes.... The discussion was about "need" if you recall. If the minimum subnet is /64 then an architectural decision has been made that everyone "needs" at least a /64. A very odd definition of need.

> No addresses are wasted. Some bit combinations
> are never used but that is not waste

Ah. I see. No irony detected here. 
I would call unused and structurally unusable bit combinations in the thousands of billions "waste;" perhaps too strong a word but then to say "nothing is wasted" might go a wee bit too far in the other direction.

> neither IPv4 or
> IPv6 is architected in a way that all bit combinations could
> be used for endpoint addresses.

That is true, and it is true of all address spaces even outside of IP. But there are different levels of structural inefficiency; to say that nothing is perfect does not mean that all such differences are irrelevant.

> > Making finer distinctions requires massive investments in
> > organizational overhead: reviews, monitoring, etc.
> 
> Precisely the justification for having standard prefix lengths
> of /64, /48 and /32 in the first place. It massively cuts
> down the overhead of having to make fine grained measurements

Yes, indeed, I am with you here 100%. 

> outgrows its address allocation. IPv4 wastes money, but IPv6
> leverages a much longer bitstring to cut out that waste in
> overhead, monitoring, reviewing and restructuring the network
> to accomodate growth.

Yes, but the unresolved problem/issue -- which is where I had hoped the discussion would begin, not end -- was about how to ration subnet claims. Recall again Leo's post about "what is a subnet," which you dismissed. 


From michael.dillon at bt.com  Sat Jun  6 17:43:20 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sat, 6 Jun 2009 22:43:20 +0100
Subject: [arin-ppml] Policy Proposal: A Modest Proposal for an
	AlternateIPv6 Allocation Process
In-Reply-To: <3c3e3fca0906051820o5bd9a23bi2da17fd120feb500@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C4974580183E280@E03MVZ2-UKDY.domain1.systemhost.net>

> > it is disturbing to see the distinction between ISP and non-ISP 
> > allocations being blurred like this.

> Blurred nothing. I kicked the it to curb. This proposal makes 
> no distinction whatsoever between ISPs and anyone else. And 
> eliminating preferential treatment based on a frequently 
> artificial distinction doesn't disturb me at all.

Nevertheless, the distinction between network operators, 
and end-sites is fundamental to the way IP networks
function. Nobody has yet come up with a way to handle
a global network without having hierarchy in the network
and that means that the non-end-sites, must be treated
differently.

> > Not to mention that the complexity raises new barriers to 
> getting IPv6 
> > addresses which is not the way we should be heading.
> 
> What complexity? You're multihomed? You qualify. Done.

I'm not multihomed at all. I have DSL connectivity at home
and certainly do not qualify for an IPv6 allocation from any
RIR.

And your comment is way out of line. I'm not arguing that this
is too complex for the big ISPs like my employer, but I'm arguing
that it is too complex for the small guys who are up to their
ass in alligators just dealing with technical and business
issues. They don't need the additional bureaucracy that you 
propose. Today, these small ISPs go to ARIN, get their /32
and that is the end of it until 10 years from now when a
few of them have grown bigger than their wildest dreams.

Read up on the network effect. Large ISPs like my employer are
absolutely dependent on small ISPs because without the small
guys, there would be far less content and eyeballs on the
net. 

Your policy is a non-starter because it is tainted with the
dumb idea of /48 slowstart for ISPs, and because it tries to
do too many radical things. 

--Michael Dillon


From bill at herrin.us  Mon Jun  8 13:10:32 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 8 Jun 2009 13:10:32 -0400
Subject: [arin-ppml] Another possible way forward on 2009-3
In-Reply-To: <4A29F4E5.3060203@gmail.com>
References: <4A29F4E5.3060203@gmail.com>
Message-ID: <3c3e3fca0906081010j7f7398cufab886d9cbe4ce6e@mail.gmail.com>

On Sat, Jun 6, 2009 at 12:47 AM, Scott Leibrand<scottleibrand at gmail.com> wrote:
> "Each RIR through their respective chosen policies and strategies may
> recover IPv4 address space which is under their administration and designate
> any such space for return to the IANA. Each RIR shall at quarterly intervals
> return any such designated address space to the IANA in aggregated blocks of
> /24 or larger, for inclusion in the recovered IPv4 pool."
>
> Thoughts?

Scott,

I think that a proposal like 2009-3 that would have IANA try to
micromanage little bits of address space here and there in a
post-free-pool world is a genuinely bad idea. We created the regional
registries to avoid that kind of mess in the first place and I'd
respectfully suggest that ICANN's transparency problems and behavior
this past decade on the DNS side of things has validated that choice.

I also think that LACNIC and AfriNIC's principals understood that they
were entering the game late in the day, and that was likely to impact
their region's holdings come depletion. They are, after all, not
stupid. I respect that in serving their region's interests they must
now test the waters to determine how much give there is on the issue.
But 2009-3 ain't it.

I would instead encourage LACNIC to evaluate ARIN's holdings with an
eye for /8's with significant amounts of recoverable address space and
space assigned to registrants in what is now the LACNIC region versus
allocated space actually in use in the ARIN region. If you can
identify additional large blocks of address space that could
reasonably be ceded to your care, I doubt you'll find ARIN
uncooperative.

I realize that won't solve the big-picture issue either, but let's
face the reality check: nothing short of renumbering and a
redistribution of IP address wealth is going to meaningfully change
the IPv4 address distribution iniquity. And that's a non-starter.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From info at arin.net  Mon Jun  8 15:10:38 2009
From: info at arin.net (Member Services)
Date: Mon, 08 Jun 2009 15:10:38 -0400
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix Size
Message-ID: <4A2D622E.4030208@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at:https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


1. Policy Proposal: Predicable IPv4 Run Out by Prefix Size

2. Proposal Originator: David Farmer

3. Proposal Version: 1.0

4. Date: 8 June 2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

Create a new subsection in section 4 of the NRPM;

4.X Maximum Allocation or Assignment during and after Run-Out

When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a
maximum allocation and assignment size will be put into effect.  The
maximum allocation or assignment will be the next whole CIDR prefix less
than or equal to one quarter (1/4) of the total unrestricted IPv4
resources available to ARIN for allocation or assignment at the time,
but no longer than the applicable minimum allocation or assignment.  All
other allocation and assignment rules, requirements, or procedures apply
in addition.

If this maximum allocation or assignment provides insufficient
resources, additional resources may be request after a three (3) month
waiting period.

This section (4.x) is applicable to allocations and assignments from
ARIN's unrestricted IPv4 resources only, and is explicitly not
applicable to resources received through Transfers to Specified
Recipients per section 8.3, or any other specially designated resources.

8. Rationale:

This proposal is intended to insure an equitable distribution of the
remaining unrestricted IPv4 number resources available to ARIN once such
resources are no longer abundantly available from IANA.  Equity is
achieved by insuring the available resources are spread among multiple
entities and that no single entity may monopolize all of the resources
available through a single request, at least until the maximum equals
the minimum allocation or assignment size.

Reducing the maximum allocation or assignment size in proportion to the
amount of resources available should minimize, or possibly eliminate,
the need to fulfill requests with multiple smaller blocks.

Beyond providing predictability and order during the run out phase, this
proposal provides an equitable means of distribution of resources if or
when additional resources become available after ARIN has initially
exhausted such resources.  Such as if resources are returned, recovered
by other means, or further resources are obtained from IANA.

Other ratios, such as one half (1/2) or one eighth (1/8) could be
considered.  One eighth (1/8) would provide greater assurance of
eliminating the need to use multiple blocks to fulfill requests and
insure a greater number of entities receive resources.  However, one
eighth (1/8) is more likely to be seen as rationing and an attempt to
artificially extend the lifetime of IPv4.  During the ARIN XXIII policy
discussion there seemed to be a consensus that attempts to extend the
lifetime IPv4 resources would be undesirable.  While on the other hand,
one half (1/2) is less likely to ration the resources, it would likely
result in the resource being spread across significantly fewer entities
and increase the need to use multiple blocks to fulfill requests.
Therefore, the ratio one quarter (1/4) is proposed as a compromise
between competing sets of goals.

9. Timetable for implementation:  Immediate





From info at arin.net  Mon Jun  8 15:54:55 2009
From: info at arin.net (Member Services)
Date: Mon, 08 Jun 2009 15:54:55 -0400
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out by Allocation
	Window
Message-ID: <4A2D6C8F.4000605@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at:https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


   1. Policy Proposal: Predictable IPv4 Run Out by Allocation Window

   2. Proposal Originator: Leo Bicknell

   3. Proposal Version: 1.0

   4. Date: 8 June 2009

   5. Proposal type: modify

   6. Policy term: permanent

   7. Policy statement:

      Replace the text in NRPM 4.2.4.4 with:

      After an organization has been a subscriber member of ARIN for one
      year, they may choose to request up to a 12 month supply of IP
      addresses.

      Starting on 1 July 2010, a gradual reduction in the allocation
      period will be applied as follows:

      As of 1 July 2010, they may choose to request up to a 9 month
      supply.

      As of 1 January 2011, they may choose to request up to a 6 month
      supply.

      As of 1 July 2011, they may choose to request up to a 3 month
      supply.

   8. Rationale:

      During the ARIN XXIII policy discussion several individuals
      described ideas similar to RIPE policy proposal 2009-03
      (http://www.ripe.net/ripe/policies/proposals/2009-03.html).
      This policy adapts the same idea into an ARIN policy for
      discussion in this region.

      From the RIPE proposal:

] This is a proposal to gradually reduce the allocation and assignment
] periods in step with the expected life time of the IPv4 unallocated
] pool in order to address the perception of unfairness once the pool
] has run out.
]
] The proposal is not intended to stretch the lifetime of the
] unallocated pool.
]
] The proposal is independent of other proposals to reserve address
] space for transition purposes and/or new entrants. It can be
] implemented independently of these.

   9. Timetable for implementation: Immediate




From dogwallah at gmail.com  Mon Jun  8 16:52:05 2009
From: dogwallah at gmail.com (McTim)
Date: Mon, 8 Jun 2009 23:52:05 +0300
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out by
	Allocation Window
In-Reply-To: <4A2D6C8F.4000605@arin.net>
References: <4A2D6C8F.4000605@arin.net>
Message-ID: <f65fb55e0906081352t16355f00rf8f4a370406beeac@mail.gmail.com>

HI Leo,

I prefer this method, as it maintains the idea that we allocate
and assign based on need.

The "rationing" (IPv4 run out by prefix size) proposal
fundamentally alters the notion of needs based allocation.

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


On 6/8/09, Member Services <info at arin.net> wrote:

> ## * ##
>
>
>    1. Policy Proposal: Predictable IPv4 Run Out by Allocation Window
>
>    2. Proposal Originator: Leo Bicknell
>
>    3. Proposal Version: 1.0
>
>    4. Date: 8 June 2009
>
>    5. Proposal type: modify
>
>    6. Policy term: permanent
>
>    7. Policy statement:
>
>       Replace the text in NRPM 4.2.4.4 with:
>
>       After an organization has been a subscriber member of ARIN for one
>       year, they may choose to request up to a 12 month supply of IP
>       addresses.
>
>       Starting on 1 July 2010, a gradual reduction in the allocation
>       period will be applied as follows:
>
>       As of 1 July 2010, they may choose to request up to a 9 month
>       supply.
>
>       As of 1 January 2011, they may choose to request up to a 6 month
>       supply.
>
>       As of 1 July 2011, they may choose to request up to a 3 month
>       supply.
>
>    8. Rationale:
>
>       During the ARIN XXIII policy discussion several individuals
>       described ideas similar to RIPE policy proposal 2009-03
>       (http://www.ripe.net/ripe/policies/proposals/2009-03.html).
>       This policy adapts the same idea into an ARIN policy for
>       discussion in this region.
>
>       From the RIPE proposal:
>
> ] This is a proposal to gradually reduce the allocation and assignment
> ] periods in step with the expected life time of the IPv4 unallocated
> ] pool in order to address the perception of unfairness once the pool
> ] has run out.
> ]
> ] The proposal is not intended to stretch the lifetime of the
> ] unallocated pool.
> ]
> ] The proposal is independent of other proposals to reserve address
> ] space for transition purposes and/or new entrants. It can be
> ] implemented independently of these.
>
>    9. Timetable for implementation: Immediate
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From terry.l.davis at boeing.com  Mon Jun  8 17:23:07 2009
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 8 Jun 2009 14:23:07 -0700
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out
 byAllocation Window
In-Reply-To: <f65fb55e0906081352t16355f00rf8f4a370406beeac@mail.gmail.com>
References: <4A2D6C8F.4000605@arin.net>
	<f65fb55e0906081352t16355f00rf8f4a370406beeac@mail.gmail.com>
Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F552F@XCH-NW-CCR1V.nw.nos.boeing.com>

McTim

There's an important element here that we may have overlooked; "critical services" and "critical infrastructure" globally.  

There are set of folks around the globe that do need priority in the allocations.  And despite some of their best intentions and work, they have not been able to yet get budget allocations from their sponsors (enterprises or governments where politics/budget must be worked) to migrate their services to IPv6.  

I don't claim to know how to adjudicate the need; just that it will exist.

Take care
Terry

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of McTim
> Sent: Monday, June 08, 2009 1:52 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out
> byAllocation Window
> 
> HI Leo,
> 
> I prefer this method, as it maintains the idea that we allocate
> and assign based on need.
> 
> The "rationing" (IPv4 run out by prefix size) proposal
> fundamentally alters the notion of needs based allocation.
> 
> --
> Cheers,
> 
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there."  Jon Postel
> 
> 
> On 6/8/09, Member Services <info at arin.net> wrote:
> 
> > ## * ##
> >
> >
> >    1. Policy Proposal: Predictable IPv4 Run Out by Allocation Window
> >
> >    2. Proposal Originator: Leo Bicknell
> >
> >    3. Proposal Version: 1.0
> >
> >    4. Date: 8 June 2009
> >
> >    5. Proposal type: modify
> >
> >    6. Policy term: permanent
> >
> >    7. Policy statement:
> >
> >       Replace the text in NRPM 4.2.4.4 with:
> >
> >       After an organization has been a subscriber member of ARIN for one
> >       year, they may choose to request up to a 12 month supply of IP
> >       addresses.
> >
> >       Starting on 1 July 2010, a gradual reduction in the allocation
> >       period will be applied as follows:
> >
> >       As of 1 July 2010, they may choose to request up to a 9 month
> >       supply.
> >
> >       As of 1 January 2011, they may choose to request up to a 6 month
> >       supply.
> >
> >       As of 1 July 2011, they may choose to request up to a 3 month
> >       supply.
> >
> >    8. Rationale:
> >
> >       During the ARIN XXIII policy discussion several individuals
> >       described ideas similar to RIPE policy proposal 2009-03
> >       (http://www.ripe.net/ripe/policies/proposals/2009-03.html).
> >       This policy adapts the same idea into an ARIN policy for
> >       discussion in this region.
> >
> >       From the RIPE proposal:
> >
> > ] This is a proposal to gradually reduce the allocation and assignment
> > ] periods in step with the expected life time of the IPv4 unallocated
> > ] pool in order to address the perception of unfairness once the pool
> > ] has run out.
> > ]
> > ] The proposal is not intended to stretch the lifetime of the
> > ] unallocated pool.
> > ]
> > ] The proposal is independent of other proposals to reserve address
> > ] space for transition purposes and/or new entrants. It can be
> > ] implemented independently of these.
> >
> >    9. Timetable for implementation: Immediate
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From petelists at templin.org  Mon Jun  8 17:06:01 2009
From: petelists at templin.org (Pete Templin)
Date: Mon, 08 Jun 2009 16:06:01 -0500
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
 Size
In-Reply-To: <4A2D622E.4030208@arin.net>
References: <4A2D622E.4030208@arin.net>
Message-ID: <4A2D7D39.3050702@templin.org>

Member Services wrote:

> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.

Can we somehow provide some clarity sooner rather than later?  At a high 
level, is this policy proposal really suggesting that 4-7 large-enough 
ISPs could wipe out all of ARIN's IPv4 free pool?  At a lower level, the 
composition of this proposal hurts my head, with things like "insure" 
vs. "ensure", or "at least until the maximum equals the minimum 
allocation or assignment size".

Pete


From owen at delong.com  Mon Jun  8 18:20:54 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 8 Jun 2009 15:20:54 -0700
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
	Size
In-Reply-To: <4A2D7D39.3050702@templin.org>
References: <4A2D622E.4030208@arin.net> <4A2D7D39.3050702@templin.org>
Message-ID: <8DE1F40F-F6C6-46DE-A6A9-2E47486D41E3@delong.com>


On Jun 8, 2009, at 2:06 PM, Pete Templin wrote:

> Member Services wrote:
>
>> This proposal is in the first stage of the Policy Development  
>> Process.
>> ARIN staff will perform the Clarity and Understanding step. Staff  
>> does
>> not evaluate the proposal at this time, their goal is to make sure  
>> that
>> they understand the proposal and believe the community will as well.
>> Staff will report their results to the ARIN Advisory Council (AC)  
>> within
>> 10 days.
>
> Can we somehow provide some clarity sooner rather than later?  At a  
> high level, is this policy proposal really suggesting that 4-7 large- 
> enough ISPs could wipe out all of ARIN's IPv4 free pool?  At a lower  
> level, the composition of this proposal hurts my head, with things  
> like "insure" vs. "ensure", or "at least until the maximum equals  
> the minimum allocation or assignment size".
>

The reality is that in the coming months, we will reach a point where a
single large-enough ISP's request could wipe out all of ARIN's IPv4
free pool. As such, the proposal attempts to create a system where
no single request can get more than some portion of what remains
until a point is reached where all that remains is a single minimum
size allocation.

I hope that clarifies.

Owen



From dave at temk.in  Mon Jun  8 18:48:33 2009
From: dave at temk.in (Dave Temkin)
Date: Mon, 08 Jun 2009 15:48:33 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
Message-ID: <4A2D9541.3000608@temk.in>

I'm going to attempt to keep this brief, but here goes:

Recently, I received a /48.  After beginning our rollout, I quickly 
discovered that we'd need a /44 at the very least.  See, I have multiple 
networks that are not interconnected by a common backbone, and so a 
single /48 would leave me with a useless routing domain given that most 
people prefix filter at le /48.

Currently, each OrgID is entitled to only one /48.  Under IPv4, if you 
operate separate, disparate networks you're allowed to request multiple 
blocks under the Multiple Discrete Networks policy.  No such policy 
exists for IPv6, however it's been proposed here:  
https://www.arin.net/policy/nrpm.html#six583

I'd love to hear suggestions on workarounds until such the proposed 
policy would be voted on and implemented. PA addressing is not a viable 
option.

If we expect IPv6 adoption to have a significant uptick we need to take 
away silly barriers to addressing such as this and make address 
assignments accessible for the common ASP or Enterprise - and right now 
it's definitely not.


-Dave


From NOC at ChangeIP.com  Mon Jun  8 19:06:52 2009
From: NOC at ChangeIP.com (NOC at ChangeIP.com)
Date: Mon, 8 Jun 2009 16:06:52 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
References: <4A2D9541.3000608@temk.in>
Message-ID: <C372A5D056554C338D1E07E542CFD206@changeip.com>

> Recently, I received a /48.  After beginning our rollout, I quickly 
> discovered that we'd need a /44 at the very least.  See, I have multiple 
> networks that are not interconnected by a common backbone, and so a 
> single /48 would leave me with a useless routing domain given that most 
> people prefix filter at le /48.
> 
> Currently, each OrgID is entitled to only one /48.  Under IPv4, if you 
> operate separate, disparate networks you're allowed to request multiple 
> blocks under the Multiple Discrete Networks policy.  No such policy 
> exists for IPv6, however it's been proposed here:  
> https://www.arin.net/policy/nrpm.html#six583

I have this same problem...


From scottleibrand at gmail.com  Mon Jun  8 19:17:53 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 08 Jun 2009 18:17:53 -0500
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2D9541.3000608@temk.in>
References: <4A2D9541.3000608@temk.in>
Message-ID: <4A2D9C21.4010507@gmail.com>

Dave,

I think you may be referring to the "IPv6 Multiple Discrete Networks" 
policy proposal at 
http://lists.arin.net/pipermail/arin-ppml/2009-March/013129.html

Would that proposal, if adopted, resolve your issue?  If so, it should 
be up for discussion at the fall meeting in Dearborn.

-Scott


Dave Temkin wrote:
> I'm going to attempt to keep this brief, but here goes:
>
> Recently, I received a /48.  After beginning our rollout, I quickly 
> discovered that we'd need a /44 at the very least.  See, I have 
> multiple networks that are not interconnected by a common backbone, 
> and so a single /48 would leave me with a useless routing domain given 
> that most people prefix filter at le /48.
>
> Currently, each OrgID is entitled to only one /48.  Under IPv4, if you 
> operate separate, disparate networks you're allowed to request 
> multiple blocks under the Multiple Discrete Networks policy.  No such 
> policy exists for IPv6, however it's been proposed here:  
> https://www.arin.net/policy/nrpm.html#six583
>
> I'd love to hear suggestions on workarounds until such the proposed 
> policy would be voted on and implemented. PA addressing is not a 
> viable option.
>
> If we expect IPv6 adoption to have a significant uptick we need to 
> take away silly barriers to addressing such as this and make address 
> assignments accessible for the common ASP or Enterprise - and right 
> now it's definitely not.
>
>
> -Dave
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From dave at temk.in  Mon Jun  8 19:25:43 2009
From: dave at temk.in (Dave Temkin)
Date: Mon, 08 Jun 2009 16:25:43 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2D9C21.4010507@gmail.com>
References: <4A2D9541.3000608@temk.in> <4A2D9C21.4010507@gmail.com>
Message-ID: <4A2D9DF7.7090503@temk.in>

Scott,

Yes, it definitely would resolve my issue.  The long and short of it 
means that if that's the only workaround that my deployment will be 
delayed until at least Dearborn...  Not exactly making IPv6 available to 
the masses.

-Dave



Scott Leibrand wrote:
> Dave,
>
> I think you may be referring to the "IPv6 Multiple Discrete Networks" 
> policy proposal at 
> http://lists.arin.net/pipermail/arin-ppml/2009-March/013129.html
>
> Would that proposal, if adopted, resolve your issue?  If so, it should 
> be up for discussion at the fall meeting in Dearborn.
>
> -Scott
>
>
> Dave Temkin wrote:
>> I'm going to attempt to keep this brief, but here goes:
>>
>> Recently, I received a /48.  After beginning our rollout, I quickly 
>> discovered that we'd need a /44 at the very least.  See, I have 
>> multiple networks that are not interconnected by a common backbone, 
>> and so a single /48 would leave me with a useless routing domain 
>> given that most people prefix filter at le /48.
>>
>> Currently, each OrgID is entitled to only one /48.  Under IPv4, if 
>> you operate separate, disparate networks you're allowed to request 
>> multiple blocks under the Multiple Discrete Networks policy.  No such 
>> policy exists for IPv6, however it's been proposed here:  
>> https://www.arin.net/policy/nrpm.html#six583
>>
>> I'd love to hear suggestions on workarounds until such the proposed 
>> policy would be voted on and implemented. PA addressing is not a 
>> viable option.
>>
>> If we expect IPv6 adoption to have a significant uptick we need to 
>> take away silly barriers to addressing such as this and make address 
>> assignments accessible for the common ASP or Enterprise - and right 
>> now it's definitely not.
>>
>>
>> -Dave
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.



From kloch at kl.net  Mon Jun  8 19:29:26 2009
From: kloch at kl.net (Kevin Loch)
Date: Mon, 08 Jun 2009 19:29:26 -0400
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out
 byAllocation Window
In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F552F@XCH-NW-CCR1V.nw.nos.boeing.com>
References: <4A2D6C8F.4000605@arin.net>	<f65fb55e0906081352t16355f00rf8f4a370406beeac@mail.gmail.com>
	<2557049CDBC35B4EBD79CFACFEC045841B9F552F@XCH-NW-CCR1V.nw.nos.boeing.com>
Message-ID: <4A2D9ED6.7010709@kl.net>

Davis, Terry L wrote:
> McTim
> 
> There's an important element here that we may have overlooked; "critical services" and "critical infrastructure" globally.  
> 
> There are set of folks around the globe that do need priority in the allocations.  And despite some of their best intentions and work, they have not been able to yet get budget allocations from their sponsors (enterprises or governments where politics/budget must be worked) to migrate their services to IPv6.  
> 
> I don't claim to know how to adjudicate the need; just that it will exist.

Do you have an example of critical services or infrastructure that does
not already have IP addresses assigned to it?

- Kevin



From stephen at sprunk.org  Mon Jun  8 19:38:45 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 08 Jun 2009 18:38:45 -0500
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out
 byAllocation Window
In-Reply-To: <2557049CDBC35B4EBD79CFACFEC045841B9F552F@XCH-NW-CCR1V.nw.nos.boeing.com>
References: <4A2D6C8F.4000605@arin.net>	<f65fb55e0906081352t16355f00rf8f4a370406beeac@mail.gmail.com>
	<2557049CDBC35B4EBD79CFACFEC045841B9F552F@XCH-NW-CCR1V.nw.nos.boeing.com>
Message-ID: <4A2DA105.1040202@sprunk.org>

Davis, Terry L wrote:
> There's an important element here that we may have overlooked; "critical services" and "critical infrastructure" globally.  
>
> There are set of folks around the globe that do need priority in the allocations.  And despite some of their best intentions and work, they have not been able to yet get budget allocations from their sponsors (enterprises or governments where politics/budget must be worked) to migrate their services to IPv6.  
>
> I don't claim to know how to adjudicate the need; just that it will exist.
>   

While the text of the proposal simply says "IP addresses", the title
implies that it should only affect IPv4 addresses and I would expect the
AC to make that editorial change.

With that assumption, I do not see how this could possibly affect IPv6
deployments, by "critical infrastructure" folks or anyone else for that
matter.  Could you explain your thinking on that?

I do see a potential problem that CI folks may not be able to get any
IPv4 space at all after exhaustion, and I would be interested in a
proposal to set aside some space for them, but I don't think that this
is the right thread to address that.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090608/c18e9e37/attachment.bin>

From farmer at umn.edu  Mon Jun  8 19:46:48 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 08 Jun 2009 18:46:48 -0500
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out
	byAllocation Window
In-Reply-To: <4A2DA105.1040202@sprunk.org>
References: <4A2D6C8F.4000605@arin.net>,
	<2557049CDBC35B4EBD79CFACFEC045841B9F552F@XCH-NW-CCR1V.nw.nos.boeing.com>,
	<4A2DA105.1040202@sprunk.org>
Message-ID: <4A2D5C98.2395.F549413@farmer.umn.edu>

This is proposed for section 4 of the NRPM, section 4 only 
deals with IPv4, section 6 only deals with IPv6.  It is only 
policies in the other sections that need to worry about being 
specific about IPv4 or IPv6 if needed as the section they are 
contained in doesn't imply which type of resource we are 
talking about. 

On 8 Jun 2009 Stephen Sprunk wrote:

> Davis, Terry L wrote:
> > There's an important element here that we may have overlooked;
> > "critical services" and "critical infrastructure" globally.  
> >
> > There are set of folks around the globe that do need priority in the
> > allocations.  And despite some of their best intentions and work,
> > they have not been able to yet get budget allocations from their
> > sponsors (enterprises or governments where politics/budget must be
> > worked) to migrate their services to IPv6.  
> >
> > I don't claim to know how to adjudicate the need; just that it will
> > exist.
> >   
> 
> While the text of the proposal simply says "IP addresses", the title
> implies that it should only affect IPv4 addresses and I would expect
> the AC to make that editorial change.
> 
> With that assumption, I do not see how this could possibly affect IPv6
> deployments, by "critical infrastructure" folks or anyone else for
> that matter.  Could you explain your thinking on that?
> 
> I do see a potential problem that CI folks may not be able to get any
> IPv4 space at all after exhaustion, and I would be interested in a
> proposal to set aside some space for them, but I don't think that this
> is the right thread to address that.
> 
> S
> 
> -- 
> Stephen Sprunk         "God does not play dice."  --Albert Einstein
> CCIE #3723         "God is an inveterate gambler, and He throws the
> K5SSS        dice at every possible opportunity." --Stephen Hawking
> 
> 



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From stephen at sprunk.org  Mon Jun  8 19:51:39 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 08 Jun 2009 18:51:39 -0500
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2D9541.3000608@temk.in>
References: <4A2D9541.3000608@temk.in>
Message-ID: <4A2DA40B.9040905@sprunk.org>

Dave Temkin wrote:
> I'm going to attempt to keep this brief, but here goes:
>
> Recently, I received a /48.  After beginning our rollout, I quickly
> discovered that we'd need a /44 at the very least.  See, I have
> multiple networks that are not interconnected by a common backbone,
> and so a single /48 would leave me with a useless routing domain given
> that most people prefix filter at le /48.

That's an understandable and very specific problem.  Thanks!

> Currently, each OrgID is entitled to only one /48.

An org is entitled to one /48 _without justification_, and there is a
specific rule on what constitutes justification for more.  According to
ARIN's stats, several blocks from /47 to /40 have been assigned, so it
is indeed possible:
https://www.arin.net/knowledge/statistics/statistics.pdf

> Under IPv4, if you operate separate, disparate networks you're allowed
> to request multiple blocks under the Multiple Discrete Networks
> policy.  No such policy exists for IPv6, however it's been proposed
> here:  https://www.arin.net/policy/nrpm.html#six583

I think you mean:
http://lists.arin.net/pipermail/arin-ppml/2009-March/013129.html

> I'd love to hear suggestions on workarounds until such the proposed
> policy would be voted on and implemented. PA addressing is not a
> viable option.

I can't think of any workarounds if you do not meet the existing policy
requirements in 6.5.8.3.

> If we expect IPv6 adoption to have a significant uptick we need to
> take away silly barriers to addressing such as this and make address
> assignments accessible for the common ASP or Enterprise - and right
> now it's definitely not.

Many of us are working towards exactly that goal, but we need to know
what the barriers are to legitimate assignments/allocations and how we
can address them without simply opening the floodgates to _everyone_
getting a block -- and a routing slot in the DFZ.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090608/ef282e65/attachment.bin>

From farmer at umn.edu  Mon Jun  8 20:15:54 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 08 Jun 2009 19:15:54 -0500
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
	Size
In-Reply-To: <4A2D7D39.3050702@templin.org>
References: <4A2D622E.4030208@arin.net>, <4A2D7D39.3050702@templin.org>
Message-ID: <4A2D636A.13087.F6F36CD@farmer.umn.edu>

On 8 Jun 2009 Pete Templin wrote:

> Member Services wrote:
> 
> > This proposal is in the first stage of the Policy Development
> > Process. ARIN staff will perform the Clarity and Understanding step.
> > Staff does not evaluate the proposal at this time, their goal is to
> > make sure that they understand the proposal and believe the
> > community will as well. Staff will report their results to the ARIN
> > Advisory Council (AC) within 10 days.
> 
> Can we somehow provide some clarity sooner rather than later?  At a
> high level, is this policy proposal really suggesting that 4-7
> large-enough ISPs could wipe out all of ARIN's IPv4 free pool?  

First of all as Owen points out, a single large enough ISP could wipe out all 
of ARIN's IPv4 free pool as the policies currently stands without something 
like this, even if you reduce the allocation window as in the other proposal.  I 
believe this to be a big problem and it is not equitable.  

I'm trying to avoid the word fair in this discussion because as was pointed out 
several times at ARIN XXIII there are multiple kinds of fairness.  I'm not really 
sure equitable is a much better word.  But in using the word I'm intending the 
following;  EQUITABILITY - The assessment of the fairness of a measure in 
its distribution of favorable or unfavorable impacts across the economic, 
environmental, social, and political interests that are affected.
 
You have the right idea, but not the right numbers,  with the proposed one 
quarter (1/4) ratio and starting at /8,  a geometric progression is created, 
such that if all allocations were of a maximum size available at the time, it 
would take 24 separate requests to wipe out the pool.  A ratio of one half 
(1/2) would require 13 maximum size requests, a ratio of one eighth (1/8) 
would require 44 maximum size requests, and a ratio one sixteenth (1/16) 
would require 80 maximum size requests.

See the following Google Docs spread sheet from more details, there are 
separate tabs for one half, one quarter, one eighth, and one sixteenth;

http://spreadsheets.google.com/ccc?key=r2IDwxI-feUNacGABcvopnQ

Please realize all requests will not be of a maximum size, the numbers above 
are purely the worst case scenario.  Also, exactly how much ARIN has in the 
IPv4 pool when this policy is triggered depends on when 10.4.2.2 is triggered 
and if it is a request form ARIN that triggers it or a request from one of the 
other RIRs.  I think in theory it could be as much as three (3) /8s or as little 
as three (3) /10s receptively in the best or worst possible timing.  I suspect 
something a little more than /8 is probably about right.  But to make the math 
in the spread sheet easier I went with an exact /8 scenario.

> At a lower level, the composition of this proposal hurts my head, with
> things like "insure" vs. "ensure", or "at least until the maximum
> equals the minimum allocation or assignment size". 

Sorry that my bad grammar is causing your a head to hurt, I'll fix the 
insure/ensure.  Would "at least until the maximum decrements down to the  
minimum allocation or assignment size" be better?  If not, do you have a 
better suggestion?

Anything else making your head hurt?

Another way to think about this, it is what your grandma taught you, don't cut 
yourself to big of a pice of pie until everyone else has had some.  Since I'm 
not sure how ARIN would pick who's grandma to hire to implement this we 
need to write a policy that does much the same thing.

> Pete
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From dave at temk.in  Mon Jun  8 20:12:46 2009
From: dave at temk.in (Dave Temkin)
Date: Mon, 08 Jun 2009 17:12:46 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2DA40B.9040905@sprunk.org>
References: <4A2D9541.3000608@temk.in> <4A2DA40B.9040905@sprunk.org>
Message-ID: <4A2DA8FE.20101@temk.in>

Stephen Sprunk wrote:
> Dave Temkin wrote:
>   
>> I'm going to attempt to keep this brief, but here goes:
>>
>> Recently, I received a /48.  After beginning our rollout, I quickly
>> discovered that we'd need a /44 at the very least.  See, I have
>> multiple networks that are not interconnected by a common backbone,
>> and so a single /48 would leave me with a useless routing domain given
>> that most people prefix filter at le /48.
>>     
>
> That's an understandable and very specific problem.  Thanks!
>
>   
>> Currently, each OrgID is entitled to only one /48.
>>     
>
> An org is entitled to one /48 _without justification_, and there is a
> specific rule on what constitutes justification for more.  According to
> ARIN's stats, several blocks from /47 to /40 have been assigned, so it
> is indeed possible:
> https://www.arin.net/knowledge/statistics/statistics.pdf
>   


Correct, and I'm not sure where the blocker is.  I highly doubt that 
anyone's fully utilized a /48 yet.

>   
>> Under IPv4, if you operate separate, disparate networks you're allowed
>> to request multiple blocks under the Multiple Discrete Networks
>> policy.  No such policy exists for IPv6, however it's been proposed
>> here:  https://www.arin.net/policy/nrpm.html#six583
>>     
>
> I think you mean:
> http://lists.arin.net/pipermail/arin-ppml/2009-March/013129.html
>   


Yes, sorry, my bad.

>   
>> I'd love to hear suggestions on workarounds until such the proposed
>> policy would be voted on and implemented. PA addressing is not a
>> viable option.
>>     
>
> I can't think of any workarounds if you do not meet the existing policy
> requirements in 6.5.8.3.
>
>   
>> If we expect IPv6 adoption to have a significant uptick we need to
>> take away silly barriers to addressing such as this and make address
>> assignments accessible for the common ASP or Enterprise - and right
>> now it's definitely not.
>>     
>
> Many of us are working towards exactly that goal, but we need to know
> what the barriers are to legitimate assignments/allocations and how we
> can address them without simply opening the floodgates to _everyone_
> getting a block -- and a routing slot in the DFZ.
>   


Understood, but we need a better exception policy in place other than 
"We'll get to it at the next meeting" if we're going to foster 
development in such an evolving space.

-Dave
> S
>
>   



From farmer at umn.edu  Mon Jun  8 20:29:25 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 08 Jun 2009 19:29:25 -0500
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2DA8FE.20101@temk.in>
References: <4A2D9541.3000608@temk.in>, <4A2DA40B.9040905@sprunk.org>,
	<4A2DA8FE.20101@temk.in>
Message-ID: <4A2D6695.17889.F7B9907@farmer.umn.edu>

On 8 Jun 2009 Dave Temkin wrote:

> Understood, but we need a better exception policy in place other than
> "We'll get to it at the next meeting" if we're going to foster
> development in such an evolving space.

Well there is the Emergency PDP, but by most accounts that 
didn't work very well with 2009-1.  I'm thinking it would have to 
be a really big problem and non-controversial to get the board 
to try another run at the Emergency PDP anytime soon.

I'm not saying your wrong, I'm just trying to think about how it 
would work without creating a loophole you can drive a convoy 
of trucks through.

Any specific ideas?


===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From owen at delong.com  Mon Jun  8 20:25:46 2009
From: owen at delong.com (Owen DeLong)
Date: Mon, 8 Jun 2009 17:25:46 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2D9541.3000608@temk.in>
References: <4A2D9541.3000608@temk.in>
Message-ID: <5F3383FC-BB7B-4E53-983F-8FFC5BE8F021@delong.com>

I believe that situation is exactly what proposal 84 is intended to  
rectify.

Unfortunately, I do not have a good answer for you under current policy.

I would urge you to review proposal 84, and, if you feel this  
addresses your
needs, be vocal in your support for it to become policy.

Owen

On Jun 8, 2009, at 3:48 PM, Dave Temkin wrote:

> I'm going to attempt to keep this brief, but here goes:
>
> Recently, I received a /48.  After beginning our rollout, I quickly  
> discovered that we'd need a /44 at the very least.  See, I have  
> multiple networks that are not interconnected by a common backbone,  
> and so a single /48 would leave me with a useless routing domain  
> given that most people prefix filter at le /48.
>
> Currently, each OrgID is entitled to only one /48.  Under IPv4, if  
> you operate separate, disparate networks you're allowed to request  
> multiple blocks under the Multiple Discrete Networks policy.  No  
> such policy exists for IPv6, however it's been proposed here:  https://www.arin.net/policy/nrpm.html 
> #six583
>
> I'd love to hear suggestions on workarounds until such the proposed  
> policy would be voted on and implemented. PA addressing is not a  
> viable option.
>
> If we expect IPv6 adoption to have a significant uptick we need to  
> take away silly barriers to addressing such as this and make address  
> assignments accessible for the common ASP or Enterprise - and right  
> now it's definitely not.
>
>
> -Dave
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From packetgrrl at gmail.com  Mon Jun  8 21:16:18 2009
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Mon, 8 Jun 2009 19:16:18 -0600
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <5F3383FC-BB7B-4E53-983F-8FFC5BE8F021@delong.com>
References: <4A2D9541.3000608@temk.in>
	<5F3383FC-BB7B-4E53-983F-8FFC5BE8F021@delong.com>
Message-ID: <c3227e9e0906081816k7e7ccebaj8ff017395818463@mail.gmail.com>

I'd like to further encourage those of you who need this to participate in
the Dearborn meeting whether in person or remotely.
Thanks
----Cathy

On Mon, Jun 8, 2009 at 6:25 PM, Owen DeLong <owen at delong.com> wrote:

> I believe that situation is exactly what proposal 84 is intended to
> rectify.
>
> Unfortunately, I do not have a good answer for you under current policy.
>
> I would urge you to review proposal 84, and, if you feel this addresses
> your
> needs, be vocal in your support for it to become policy.
>
> Owen
>
>
> On Jun 8, 2009, at 3:48 PM, Dave Temkin wrote:
>
>  I'm going to attempt to keep this brief, but here goes:
>>
>> Recently, I received a /48.  After beginning our rollout, I quickly
>> discovered that we'd need a /44 at the very least.  See, I have multiple
>> networks that are not interconnected by a common backbone, and so a single
>> /48 would leave me with a useless routing domain given that most people
>> prefix filter at le /48.
>>
>> Currently, each OrgID is entitled to only one /48.  Under IPv4, if you
>> operate separate, disparate networks you're allowed to request multiple
>> blocks under the Multiple Discrete Networks policy.  No such policy exists
>> for IPv6, however it's been proposed here:
>> https://www.arin.net/policy/nrpm.html#six583
>>
>> I'd love to hear suggestions on workarounds until such the proposed policy
>> would be voted on and implemented. PA addressing is not a viable option.
>>
>> If we expect IPv6 adoption to have a significant uptick we need to take
>> away silly barriers to addressing such as this and make address assignments
>> accessible for the common ASP or Enterprise - and right now it's definitely
>> not.
>>
>>
>> -Dave
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090608/a7a6145f/attachment.htm>

From farmer at umn.edu  Mon Jun  8 21:49:46 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 08 Jun 2009 20:49:46 -0500
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out by
	Allocation Window
In-Reply-To: <f65fb55e0906081352t16355f00rf8f4a370406beeac@mail.gmail.com>
References: <4A2D6C8F.4000605@arin.net>,
	<f65fb55e0906081352t16355f00rf8f4a370406beeac@mail.gmail.com>
Message-ID: <4A2D796A.24442.FC52A09@farmer.umn.edu>

I believe that the two proposals are complementary and that 
they both should be implemented.

Both proposals are based on need, they simply deal with the 
consequences of the fact that need will exceed supply and we 
will run out.  They each do it in slightly different ways.

Reducing the allocation window, helps interleave the need a bit 
better and I believe is necessary, but it doesn't deal with the 
terminal inequities of how to split up that last little bits. 

Our current policies don't need to deal with how to equitably 
apportion resources.  Its just not an issue because when ARIN 
runs low they simply get more, so there is no questions of 
equity in the current system.  But when the demand outstrips 
supply equity will become a question we need to answer.

An example;  Imagine NYBISP (Name Your Big ISP) justifies a 
/8 pers year, we reduce that to a 3 month allocation window 
they still justify about a /10 per 3 month period, ARIN is down 
to the last /10 should NYBISP get all the address space ARIN 
has?  Are you ready for the political storm if that is what 
happens?  We can't blame NYBISP because they just did what 
we told them to do, they are playing by the rules.

I'm not saying that big ISPs are bad, I'm just saying that if we 
tell the big ISPs it is ok to clean out ARIN of IPv4 addresses in 
a single request they can and will.  And we can't blame them 
when they do.

If you look at the spread sheets linked here, I wouldn't classify 
this as rationing at least not with the one half or one quarter 
ratios, maybe it is rationing at the one eighth or one sixteenth 
ratios.

http://spreadsheets.google.com/ccc?key=r2IDwxI-
feUNacGABcvopnQ

Even if you insist on calling it rationing, I believe it is very 
minimal rationing.  And it is not rationing for rationing sake, the 
limit is in proportion to the amount of resources ARIN has, if 
ARIN has a lot of resource and you can justify a lot of resource 
you can get them, you just can't have everything ARIN has.

On 8 Jun 2009 McTim wrote:

> HI Leo,
> 
> I prefer this method, as it maintains the idea that we allocate
> and assign based on need.
> 
> The "rationing" (IPv4 run out by prefix size) proposal
> fundamentally alters the notion of needs based allocation.
> 
> -- 
> Cheers,
> 
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there."  Jon Postel
> 
> 
> On 6/8/09, Member Services <info at arin.net> wrote:
> 
> > ## * ##
> >
> >
> >    1. Policy Proposal: Predictable IPv4 Run Out by Allocation Window
> >
> >    2. Proposal Originator: Leo Bicknell
> >
> >    3. Proposal Version: 1.0
> >
> >    4. Date: 8 June 2009
> >
> >    5. Proposal type: modify
> >
> >    6. Policy term: permanent
> >
> >    7. Policy statement:
> >
> >       Replace the text in NRPM 4.2.4.4 with:
> >
> >       After an organization has been a subscriber member of ARIN for
> >       one year, they may choose to request up to a 12 month supply
> >       of IP addresses.
> >
> >       Starting on 1 July 2010, a gradual reduction in the allocation
> >       period will be applied as follows:
> >
> >       As of 1 July 2010, they may choose to request up to a 9 month
> >       supply.
> >
> >       As of 1 January 2011, they may choose to request up to a 6
> >       month supply.
> >
> >       As of 1 July 2011, they may choose to request up to a 3 month
> >       supply.
> >
> >    8. Rationale:
> >
> >       During the ARIN XXIII policy discussion several individuals
> >       described ideas similar to RIPE policy proposal 2009-03
> >       (http://www.ripe.net/ripe/policies/proposals/2009-03.html).
> >       This policy adapts the same idea into an ARIN policy for
> >       discussion in this region.
> >
> >       From the RIPE proposal:
> >
> > ] This is a proposal to gradually reduce the allocation and
> > ] assignment periods in step with the expected life time of the IPv4
> > ] unallocated pool in order to address the perception of unfairness
> > ] once the pool has run out.
> > ]
> > ] The proposal is not intended to stretch the lifetime of the
> > ] unallocated pool.
> > ]
> > ] The proposal is independent of other proposals to reserve address
> > ] space for transition purposes and/or new entrants. It can be
> > ] implemented independently of these.
> >
> >    9. Timetable for implementation: Immediate
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From randy at psg.com  Mon Jun  8 22:00:01 2009
From: randy at psg.com (Randy Bush)
Date: Tue, 09 Jun 2009 11:00:01 +0900
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out
	by	Allocation Window
In-Reply-To: <4A2D796A.24442.FC52A09@farmer.umn.edu>
References: <4A2D6C8F.4000605@arin.net>
Message-ID: <m263f6go9q.wl%randy@psg.com>

what do these policies do to meet the need for a small bit of ipv4 space
by the new entrant multi-homed enterprise which wishe to connect to the
dual-stack internet five years from now?

randy


From farmer at umn.edu  Mon Jun  8 22:10:20 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 08 Jun 2009 21:10:20 -0500
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out by
	Allocation Window
In-Reply-To: <m263f6go9q.wl%randy@psg.com>
References: <4A2D6C8F.4000605@arin.net>,
	<4A2D796A.24442.FC52A09@farmer.umn.edu>,
	<m263f6go9q.wl%randy@psg.com>
Message-ID: <4A2D7E3C.26310.FD7FBE8@farmer.umn.edu>

On 9 Jun 2009 Randy Bush wrote:

> what do these policies do to meet the need for a small bit of ipv4
> space by the new entrant multi-homed enterprise which wishe to connect
> to the dual-stack internet five years from now?
> 
> randy

Nothing at all, ARIN already has a policy that is suppose to 
deal with that see 4.10 of the NRPM.

https://www.arin.net/policy/nrpm.html#four10

It was Draft Policy 2008-5 if you want to see other details about 
it.

https://www.arin.net/policy/proposals/2008_5.html

Some have suggested there should be bigger block reserved, 
personally, I'd be ok with that, but these policies are intended 
to deal with what is left outside of that.



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From randy at psg.com  Mon Jun  8 22:19:45 2009
From: randy at psg.com (Randy Bush)
Date: Tue, 09 Jun 2009 11:19:45 +0900
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out by
	Allocation Window
In-Reply-To: <4A2D7E3C.26310.FD7FBE8@farmer.umn.edu>
References: <4A2D6C8F.4000605@arin.net>
Message-ID: <m23aaagncu.wl%randy@psg.com>

>> what do these policies do to meet the need for a small bit of ipv4
>> space by the new entrant multi-homed enterprise which wishe to connect
>> to the dual-stack internet five years from now?
> Nothing at all, ARIN already has a policy that is suppose to 
> deal with that see 4.10 of the NRPM.
> https://www.arin.net/policy/nrpm.html#four10
> Some have suggested there should be bigger block reserved

'zactly.  seemed a bit stingy to me.

> these policies are intended to deal with what is left outside of that.

ok.  i can cope.

randy


From terry.l.davis at boeing.com  Mon Jun  8 22:57:13 2009
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 8 Jun 2009 19:57:13 -0700
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run
 OutbyAllocation Window
In-Reply-To: <4A2D9ED6.7010709@kl.net>
References: <4A2D6C8F.4000605@arin.net>	<f65fb55e0906081352t16355f00rf8f4a37
	0406beeac@mail.gmail.com><2557049CDBC35B4EBD79CFACFEC045841B9F552F@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A2D9ED6.7010709@kl.net>
Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5535@XCH-NW-CCR1V.nw.nos.boeing.com>

Kevin

Like all of us, "life happens" and then a group may realize that they don't have the network resources they need.

One of the most interesting conversations you could have would be with a state or federal "fire boss" for a major brush/forest fire. You get a new view of what "communications means"; they carry 6 or more individual radios/cell phones to maintain links to all the various different agencies assisting.

Take care
Terry

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Kevin Loch
> Sent: Monday, June 08, 2009 4:29 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Predictable IPv4 Run
> OutbyAllocation Window
> 
> Davis, Terry L wrote:
> > McTim
> >
> > There's an important element here that we may have overlooked; "critical
> services" and "critical infrastructure" globally.
> >
> > There are set of folks around the globe that do need priority in the
> allocations.  And despite some of their best intentions and work, they
> have not been able to yet get budget allocations from their sponsors
> (enterprises or governments where politics/budget must be worked) to
> migrate their services to IPv6.
> >
> > I don't claim to know how to adjudicate the need; just that it will
> exist.
> 
> Do you have an example of critical services or infrastructure that does
> not already have IP addresses assigned to it?
> 
> - Kevin
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From terry.l.davis at boeing.com  Mon Jun  8 22:59:14 2009
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Mon, 8 Jun 2009 19:59:14 -0700
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out
 byAllocation Window
In-Reply-To: <4A2DA105.1040202@sprunk.org>
References: <4A2D6C8F.4000605@arin.net>
	<f65fb55e0906081352t16355f00rf8f4a370406beeac@mail.gmail.com>
	<2557049CDBC35B4EBD79CFACFEC045841B9F552F@XCH-NW-CCR1V.nw.nos.boeing.com>
	<4A2DA105.1040202@sprunk.org>
Message-ID: <2557049CDBC35B4EBD79CFACFEC045841B9F5536@XCH-NW-CCR1V.nw.nos.boeing.com>

Stephan

Your last paragraph said it all relative to IPv4 space.  We are on the same
page.

Take care
Terry

> -----Original Message-----
> From: Stephen Sprunk [mailto:stephen at sprunk.org]
> Sent: Monday, June 08, 2009 4:39 PM
> To: Davis, Terry L
> Cc: 'McTim'; ARIN PPML
> Subject: Re: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out
> byAllocation Window
> 
> Davis, Terry L wrote:
> > There's an important element here that we may have overlooked; "critical
> services" and "critical infrastructure" globally.
> >
> > There are set of folks around the globe that do need priority in the
> allocations.  And despite some of their best intentions and work, they
> have not been able to yet get budget allocations from their sponsors
> (enterprises or governments where politics/budget must be worked) to
> migrate their services to IPv6.
> >
> > I don't claim to know how to adjudicate the need; just that it will
> exist.
> >
> 
> While the text of the proposal simply says "IP addresses", the title
> implies that it should only affect IPv4 addresses and I would expect the
> AC to make that editorial change.
> 
> With that assumption, I do not see how this could possibly affect IPv6
> deployments, by "critical infrastructure" folks or anyone else for that
> matter.  Could you explain your thinking on that?
> 
> I do see a potential problem that CI folks may not be able to get any
> IPv4 space at all after exhaustion, and I would be interested in a
> proposal to set aside some space for them, but I don't think that this
> is the right thread to address that.
> 
> S
> 
> --
> Stephen Sprunk         "God does not play dice."  --Albert Einstein
> CCIE #3723         "God is an inveterate gambler, and He throws the
> K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6231 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090608/b512b57d/attachment.bin>

From dave at temk.in  Tue Jun  9 00:48:36 2009
From: dave at temk.in (Dave Temkin)
Date: Mon, 08 Jun 2009 21:48:36 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <c3227e9e0906081816k7e7ccebaj8ff017395818463@mail.gmail.com>
References: <4A2D9541.3000608@temk.in>	
	<5F3383FC-BB7B-4E53-983F-8FFC5BE8F021@delong.com>
	<c3227e9e0906081816k7e7ccebaj8ff017395818463@mail.gmail.com>
Message-ID: <4A2DE9A4.9050001@temk.in>

It's a shame that that's the answer.

The problem:  "Adopt IPv6 as soon as possible!  We need as much content 
as possible on IPv6 to drive adoption!"

The answer:  "Wait 5 months and then maybe we'll make it possible for 
you, and the average enterprise, to deploy it... Or maybe not if people 
don't like the exact wording of the proposal"

I guess we've waited 9 years, what's another 5 months or years?

-Dave



cja at daydream.com wrote:
> I'd like to further encourage those of you who need this to 
> participate in the Dearborn meeting whether in person or remotely.  
>
> Thanks
> ----Cathy
>
> On Mon, Jun 8, 2009 at 6:25 PM, Owen DeLong <owen at delong.com 
> <mailto:owen at delong.com>> wrote:
>
>     I believe that situation is exactly what proposal 84 is intended
>     to rectify.
>
>     Unfortunately, I do not have a good answer for you under current
>     policy.
>
>     I would urge you to review proposal 84, and, if you feel this
>     addresses your
>     needs, be vocal in your support for it to become policy.
>
>     Owen
>
>
>     On Jun 8, 2009, at 3:48 PM, Dave Temkin wrote:
>
>         I'm going to attempt to keep this brief, but here goes:
>
>         Recently, I received a /48.  After beginning our rollout, I
>         quickly discovered that we'd need a /44 at the very least.
>          See, I have multiple networks that are not interconnected by
>         a common backbone, and so a single /48 would leave me with a
>         useless routing domain given that most people prefix filter at
>         le /48.
>
>         Currently, each OrgID is entitled to only one /48.  Under
>         IPv4, if you operate separate, disparate networks you're
>         allowed to request multiple blocks under the Multiple Discrete
>         Networks policy.  No such policy exists for IPv6, however it's
>         been proposed here:  https://www.arin.net/policy/nrpm.html#six583
>
>         I'd love to hear suggestions on workarounds until such the
>         proposed policy would be voted on and implemented. PA
>         addressing is not a viable option.
>
>         If we expect IPv6 adoption to have a significant uptick we
>         need to take away silly barriers to addressing such as this
>         and make address assignments accessible for the common ASP or
>         Enterprise - and right now it's definitely not.
>
>
>         -Dave
>         _______________________________________________
>         PPML
>         You are receiving this message because you are subscribed to
>         the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>         <mailto:ARIN-PPML at arin.net>).
>         Unsubscribe or manage your mailing list subscription at:
>         http://lists.arin.net/mailman/listinfo/arin-ppml
>         Please contact info at arin.net <mailto:info at arin.net> if you
>         experience any issues.
>
>
>     _______________________________________________
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto:ARIN-PPML at arin.net>).
>     Unsubscribe or manage your mailing list subscription at:
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>     Please contact info at arin.net <mailto:info at arin.net> if you
>     experience any issues.
>
>



From scottleibrand at gmail.com  Tue Jun  9 02:00:20 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 09 Jun 2009 01:00:20 -0500
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2DE9A4.9050001@temk.in>
References: <4A2D9541.3000608@temk.in>		<5F3383FC-BB7B-4E53-983F-8FFC5BE8F021@delong.com>	<c3227e9e0906081816k7e7ccebaj8ff017395818463@mail.gmail.com>
	<4A2DE9A4.9050001@temk.in>
Message-ID: <4A2DFA74.5050603@gmail.com>

Dave,

This is the kind of thing that we all should have been able to see would 
be a problem at some point.  I personally will take some responsibility 
for not proposing it before the San Antonio meeting, as we saw the need 
for it when we started detailed planning for IPv6 deployment.   And I'm 
sure I'm not the only one, but for whatever reason, no one thought this 
was a serious drawback until the last few months.

One lesson from this is that we all need to be planning ahead, and 
thinking about what kind of issues might arise in the future as we 
deploy IPv6.  There's no reason something like this should sneak up on 
us, so I would encourage everyone to think about what policy might be 
needed in the near future.

-Scott

Dave Temkin wrote:
> It's a shame that that's the answer.
>
> The problem:  "Adopt IPv6 as soon as possible!  We need as much 
> content as possible on IPv6 to drive adoption!"
>
> The answer:  "Wait 5 months and then maybe we'll make it possible for 
> you, and the average enterprise, to deploy it... Or maybe not if 
> people don't like the exact wording of the proposal"
>
> I guess we've waited 9 years, what's another 5 months or years?
>
> -Dave
>
>
>
> cja at daydream.com wrote:
>> I'd like to further encourage those of you who need this to 
>> participate in the Dearborn meeting whether in person or remotely. 
>> Thanks
>> ----Cathy
>>
>> On Mon, Jun 8, 2009 at 6:25 PM, Owen DeLong <owen at delong.com 
>> <mailto:owen at delong.com>> wrote:
>>
>>     I believe that situation is exactly what proposal 84 is intended
>>     to rectify.
>>
>>     Unfortunately, I do not have a good answer for you under current
>>     policy.
>>
>>     I would urge you to review proposal 84, and, if you feel this
>>     addresses your
>>     needs, be vocal in your support for it to become policy.
>>
>>     Owen
>>
>>
>>     On Jun 8, 2009, at 3:48 PM, Dave Temkin wrote:
>>
>>         I'm going to attempt to keep this brief, but here goes:
>>
>>         Recently, I received a /48.  After beginning our rollout, I
>>         quickly discovered that we'd need a /44 at the very least.
>>          See, I have multiple networks that are not interconnected by
>>         a common backbone, and so a single /48 would leave me with a
>>         useless routing domain given that most people prefix filter at
>>         le /48.
>>
>>         Currently, each OrgID is entitled to only one /48.  Under
>>         IPv4, if you operate separate, disparate networks you're
>>         allowed to request multiple blocks under the Multiple Discrete
>>         Networks policy.  No such policy exists for IPv6, however it's
>>         been proposed here:  
>> https://www.arin.net/policy/nrpm.html#six583
>>
>>         I'd love to hear suggestions on workarounds until such the
>>         proposed policy would be voted on and implemented. PA
>>         addressing is not a viable option.
>>
>>         If we expect IPv6 adoption to have a significant uptick we
>>         need to take away silly barriers to addressing such as this
>>         and make address assignments accessible for the common ASP or
>>         Enterprise - and right now it's definitely not.
>>
>>
>>         -Dave
>>         _______________________________________________
>>         PPML
>>         You are receiving this message because you are subscribed to
>>         the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>         <mailto:ARIN-PPML at arin.net>).
>>         Unsubscribe or manage your mailing list subscription at:
>>         http://lists.arin.net/mailman/listinfo/arin-ppml
>>         Please contact info at arin.net <mailto:info at arin.net> if you
>>         experience any issues.
>>
>>
>>     _______________________________________________
>>     PPML
>>     You are receiving this message because you are subscribed to
>>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>     <mailto:ARIN-PPML at arin.net>).
>>     Unsubscribe or manage your mailing list subscription at:
>>     http://lists.arin.net/mailman/listinfo/arin-ppml
>>     Please contact info at arin.net <mailto:info at arin.net> if you
>>     experience any issues.
>>
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From kris.foster.ml at gmail.com  Tue Jun  9 02:24:50 2009
From: kris.foster.ml at gmail.com (Kris Foster)
Date: Mon, 8 Jun 2009 23:24:50 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2DE9A4.9050001@temk.in>
References: <4A2D9541.3000608@temk.in>	
	<5F3383FC-BB7B-4E53-983F-8FFC5BE8F021@delong.com>
	<c3227e9e0906081816k7e7ccebaj8ff017395818463@mail.gmail.com>
	<4A2DE9A4.9050001@temk.in>
Message-ID: <A847F354-BEBA-4444-B408-C6C2885D9350@gmail.com>

+1

On Jun 8, 2009, at 9:48 PM, Dave Temkin wrote:

> It's a shame that that's the answer.
>
> The problem:  "Adopt IPv6 as soon as possible!  We need as much  
> content as possible on IPv6 to drive adoption!"
>
> The answer:  "Wait 5 months and then maybe we'll make it possible  
> for you, and the average enterprise, to deploy it... Or maybe not if  
> people don't like the exact wording of the proposal"
>
> I guess we've waited 9 years, what's another 5 months or years?
>
> -Dave
>
>
>
> cja at daydream.com wrote:
>> I'd like to further encourage those of you who need this to  
>> participate in the Dearborn meeting whether in person or remotely.
>> Thanks
>> ----Cathy
>>
>> On Mon, Jun 8, 2009 at 6:25 PM, Owen DeLong <owen at delong.com <mailto:owen at delong.com 
>> >> wrote:
>>
>>    I believe that situation is exactly what proposal 84 is intended
>>    to rectify.
>>
>>    Unfortunately, I do not have a good answer for you under current
>>    policy.
>>
>>    I would urge you to review proposal 84, and, if you feel this
>>    addresses your
>>    needs, be vocal in your support for it to become policy.
>>
>>    Owen
>>
>>
>>    On Jun 8, 2009, at 3:48 PM, Dave Temkin wrote:
>>
>>        I'm going to attempt to keep this brief, but here goes:
>>
>>        Recently, I received a /48.  After beginning our rollout, I
>>        quickly discovered that we'd need a /44 at the very least.
>>         See, I have multiple networks that are not interconnected by
>>        a common backbone, and so a single /48 would leave me with a
>>        useless routing domain given that most people prefix filter at
>>        le /48.
>>
>>        Currently, each OrgID is entitled to only one /48.  Under
>>        IPv4, if you operate separate, disparate networks you're
>>        allowed to request multiple blocks under the Multiple Discrete
>>        Networks policy.  No such policy exists for IPv6, however it's
>>        been proposed here:  https://www.arin.net/policy/nrpm.html#six583
>>
>>        I'd love to hear suggestions on workarounds until such the
>>        proposed policy would be voted on and implemented. PA
>>        addressing is not a viable option.
>>
>>        If we expect IPv6 adoption to have a significant uptick we
>>        need to take away silly barriers to addressing such as this
>>        and make address assignments accessible for the common ASP or
>>        Enterprise - and right now it's definitely not.
>>
>>
>>        -Dave
>>        _______________________________________________
>>        PPML
>>        You are receiving this message because you are subscribed to
>>        the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>        <mailto:ARIN-PPML at arin.net>).
>>        Unsubscribe or manage your mailing list subscription at:
>>        http://lists.arin.net/mailman/listinfo/arin-ppml
>>        Please contact info at arin.net <mailto:info at arin.net> if you
>>        experience any issues.
>>
>>
>>    _______________________________________________
>>    PPML
>>    You are receiving this message because you are subscribed to
>>    the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>>    <mailto:ARIN-PPML at arin.net>).
>>    Unsubscribe or manage your mailing list subscription at:
>>    http://lists.arin.net/mailman/listinfo/arin-ppml
>>    Please contact info at arin.net <mailto:info at arin.net> if you
>>    experience any issues.
>>
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From michael.dillon at bt.com  Tue Jun  9 03:38:42 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 9 Jun 2009 08:38:42 +0100
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2D9541.3000608@temk.in>
Message-ID: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>

> Recently, I received a /48.  After beginning our rollout, I 
> quickly discovered that we'd need a /44 at the very least.  

Have you asked ARIN if you can trade it in for a /44?

I don't see any reason why you can't rerun the initial
application, as long as you give back the block received
and fully justify the new block. That should be consistent
with the policy.

--Michael Dillon


From info at arin.net  Tue Jun  9 08:55:46 2009
From: info at arin.net (Member Services)
Date: Tue, 09 Jun 2009 08:55:46 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
Message-ID: <4A2E5BD2.8090708@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at:https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


1. Policy Proposal Name: Customer Confidentiality

2. Proposal Originator: Aaron Wendel

3. Proposal Version: 1.0

4. Date: 9 June 2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

ISPs may choose to enter their own address and phone number in
reassignments and reallocations in lieu of the customer's address and
phone number.  The customer's actual information must be provided to
ARIN on request and will be held in the strictest confidence.

8. Rationale:

Customer contact lists are one of the most proprietary and confidential
pieces of information in any business.  The requirements for ISPs to
publish those lists via SWIP or RWHOIS runs contrary to good business
practices and invites competitors and others to solicit both individuals
and companies receiving reassignments and sub allocations from upstream
providers.

9. Timetable for implementation: immediate



From michael.dillon at bt.com  Tue Jun  9 09:09:43 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 9 Jun 2009 14:09:43 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
Message-ID: <28E139F46D45AF49A31950F88C497458018C2D8A@E03MVZ2-UKDY.domain1.systemhost.net>


 ISPs may choose to enter their own address and phone number 
> in reassignments and reallocations in lieu of the customer's 
> address and phone number.  The customer's actual information 
> must be provided to ARIN on request and will be held in the 
> strictest confidence.

I generally agree with this proposal. The purpose of whois
is to publish contact info for someone who is ready,
willing and able to take action in connection with network
issues ranging from outages, to incorrect configurations
and including network abuse. In an increasing number of
cases, that readiness (24/7), willingness and ability to
act are better found in the ISP, not in the end customer.

In addition, it is becoming so common for contacts to be
unresponsive, that more and more people don't even bother
chasing after an issue. It is common to see pleas for contact
information which are repeatedly answered with a recommendation
to go to the address-user's upstream ISP. This is now
becoming best practice because that ISP has a contractual
relationship with the address-user and almost certainly has
better internal contact info for them which cannot be
published in whois.

By modifying whois records to point to an ISP's preferred
contact point, we give message senders the ability to
quickly make contact with an end-user network, or to get
the ISP to take charge of problem resolution.

Perhaps the bit about "actual information" could be reworded
a bit. I interpret that as meaning that full and complete
info must accompany address applications, and will therefore
be protected by the normal NDA which covers all info submitted
to justify an address application.

Under current policy ARIN is meddling in ISP business models 
because it is not possible for an ISP to offer a fully-managed
Internet access service. If an ISP has to publish their customer's
name and valid contact address info in whois, then that customer
will be pestered with queries that should have been covered
by the ISP in a fully-managed scenario. It is time to fix this.

--Michael Dillon


From mueller at syr.edu  Tue Jun  9 09:28:35 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 9 Jun 2009 09:28:35 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7EC5@SUEX07-MBX-04.ad.syr.edu>

I strongly support this proposal. --MM

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Member Services
> Sent: Tuesday, June 09, 2009 8:56 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.
> 
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> 1. Policy Proposal Name: Customer Confidentiality
> 
> 2. Proposal Originator: Aaron Wendel
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 9 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number.  The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.
> 
> 8. Rationale:
> 
> Customer contact lists are one of the most proprietary and confidential
> pieces of information in any business.  The requirements for ISPs to
> publish those lists via SWIP or RWHOIS runs contrary to good business
> practices and invites competitors and others to solicit both individuals
> and companies receiving reassignments and sub allocations from upstream
> providers.
> 
> 9. Timetable for implementation: immediate
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From dsd at servervault.com  Tue Jun  9 09:33:00 2009
From: dsd at servervault.com (Divins, David)
Date: Tue, 9 Jun 2009 09:33:00 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <E7956D9775C98F4DB72321439A2F91A9262F30@mail1.dulles.sv.int>

I support this proposal and I swear I did not submit it.

Please see the archives for all my reasons :-)

-dsd

David Divins
Principal Engineer
ServerVault Corp.
(703) 652-5955

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Member Services
Sent: Tuesday, June 09, 2009 8:56 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their
deliberations.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at:https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


1. Policy Proposal Name: Customer Confidentiality

2. Proposal Originator: Aaron Wendel

3. Proposal Version: 1.0

4. Date: 9 June 2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

ISPs may choose to enter their own address and phone number in
reassignments and reallocations in lieu of the customer's address and
phone number.  The customer's actual information must be provided to
ARIN on request and will be held in the strictest confidence.

8. Rationale:

Customer contact lists are one of the most proprietary and confidential
pieces of information in any business.  The requirements for ISPs to
publish those lists via SWIP or RWHOIS runs contrary to good business
practices and invites competitors and others to solicit both individuals
and companies receiving reassignments and sub allocations from upstream
providers.

9. Timetable for implementation: immediate

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From Wesley.E.George at sprint.com  Tue Jun  9 10:02:12 2009
From: Wesley.E.George at sprint.com (George, Wes E [NTK])
Date: Tue, 9 Jun 2009 09:02:12 -0500
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out by
 Allocation	Window
In-Reply-To: <4A2D6C8F.4000605@arin.net>
References: <4A2D6C8F.4000605@arin.net>
Message-ID: <F7EB0A7C707E39409A73CD0353242551A7F196D4D7@PLSWM01C.ad.sprint.com>

I don't have issue with the idea behind this proposal, but I do have a few points to make on the specifics.

First, I'll make the obligatory comment about this potentially causing IPv4 deaggregation because the block allocations will be smaller, but that's unavoidable and likely of limited impact with this few addresses left, so probably doesn't matter, but someone had to say it. :-)
On a more serious note, what would be done if a requestor normally asks for a /22 or similar sized block for their year, but now doesn't qualify for that much space due to the reduction in time. Is ARIN going to be allocating /24s now? There probably needs to be a lower limit on size for this and similar proposals.

Second, is there a waiting period enforced on this policy? Say a requestor gets their 3/6/9 month supply and for some reason exhausts it before the end of that period. Are they still allowed to come back for additional addresses assuming they can justify them or must they wait until exactly 3/6/9 months after their prior request? There's no mention of a waiting period in this policy, but that figures into other policies, so I thought I should confirm.

Last, I recommend that the hard and fast dates be changed to something related to the remaining amount of IPv4 address space. One of the few things that we know for certain is that no one knows exactly when we'll get to IPv4 exhaust (until after it happens), especially in light of all of the policies flying around to make it yet harder to get IPv4 allocations. Therefore I do not support a specific date, even if it is based on the best projections of the moment. If the date is overly aggressive, it will mainly result in a lot more administrative overhead for both ARIN and its requestors without really affecting who gets what space, and if the date is conservative, the policy will not take effect until it's too late.
This needs to be controlled by how much space is left. Perhaps in order to make this policy more effective, it should start when IANA is down to X /8's available, where X > 2 but less than the current value, and get tighter as subsequent /8s are allocated to RIRs.
Also, it should have a termination period, again based on the available pool of IPv4 addresses. While I agree that availability of IPv4 addresses will start becoming more and more irrelevant, if there are still people using them, and more become available as the migration to IPv6 progresses, there's no reason to continue wasting everyone's time with tiny allocation windows.

Thanks,
Wes

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services
Sent: Monday, June 08, 2009 3:55 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out by Allocation Window


      Starting on 1 July 2010, a gradual reduction in the allocation
      period will be applied as follows:

      As of 1 July 2010, they may choose to request up to a 9 month
      supply.

      As of 1 January 2011, they may choose to request up to a 6 month
      supply.

      As of 1 July 2011, they may choose to request up to a 3 month
      supply.


This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.



From farmer at umn.edu  Tue Jun  9 10:07:32 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 09 Jun 2009 09:07:32 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <4A2E2654.269.2721817@farmer.umn.edu>

In general, the concept of privacy or confidentially attaches to 
the client or customer not to the agent or service provider.  An 
example, attorney client privilege is a right of the client and a 
duty of the attorney, it is for the benefit of the client not the 
attorney.

If withholding such information is solely in the business interest 
of the agent or service provider, the ISP in this case, and 
especially if it in anyway damages the interest of client or 
customer, then I'm opposed to such policies.

Customer information is not solely the property of the agent or 
service provider, the client or customer should have the 
controlling interest in such information.

I generally support an effort to increased Customer 
Confidentially, but it needs to focus on the Customer's interest 
not solely on the ISP's interest.  So I am worried about how 
this proposal is written and that it seems to focus on the ISP's 
interest not the Customer's interest. 

It maybe as simple as requiring an ISP to provide the actual 
customer information in Whois if direct by the customer to do 
so.  That might be all it takes to put the customer's interest 
ahead of the ISP's interest.

I'm fine with an ISP choosing the default action, but the 
customer should have a choice about their information, not 
solely the ISP.

On 9 Jun 2009 Member Services wrote:

> 1. Policy Proposal Name: Customer Confidentiality
> 
> 2. Proposal Originator: Aaron Wendel
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 9 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number.  The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.
> 
> 8. Rationale:
> 
> Customer contact lists are one of the most proprietary and
> confidential pieces of information in any business.  The requirements
> for ISPs to publish those lists via SWIP or RWHOIS runs contrary to
> good business practices and invites competitors and others to solicit
> both individuals and companies receiving reassignments and sub
> allocations from upstream providers.
> 
> 9. Timetable for implementation: immediate


===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From bicknell at ufp.org  Tue Jun  9 10:08:12 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Jun 2009 10:08:12 -0400
Subject: [arin-ppml] Policy Proposal: Predictable IPv4 Run Out by
	Allocation	Window
In-Reply-To: <F7EB0A7C707E39409A73CD0353242551A7F196D4D7@PLSWM01C.ad.sprint.com>
References: <4A2D6C8F.4000605@arin.net>
	<F7EB0A7C707E39409A73CD0353242551A7F196D4D7@PLSWM01C.ad.sprint.com>
Message-ID: <20090609140811.GA76244@ussenterprise.ufp.org>

In a message written on Tue, Jun 09, 2009 at 09:02:12AM -0500, George, Wes E [NTK] wrote:
> Last, I recommend that the hard and fast dates be changed to
> something related to the remaining amount of IPv4 address space.

As a point of information; the dates were lifted directly from the
RIPE proposal.  I don't know if there is value in multiple RIR's
being substantially similar on this issue or not.

I would like more opinions on the topic.  These two proposals were sent
off to generate this sort of discussion and get more feedback and it
seems to be working.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/715c597b/attachment.sig>

From michael.dillon at bt.com  Tue Jun  9 10:21:31 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 9 Jun 2009 15:21:31 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E2654.269.2721817@farmer.umn.edu>
Message-ID: <28E139F46D45AF49A31950F88C497458018C2F4F@E03MVZ2-UKDY.domain1.systemhost.net>

> I generally support an effort to increased Customer 
> Confidentially, but it needs to focus on the Customer's 
> interest not solely on the ISP's interest.  So I am worried 
> about how this proposal is written and that it seems to focus 
> on the ISP's interest not the Customer's interest. 

This policy proposal benefits both Customer and ISP. A customer
can elect to keep their contact info out of whois with the
understanding that the ISP will now relay messages to them,
and probably filter out junk like SPAM. On the other hand,
the ISP now has the option to offer a fully-managed Internet
access service and shield the customer from all communications
related to network abuse or malfunction.

As it stands, this proposal doesn't favor one or the other.

> It maybe as simple as requiring an ISP to provide the actual 
> customer information in Whois if direct by the customer to do 
> so.  That might be all it takes to put the customer's 
> interest ahead of the ISP's interest.

That would be reasonable. If an end user customer is ready,
willing and able to act on communications received, then they
should be able to have their info published. By getting the
wording right, we avoid creating a corner case. Since ARIN
has a direct bilateral relationship with the ISP, we can require 
them to provide contacts that are ready, willing and able to
act, but we should not force that on 3rd parties, the ISP
customers. But it is right to force the ISPs to allow the 
customer to elect to publish this info, if the customer chooses.

> I'm fine with an ISP choosing the default action, but the 
> customer should have a choice about their information, not 
> solely the ISP.

I agree. Going forward we need to be careful to not restrict
the choice of Internet users or ISPs except where that restriction
of choice is absolutely essential.

--Michael Dillon


From tvest at pch.net  Tue Jun  9 10:27:30 2009
From: tvest at pch.net (Tom Vest)
Date: Tue, 9 Jun 2009 10:27:30 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E2654.269.2721817@farmer.umn.edu>
References: <4A2E5BD2.8090708@arin.net> <4A2E2654.269.2721817@farmer.umn.edu>
Message-ID: <4E51F5EF-C023-4690-BAEB-94EE815C009F@pch.net>

Hi David,

I was think thinking something very similar.
Regardless of which party initiates the action, if the end result is  
the use of ISP contact information to mask the identity of the end  
customer, then by definition the ISP is effectively agreeing to act as  
the customer's proxy (or at least proxy of last resort) in any/all  
recognized legitimate interactions are mediated by whois, for as long  
as that identity substitution remains in effect.

I imagine that "recognized legitimate" uses of whois could/should be  
imported by reference to broader established policies, and the actual  
scope/details of discretionary proxy services should be left to  
specific bilateral arrangements -- but I think that the "proxy of last  
resort" language should probably be added to the proposal.

TV

On Jun 9, 2009, at 10:07 AM, David Farmer wrote:

> In general, the concept of privacy or confidentially attaches to
> the client or customer not to the agent or service provider.  An
> example, attorney client privilege is a right of the client and a
> duty of the attorney, it is for the benefit of the client not the
> attorney.
>
> If withholding such information is solely in the business interest
> of the agent or service provider, the ISP in this case, and
> especially if it in anyway damages the interest of client or
> customer, then I'm opposed to such policies.
>
> Customer information is not solely the property of the agent or
> service provider, the client or customer should have the
> controlling interest in such information.
>
> I generally support an effort to increased Customer
> Confidentially, but it needs to focus on the Customer's interest
> not solely on the ISP's interest.  So I am worried about how
> this proposal is written and that it seems to focus on the ISP's
> interest not the Customer's interest.
>
> It maybe as simple as requiring an ISP to provide the actual
> customer information in Whois if direct by the customer to do
> so.  That might be all it takes to put the customer's interest
> ahead of the ISP's interest.
>
> I'm fine with an ISP choosing the default action, but the
> customer should have a choice about their information, not
> solely the ISP.
>
> On 9 Jun 2009 Member Services wrote:
>
>> 1. Policy Proposal Name: Customer Confidentiality
>>
>> 2. Proposal Originator: Aaron Wendel
>>
>> 3. Proposal Version: 1.0
>>
>> 4. Date: 9 June 2009
>>
>> 5. Proposal type: new
>>
>> 6. Policy term: permanent
>>
>> 7. Policy statement:
>>
>> ISPs may choose to enter their own address and phone number in
>> reassignments and reallocations in lieu of the customer's address and
>> phone number.  The customer's actual information must be provided to
>> ARIN on request and will be held in the strictest confidence.
>>
>> 8. Rationale:
>>
>> Customer contact lists are one of the most proprietary and
>> confidential pieces of information in any business.  The requirements
>> for ISPs to publish those lists via SWIP or RWHOIS runs contrary to
>> good business practices and invites competitors and others to solicit
>> both individuals and companies receiving reassignments and sub
>> allocations from upstream providers.
>>
>> 9. Timetable for implementation: immediate
>
>
> ===============================================
> David Farmer                                      Email:farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota		       Phone: 612-626-0815
> 2218 University Ave SE		       Cell: 612-812-9952
> Minneapolis, MN 55414-3029	       FAX: 612-626-1818
> ===============================================
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From mksmith at adhost.com  Tue Jun  9 10:41:28 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 9 Jun 2009 07:41:28 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160621122F@ad-exh01.adhost.lan>

I fully support this proposal.  Since I am the one paying for the use of
the IP space it makes sense that my contact information should be
presented in SWIP/WHOIS.  

Regards,

Mike

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Member Services
> Sent: Tuesday, June 09, 2009 5:56 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy
Development
> Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure
that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC)
> within
> 10 days.
> 
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their
> deliberations.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> 1. Policy Proposal Name: Customer Confidentiality
> 
> 2. Proposal Originator: Aaron Wendel
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 9 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number.  The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.
> 
> 8. Rationale:
> 
> Customer contact lists are one of the most proprietary and
confidential
> pieces of information in any business.  The requirements for ISPs to
> publish those lists via SWIP or RWHOIS runs contrary to good business
> practices and invites competitors and others to solicit both
> individuals
> and companies receiving reassignments and sub allocations from
upstream
> providers.
> 
> 9. Timetable for implementation: immediate
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From bill at herrin.us  Tue Jun  9 10:51:53 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 9 Jun 2009 10:51:53 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>

On Tue, Jun 9, 2009 at 8:55 AM, Member Services<info at arin.net> wrote:
> 1. Policy Proposal Name: Customer Confidentiality
>
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number. ?The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.

I oppose this policy as written, however I would support the policy if
"address" was clarified to mean email address but not postal address.

Describing the registrant's identity for the consumption of
non-trivial amounts of IPv4 address space serves good public policy.
It makes it possible for third parties to perform spot-checks which
audit the ISP's honest use of address space. Whether used or not, this
greatly impacts ARIN's process transparency. This is especially
helpful when a supposed ISP is suspected of fraud. A name alone or
fully private registrations are insufficient for auditing.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From dave at temk.in  Tue Jun  9 11:21:43 2009
From: dave at temk.in (Dave Temkin)
Date: Tue, 09 Jun 2009 08:21:43 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A2E7E07.2000407@temk.in>

I can't justify the new block.  I have a few thousand potentially 
addressable hosts, definitely not enough to fill multiple /48's, the 
same as pretty much every other network out there with a very few 
exceptions.

I went the other route, as suggested by many people, and attempted to 
submit my application as a LIR, given that we run a separate 
transport/transit backbone from our content serving network (two 
separate AS's, one providing transit services to the other).  I was told 
that we don't meet section 6.5.1.4 of the NRPM -

"be an existing, known ISP in the ARIN region or have a plan for making 
at least 200 end-site assignments to other organizations within 5 
years.", however when pressed as to how 10310 or 15169 meet that 
requirement (specifically 200 end-site assignments to other 
organizations), I got no answer.  The reality of it is that neither fit 
that description - Yahoo and Google provide transit services to 
themselves only, and while they may have 200 end sites, they are 
definitely *not* other organizations.  I do not understand why ARIN 
management would have made exceptions for these two companies (and 
probably many others).

-Dave



michael.dillon at bt.com wrote:
>> Recently, I received a /48.  After beginning our rollout, I 
>> quickly discovered that we'd need a /44 at the very least.  
>>     
>
> Have you asked ARIN if you can trade it in for a /44?
>
> I don't see any reason why you can't rerun the initial
> application, as long as you give back the block received
> and fully justify the new block. That should be consistent
> with the policy.
>
> --Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   



From farmer at umn.edu  Tue Jun  9 11:34:14 2009
From: farmer at umn.edu (David Farmer)
Date: Tue, 09 Jun 2009 10:34:14 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <28E139F46D45AF49A31950F88C497458018C2F4F@E03MVZ2-UKDY.domain1.systemhost.net>
References: <4A2E2654.269.2721817@farmer.umn.edu>,
	<28E139F46D45AF49A31950F88C497458018C2F4F@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A2E3AA6.23268.2C179DE@farmer.umn.edu>

On 9 Jun 2009 michael.dillon at bt.com wrote:

> > I generally support an effort to increased Customer 
> > Confidentially, but it needs to focus on the Customer's 
> > interest not solely on the ISP's interest.  So I am worried 
> > about how this proposal is written and that it seems to focus 
> > on the ISP's interest not the Customer's interest. 
> 
> This policy proposal benefits both Customer and ISP. A customer
> can elect to keep their contact info out of whois with the
> understanding that the ISP will now relay messages to them,
> and probably filter out junk like SPAM. On the other hand,
> the ISP now has the option to offer a fully-managed Internet
> access service and shield the customer from all communications
> related to network abuse or malfunction.
> 
> As it stands, this proposal doesn't favor one or the other.

I do believe this can be a benefit to the customer and in the customer's 
interest, but the provided rational only focuses on the ISP's interest in 
making the Customer's information confidential.  Nothing in the rational 
speaks to why this is in the customer's interest, that probably should be 
included too.



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From lar at mwtcorp.net  Tue Jun  9 12:41:11 2009
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Tue, 09 Jun 2009 10:41:11 -0600
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <web-1010145@be1.mail.trib.com>

I too strongly support this proposal.

As a VOIP provider I have to certify CPNI (Customer Proprietary Network
Information) each year to the FCC. This puts a burden on me to keep
most customer information confidential. This includes their name and
mailing address. So far this has related to Call Detail information
and other voice related information. It can be argued that IP information
for VOIP customers should be included as part of the CPNI.

If it is, the current policy would be in conflict with the FCC under some
conditions.

> 
> 1. Policy Proposal Name: Customer Confidentiality
> 
> 2. Proposal Originator: Aaron Wendel
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 9 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number.  The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.
> 
> 8. Rationale:
> 
> Customer contact lists are one of the most proprietary and confidential
> pieces of information in any business.  The requirements for ISPs to
> publish those lists via SWIP or RWHOIS runs contrary to good business
> practices and invites competitors and others to solicit both individuals
> and companies receiving reassignments and sub allocations from upstream
> providers.
> 
> 9. Timetable for implementation: immediate
> 

Larry Ash
Network Administrator
Mountain West Telephone
400 East 1st St.
Casper, WY 82601
Office 307 233-8387


From bjohnson at drtel.com  Tue Jun  9 12:46:00 2009
From: bjohnson at drtel.com (Brian Johnson)
Date: Tue, 9 Jun 2009 11:46:00 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <29A54911243620478FF59F00EBB12F47017E3690@ex01.drtel.lan>

I support this proposal... with one question?

Wouldn't this be, in practice, the same as a customer "opt-out" of
SWIP/RWHOIS? Not that I have even the slightest problem with this.

- Brian

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Member Services
> Sent: Tuesday, June 09, 2009 7:56 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy
Development
> Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure
that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC)
> within
> 10 days.
> 
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their
> deliberations.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> 1. Policy Proposal Name: Customer Confidentiality
> 
> 2. Proposal Originator: Aaron Wendel
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 9 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number.  The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.
> 
> 8. Rationale:
> 
> Customer contact lists are one of the most proprietary and
confidential
> pieces of information in any business.  The requirements for ISPs to
> publish those lists via SWIP or RWHOIS runs contrary to good business
> practices and invites competitors and others to solicit both
> individuals
> and companies receiving reassignments and sub allocations from
upstream
> providers.
> 
> 9. Timetable for implementation: immediate
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From michael.dillon at bt.com  Tue Jun  9 12:50:40 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 9 Jun 2009 17:50:40 +0100
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2E7E07.2000407@temk.in>
Message-ID: <28E139F46D45AF49A31950F88C497458018C3220@E03MVZ2-UKDY.domain1.systemhost.net>

> Yahoo and Google provide transit services to 
> themselves only, and while they may have 200 end sites, they 
> are definitely *not* other organizations.  I do not 
> understand why ARIN management would have made exceptions for 
> these two companies (and probably many others).

Probably because these companies operate in many countries.
Typically, this is done by incorporating separate corporate
entities in each country, and then managing them using
majority share ownership or a majority of seats on the 
board, or just by contractual means. This means that
often these so-called subsidiaries are only partly owned
by the mother ship, and may truly be independent organizations
that have contracted to use the mother ship's brand, and
products.

In fact, it is common for MotherShip France SA, as an
example, to be a holding company that is connected to
several other corporations one of which owns a data centre,
one of which employs data centre ops staff, one of which
employs sales staff, etc.

With this kind of scenario, it doesn't take too many 
countries, plus a few acquisitions, to push a company
over the 200 org limit. And note that the limit is
projected 5 years from now, so any company with 
international expansion plans, or acquisition plans,
should have no trouble meeting the guidelines.

Five years is a long time. Few companies actually have
much of a five year plan in any kind of detail. My recommendation
to everyone is that if the 200 org limit is a factor in
not getting the allocation you need, then talk to your
CEO and explain the benefits of taking time to brainstorm
and formally develop a five year vision, which you can then
turn into a five year plan.

Anyone who is doing IPv6 deployment today is a visionary
business pioneer, and stands to do very well when the IPv4
address crunch impacts old-guard ISPs. Even if you only
sell against the old-guard using FUD, you will still sign
contracts and do much business. 200 organizations is not
hard to imagine for a visionary IPv6 business pioneer.

--Michael Dillon


From dave at temk.in  Tue Jun  9 13:01:40 2009
From: dave at temk.in (Dave Temkin)
Date: Tue, 09 Jun 2009 10:01:40 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <28E139F46D45AF49A31950F88C497458018C3220@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458018C3220@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A2E9574.9070007@temk.in>

michael.dillon at bt.com wrote:
>> Yahoo and Google provide transit services to 
>> themselves only, and while they may have 200 end sites, they 
>> are definitely *not* other organizations.  I do not 
>> understand why ARIN management would have made exceptions for 
>> these two companies (and probably many others).
>>     
>
> Probably because these companies operate in many countries.
> Typically, this is done by incorporating separate corporate
> entities in each country, and then managing them using
> majority share ownership or a majority of seats on the 
> board, or just by contractual means. This means that
> often these so-called subsidiaries are only partly owned
> by the mother ship, and may truly be independent organizations
> that have contracted to use the mother ship's brand, and
> products.
>
> In fact, it is common for MotherShip France SA, as an
> example, to be a holding company that is connected to
> several other corporations one of which owns a data centre,
> one of which employs data centre ops staff, one of which
> employs sales staff, etc.
>
> With this kind of scenario, it doesn't take too many 
> countries, plus a few acquisitions, to push a company
> over the 200 org limit. And note that the limit is
> projected 5 years from now, so any company with 
> international expansion plans, or acquisition plans,
> should have no trouble meeting the guidelines.
>
> Five years is a long time. Few companies actually have
> much of a five year plan in any kind of detail. My recommendation
> to everyone is that if the 200 org limit is a factor in
> not getting the allocation you need, then talk to your
> CEO and explain the benefits of taking time to brainstorm
> and formally develop a five year vision, which you can then
> turn into a five year plan.
>
> Anyone who is doing IPv6 deployment today is a visionary
> business pioneer, and stands to do very well when the IPv4
> address crunch impacts old-guard ISPs. Even if you only
> sell against the old-guard using FUD, you will still sign
> contracts and do much business. 200 organizations is not
> hard to imagine for a visionary IPv6 business pioneer.
>
> --Michael Dillon
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   


Michael,

You make some fantastic points that actually do directly apply.

Thanks,

-Dave


From kris.foster.ml at gmail.com  Tue Jun  9 13:02:47 2009
From: kris.foster.ml at gmail.com (Kris Foster)
Date: Tue, 9 Jun 2009 10:02:47 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <28E139F46D45AF49A31950F88C497458018C3220@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458018C3220@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <AC35E834-B1EE-48AC-804C-A64994E416DF@gmail.com>


On Jun 9, 2009, at 9:50 AM, <michael.dillon at bt.com> <michael.dillon at bt.com 
 > wrote:

>> Yahoo and Google provide transit services to
>> themselves only, and while they may have 200 end sites, they
>> are definitely *not* other organizations.  I do not
>> understand why ARIN management would have made exceptions for
>> these two companies (and probably many others).
>
> Five years is a long time. Few companies actually have
> much of a five year plan in any kind of detail. My recommendation
> to everyone is that if the 200 org limit is a factor in
> not getting the allocation you need, then talk to your
> CEO and explain the benefits of taking time to brainstorm
> and formally develop a five year vision, which you can then
> turn into a five year plan.


It sounds like ARIN's policy failures weren't failures at all, just  
that content was mistaken and we were meant to be ISPs after all.

--
kris


From stephen at sprunk.org  Tue Jun  9 13:03:19 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Tue, 09 Jun 2009 12:03:19 -0500
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2E7E07.2000407@temk.in>
References: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A2E7E07.2000407@temk.in>
Message-ID: <4A2E95D7.2090802@sprunk.org>

Dave Temkin wrote:
> I went the other route, as suggested by many people, and attempted to
> submit my application as a LIR, given that we run a separate
> transport/transit backbone from our content serving network (two
> separate AS's, one providing transit services to the other).  I was
> told that we don't meet section 6.5.1.4 of the NRPM -
>
> "be an existing, known ISP in the ARIN region or have a plan for
> making at least 200 end-site assignments to other organizations within
> 5 years.", however when pressed as to how 10310 or 15169 meet that
> requirement (specifically 200 end-site assignments to other
> organizations), I got no answer.  The reality of it is that neither
> fit that description - Yahoo and Google provide transit services to
> themselves only, and while they may have 200 end sites, they are
> definitely *not* other organizations.  I do not understand why ARIN
> management would have made exceptions for these two companies (and
> probably many others).

IIRC, the /32s issued to end-user orgs like Yahoo, Google, Cisco, IBM,
etc. are from well before the direct-assignment policy was adopted, and
at that time it was apparently accepted that "really big" end users
could claim to be LIRs.  Now that there is a specific policy for all end
users, though, that hole has been closed and those few prior exceptions
have been grandfathered -- though IMHO they shouldn't be, as the legal
situation is quite different from IPv4 legacy space and moving those
companies into end-user blocks would also eventually put pressure on
certain ISPs that are still choosing to filter at /32 in the /48 block...

Also, keep in mind that the maintenance fees for being an LIR are
significantly higher than for end-user orgs; waiting a few months for
the Multiple Discrete Networks policy may test your patience, but it's
worth it financially.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/fd0124e9/attachment.bin>

From kkargel at polartel.com  Tue Jun  9 13:10:05 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 12:10:05 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2A8@mail>

I am in general opposed to this proposal.  There are good and valid reasons
for making direct contacts for a network discoverable.  If a host runs amok
and is causing grave problems then I need to be able to contact the person
responsible for that host.  I do not need to find a contact for someone
three tiers up who will contact someone else who will contact someone who
will contact the host owner.


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Member Services
> Sent: Tuesday, June 09, 2009 7:56 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.
> 
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> 1. Policy Proposal Name: Customer Confidentiality
> 
> 2. Proposal Originator: Aaron Wendel
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 9 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number.  The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.
> 
> 8. Rationale:
> 
> Customer contact lists are one of the most proprietary and confidential
> pieces of information in any business.  The requirements for ISPs to
> publish those lists via SWIP or RWHOIS runs contrary to good business
> practices and invites competitors and others to solicit both individuals
> and companies receiving reassignments and sub allocations from upstream
> providers.
> 
> 9. Timetable for implementation: immediate
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/2377e60e/attachment.bin>

From bicknell at ufp.org  Tue Jun  9 13:23:58 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 9 Jun 2009 13:23:58 -0400
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2E7E07.2000407@temk.in>
References: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A2E7E07.2000407@temk.in>
Message-ID: <20090609172358.GA96741@ussenterprise.ufp.org>

In a message written on Tue, Jun 09, 2009 at 08:21:43AM -0700, Dave Temkin wrote:
> "be an existing, known ISP in the ARIN region or have a plan for making 
> at least 200 end-site assignments to other organizations within 5 
> years.", however when pressed as to how 10310 or 15169 meet that 
> requirement (specifically 200 end-site assignments to other 
> organizations), I got no answer.  The reality of it is that neither fit 
> that description - Yahoo and Google provide transit services to 
> themselves only, and while they may have 200 end sites, they are 
> definitely *not* other organizations.  I do not understand why ARIN 
> management would have made exceptions for these two companies (and 
> probably many others).

I can't speak to the two specific cases, but I note the policy you
reference is an /or/.

I believe "be an existing, known ISP in the ARIN region" is met if
you have IPv4 Assignments (you pay ISP fees, you enter SWIPs, you
got your space as assignments).  It's entirely possible there are
folks who qualify under the first half of the clause that will never
have 200 sites.

As others have noted, there is active policy work in many directions to
address this problem.  Also, filtering is still being developed on the
IPv6 Internet, while there are folks who strict filter on /48's, there
are also folks who do not.  It may be worth participating in forums like
NANOG and making the argument that the filter should be (as an example)
a /50, allowing for a limited amount of deaggregation for end sites.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/1cc4f34b/attachment.sig>

From matthew at matthew.at  Tue Jun  9 13:29:27 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 09 Jun 2009 10:29:27 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2A8@mail>
References: <4A2E5BD2.8090708@arin.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2A8@mail>
Message-ID: <4A2E9BF7.6000607@matthew.at>

Kevin Kargel wrote:
> I am in general opposed to this proposal.  There are good and valid reasons
> for making direct contacts for a network discoverable.  If a host runs amok
> and is causing grave problems then I need to be able to contact the person
> responsible for that host.  I do not need to find a contact for someone
> three tiers up who will contact someone else who will contact someone who
> will contact the host owner.
>
>   
I am strongly in favor of this proposal, and have argued against 
disclosure of customer data this way since the very first time it was 
required years ago.

There are good and valid reasons for making someone who is actually 
technically knowledgeable and reachable be listed as a contact. SWIP and 
RWhois have never gone down to the host level, and so "contacting the 
person responsible for the host" is rarely possible. Consumer records 
are already protected this way, and any larger organization is big 
enough that you're going to be talking to someone "three tiers up" or 
higher anyway. Here at my day job for instance, the abuse contact would 
talk to his boss who would enlist the desktop support people who would 
contact the employee or their manager. And of course most employees 
wouldn't know anything about the problem you wanted to talk to them 
about anyway, so they'd need to get desktop support involved again 
anyway. Similarly with hosting companies... you'll talk to the NOC for 
the datacenter, and they'll call the guy who runs the cage full of 
servers, and they will call the person running the virtual hosting 
system on those servers, and that person will call the person whose 
software is giving you trouble.

All you really need is a contact who can: actually terminate the 
connection if that's what is required, or contact a responsible party in 
a timely fashion. So I think that means that for single-homed networks, 
their ISP is appropriate, but for multi-homed networks, you'll want the 
person who runs routers at the multi-homed organization (but not any 
farther down).

Matthew Kaufman



From kevin at steadfast.net  Tue Jun  9 14:23:09 2009
From: kevin at steadfast.net (Kevin Stange)
Date: Tue, 09 Jun 2009 13:23:09 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
Message-ID: <4A2EA88D.5030102@steadfast.net>

William Herrin wrote:
> On Tue, Jun 9, 2009 at 8:55 AM, Member Services<info at arin.net> wrote:
>> 1. Policy Proposal Name: Customer Confidentiality
>>
>> ISPs may choose to enter their own address and phone number in
>> reassignments and reallocations in lieu of the customer's address and
>> phone number.  The customer's actual information must be provided to
>> ARIN on request and will be held in the strictest confidence.
> 
> I oppose this policy as written, however I would support the policy if
> "address" was clarified to mean email address but not postal address.

I support this policy fully, as written, or with any additional clauses
to expand the language to explicitly mention protection of end-users as
additional rationale.

> Describing the registrant's identity for the consumption of
> non-trivial amounts of IPv4 address space serves good public policy.
> It makes it possible for third parties to perform spot-checks which
> audit the ISP's honest use of address space. Whether used or not, this
> greatly impacts ARIN's process transparency. This is especially
> helpful when a supposed ISP is suspected of fraud. A name alone or
> fully private registrations are insufficient for auditing.

Is it anyone's job but the IP regulatory agencies and governmental
agencies to investigate charges of fraud?  If it's suspected, there
should certainly be other clues besides rwhois, enough to involve people
to whom this job is assigned.  I don't see how it can be argued that the
ISP should *have to* make this information available for "third parties"
at random to dig around, effectively gaining a customer database as a
result.  This isn't just about the ISP's protection, though.

Privacy of personal information is something our customers regularly ask
us about because our system automatically publishes their information in
rwhois.  In many cases, these customers do not have the technical
knowledge to know how to handle contact involving their IP usage, and
would simply defer to us anyway.  We have no problem with fielding these
questions and filtering queries to them that they don't really have need
to worry about.

Some "controversial" companies end up having home addresses and other
information published which exposes them to possible retaliation and the
idea that this information is supposed to be public record makes them
uncomfortable.  Sure, that information isn't that hard to find, but
we're just giving it away now in a way that can be systematically
queried and republished.

I don't think we'd change our "default" of publishing customer
information, but we certainly support giving them the ability to opt for
privacy if it suits them and will, as always, cooperate with ARIN and
law enforcement to provide the "privatized" information if it's needed
for administrative or legal reasons.

-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/9fca0354/attachment.sig>

From mueller at syr.edu  Tue Jun  9 14:30:10 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 9 Jun 2009 14:30:10 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E2654.269.2721817@farmer.umn.edu>
References: <4A2E5BD2.8090708@arin.net> <4A2E2654.269.2721817@farmer.umn.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A4F@SUEX07-MBX-04.ad.syr.edu>

Good catch, David. The policy should be amended to read, "If the customer requests, ISPs may choose to enter their own address and phone number in reassignments and reallocations in lieu of the customer's address and..."

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
> Sent: Tuesday, June 09, 2009 10:08 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> In general, the concept of privacy or confidentially attaches to 
> the client or customer not to the agent or service provider.  An 
> example, attorney client privilege is a right of the client and a 
> duty of the attorney, it is for the benefit of the client not the 
> attorney.
> 
> If withholding such information is solely in the business interest 
> of the agent or service provider, the ISP in this case, and 
> especially if it in anyway damages the interest of client or 
> customer, then I'm opposed to such policies.
> 
> Customer information is not solely the property of the agent or 
> service provider, the client or customer should have the 
> controlling interest in such information.
> 
> I generally support an effort to increased Customer 
> Confidentially, but it needs to focus on the Customer's interest 
> not solely on the ISP's interest.  So I am worried about how 
> this proposal is written and that it seems to focus on the ISP's 
> interest not the Customer's interest. 
> 
> It maybe as simple as requiring an ISP to provide the actual 
> customer information in Whois if direct by the customer to do 
> so.  That might be all it takes to put the customer's interest 
> ahead of the ISP's interest.
> 
> I'm fine with an ISP choosing the default action, but the 
> customer should have a choice about their information, not 
> solely the ISP.
> 
> On 9 Jun 2009 Member Services wrote:
> 
> > 1. Policy Proposal Name: Customer Confidentiality
> > 
> > 2. Proposal Originator: Aaron Wendel
> > 
> > 3. Proposal Version: 1.0
> > 
> > 4. Date: 9 June 2009
> > 
> > 5. Proposal type: new
> > 
> > 6. Policy term: permanent
> > 
> > 7. Policy statement:
> > 
> > ISPs may choose to enter their own address and phone number in
> > reassignments and reallocations in lieu of the customer's 
> address and
> > phone number.  The customer's actual information must be provided to
> > ARIN on request and will be held in the strictest confidence.
> > 
> > 8. Rationale:
> > 
> > Customer contact lists are one of the most proprietary and
> > confidential pieces of information in any business.  The 
> requirements
> > for ISPs to publish those lists via SWIP or RWHOIS runs contrary to
> > good business practices and invites competitors and others 
> to solicit
> > both individuals and companies receiving reassignments and sub
> > allocations from upstream providers.
> > 
> > 9. Timetable for implementation: immediate
> 
> 
> ===============================================
> David Farmer                                      Email:farmer at umn.edu
> Office of Information Technology
> Networking & Telecomunication Services
> University of Minnesota		       Phone: 612-626-0815
> 2218 University Ave SE		       Cell: 612-812-9952
> Minneapolis, MN 55414-3029	       FAX: 612-626-1818
> ===============================================
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 

From mueller at syr.edu  Tue Jun  9 14:36:03 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Tue, 9 Jun 2009 14:36:03 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>

I don't understand how this is a consideration if the ISP continues to be accurately identified in the whois. I don't understand how a third party's suspicion of an ISP gives them a right to access a customers' data as opposed to the ISP data. Recall that ARIN has access to the customer information and would thus be accessible to any real fraud investigation. 

> -----Original Message-----
> It makes it possible for third parties to perform spot-checks which
> audit the ISP's honest use of address space. Whether used or not, this
> greatly impacts ARIN's process transparency. This is especially
> helpful when a supposed ISP is suspected of fraud. A name alone or
> fully private registrations are insufficient for auditing.
> 
> Regards,
> Bill Herrin
> 


From kevin at steadfast.net  Tue Jun  9 14:30:30 2009
From: kevin at steadfast.net (Kevin Stange)
Date: Tue, 09 Jun 2009 13:30:30 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2A8@mail>
References: <4A2E5BD2.8090708@arin.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2A8@mail>
Message-ID: <4A2EAA46.1000506@steadfast.net>

Kevin Kargel wrote:
> I am in general opposed to this proposal.  There are good and valid reasons
> for making direct contacts for a network discoverable.  If a host runs amok
> and is causing grave problems then I need to be able to contact the person
> responsible for that host.  I do not need to find a contact for someone
> three tiers up who will contact someone else who will contact someone who
> will contact the host owner.
> 

Many of our customers would be slow to respond or unsure how to handle
direct contact, which is one of the reasons I like this proposal.  Even
when we direct such queries downstream from time to time, we get back a
"what do I do with this?" response and basically end up having to deal
with the issue ourselves.  If there's a suitably insane issue going on
with a customer's machine, contacting us directly can result in
immediate resolution where it might take hours to days contacting the
customer directly.  We have the power to shut down VLANs, issue null
routes, and sometimes just directly access machines to resolve issues.
Chances are that we know a better way to get in touch with the customer
faster that may not be something rwhois would generally contain such as
an IM screen name or alternate phone number or email account, or that
the customer is noted in our system to be away on vacation for 6 weeks
and wants us to shut down a box in the event of anything seriously wrong.

Having centralized contacts gives us a filter, so we can block out
useless contact to our customers and keep track of what kind of strange
things our customers are doing with their IPs, intentionally, or
inadvertently, so that we can handle abuses and keep in touch with
customers to provide guidance.

That said, as it stands now, most abuse reporters just contact us
directly anyway, even if rwhois specifies to contact someone else, so I
don't expect much to change in this regard anyway.


-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/0b493cf2/attachment.sig>

From matthew at matthew.at  Tue Jun  9 14:38:50 2009
From: matthew at matthew.at (Matthew Kaufman)
Date: Tue, 09 Jun 2009 11:38:50 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E2654.269.2721817@farmer.umn.edu>
References: <4A2E5BD2.8090708@arin.net> <4A2E2654.269.2721817@farmer.umn.edu>
Message-ID: <4A2EAC3A.8020406@matthew.at>

David Farmer wrote:
> I'm fine with an ISP choosing the default action, but the 
> customer should have a choice about their information, not 
> solely the ISP.
>   
I support this recommended change. I believe it should be up to the 
customer, but the ISP (as the one doing the data entry) likely needs to 
be able to set the default policy for non-response, as different ISPs 
may have different opinions on what to do with a customer who says "I 
don't care either way" (or worse "I don't understand what you're asking 
me").

Matthew Kaufman


From kloch at kl.net  Tue Jun  9 14:47:31 2009
From: kloch at kl.net (Kevin Loch)
Date: Tue, 09 Jun 2009 14:47:31 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A2EAE43.9060702@kl.net>

Milton L Mueller wrote:
> I don't understand how this is a consideration if the ISP continues to be 
 > accurately identified in the whois.

Is it required that rwhois servers be accessible to the public or just 
to ARIN for making/validating reassignments?  If so then that is a
way to limit the distribution of confidential customer info to just
ARIN staff (which is covered by the RSA) that would not require this
policy change.

I am hesitant to support a policy that would reduce the quality and
depth of reassignment data.  This is especially important as we
get closer to IPv4 runout and the temptation to fudge reassignments
increases.

- Kevin


From kkargel at polartel.com  Tue Jun  9 14:55:14 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 13:55:14 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2EAA46.1000506@steadfast.net>
References: <4A2E5BD2.8090708@arin.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2A8@mail>
	<4A2EAA46.1000506@steadfast.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AC@mail>

> -----Original Message-----
> From: Kevin Stange [mailto:kevin at steadfast.net]
> Sent: Tuesday, June 09, 2009 1:31 PM
> To: Kevin Kargel
> Cc: arin ppml
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> Kevin Kargel wrote:
> > I am in general opposed to this proposal.  There are good and valid
> reasons
> > for making direct contacts for a network discoverable.  If a host runs
> amok
> > and is causing grave problems then I need to be able to contact the
> person
> > responsible for that host.  I do not need to find a contact for someone
> > three tiers up who will contact someone else who will contact someone
> who
> > will contact the host owner.
> >
> 
> Many of our customers would be slow to respond or unsure how to handle
> direct contact, which is one of the reasons I like this proposal.  Even
> when we direct such queries downstream from time to time, we get back a
> "what do I do with this?" response and basically end up having to deal
> with the issue ourselves.  If there's a suitably insane issue going on
> with a customer's machine, contacting us directly can result in
> immediate resolution where it might take hours to days contacting the
> customer directly.  We have the power to shut down VLANs, issue null
> routes, and sometimes just directly access machines to resolve issues.
> Chances are that we know a better way to get in touch with the customer
> faster that may not be something rwhois would generally contain such as
> an IM screen name or alternate phone number or email account, or that
> the customer is noted in our system to be away on vacation for 6 weeks
> and wants us to shut down a box in the event of anything seriously wrong.
> 
> Having centralized contacts gives us a filter, so we can block out
> useless contact to our customers and keep track of what kind of strange
> things our customers are doing with their IPs, intentionally, or
> inadvertently, so that we can handle abuses and keep in touch with
> customers to provide guidance.
> 
> That said, as it stands now, most abuse reporters just contact us
> directly anyway, even if rwhois specifies to contact someone else, so I
> don't expect much to change in this regard anyway.

I would agree that in the best possible world the abuse contact would be
someone who could do something about the issue.  In the real world this is
seldom the end user.

In the case of an ISP they are often the best PoC because they are in a
position to stop routing of a problem host.  In an enterprise network that
would be the NOC center for the aggregate router.  In this case it gets more
confusing because a single network may be distributed amongst several NOC's,
each of which has their own administration and routing policies.

In any case though, this contact "should" be a monitored live person
reachable contact who can directly manage the network in question.  At the
very least the PoC should be one phone call removed from that administrator.

Leaving the PoC as the top level ISP could put contact with an effective
administrator a number of tiers away, and could engender a situation where
resolution of an immediate issue is days away.

Filtering customers from abuse contacts is not a good thing.  If customer
networks are exposed directly to the internet then the customer needs to
have capable administrators on staff or under contract and those
administrators must be reachable.  

Expecting reasonable responsibility is not unreasonable.  Vehicle drivers on
public roads are or should be required to have the knowledge, resources and
skills to operate a vehicle. Network operators on public networks should
likewise be expected to have the knowledge, resources and skills to operate
a network.

I am not saying the PoC needs to be the customer, I am saying the PoC should
be a cognizant administrator or administration center.


> 
> 
> --
> Kevin Stange
> Chief Technology Officer
> Steadfast Networks
> http://steadfast.net
> Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/fc992fe4/attachment.bin>

From jay at impulse.net  Tue Jun  9 15:01:06 2009
From: jay at impulse.net (Jay Hennigan)
Date: Tue, 09 Jun 2009 12:01:06 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <29A54911243620478FF59F00EBB12F47017E3690@ex01.drtel.lan>
References: <4A2E5BD2.8090708@arin.net>
	<29A54911243620478FF59F00EBB12F47017E3690@ex01.drtel.lan>
Message-ID: <4A2EB172.50802@impulse.net>

Brian Johnson wrote:
> I support this proposal... with one question?
> 
> Wouldn't this be, in practice, the same as a customer "opt-out" of
> SWIP/RWHOIS? Not that I have even the slightest problem with this.

I support this proposal as written.

I view it more as a customer "opt-in" to SWIP/RWHOIS which is IMNSHO far 
preferable to "opt-out".

"Opt-out" = "We will spam you back to the stone age until you beg us to 
stop, and we will sell your identity to others who will do likewise."

"Opt-in" = "We won't annoy you or disclose your identity unless we have 
your specific (and revokable) permission to do so."


-- 
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From kkargel at polartel.com  Tue Jun  9 15:04:15 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 14:04:15 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AE@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Milton L Mueller
> Sent: Tuesday, June 09, 2009 1:36 PM
> To: 'William Herrin'
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> I don't understand how this is a consideration if the ISP continues to be
> accurately identified in the whois. I don't understand how a third party's
> suspicion of an ISP gives them a right to access a customers' data as
> opposed to the ISP data. Recall that ARIN has access to the customer
> information and would thus be accessible to any real fraud investigation.

To my mind the issue is not one of fraud investigation but one of abuse
resolution.  It is all too easy for a network host to broadcast a number of
types of storm traffic from innocent causes such as hardware or software
failure or mis-configuration.  Even things as simple as routing loops can be
debilitating to more than the end user in question.

The end user need not be identified, but a contact to an administrator who
can deal with routing and traffic issues should be required.

I am all for privacy, but reachability of an effective PoC needs to be
maintained.  A PoC who calls a contact who relays a message to someone who
knows who the administrator is cannot be effective.


> 
> > -----Original Message-----
> > It makes it possible for third parties to perform spot-checks which
> > audit the ISP's honest use of address space. Whether used or not, this
> > greatly impacts ARIN's process transparency. This is especially
> > helpful when a supposed ISP is suspected of fraud. A name alone or
> > fully private registrations are insufficient for auditing.
> >
> > Regards,
> > Bill Herrin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/0ca21627/attachment.bin>

From dsd at servervault.com  Tue Jun  9 15:10:35 2009
From: dsd at servervault.com (Divins, David)
Date: Tue, 9 Jun 2009 15:10:35 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2EAE43.9060702@kl.net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<4A2EAE43.9060702@kl.net>
Message-ID: <E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int>

An RWHOIS server is required to be available to ARIN and the Internet.
It is against the current policy to ACL the RWHOIS to just ARIN.

There are many end customers who do not want out-sourced, hosted,
sensitive application pod's information listed as a directory of where
to find them.  Not everyone uses public DNS.

-dsd

David Divins
Principal Engineer
ServerVault Corp.
(703) 652-5955

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Kevin Loch
Sent: Tuesday, June 09, 2009 2:48 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

Milton L Mueller wrote:
> I don't understand how this is a consideration if the ISP continues to
be 
 > accurately identified in the whois.

Is it required that rwhois servers be accessible to the public or just 
to ARIN for making/validating reassignments?  If so then that is a
way to limit the distribution of confidential customer info to just
ARIN staff (which is covered by the RSA) that would not require this
policy change.

I am hesitant to support a policy that would reduce the quality and
depth of reassignment data.  This is especially important as we
get closer to IPv4 runout and the temptation to fudge reassignments
increases.

- Kevin
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From kevin at steadfast.net  Tue Jun  9 15:13:54 2009
From: kevin at steadfast.net (Kevin Stange)
Date: Tue, 09 Jun 2009 14:13:54 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AC@mail>
References: <4A2E5BD2.8090708@arin.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2A8@mail>
	<4A2EAA46.1000506@steadfast.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AC@mail>
Message-ID: <4A2EB472.5060706@steadfast.net>

Kevin Kargel wrote:
>> -----Original Message-----
>> From: Kevin Stange [mailto:kevin at steadfast.net]
>> Sent: Tuesday, June 09, 2009 1:31 PM
>> To: Kevin Kargel
>> Cc: arin ppml
>> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
>>
>> Kevin Kargel wrote:
>>> I am in general opposed to this proposal.  There are good and valid
>> reasons
>>> for making direct contacts for a network discoverable.  If a host runs
>> amok
>>> and is causing grave problems then I need to be able to contact the
>> person
>>> responsible for that host.  I do not need to find a contact for someone
>>> three tiers up who will contact someone else who will contact someone
>> who
>>> will contact the host owner.
>>>
>> Many of our customers would be slow to respond or unsure how to handle
>> direct contact, which is one of the reasons I like this proposal.  Even
>> when we direct such queries downstream from time to time, we get back a
>> "what do I do with this?" response and basically end up having to deal
>> with the issue ourselves.  If there's a suitably insane issue going on
>> with a customer's machine, contacting us directly can result in
>> immediate resolution where it might take hours to days contacting the
>> customer directly.  We have the power to shut down VLANs, issue null
>> routes, and sometimes just directly access machines to resolve issues.
>> Chances are that we know a better way to get in touch with the customer
>> faster that may not be something rwhois would generally contain such as
>> an IM screen name or alternate phone number or email account, or that
>> the customer is noted in our system to be away on vacation for 6 weeks
>> and wants us to shut down a box in the event of anything seriously wrong.
>>
>> Having centralized contacts gives us a filter, so we can block out
>> useless contact to our customers and keep track of what kind of strange
>> things our customers are doing with their IPs, intentionally, or
>> inadvertently, so that we can handle abuses and keep in touch with
>> customers to provide guidance.
>>
>> That said, as it stands now, most abuse reporters just contact us
>> directly anyway, even if rwhois specifies to contact someone else, so I
>> don't expect much to change in this regard anyway.
> 
> I would agree that in the best possible world the abuse contact would be
> someone who could do something about the issue.  In the real world this is
> seldom the end user.
> 
> In the case of an ISP they are often the best PoC because they are in a
> position to stop routing of a problem host.  In an enterprise network that
> would be the NOC center for the aggregate router.  In this case it gets more
> confusing because a single network may be distributed amongst several NOC's,
> each of which has their own administration and routing policies.

I think in most cases that is why people ignore the bottom level contact
and continue to contact the assignee of the netblock directly, figuring
that the customer-end contact is going to be useless.  It's not always
true, but I think the risk gets higher, the smaller the re-allocated
netblock goes or the more levels down it goes.

> In any case though, this contact "should" be a monitored live person
> reachable contact who can directly manage the network in question.  At the
> very least the PoC should be one phone call removed from that administrator.

I could accept a proposal that suggests that privacy should be limited
such that if the furthest downstream party wishes to have privacy, the
ISP must replace the contact information with that of an immediate POC
that can handle issues on their behalf promptly.  In that case, you have
to address how you can validate that information, or establish a
complaint and resolution (or penalty) process if it turns out that
information published does not meet that criteria.

> Leaving the PoC as the top level ISP could put contact with an effective
> administrator a number of tiers away, and could engender a situation where
> resolution of an immediate issue is days away.

I suppose this does tend to happen a lot.  When we first started, our
IPs were allocated to us from Savvis to our reseller, to us.  We had our
IPs SWIPed to ensure we were contacted, but there were abuse reports
sent directly to Savvis that could take days to reach us.  That just
seems irresponsible, since forwarding email is relatively trivial.

> Filtering customers from abuse contacts is not a good thing.  If customer
> networks are exposed directly to the internet then the customer needs to
> have capable administrators on staff or under contract and those
> administrators must be reachable.  
> 
> Expecting reasonable responsibility is not unreasonable.  Vehicle drivers on
> public roads are or should be required to have the knowledge, resources and
> skills to operate a vehicle. Network operators on public networks should
> likewise be expected to have the knowledge, resources and skills to operate
> a network.

I trust you do not work with dedicated server hosting much. ;)

Expecting this level of knowledge or an appropriate system administrator
is impossible in our business, even when we explicitly tell customers
about the need for this.  Sometimes, a customer believes he has a
competent administrator on staff which turns out to be only slightly
more literate in server and network management than the customer
himself.  Other times the competent administrator leaves the company or
is laid off, with the customer getting the ensuing mess to deal with,
clueless.  It's routine, and letting us field the abuse reports in this
case is the best way we can make sure such issues actually get explained
to the customer and handled promptly.

-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/a6bd52d9/attachment.sig>

From bjohnson at drtel.com  Tue Jun  9 15:21:09 2009
From: bjohnson at drtel.com (Brian Johnson)
Date: Tue, 9 Jun 2009 14:21:09 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2EB172.50802@impulse.net>
References: <4A2E5BD2.8090708@arin.net><29A54911243620478FF59F00EBB12F47017E3690@ex01.drtel.lan>
	<4A2EB172.50802@impulse.net>
Message-ID: <29A54911243620478FF59F00EBB12F47017E36AB@ex01.drtel.lan>

Jay Hennigan wrote:
> 
> Brian Johnson wrote:
> > I support this proposal... with one question?
> >
> > Wouldn't this be, in practice, the same as a customer "opt-out" of
> > SWIP/RWHOIS? Not that I have even the slightest problem with this.
> 
> I support this proposal as written.
> 
> I view it more as a customer "opt-in" to SWIP/RWHOIS which is IMNSHO
> far
> preferable to "opt-out".
> 
> "Opt-out" = "We will spam you back to the stone age until you beg us
to
> stop, and we will sell your identity to others who will do likewise."
> 
> "Opt-in" = "We won't annoy you or disclose your identity unless we
have
> your specific (and revokable) permission to do so."
> 

I just view the current environment as a disclose first and so would
view a change in this as an opt-out policy.

No response needed as I know this is just semantics anyhow.

- Brian.


From kevin at steadfast.net  Tue Jun  9 15:24:50 2009
From: kevin at steadfast.net (Kevin Stange)
Date: Tue, 09 Jun 2009 14:24:50 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2EB172.50802@impulse.net>
References: <4A2E5BD2.8090708@arin.net>	<29A54911243620478FF59F00EBB12F47017E3690@ex01.drtel.lan>
	<4A2EB172.50802@impulse.net>
Message-ID: <4A2EB702.8010801@steadfast.net>

Jay Hennigan wrote:
> Brian Johnson wrote:
>> I support this proposal... with one question?
>>
>> Wouldn't this be, in practice, the same as a customer "opt-out" of
>> SWIP/RWHOIS? Not that I have even the slightest problem with this.
> 
> I support this proposal as written.
> 
> I view it more as a customer "opt-in" to SWIP/RWHOIS which is IMNSHO far
> preferable to "opt-out".
> 
> "Opt-out" = "We will spam you back to the stone age until you beg us to
> stop, and we will sell your identity to others who will do likewise."
> 
> "Opt-in" = "We won't annoy you or disclose your identity unless we have
> your specific (and revokable) permission to do so."

I don't think it's analogous to an opt-in policy because it's not
requiring that information no longer be published unless it's opted in.
 It does allow ISPs to offer a policy that is "opt-in" or choose to
utilize "opt-out" instead.

-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/1806669b/attachment.sig>

From kkargel at polartel.com  Tue Jun  9 15:49:25 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 14:49:25 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net>
	<E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Divins, David
> Sent: Tuesday, June 09, 2009 2:11 PM
> To: Kevin Loch; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> An RWHOIS server is required to be available to ARIN and the Internet.
> It is against the current policy to ACL the RWHOIS to just ARIN.
> 
> There are many end customers who do not want out-sourced, hosted,
> sensitive application pod's information listed as a directory of where
> to find them.  Not everyone uses public DNS.

Public actions have public accountability.  If you don't want your picture
taken going in to a strip club then don't go to a strip club. 

You can't demand public access without reachability.


> 
> -dsd
> 
> David Divins
> Principal Engineer
> ServerVault Corp.
> (703) 652-5955
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Kevin Loch
> Sent: Tuesday, June 09, 2009 2:48 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> Milton L Mueller wrote:
> > I don't understand how this is a consideration if the ISP continues to
> be
>  > accurately identified in the whois.
> 
> Is it required that rwhois servers be accessible to the public or just
> to ARIN for making/validating reassignments?  If so then that is a
> way to limit the distribution of confidential customer info to just
> ARIN staff (which is covered by the RSA) that would not require this
> policy change.
> 
> I am hesitant to support a policy that would reduce the quality and
> depth of reassignment data.  This is especially important as we
> get closer to IPv4 runout and the temptation to fudge reassignments
> increases.
> 
> - Kevin
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/7271770d/attachment.bin>

From kkargel at polartel.com  Tue Jun  9 15:56:16 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 14:56:16 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2EB472.5060706@steadfast.net>
References: <4A2E5BD2.8090708@arin.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2A8@mail>
	<4A2EAA46.1000506@steadfast.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AC@mail>
	<4A2EB472.5060706@steadfast.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2B0@mail>

{SNIP}
> 
> I could accept a proposal that suggests that privacy should be limited
> such that if the furthest downstream party wishes to have privacy, the
> ISP must replace the contact information with that of an immediate POC
> that can handle issues on their behalf promptly.  In that case, you have
> to address how you can validate that information, or establish a
> complaint and resolution (or penalty) process if it turns out that
> information published does not meet that criteria.
>

I would also support wording to that effect.

 
> > Leaving the PoC as the top level ISP could put contact with an effective
> > administrator a number of tiers away, and could engender a situation
> where
> > resolution of an immediate issue is days away.
> 
> I suppose this does tend to happen a lot.  When we first started, our
> IPs were allocated to us from Savvis to our reseller, to us.  We had our
> IPs SWIPed to ensure we were contacted, but there were abuse reports
> sent directly to Savvis that could take days to reach us.  That just
> seems irresponsible, since forwarding email is relatively trivial.
> 
> > Filtering customers from abuse contacts is not a good thing.  If
> customer
> > networks are exposed directly to the internet then the customer needs to
> > have capable administrators on staff or under contract and those
> > administrators must be reachable.
> >
> > Expecting reasonable responsibility is not unreasonable.  Vehicle
> drivers on
> > public roads are or should be required to have the knowledge, resources
> and
> > skills to operate a vehicle. Network operators on public networks should
> > likewise be expected to have the knowledge, resources and skills to
> operate
> > a network.
> 
> I trust you do not work with dedicated server hosting much. ;)

Ah, but in the case of hosted servers the server host would actually be a
more appropriate contact than the end user, and the server host is the
actual owner (we can say that now that we can sell IP blocks) of the IP
addresses.  The server host has the capability of immediately modifying the
customer traffic and routing. In this case the server host is the network
operator, not the web author.  I agree wholeheartedly that it would be not
be reasonable or prudent to expect web authors to understand routing issues.

> 
> Expecting this level of knowledge or an appropriate system administrator
> is impossible in our business, even when we explicitly tell customers
> about the need for this.  Sometimes, a customer believes he has a
> competent administrator on staff which turns out to be only slightly
> more literate in server and network management than the customer
> himself.  Other times the competent administrator leaves the company or
> is laid off, with the customer getting the ensuing mess to deal with,
> clueless.  It's routine, and letting us field the abuse reports in this
> case is the best way we can make sure such issues actually get explained
> to the customer and handled promptly.
> 
> --
> Kevin Stange
> Chief Technology Officer
> Steadfast Networks
> http://steadfast.net
> Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/6dd0bf61/attachment.bin>

From dsd at servervault.com  Tue Jun  9 16:00:21 2009
From: dsd at servervault.com (Divins, David)
Date: Tue, 9 Jun 2009 16:00:21 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net>
	<E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>
Message-ID: <E7956D9775C98F4DB72321439A2F91A9263055@mail1.dulles.sv.int>

I do not believe IP addresses are Public Actions. Access need not be
public.  It can be simply Globally Unique.

-dsd

David Divins
Principal Engineer
ServerVault Corp.
(703) 652-5955

-----Original Message-----
From: Kevin Kargel [mailto:kkargel at polartel.com] 
Sent: Tuesday, June 09, 2009 3:49 PM
To: Divins, David; Kevin Loch; arin-ppml at arin.net
Subject: RE: [arin-ppml] Policy Proposal: Customer Confidentiality



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Divins, David
> Sent: Tuesday, June 09, 2009 2:11 PM
> To: Kevin Loch; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> An RWHOIS server is required to be available to ARIN and the Internet.
> It is against the current policy to ACL the RWHOIS to just ARIN.
> 
> There are many end customers who do not want out-sourced, hosted,
> sensitive application pod's information listed as a directory of where
> to find them.  Not everyone uses public DNS.

Public actions have public accountability.  If you don't want your
picture
taken going in to a strip club then don't go to a strip club. 

You can't demand public access without reachability.


> 
> -dsd
> 
> David Divins
> Principal Engineer
> ServerVault Corp.
> (703) 652-5955
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Kevin Loch
> Sent: Tuesday, June 09, 2009 2:48 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> Milton L Mueller wrote:
> > I don't understand how this is a consideration if the ISP continues
to
> be
>  > accurately identified in the whois.
> 
> Is it required that rwhois servers be accessible to the public or just
> to ARIN for making/validating reassignments?  If so then that is a
> way to limit the distribution of confidential customer info to just
> ARIN staff (which is covered by the RSA) that would not require this
> policy change.
> 
> I am hesitant to support a policy that would reduce the quality and
> depth of reassignment data.  This is especially important as we
> get closer to IPv4 runout and the temptation to fudge reassignments
> increases.
> 
> - Kevin
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From mksmith at adhost.com  Tue Jun  9 15:58:17 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 9 Jun 2009 12:58:17 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AE@mail>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AE@mail>
Message-ID: <17838240D9A5544AAA5FF95F8D52031606211316@ad-exh01.adhost.lan>



> > On Behalf Of Milton L Mueller
> > Sent: Tuesday, June 09, 2009 1:36 PM
> > To: 'William Herrin'
> > Cc: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> >
> > I don't understand how this is a consideration if the ISP continues
> to
> > be accurately identified in the whois. I don't understand how a
third
> > party's suspicion of an ISP gives them a right to access a
customers'
> > data as opposed to the ISP data. Recall that ARIN has access to the
> > customer information and would thus be accessible to any real fraud
> investigation.
> 
> To my mind the issue is not one of fraud investigation but one of
abuse
> resolution.  It is all too easy for a network host to broadcast a
> number of types of storm traffic from innocent causes such as hardware
> or software failure or mis-configuration.  Even things as simple as
> routing loops can be debilitating to more than the end user in
> question.
> 
> The end user need not be identified, but a contact to an administrator
> who can deal with routing and traffic issues should be required.
> 
> I am all for privacy, but reachability of an effective PoC needs to be
> maintained.  A PoC who calls a contact who relays a message to someone
> who knows who the administrator is cannot be effective.
> 

I would argue that I am the effective PoC for "my" address space.  In
fact, since the official abuse contact for the ARIN-assigned space is
listed as authoritative, that's the one that gets notified in the event
of issues, not the customer's address in SWIP.  However, having my
customer's contact information has proven to be helpful to my
competitors.  If you know how to scrape SWIP you know a lot, and I would
argue too much, about my business.

Mike


From kkargel at polartel.com  Tue Jun  9 15:59:14 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 14:59:14 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <29A54911243620478FF59F00EBB12F47017E36AB@ex01.drtel.lan>
References: <4A2E5BD2.8090708@arin.net><29A54911243620478FF59F00EBB12F47017E3690@ex01.drtel.lan><4A2EB172.50802@impulse.net>
	<29A54911243620478FF59F00EBB12F47017E36AB@ex01.drtel.lan>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2B1@mail>

Top post --  sorry

Now that we can "own" and "sell" IP's might it not be a better idea to only
require granularity of PoC down to the IP owner and at the same time hold
the owner responsible for the traffic?


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Brian Johnson
> Sent: Tuesday, June 09, 2009 2:21 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> Jay Hennigan wrote:
> >
> > Brian Johnson wrote:
> > > I support this proposal... with one question?
> > >
> > > Wouldn't this be, in practice, the same as a customer "opt-out" of
> > > SWIP/RWHOIS? Not that I have even the slightest problem with this.
> >
> > I support this proposal as written.
> >
> > I view it more as a customer "opt-in" to SWIP/RWHOIS which is IMNSHO
> > far
> > preferable to "opt-out".
> >
> > "Opt-out" = "We will spam you back to the stone age until you beg us
> to
> > stop, and we will sell your identity to others who will do likewise."
> >
> > "Opt-in" = "We won't annoy you or disclose your identity unless we
> have
> > your specific (and revokable) permission to do so."
> >
> 
> I just view the current environment as a disclose first and so would
> view a change in this as an opt-out policy.
> 
> No response needed as I know this is just semantics anyhow.
> 
> - Brian.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/d39185af/attachment.bin>

From kkargel at polartel.com  Tue Jun  9 16:02:24 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 15:02:24 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <E7956D9775C98F4DB72321439A2F91A9263055@mail1.dulles.sv.int>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net><E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int><70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>
	<E7956D9775C98F4DB72321439A2F91A9263055@mail1.dulles.sv.int>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2B2@mail>




> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Divins, David
> Sent: Tuesday, June 09, 2009 3:00 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> I do not believe IP addresses are Public Actions. Access need not be
> public.  It can be simply Globally Unique.

The IP addresses themselves are not a public action, but the network traffic
that is related to those IP addresses is.  In my example the IP address is
the door you may enter or exit, you are the traffic.  If you don't want to
be accountable for your traffic then keep it off the public network.

> 
> -dsd
> 
> David Divins
> Principal Engineer
> ServerVault Corp.
> (703) 652-5955
> 
> -----Original Message-----
> From: Kevin Kargel [mailto:kkargel at polartel.com]
> Sent: Tuesday, June 09, 2009 3:49 PM
> To: Divins, David; Kevin Loch; arin-ppml at arin.net
> Subject: RE: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
> > Behalf Of Divins, David
> > Sent: Tuesday, June 09, 2009 2:11 PM
> > To: Kevin Loch; arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> >
> > An RWHOIS server is required to be available to ARIN and the Internet.
> > It is against the current policy to ACL the RWHOIS to just ARIN.
> >
> > There are many end customers who do not want out-sourced, hosted,
> > sensitive application pod's information listed as a directory of where
> > to find them.  Not everyone uses public DNS.
> 
> Public actions have public accountability.  If you don't want your
> picture
> taken going in to a strip club then don't go to a strip club.
> 
> You can't demand public access without reachability.
> 
> 
> >
> > -dsd
> >
> > David Divins
> > Principal Engineer
> > ServerVault Corp.
> > (703) 652-5955
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
> > Behalf Of Kevin Loch
> > Sent: Tuesday, June 09, 2009 2:48 PM
> > To: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> >
> > Milton L Mueller wrote:
> > > I don't understand how this is a consideration if the ISP continues
> to
> > be
> >  > accurately identified in the whois.
> >
> > Is it required that rwhois servers be accessible to the public or just
> > to ARIN for making/validating reassignments?  If so then that is a
> > way to limit the distribution of confidential customer info to just
> > ARIN staff (which is covered by the RSA) that would not require this
> > policy change.
> >
> > I am hesitant to support a policy that would reduce the quality and
> > depth of reassignment data.  This is especially important as we
> > get closer to IPv4 runout and the temptation to fudge reassignments
> > increases.
> >
> > - Kevin
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/326e2a71/attachment.bin>

From aaron at wholesaleinternet.net  Tue Jun  9 15:33:41 2009
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Tue, 9 Jun 2009 14:33:41 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <005e01c9e939$31b54220$951fc660$@net>

I purposely wrote the policy to be short, to the point, and easy to
understand.  The customer's communication with their provider should include
whether they want their personal information published in a publically
accessible database.

My point in writing this policy was to protect information that is
proprietary to any business.  Tell a realtor you know that you're thinking
about going into real estate and you'd like his customer list. Then tell him
that you actually need his customer list to make sure he's legit.  If all he
does is laugh at you then you got off lucky.  I can think of no other
private business that is required to publish customer information to the
public.

Customers can ask to have their information included and many of ours
specifically do but many of them have no idea how to admin their own
networks.  That's why they come to us.

This is my first policy proposal and the first I've seen from a source
outside the usual suspects you see bating around the proposals on the list.
I am not sure how to change the wording or if it needs changing but I feel
this is an important issue and am open to suggestions and guidance on
changes that people feel need to be made to make this a workable policy.

Aaron



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Milton L Mueller
Sent: Tuesday, June 09, 2009 1:36 PM
To: 'William Herrin'
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

I don't understand how this is a consideration if the ISP continues to be
accurately identified in the whois. I don't understand how a third party's
suspicion of an ISP gives them a right to access a customers' data as
opposed to the ISP data. Recall that ARIN has access to the customer
information and would thus be accessible to any real fraud investigation. 

> -----Original Message-----
> It makes it possible for third parties to perform spot-checks which
> audit the ISP's honest use of address space. Whether used or not, this
> greatly impacts ARIN's process transparency. This is especially
> helpful when a supposed ISP is suspected of fraud. A name alone or
> fully private registrations are insufficient for auditing.
> 
> Regards,
> Bill Herrin
> 
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



From kkargel at polartel.com  Tue Jun  9 16:07:10 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 15:07:10 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031606211316@ad-exh01.adhost.lan>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AE@mail>
	<17838240D9A5544AAA5FF95F8D52031606211316@ad-exh01.adhost.lan>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2B3@mail>

{SNIP}
> 
> I would argue that I am the effective PoC for "my" address space.  In
> fact, since the official abuse contact for the ARIN-assigned space is
> listed as authoritative, that's the one that gets notified in the event
> of issues, not the customer's address in SWIP.  However, having my
> customer's contact information has proven to be helpful to my
> competitors.  If you know how to scrape SWIP you know a lot, and I would
> argue too much, about my business.

I agree completely and I believe you are actually making my case.  In your
situation you are the aggregation point for your customers traffic.  You can
control that traffic and ameliorate traffic issues.  Because of that you
would in fact be the most appropriate PoC for that network.

I don't think it matters whether the end user is listed as Poc, it does
matter whether the NOC is listed as PoC.  If I need to contact a NOC I don't
care if I am talking to the proprietor, I do care if I am talking to someone
who can do something about a problem.

> 
> Mike
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/5692c918/attachment.bin>

From kkargel at polartel.com  Tue Jun  9 16:11:52 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 15:11:52 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <005e01c9e939$31b54220$951fc660$@net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<005e01c9e939$31b54220$951fc660$@net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2B4@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Aaron Wendel
> Sent: Tuesday, June 09, 2009 2:34 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> I purposely wrote the policy to be short, to the point, and easy to
> understand.  The customer's communication with their provider should
> include
> whether they want their personal information published in a publically
> accessible database.
> 
> My point in writing this policy was to protect information that is
> proprietary to any business.  Tell a realtor you know that you're thinking
> about going into real estate and you'd like his customer list. Then tell
> him
> that you actually need his customer list to make sure he's legit.  If all
> he
> does is laugh at you then you got off lucky.  I can think of no other
> private business that is required to publish customer information to the
> public.
> 
> Customers can ask to have their information included and many of ours
> specifically do but many of them have no idea how to admin their own
> networks.  That's why they come to us.
> 
> This is my first policy proposal and the first I've seen from a source
> outside the usual suspects you see bating around the proposals on the
> list.
> I am not sure how to change the wording or if it needs changing but I feel
> this is an important issue and am open to suggestions and guidance on
> changes that people feel need to be made to make this a workable policy.

I think you got off to a great start.  Good Work and kudo's and thanks!

My input would be that the IP block owner should be listed as PoC by
default, and be responsible for the network traffic.  If the IP owner does
not want to assume responsibility they should have the option of changing
(SWIP?) the PoC to an effective and reachable administrator specified by the
customer.  To maintain privacy that PoC need not be the customer.

Does that make sense?

> 
> Aaron
> 
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Milton L Mueller
> Sent: Tuesday, June 09, 2009 1:36 PM
> To: 'William Herrin'
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> I don't understand how this is a consideration if the ISP continues to be
> accurately identified in the whois. I don't understand how a third party's
> suspicion of an ISP gives them a right to access a customers' data as
> opposed to the ISP data. Recall that ARIN has access to the customer
> information and would thus be accessible to any real fraud investigation.
> 
> > -----Original Message-----
> > It makes it possible for third parties to perform spot-checks which
> > audit the ISP's honest use of address space. Whether used or not, this
> > greatly impacts ARIN's process transparency. This is especially
> > helpful when a supposed ISP is suspected of fraud. A name alone or
> > fully private registrations are insufficient for auditing.
> >
> > Regards,
> > Bill Herrin
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/1e6cef1f/attachment.bin>

From michael.dillon at bt.com  Tue Jun  9 16:16:52 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 9 Jun 2009 21:16:52 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A4F@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <28E139F46D45AF49A31950F88C497458018C32C3@E03MVZ2-UKDY.domain1.systemhost.net>

 
> The policy should be amended to read, "If 
> the customer requests, ISPs may choose to enter their own 
> address and phone number in reassignments and reallocations 
> in lieu of the customer's address and..."

That is opt-in to privacy which I oppose. Privacy should be
the default unless the customer opts-out of privacy and 
indicates their wish to participate in Internet operations.

--Michael Dillon




From michael.dillon at bt.com  Tue Jun  9 16:24:13 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 9 Jun 2009 21:24:13 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AE@mail>
Message-ID: <28E139F46D45AF49A31950F88C497458018C32CB@E03MVZ2-UKDY.domain1.systemhost.net>


> I am all for privacy, but reachability of an effective PoC 
> needs to be maintained.  A PoC who calls a contact who relays 
> a message to someone who knows who the administrator is 
> cannot be effective.

That is precisely the situation that we have today and the
motivation behind this policy proposal. Today the end user
POC info is in whois, so a complainant emails the POC who 
calls their contact at the ISP (help desk) who relays the
message to the ops manager who knows who the network or 
data center admin is. By putting ISP info in the POC, 
a complaint will go direct to the admin.

-- Michael Dillon


From kevin at steadfast.net  Tue Jun  9 16:24:50 2009
From: kevin at steadfast.net (Kevin Stange)
Date: Tue, 09 Jun 2009 15:24:50 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <28E139F46D45AF49A31950F88C497458018C32C3@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458018C32C3@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A2EC512.8020503@steadfast.net>

michael.dillon at bt.com wrote:
>  
>> The policy should be amended to read, "If 
>> the customer requests, ISPs may choose to enter their own 
>> address and phone number in reassignments and reallocations 
>> in lieu of the customer's address and..."
> 
> That is opt-in to privacy which I oppose. Privacy should be
> the default unless the customer opts-out of privacy and 
> indicates their wish to participate in Internet operations.
> 

I don't think I can agree with that.  If this policy reverses the
existing policy and requires information NOT be published unless it's
opted into, all SWIPs, rwhois, and other reallocations would have to be
immediately resubmitted with new POC information or ISPs would need to
seek permission from all affected customers to retain them as is,
resulting in a mountain of paperwork for everyone involved.  Unless
there's a sizable transitional period or grandfathering, this would be a
nightmare for larger networks to accomplish.

I would prefer that this policy leave the option for an ISP to choose to
operate an opt-in or opt-out privacy system.  The downstream customers
or users would certainly have their option to choose whether to utilize
a service provider depending upon which policy it implements.

-- 
Kevin Stange
Chief Technology Officer
Steadfast Networks
http://steadfast.net
Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/1cafcfd0/attachment.sig>

From Daniel_Alexander at Cable.Comcast.com  Tue Jun  9 16:41:25 2009
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Tue, 9 Jun 2009 16:41:25 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <005e01c9e939$31b54220$951fc660$@net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<005e01c9e939$31b54220$951fc660$@net>
Message-ID: <997BC128AE961E4A8B880CD7442D94800C08D8AB@NJCHLEXCMB01.cable.comcast.com>

Aaron,

You are off to a great start and have spurred good discussion. This is
in no way a criticism of the proposal but only a related thought for the
community to consider.

Given current policies and the proposed change, should the removal of
section 4.2.3.7.2 (/29 requirement) be included in such a change? Is
there a point of having hundreds of thousands or millions of /29's,
/28's, etc. with "private customer" and "private address" or the ISP
address information in whois? 

Is there any reason to have all the more specifics listed in whois if a
single aggregate record would cover the same address and POC
information? Of course if an end user wants the more specific listed
with different details, they should be allowed to do so. It just seems
that whois is getting cluttered with specifics that provide no
constructive use that would not be covered by the parent record.

Dan Alexander
ARIN AC

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Aaron Wendel
Sent: Tuesday, June 09, 2009 3:34 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

I purposely wrote the policy to be short, to the point, and easy to
understand.  The customer's communication with their provider should
include
whether they want their personal information published in a publically
accessible database.

My point in writing this policy was to protect information that is
proprietary to any business.  Tell a realtor you know that you're
thinking
about going into real estate and you'd like his customer list. Then tell
him
that you actually need his customer list to make sure he's legit.  If
all he
does is laugh at you then you got off lucky.  I can think of no other
private business that is required to publish customer information to the
public.

Customers can ask to have their information included and many of ours
specifically do but many of them have no idea how to admin their own
networks.  That's why they come to us.

This is my first policy proposal and the first I've seen from a source
outside the usual suspects you see bating around the proposals on the
list.
I am not sure how to change the wording or if it needs changing but I
feel
this is an important issue and am open to suggestions and guidance on
changes that people feel need to be made to make this a workable policy.

Aaron



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Milton L Mueller
Sent: Tuesday, June 09, 2009 1:36 PM
To: 'William Herrin'
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

I don't understand how this is a consideration if the ISP continues to
be
accurately identified in the whois. I don't understand how a third
party's
suspicion of an ISP gives them a right to access a customers' data as
opposed to the ISP data. Recall that ARIN has access to the customer
information and would thus be accessible to any real fraud
investigation. 

> -----Original Message-----
> It makes it possible for third parties to perform spot-checks which
> audit the ISP's honest use of address space. Whether used or not, this
> greatly impacts ARIN's process transparency. This is especially
> helpful when a supposed ISP is suspected of fraud. A name alone or
> fully private registrations are insufficient for auditing.
> 
> Regards,
> Bill Herrin
> 
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From aaron at wholesaleinternet.net  Tue Jun  9 17:07:27 2009
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Tue, 9 Jun 2009 16:07:27 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800C08D8AB@NJCHLEXCMB01.cable.comcast.com>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<005e01c9e939$31b54220$951fc660$@net>
	<997BC128AE961E4A8B880CD7442D94800C08D8AB@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <00ae01c9e946$4b386760$e1a93620$@net>

Here are some considerations I took into account.  Even though the proposal
is only 2 sentences it's literally the 20th time I wrote it.

The policy states that the ISP may use it's address and phone number. I
purposefully left out name.  The point of this was to show that there was a
real entity using the block and what block they were using.  If you are
having abuse issues with a range this will show you how extensive that range
is so you can block/null/whatever while a resolution is sought with the ISP.

My intention with the policy is that a SWIP would have the customer's name,
and the ISPs contact info.

Also, I used the word "may" because I wanted to leave it open to the ISPs on
whether they use it or not.  It's an option that doesn't exist now.  If you
choose to publish your customer list then that's up to you.

Not a perfect solution but one that I thought would serve both the privacy
side of the argument and the abuse side.

So the request was made to me off list that I change the proposal to do away
with SWIP and RWHOIS entirely.  I believe that they still serve a purpose
for justification of new ranges and as a marker for how much of a certain IP
space is allocated to a certain customer.

Aaron




-----Original Message-----
From: Alexander, Daniel [mailto:Daniel_Alexander at Cable.Comcast.com] 
Sent: Tuesday, June 09, 2009 3:41 PM
To: Aaron Wendel; arin-ppml at arin.net
Subject: RE: [arin-ppml] Policy Proposal: Customer Confidentiality

Aaron,

You are off to a great start and have spurred good discussion. This is
in no way a criticism of the proposal but only a related thought for the
community to consider.

Given current policies and the proposed change, should the removal of
section 4.2.3.7.2 (/29 requirement) be included in such a change? Is
there a point of having hundreds of thousands or millions of /29's,
/28's, etc. with "private customer" and "private address" or the ISP
address information in whois? 

Is there any reason to have all the more specifics listed in whois if a
single aggregate record would cover the same address and POC
information? Of course if an end user wants the more specific listed
with different details, they should be allowed to do so. It just seems
that whois is getting cluttered with specifics that provide no
constructive use that would not be covered by the parent record.

Dan Alexander
ARIN AC

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Aaron Wendel
Sent: Tuesday, June 09, 2009 3:34 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

I purposely wrote the policy to be short, to the point, and easy to
understand.  The customer's communication with their provider should
include
whether they want their personal information published in a publically
accessible database.

My point in writing this policy was to protect information that is
proprietary to any business.  Tell a realtor you know that you're
thinking
about going into real estate and you'd like his customer list. Then tell
him
that you actually need his customer list to make sure he's legit.  If
all he
does is laugh at you then you got off lucky.  I can think of no other
private business that is required to publish customer information to the
public.

Customers can ask to have their information included and many of ours
specifically do but many of them have no idea how to admin their own
networks.  That's why they come to us.

This is my first policy proposal and the first I've seen from a source
outside the usual suspects you see bating around the proposals on the
list.
I am not sure how to change the wording or if it needs changing but I
feel
this is an important issue and am open to suggestions and guidance on
changes that people feel need to be made to make this a workable policy.

Aaron



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Milton L Mueller
Sent: Tuesday, June 09, 2009 1:36 PM
To: 'William Herrin'
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

I don't understand how this is a consideration if the ISP continues to
be
accurately identified in the whois. I don't understand how a third
party's
suspicion of an ISP gives them a right to access a customers' data as
opposed to the ISP data. Recall that ARIN has access to the customer
information and would thus be accessible to any real fraud
investigation. 

> -----Original Message-----
> It makes it possible for third parties to perform spot-checks which
> audit the ISP's honest use of address space. Whether used or not, this
> greatly impacts ARIN's process transparency. This is especially
> helpful when a supposed ISP is suspected of fraud. A name alone or
> fully private registrations are insufficient for auditing.
> 
> Regards,
> Bill Herrin
> 
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



From bill at herrin.us  Tue Jun  9 17:43:20 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 9 Jun 2009 17:43:20 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <005e01c9e939$31b54220$951fc660$@net>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<005e01c9e939$31b54220$951fc660$@net>
Message-ID: <3c3e3fca0906091443w21470295g10c2a88da3338be1@mail.gmail.com>

On Tue, Jun 9, 2009 at 3:33 PM, Aaron Wendel<aaron at wholesaleinternet.net> wrote:
> My point in writing this policy was to protect information that is
> proprietary to any business. ?Tell a realtor you know that you're thinking
> about going into real estate and you'd like his customer list. Then tell him
> that you actually need his customer list to make sure he's legit. ?If all he
> does is laugh at you then you got off lucky. ?I can think of no other
> private business that is required to publish customer information to the
> public.

Aaron,

Since you brought it up, let's talk real estate. Do you own a house?
If you do and I know your address then I know who you are and I know
how much you paid for the house because your identity and quite a bit
of information about you is published in the public tax records.

Go ahead and try it with the address in my sig:
http://icare.fairfaxcounty.gov/Search/GenericSearch.aspx?mode=ADDRESS

As with land, the public has a bona fide interest in knowing who is
using IP addresses in more than a transient way.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From aaron at wholesaleinternet.net  Tue Jun  9 18:10:10 2009
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Tue, 9 Jun 2009 17:10:10 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <3c3e3fca0906091443w21470295g10c2a88da3338be1@mail.gmail.com>
References: <4A2E5BD2.8090708@arin.net>	
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>	
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>	
	<005e01c9e939$31b54220$951fc660$@net>
	<3c3e3fca0906091443w21470295g10c2a88da3338be1@mail.gmail.com>
Message-ID: <00ba01c9e94f$0dd71f20$29855d60$@net>

Hi William,

I disagree.  

I do own my primary residence but searching public records will get you
nowhere.  There is no mortgage filing/interest in my house.  The name on the
property records is a trust and the original sale records show a single
dollar received in consideration for the filing of the deed.

Even with my address:  I live on a private street so the best google will
get you is a satellite view of a bunch of trees.  The county website will
show you tax assessment which is nowhere near what I paid for the house and
there are no names on the website.  Even the number of bedrooms and sq ft is
off.

It sounds fishy but I'm not trying to hide anything.  It's simply a set of
circumstances and choices I've made in how I deal with managing my property
acquisitions. 

To address the point you were trying to make, real property is subject to
regulations set forth by government agencies. There are open records laws
that govern what information needs to be made public.  Last time I checked
those laws did not apply to private companies.

My proposal does not preclude the availability of customer information to
ARIN or any government agency that has a legitimate need to view it. It even
says that such information must be made available to ARIN on request.

Once again, I wrote the proposal to present the option.  It still allows you
to publish your customer list if you so choose.  It takes nothing away you
currently have.

Aaron


-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William
Herrin
Sent: Tuesday, June 09, 2009 4:43 PM
To: Aaron Wendel
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

On Tue, Jun 9, 2009 at 3:33 PM, Aaron Wendel<aaron at wholesaleinternet.net>
wrote:
> My point in writing this policy was to protect information that is
> proprietary to any business. ?Tell a realtor you know that you're thinking
> about going into real estate and you'd like his customer list. Then tell
him
> that you actually need his customer list to make sure he's legit. ?If all
he
> does is laugh at you then you got off lucky. ?I can think of no other
> private business that is required to publish customer information to the
> public.

Aaron,

Since you brought it up, let's talk real estate. Do you own a house?
If you do and I know your address then I know who you are and I know
how much you paid for the house because your identity and quite a bit
of information about you is published in the public tax records.

Go ahead and try it with the address in my sig:
http://icare.fairfaxcounty.gov/Search/GenericSearch.aspx?mode=ADDRESS

As with land, the public has a bona fide interest in knowing who is
using IP addresses in more than a transient way.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



From Daniel_Alexander at Cable.Comcast.com  Tue Jun  9 18:17:37 2009
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Tue, 9 Jun 2009 18:17:37 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <3c3e3fca0906091443w21470295g10c2a88da3338be1@mail.gmail.com>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><005e01c9e939$31b54220$951fc660$@net>
	<3c3e3fca0906091443w21470295g10c2a88da3338be1@mail.gmail.com>
Message-ID: <997BC128AE961E4A8B880CD7442D94800C08D993@NJCHLEXCMB01.cable.comcast.com>

Bill,

Do you think the community needs to know the details of every user of the IP address space, or do they just need to know the contact information of those that are responsible for its use?

-Dan

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
Sent: Tuesday, June 09, 2009 5:43 PM
To: Aaron Wendel
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

On Tue, Jun 9, 2009 at 3:33 PM, Aaron Wendel<aaron at wholesaleinternet.net> wrote:
> My point in writing this policy was to protect information that is
> proprietary to any business. ?Tell a realtor you know that you're thinking
> about going into real estate and you'd like his customer list. Then tell him
> that you actually need his customer list to make sure he's legit. ?If all he
> does is laugh at you then you got off lucky. ?I can think of no other
> private business that is required to publish customer information to the
> public.

Aaron,

Since you brought it up, let's talk real estate. Do you own a house?
If you do and I know your address then I know who you are and I know
how much you paid for the house because your identity and quite a bit
of information about you is published in the public tax records.

Go ahead and try it with the address in my sig:
http://icare.fairfaxcounty.gov/Search/GenericSearch.aspx?mode=ADDRESS

As with land, the public has a bona fide interest in knowing who is
using IP addresses in more than a transient way.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From owen at delong.com  Tue Jun  9 18:22:42 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Jun 2009 15:22:42 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2EAE43.9060702@kl.net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<4A2EAE43.9060702@kl.net>
Message-ID: <94D2A8BE-CA95-49D2-BA7C-7C18F6E809C4@delong.com>

They are required to be publicly accessible although there
has definitely been some skirting of that requirement by some
organizations in the past.

Owen

On Jun 9, 2009, at 11:47 AM, Kevin Loch wrote:

> Milton L Mueller wrote:
>> I don't understand how this is a consideration if the ISP continues  
>> to be
> > accurately identified in the whois.
>
> Is it required that rwhois servers be accessible to the public or  
> just to ARIN for making/validating reassignments?  If so then that  
> is a
> way to limit the distribution of confidential customer info to just
> ARIN staff (which is covered by the RSA) that would not require this
> policy change.
>
> I am hesitant to support a policy that would reduce the quality and
> depth of reassignment data.  This is especially important as we
> get closer to IPv4 runout and the temptation to fudge reassignments
> increases.
>
> - Kevin
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From owen at delong.com  Tue Jun  9 18:44:39 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 9 Jun 2009 15:44:39 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <005e01c9e939$31b54220$951fc660$@net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<005e01c9e939$31b54220$951fc660$@net>
Message-ID: <2C4FE2DF-DDCB-4000-A3BB-AD06451B2A4D@delong.com>


On Jun 9, 2009, at 12:33 PM, Aaron Wendel wrote:

> I purposely wrote the policy to be short, to the point, and easy to
> understand.  The customer's communication with their provider should  
> include
> whether they want their personal information published in a publically
> accessible database.
>
> My point in writing this policy was to protect information that is
> proprietary to any business.  Tell a realtor you know that you're  
> thinking
> about going into real estate and you'd like his customer list. Then  
> tell him
> that you actually need his customer list to make sure he's legit.   
> If all he
> does is laugh at you then you got off lucky.  I can think of no other
> private business that is required to publish customer information to  
> the
> public.
>
The realtor is not connecting you to a global packet switched network.
To my knowledge, no other private business does that.

For better or worse, we already have a huge exception for residential
customer privacy. Extending this to allow ISPs to obscure whatever
data they want about their allocation/assignment practices is, in my
opinion, contrary to the public interest and certainly should apply to
any IPv4 assignment larger than a /27 or IPv6 assignment larger than
a /56. It further should not apply to any IPv4 or IPv6 allocation.

This is just my own opinion.

Owen




From kkargel at polartel.com  Tue Jun  9 18:53:39 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 9 Jun 2009 17:53:39 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <2C4FE2DF-DDCB-4000-A3BB-AD06451B2A4D@delong.com>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><005e01c9e939$31b54220$951fc660$@net>
	<2C4FE2DF-DDCB-4000-A3BB-AD06451B2A4D@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2B8@mail>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Tuesday, June 09, 2009 5:45 PM
> To: Aaron Wendel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> 
> On Jun 9, 2009, at 12:33 PM, Aaron Wendel wrote:
> 
> > I purposely wrote the policy to be short, to the point, and easy to
> > understand.  The customer's communication with their provider should
> > include
> > whether they want their personal information published in a publically
> > accessible database.
> >
> > My point in writing this policy was to protect information that is
> > proprietary to any business.  Tell a realtor you know that you're
> > thinking
> > about going into real estate and you'd like his customer list. Then
> > tell him
> > that you actually need his customer list to make sure he's legit.
> > If all he
> > does is laugh at you then you got off lucky.  I can think of no other
> > private business that is required to publish customer information to
> > the
> > public.
> >
> The realtor is not connecting you to a global packet switched network.
> To my knowledge, no other private business does that.
> 
> For better or worse, we already have a huge exception for residential
> customer privacy. Extending this to allow ISPs to obscure whatever
> data they want about their allocation/assignment practices is, in my
> opinion, contrary to the public interest and certainly should apply to
> any IPv4 assignment larger than a /27 or IPv6 assignment larger than
> a /56. It further should not apply to any IPv4 or IPv6 allocation.
> 
> This is just my own opinion.
> 
> Owen

I like the idea of limiting this to long prefix assignments..  

> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/628aa179/attachment.bin>

From bill at herrin.us  Tue Jun  9 19:11:23 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 9 Jun 2009 19:11:23 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800C08D993@NJCHLEXCMB01.cable.comcast.com>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<005e01c9e939$31b54220$951fc660$@net>
	<3c3e3fca0906091443w21470295g10c2a88da3338be1@mail.gmail.com>
	<997BC128AE961E4A8B880CD7442D94800C08D993@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <3c3e3fca0906091611g11f7f018l6940646bd6460d40@mail.gmail.com>

On Tue, Jun 9, 2009 at 6:17 PM, Alexander,
Daniel<Daniel_Alexander at cable.comcast.com> wrote:
> Do you think the community needs to know the details of every
> user of the IP address space, or do they just need to know the
> contact information of those that are responsible for its use?

Daniel,

Let me put it to you this way: I don't own a gun. I don't want to own
a gun. I probably never will. But I strongly support the second
amendment because as archaic as it may seem, the fact of a well armed
populace plays an important role in keeping our governments from
straying too far.

I could care less who is currently using 199.33.224.1. If he's bugging
me, I'll drop his packets. But I do care about the transparency of the
address allocation process. Open records make it hard to cheat:
there's too much of a chance that some curious fellow will notice an
oddity in one of the records and trigger the audit that busts you. You
can cheat if you really want to but it takes some effort. Closed
records make cheating relatively easy: ARIN doesn't have the resources
to do any significant amount of auditing and we wouldn't want them to
if they did. Since no one else can see your records, you're just an
opaque block of consumption

In a world where we will very soon have too few IP addresses to go
around, the last thing we need to do is make it easier to cheat.



On Tue, Jun 9, 2009 at 6:10 PM, Aaron Wendel<aaron at wholesaleinternet.net> wrote:
> [The proposal] still allows you
> to publish your customer list if you so choose.

Aaron,

Would you like to reconsider that statement? However technically
accurate, its a blatent falsehood which insults the intelligence of
your peers on this group. I presume I don't have to explain why.

> It takes nothing away you currently have.

It takes my ability to assess whether you too are playing the game
honestly. If Reagan was right when he said, "trust but verify," it
takes my ability to trust you. And fails to replace it with the kind
of adversarial system that's required in an untrusted environment.

At a more practical level, it also makes it a good bit harder for the
RBLs like Spamhaus to track spammers since they won't have access to
identifying information with which to correlate prior activities from
elsewhere with the current ones.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From scottleibrand at gmail.com  Tue Jun  9 19:29:51 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 09 Jun 2009 16:29:51 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <00ae01c9e946$4b386760$e1a93620$@net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>	<005e01c9e939$31b54220$951fc660$@net>	<997BC128AE961E4A8B880CD7442D94800C08D8AB@NJCHLEXCMB01.cable.comcast.com>
	<00ae01c9e946$4b386760$e1a93620$@net>
Message-ID: <4A2EF06F.4070204@gmail.com>

I think this message has a few important points that are being missed in 
this discussion:

Aaron Wendel wrote:
> Here are some considerations I took into account.  Even though the proposal
> is only 2 sentences it's literally the 20th time I wrote it.
>   

BTW, thank you for taking the trouble to be precise about language.  It 
really helps to have a short, precise, and concise proposal.

> The policy states that the ISP may use it's address and phone number. I
> purposefully left out name.  The point of this was to show that there was a
> real entity using the block and what block they were using.  If you are
> having abuse issues with a range this will show you how extensive that range
> is so you can block/null/whatever while a resolution is sought with the ISP.
>
> My intention with the policy is that a SWIP would have the customer's name,
> and the ISPs contact info.
>   

I think this is a very important point.  To paraphrase, it means that a 
company still has to publish details about what downstream organizations 
have received address space.  That is an important requirement to 
preserve, IMO.  It also makes it possible to check how much space a 
given prospect/customer has from other providers (if you're an ISP 
evaluating an IP space request from that customer).

I support encouraging ISPs to put in the best contact information 
available, whether it points to the end customer or the ISP. 

> Also, I used the word "may" because I wanted to leave it open to the ISPs on
> whether they use it or not.  It's an option that doesn't exist now.  If you
> choose to publish your customer list then that's up to you.
>
> Not a perfect solution but one that I thought would serve both the privacy
> side of the argument and the abuse side.
>   

I think this proposal strikes a good balance between a number of 
competing requirements, and plan to support it.

-Scott

> So the request was made to me off list that I change the proposal to do away
> with SWIP and RWHOIS entirely.  I believe that they still serve a purpose
> for justification of new ranges and as a marker for how much of a certain IP
> space is allocated to a certain customer.
>
> Aaron
>
>
>
>
> -----Original Message-----
> From: Alexander, Daniel [mailto:Daniel_Alexander at Cable.Comcast.com] 
> Sent: Tuesday, June 09, 2009 3:41 PM
> To: Aaron Wendel; arin-ppml at arin.net
> Subject: RE: [arin-ppml] Policy Proposal: Customer Confidentiality
>
> Aaron,
>
> You are off to a great start and have spurred good discussion. This is
> in no way a criticism of the proposal but only a related thought for the
> community to consider.
>
> Given current policies and the proposed change, should the removal of
> section 4.2.3.7.2 (/29 requirement) be included in such a change? Is
> there a point of having hundreds of thousands or millions of /29's,
> /28's, etc. with "private customer" and "private address" or the ISP
> address information in whois? 
>
> Is there any reason to have all the more specifics listed in whois if a
> single aggregate record would cover the same address and POC
> information? Of course if an end user wants the more specific listed
> with different details, they should be allowed to do so. It just seems
> that whois is getting cluttered with specifics that provide no
> constructive use that would not be covered by the parent record.
>
> Dan Alexander
> ARIN AC
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Aaron Wendel
> Sent: Tuesday, June 09, 2009 3:34 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
>
> I purposely wrote the policy to be short, to the point, and easy to
> understand.  The customer's communication with their provider should
> include
> whether they want their personal information published in a publically
> accessible database.
>
> My point in writing this policy was to protect information that is
> proprietary to any business.  Tell a realtor you know that you're
> thinking
> about going into real estate and you'd like his customer list. Then tell
> him
> that you actually need his customer list to make sure he's legit.  If
> all he
> does is laugh at you then you got off lucky.  I can think of no other
> private business that is required to publish customer information to the
> public.
>
> Customers can ask to have their information included and many of ours
> specifically do but many of them have no idea how to admin their own
> networks.  That's why they come to us.
>
> This is my first policy proposal and the first I've seen from a source
> outside the usual suspects you see bating around the proposals on the
> list.
> I am not sure how to change the wording or if it needs changing but I
> feel
> this is an important issue and am open to suggestions and guidance on
> changes that people feel need to be made to make this a workable policy.
>
> Aaron
>
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Milton L Mueller
> Sent: Tuesday, June 09, 2009 1:36 PM
> To: 'William Herrin'
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
>
> I don't understand how this is a consideration if the ISP continues to
> be
> accurately identified in the whois. I don't understand how a third
> party's
> suspicion of an ISP gives them a right to access a customers' data as
> opposed to the ISP data. Recall that ARIN has access to the customer
> information and would thus be accessible to any real fraud
> investigation. 
>
>   
>> -----Original Message-----
>> It makes it possible for third parties to perform spot-checks which
>> audit the ISP's honest use of address space. Whether used or not, this
>> greatly impacts ARIN's process transparency. This is especially
>> helpful when a supposed ISP is suspected of fraud. A name alone or
>> fully private registrations are insufficient for auditing.
>>
>> Regards,
>> Bill Herrin
>>
>>     
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   


From jay at impulse.net  Tue Jun  9 20:07:32 2009
From: jay at impulse.net (Jay Hennigan)
Date: Tue, 09 Jun 2009 17:07:32 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <2C4FE2DF-DDCB-4000-A3BB-AD06451B2A4D@delong.com>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>	<005e01c9e939$31b54220$951fc660$@net>
	<2C4FE2DF-DDCB-4000-A3BB-AD06451B2A4D@delong.com>
Message-ID: <4A2EF944.1010604@impulse.net>

Owen DeLong wrote:

> The realtor is not connecting you to a global packet switched network.
> To my knowledge, no other private business does that.

Cellular telephone companies do.  And they don't publish their customer 
lists.

Note that I said cellular which has been packet-switched since AMPS went 
away.  Landline telephone companies also connect you to a global 
switched network, which happens to be circuit-switched.  They may or may 
not publish some of their customer lists.  Telephone companies are in 
the unique position of charging extra for both unlisted numbers and 
extra listings.

Telephone companies also allow their customers to hide their source 
address from the recipient on a per-line or per-call basis.

-- 
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From tedm at ipinc.net  Tue Jun  9 20:41:53 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 09 Jun 2009 17:41:53 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <4A2F0151.70703@ipinc.net>


We (my org) completely oppose this policy as it runs counter to
the general privacy adoptions of the worldwide Domain Name System.

In DNS you are allowed to hide the domain name holder's street
address as well as e-mail but you are NOT allowed to hide the NAME
of the holder.

If ARIN is to adopt such a policy it should align with that used by DNS.

Ted

Member Services wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.
> 
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> 1. Policy Proposal Name: Customer Confidentiality
> 
> 2. Proposal Originator: Aaron Wendel
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 9 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number.  The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.
> 
> 8. Rationale:
> 
> Customer contact lists are one of the most proprietary and confidential
> pieces of information in any business.  The requirements for ISPs to
> publish those lists via SWIP or RWHOIS runs contrary to good business
> practices and invites competitors and others to solicit both individuals
> and companies receiving reassignments and sub allocations from upstream
> providers.
> 
> 9. Timetable for implementation: immediate
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From scottleibrand at gmail.com  Tue Jun  9 20:45:48 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 09 Jun 2009 17:45:48 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2F0151.70703@ipinc.net>
References: <4A2E5BD2.8090708@arin.net> <4A2F0151.70703@ipinc.net>
Message-ID: <4A2F023C.7040601@gmail.com>

Ted,

See my last post.  This would not allow you to hide the name on the 
SWIP, just address and phone number.

-Scott

Ted Mittelstaedt wrote:
>
> We (my org) completely oppose this policy as it runs counter to
> the general privacy adoptions of the worldwide Domain Name System.
>
> In DNS you are allowed to hide the domain name holder's street
> address as well as e-mail but you are NOT allowed to hide the NAME
> of the holder.
>
> If ARIN is to adopt such a policy it should align with that used by DNS.
>
> Ted
>
> Member Services wrote:
>> ARIN received the following policy proposal and is posting it to the
>> Public Policy Mailing List (PPML) in accordance with Policy Development
>> Process.
>>
>> This proposal is in the first stage of the Policy Development Process.
>> ARIN staff will perform the Clarity and Understanding step. Staff does
>> not evaluate the proposal at this time, their goal is to make sure that
>> they understand the proposal and believe the community will as well.
>> Staff will report their results to the ARIN Advisory Council (AC) within
>> 10 days.
>>
>> The AC will review the proposal at their next regularly scheduled
>> meeting (if the period before the next regularly scheduled meeting is
>> less than 10 days, then the period may be extended to the subsequent
>> regularly scheduled meeting). The AC will decide how to utilize the
>> proposal and announce the decision to the PPML.
>>
>> In the meantime, the AC invites everyone to comment on the proposal on
>> the PPML, particularly their support or non-support and the reasoning
>> behind their opinion. Such participation contributes to a thorough
>> vetting and provides important guidance to the AC in their 
>> deliberations.
>>
>> The ARIN Policy Development Process can be found at:
>> https://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found
>> at:https://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> 1. Policy Proposal Name: Customer Confidentiality
>>
>> 2. Proposal Originator: Aaron Wendel
>>
>> 3. Proposal Version: 1.0
>>
>> 4. Date: 9 June 2009
>>
>> 5. Proposal type: new
>>
>> 6. Policy term: permanent
>>
>> 7. Policy statement:
>>
>> ISPs may choose to enter their own address and phone number in
>> reassignments and reallocations in lieu of the customer's address and
>> phone number.  The customer's actual information must be provided to
>> ARIN on request and will be held in the strictest confidence.
>>
>> 8. Rationale:
>>
>> Customer contact lists are one of the most proprietary and confidential
>> pieces of information in any business.  The requirements for ISPs to
>> publish those lists via SWIP or RWHOIS runs contrary to good business
>> practices and invites competitors and others to solicit both individuals
>> and companies receiving reassignments and sub allocations from upstream
>> providers.
>>
>> 9. Timetable for implementation: immediate
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From tedm at ipinc.net  Tue Jun  9 20:48:57 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 09 Jun 2009 17:48:57 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <005e01c9e939$31b54220$951fc660$@net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<005e01c9e939$31b54220$951fc660$@net>
Message-ID: <4A2F02F9.70900@ipinc.net>

Aaron Wendel wrote:
> I purposely wrote the policy to be short, to the point, and easy to
> understand.  The customer's communication with their provider should include
> whether they want their personal information published in a publically
> accessible database.
> 
> My point in writing this policy was to protect information that is
> proprietary to any business.  Tell a realtor you know that you're thinking
> about going into real estate and you'd like his customer list. Then tell him
> that you actually need his customer list to make sure he's legit.  If all he
> does is laugh at you then you got off lucky.  I can think of no other
> private business that is required to publish customer information to the
> public.

Every private business that runs a public-access business like a 
restaurant is required to post many notices.  An obvious one is
health inspection info.

Private individuals who drive vehicles on the road must display liscense
plates.

Use of the Internet is use of a public resource just like use of the 
roads is use of a public resource.  Vehicles that use public roads must 
display licenses.  Your example is therefore bogus.

The problem with simple proposals like yours is they take a sledge 
hammer to a problem that needs a delicate touch.  Hopefully after 
everyone has got past their orgy of "oh cool I can go off and be 
anonymous" they will come to their senses and realize this.

Ted

> 
> Customers can ask to have their information included and many of ours
> specifically do but many of them have no idea how to admin their own
> networks.  That's why they come to us.
> 
> This is my first policy proposal and the first I've seen from a source
> outside the usual suspects you see bating around the proposals on the list.
> I am not sure how to change the wording or if it needs changing but I feel
> this is an important issue and am open to suggestions and guidance on
> changes that people feel need to be made to make this a workable policy.
> 
> Aaron
> 
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Milton L Mueller
> Sent: Tuesday, June 09, 2009 1:36 PM
> To: 'William Herrin'
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> I don't understand how this is a consideration if the ISP continues to be
> accurately identified in the whois. I don't understand how a third party's
> suspicion of an ISP gives them a right to access a customers' data as
> opposed to the ISP data. Recall that ARIN has access to the customer
> information and would thus be accessible to any real fraud investigation. 
> 
>> -----Original Message-----
>> It makes it possible for third parties to perform spot-checks which
>> audit the ISP's honest use of address space. Whether used or not, this
>> greatly impacts ARIN's process transparency. This is especially
>> helpful when a supposed ISP is suspected of fraud. A name alone or
>> fully private registrations are insufficient for auditing.
>>
>> Regards,
>> Bill Herrin
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From randy at psg.com  Tue Jun  9 20:56:15 2009
From: randy at psg.com (Randy Bush)
Date: Wed, 10 Jun 2009 09:56:15 +0900
Subject: [arin-ppml] [arin-council] Returning Legacy Space to IANA.
	Attorney client communcation.
In-Reply-To: <4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
Message-ID: <m2r5xsdhzk.wl%randy@psg.com>

> Most large service providers in the region don't believe we're going
> to get a fair shake in the end.

what is perceived as 'fair' differs widely.  some think the largeer
holders have fed sufficiently at the trough.  some think the rich should
get richer.  ymmv.

randy


From martin.hannigan at batelnet.bs  Tue Jun  9 20:49:51 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Tue, 9 Jun 2009 20:49:51 -0400
Subject: [arin-ppml] [arin-council] Returning Legacy Space to IANA.
	Attorney client communcation.
In-Reply-To: <m24ouunjkz.wl%randy@psg.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
Message-ID: <4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>

On Fri, Jun 5, 2009 at 11:10 PM, Randy Bush<randy at psg.com> wrote:
>> in san antonio, jcurran described the return-to-IANA policy for
>> recovered space as a "land grab".
>
> it isn't. ?it is a test by lacnic to show that the arin region is run by
> self-serving imperialist yanquis.
>
> they believe, rightly or wrongly, that the us military will return,
> under a deal made with arin, a large amount of ipv4 space in return for
> the blocking of an amazing amount of ipv6 space. ?lacnic, and others,
> believe that, should this occur, that ipv4 space should be shared by
> all.
>


Most large service providers in the region don't believe we're going
to get a fair shake in the end. Hopefully, the AC and BoT realize
that.

These paranoia's are creating the conditions for the markets that
everyone fears.

[ snip ]


From tedm at ipinc.net  Tue Jun  9 21:13:39 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 09 Jun 2009 18:13:39 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <00ae01c9e946$4b386760$e1a93620$@net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>	<005e01c9e939$31b54220$951fc660$@net>	<997BC128AE961E4A8B880CD7442D94800C08D8AB@NJCHLEXCMB01.cable.comcast.com>
	<00ae01c9e946$4b386760$e1a93620$@net>
Message-ID: <4A2F08C3.5060305@ipinc.net>

Aaron Wendel wrote:
> Here are some considerations I took into account.  Even though the proposal
> is only 2 sentences it's literally the 20th time I wrote it.
> 
> The policy states that the ISP may use it's address and phone number. I
> purposefully left out name.  The point of this was to show that there was a
> real entity using the block and what block they were using.  If you are
> having abuse issues with a range this will show you how extensive that range
> is so you can block/null/whatever while a resolution is sought with the ISP.
> 
> My intention with the policy is that a SWIP would have the customer's name,
> and the ISPs contact info.
> 

I don't have a problem with this.  However you don't explicitly say 
this.  You say:

ISPs may choose to enter their own address and phone number in
reassignments and reallocations in lieu of the customer's address and
phone number.  The customer's actual information must be provided to
ARIN on request and will be held in the strictest confidence.

This leaves open the question of whether the ISP can submit it's name or
the customers name in the SWIP record.  Your Rationale also talks about
"customer contact" which by definition includes the customer NAME as 
well as contact info.

In your zeal to simplify you have committed a serious error.  You have
not specified exactly what you mean, you have left it grey.  As a result
if this passes people will be claiming that they don't need to submit 
the customer name.

I would strongly suggest that if you actually WANT the customer name
and ISP contact info to show up, that you send in a policy amendment
that says this.

Ted

> Also, I used the word "may" because I wanted to leave it open to the ISPs on
> whether they use it or not.  It's an option that doesn't exist now.  If you
> choose to publish your customer list then that's up to you.
> 
> Not a perfect solution but one that I thought would serve both the privacy
> side of the argument and the abuse side.
> 
> So the request was made to me off list that I change the proposal to do away
> with SWIP and RWHOIS entirely.  I believe that they still serve a purpose
> for justification of new ranges and as a marker for how much of a certain IP
> space is allocated to a certain customer.
> 
> Aaron
> 
> 
> 
> 
> -----Original Message-----
> From: Alexander, Daniel [mailto:Daniel_Alexander at Cable.Comcast.com] 
> Sent: Tuesday, June 09, 2009 3:41 PM
> To: Aaron Wendel; arin-ppml at arin.net
> Subject: RE: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> Aaron,
> 
> You are off to a great start and have spurred good discussion. This is
> in no way a criticism of the proposal but only a related thought for the
> community to consider.
> 
> Given current policies and the proposed change, should the removal of
> section 4.2.3.7.2 (/29 requirement) be included in such a change? Is
> there a point of having hundreds of thousands or millions of /29's,
> /28's, etc. with "private customer" and "private address" or the ISP
> address information in whois? 
> 
> Is there any reason to have all the more specifics listed in whois if a
> single aggregate record would cover the same address and POC
> information? Of course if an end user wants the more specific listed
> with different details, they should be allowed to do so. It just seems
> that whois is getting cluttered with specifics that provide no
> constructive use that would not be covered by the parent record.
> 
> Dan Alexander
> ARIN AC
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Aaron Wendel
> Sent: Tuesday, June 09, 2009 3:34 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> I purposely wrote the policy to be short, to the point, and easy to
> understand.  The customer's communication with their provider should
> include
> whether they want their personal information published in a publically
> accessible database.
> 
> My point in writing this policy was to protect information that is
> proprietary to any business.  Tell a realtor you know that you're
> thinking
> about going into real estate and you'd like his customer list. Then tell
> him
> that you actually need his customer list to make sure he's legit.  If
> all he
> does is laugh at you then you got off lucky.  I can think of no other
> private business that is required to publish customer information to the
> public.
> 
> Customers can ask to have their information included and many of ours
> specifically do but many of them have no idea how to admin their own
> networks.  That's why they come to us.
> 
> This is my first policy proposal and the first I've seen from a source
> outside the usual suspects you see bating around the proposals on the
> list.
> I am not sure how to change the wording or if it needs changing but I
> feel
> this is an important issue and am open to suggestions and guidance on
> changes that people feel need to be made to make this a workable policy.
> 
> Aaron
> 
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Milton L Mueller
> Sent: Tuesday, June 09, 2009 1:36 PM
> To: 'William Herrin'
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> I don't understand how this is a consideration if the ISP continues to
> be
> accurately identified in the whois. I don't understand how a third
> party's
> suspicion of an ISP gives them a right to access a customers' data as
> opposed to the ISP data. Recall that ARIN has access to the customer
> information and would thus be accessible to any real fraud
> investigation. 
> 
>> -----Original Message-----
>> It makes it possible for third parties to perform spot-checks which
>> audit the ISP's honest use of address space. Whether used or not, this
>> greatly impacts ARIN's process transparency. This is especially
>> helpful when a supposed ISP is suspected of fraud. A name alone or
>> fully private registrations are insufficient for auditing.
>>
>> Regards,
>> Bill Herrin
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From tedm at ipinc.net  Tue Jun  9 21:35:23 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 09 Jun 2009 18:35:23 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2F023C.7040601@gmail.com>
References: <4A2E5BD2.8090708@arin.net> <4A2F0151.70703@ipinc.net>
	<4A2F023C.7040601@gmail.com>
Message-ID: <4A2F0DDB.4070808@ipinc.net>

Scott Leibrand wrote:
> Ted,
> 
> See my last post.  This would not allow you to hide the name on the 
> SWIP, just address and phone number.
> 

Not exactly true.  Policy implementation is a matter of interpretation
of the written policy.  It is entirely possible to write a policy and 
have it go into the manual and end up with it being interpreted 
differently than your intention.  That is one reason why the Rationale 
section exists - to help ARIN staff interpret policy changes so they are 
interpreted the way you intend, not some different way.

With this proposal, the Rationale is very generally written, and the 
policy proposal attempts to be concise.  Unfortunately, concise 
statements are very subject to reinterpretation.  Since the NAME field 
is NOT specified by the policy change, and the Rationale section talks a 
great deal about privacy and customer contact, it is pretty easy to make 
  a case that publishing the company name would defeat the point of 
hiding the company contact info - and thus defeat the intent of the 
privacy desires as expressed in the Rationale.

It's my hope that the policy submitter will rewrite the submission to 
make it more explicit.  I understand it's his first and as such is a 
learning experience.  I also am not surprised to see it as I expected 
something along these lines if my own whois POC cleanup policy was 
adopted.  But it must be explicit that the ISP filing the SWIP may opt 
to privatize the street address/e-mail/etc but that they ARE NOT ALLOWED 
to do this with the NAME of the customer.  I frankly also find nothing 
is served by hiding the e-mail address as well, since if the customer 
wants they can use a privatized domain name that also reveals nothing - 
but that is a minor quibble and not anywhere nearly as important as 
explicitly stating the customer name, not the ISP name, must be present 
in the SWIP.


Ted

> -Scott
> 
> Ted Mittelstaedt wrote:
>>
>> We (my org) completely oppose this policy as it runs counter to
>> the general privacy adoptions of the worldwide Domain Name System.
>>
>> In DNS you are allowed to hide the domain name holder's street
>> address as well as e-mail but you are NOT allowed to hide the NAME
>> of the holder.
>>
>> If ARIN is to adopt such a policy it should align with that used by DNS.
>>
>> Ted
>>
>> Member Services wrote:
>>> ARIN received the following policy proposal and is posting it to the
>>> Public Policy Mailing List (PPML) in accordance with Policy Development
>>> Process.
>>>
>>> This proposal is in the first stage of the Policy Development Process.
>>> ARIN staff will perform the Clarity and Understanding step. Staff does
>>> not evaluate the proposal at this time, their goal is to make sure that
>>> they understand the proposal and believe the community will as well.
>>> Staff will report their results to the ARIN Advisory Council (AC) within
>>> 10 days.
>>>
>>> The AC will review the proposal at their next regularly scheduled
>>> meeting (if the period before the next regularly scheduled meeting is
>>> less than 10 days, then the period may be extended to the subsequent
>>> regularly scheduled meeting). The AC will decide how to utilize the
>>> proposal and announce the decision to the PPML.
>>>
>>> In the meantime, the AC invites everyone to comment on the proposal on
>>> the PPML, particularly their support or non-support and the reasoning
>>> behind their opinion. Such participation contributes to a thorough
>>> vetting and provides important guidance to the AC in their 
>>> deliberations.
>>>
>>> The ARIN Policy Development Process can be found at:
>>> https://www.arin.net/policy/pdp.html
>>>
>>> Mailing list subscription information can be found
>>> at:https://www.arin.net/mailing_lists/
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> ## * ##
>>>
>>>
>>> 1. Policy Proposal Name: Customer Confidentiality
>>>
>>> 2. Proposal Originator: Aaron Wendel
>>>
>>> 3. Proposal Version: 1.0
>>>
>>> 4. Date: 9 June 2009
>>>
>>> 5. Proposal type: new
>>>
>>> 6. Policy term: permanent
>>>
>>> 7. Policy statement:
>>>
>>> ISPs may choose to enter their own address and phone number in
>>> reassignments and reallocations in lieu of the customer's address and
>>> phone number.  The customer's actual information must be provided to
>>> ARIN on request and will be held in the strictest confidence.
>>>
>>> 8. Rationale:
>>>
>>> Customer contact lists are one of the most proprietary and confidential
>>> pieces of information in any business.  The requirements for ISPs to
>>> publish those lists via SWIP or RWHOIS runs contrary to good business
>>> practices and invites competitors and others to solicit both individuals
>>> and companies receiving reassignments and sub allocations from upstream
>>> providers.
>>>
>>> 9. Timetable for implementation: immediate
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.



From scottleibrand at gmail.com  Tue Jun  9 22:44:01 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 09 Jun 2009 19:44:01 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2F0DDB.4070808@ipinc.net>
References: <4A2E5BD2.8090708@arin.net> <4A2F0151.70703@ipinc.net>
	<4A2F023C.7040601@gmail.com> <4A2F0DDB.4070808@ipinc.net>
Message-ID: <4A2F1DF1.3070402@gmail.com>

Ted Mittelstaedt wrote:
> Scott Leibrand wrote:
>> Ted,
>>
>> See my last post.  This would not allow you to hide the name on the 
>> SWIP, just address and phone number.
>>
>
> Not exactly true.  Policy implementation is a matter of interpretation
> of the written policy.  It is entirely possible to write a policy and 
> have it go into the manual and end up with it being interpreted 
> differently than your intention.  That is one reason why the Rationale 
> section exists - to help ARIN staff interpret policy changes so they 
> are interpreted the way you intend, not some different way.
>
> With this proposal, the Rationale is very generally written, and the 
> policy proposal attempts to be concise.  Unfortunately, concise 
> statements are very subject to reinterpretation.  Since the NAME field 
> is NOT specified by the policy change, and the Rationale section talks 
> a great deal about privacy and customer contact, it is pretty easy to 
> make  a case that publishing the company name would defeat the point 
> of hiding the company contact info - and thus defeat the intent of the 
> privacy desires as expressed in the Rationale.

Fair enough.  We actually do have another mechanism to address this, as 
well.  Right now, this policy proposal is being reviewed by ARIN staff 
for "clarity and understanding".  This question, of whether the name 
field is still required on SWIPs, is one of the things that they'll 
likely get clarity on, and express their understanding and 
interpretation.  One beneficial result of that process is that it 
usually prompts the author and/or the AC to revise the proposal to clear 
up anything that's confusing.  (And in this case, the fact that we're 
talking about it here on PPML gives us yet another way to identify 
things that are open to interpretation.)
>
> It's my hope that the policy submitter will rewrite the submission to 
> make it more explicit.  I understand it's his first and as such is a 
> learning experience.  I also am not surprised to see it as I expected 
> something along these lines if my own whois POC cleanup policy was 
> adopted.  But it must be explicit that the ISP filing the SWIP may opt 
> to privatize the street address/e-mail/etc but that they ARE NOT 
> ALLOWED to do this with the NAME of the customer.  I frankly also find 
> nothing is served by hiding the e-mail address as well, since if the 
> customer wants they can use a privatized domain name that also reveals 
> nothing - but that is a minor quibble and not anywhere nearly as 
> important as explicitly stating the customer name, not the ISP name, 
> must be present in the SWIP.

I think that is a good clarification to make.  Aaron, if you have any 
trouble coming up with good clarification text, the AC will be happy to 
help draft it.

-Scott
>
>
> Ted
>
>> -Scott
>>
>> Ted Mittelstaedt wrote:
>>>
>>> We (my org) completely oppose this policy as it runs counter to
>>> the general privacy adoptions of the worldwide Domain Name System.
>>>
>>> In DNS you are allowed to hide the domain name holder's street
>>> address as well as e-mail but you are NOT allowed to hide the NAME
>>> of the holder.
>>>
>>> If ARIN is to adopt such a policy it should align with that used by 
>>> DNS.
>>>
>>> Ted
>>>
>>> Member Services wrote:
>>>> ARIN received the following policy proposal and is posting it to the
>>>> Public Policy Mailing List (PPML) in accordance with Policy 
>>>> Development
>>>> Process.
>>>>
>>>> This proposal is in the first stage of the Policy Development Process.
>>>> ARIN staff will perform the Clarity and Understanding step. Staff does
>>>> not evaluate the proposal at this time, their goal is to make sure 
>>>> that
>>>> they understand the proposal and believe the community will as well.
>>>> Staff will report their results to the ARIN Advisory Council (AC) 
>>>> within
>>>> 10 days.
>>>>
>>>> The AC will review the proposal at their next regularly scheduled
>>>> meeting (if the period before the next regularly scheduled meeting is
>>>> less than 10 days, then the period may be extended to the subsequent
>>>> regularly scheduled meeting). The AC will decide how to utilize the
>>>> proposal and announce the decision to the PPML.
>>>>
>>>> In the meantime, the AC invites everyone to comment on the proposal on
>>>> the PPML, particularly their support or non-support and the reasoning
>>>> behind their opinion. Such participation contributes to a thorough
>>>> vetting and provides important guidance to the AC in their 
>>>> deliberations.
>>>>
>>>> The ARIN Policy Development Process can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>>
>>>> Mailing list subscription information can be found
>>>> at:https://www.arin.net/mailing_lists/
>>>>
>>>> Regards,
>>>>
>>>> Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>>
>>>> ## * ##
>>>>
>>>>
>>>> 1. Policy Proposal Name: Customer Confidentiality
>>>>
>>>> 2. Proposal Originator: Aaron Wendel
>>>>
>>>> 3. Proposal Version: 1.0
>>>>
>>>> 4. Date: 9 June 2009
>>>>
>>>> 5. Proposal type: new
>>>>
>>>> 6. Policy term: permanent
>>>>
>>>> 7. Policy statement:
>>>>
>>>> ISPs may choose to enter their own address and phone number in
>>>> reassignments and reallocations in lieu of the customer's address and
>>>> phone number.  The customer's actual information must be provided to
>>>> ARIN on request and will be held in the strictest confidence.
>>>>
>>>> 8. Rationale:
>>>>
>>>> Customer contact lists are one of the most proprietary and 
>>>> confidential
>>>> pieces of information in any business.  The requirements for ISPs to
>>>> publish those lists via SWIP or RWHOIS runs contrary to good business
>>>> practices and invites competitors and others to solicit both 
>>>> individuals
>>>> and companies receiving reassignments and sub allocations from 
>>>> upstream
>>>> providers.
>>>>
>>>> 9. Timetable for implementation: immediate
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>


From aaron at wholesaleinternet.net  Tue Jun  9 23:01:05 2009
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Tue, 9 Jun 2009 22:01:05 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2F1DF1.3070402@gmail.com>
References: <4A2E5BD2.8090708@arin.net>
	<4A2F0151.70703@ipinc.net>	<4A2F023C.7040601@gmail.com>
	<4A2F0DDB.4070808@ipinc.net> <4A2F1DF1.3070402@gmail.com>
Message-ID: <00db01c9e977$b2292230$167b6690$@net>

I've submitted a "Version 2" with the following wording:

ISPs may choose to enter the customer's name along with the ISP's address
and phone number in reassignments and reallocations in lieu of the
customer's address and phone number.  The customer's actual information must
be provided to ARIN on request and will be held in the strictest confidence.

That should make it clearer. 

Aaron


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Scott Leibrand
Sent: Tuesday, June 09, 2009 9:44 PM
To: Ted Mittelstaedt
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

Ted Mittelstaedt wrote:
> Scott Leibrand wrote:
>> Ted,
>>
>> See my last post.  This would not allow you to hide the name on the 
>> SWIP, just address and phone number.
>>
>
> Not exactly true.  Policy implementation is a matter of interpretation
> of the written policy.  It is entirely possible to write a policy and 
> have it go into the manual and end up with it being interpreted 
> differently than your intention.  That is one reason why the Rationale 
> section exists - to help ARIN staff interpret policy changes so they 
> are interpreted the way you intend, not some different way.
>
> With this proposal, the Rationale is very generally written, and the 
> policy proposal attempts to be concise.  Unfortunately, concise 
> statements are very subject to reinterpretation.  Since the NAME field 
> is NOT specified by the policy change, and the Rationale section talks 
> a great deal about privacy and customer contact, it is pretty easy to 
> make  a case that publishing the company name would defeat the point 
> of hiding the company contact info - and thus defeat the intent of the 
> privacy desires as expressed in the Rationale.

Fair enough.  We actually do have another mechanism to address this, as 
well.  Right now, this policy proposal is being reviewed by ARIN staff 
for "clarity and understanding".  This question, of whether the name 
field is still required on SWIPs, is one of the things that they'll 
likely get clarity on, and express their understanding and 
interpretation.  One beneficial result of that process is that it 
usually prompts the author and/or the AC to revise the proposal to clear 
up anything that's confusing.  (And in this case, the fact that we're 
talking about it here on PPML gives us yet another way to identify 
things that are open to interpretation.)
>
> It's my hope that the policy submitter will rewrite the submission to 
> make it more explicit.  I understand it's his first and as such is a 
> learning experience.  I also am not surprised to see it as I expected 
> something along these lines if my own whois POC cleanup policy was 
> adopted.  But it must be explicit that the ISP filing the SWIP may opt 
> to privatize the street address/e-mail/etc but that they ARE NOT 
> ALLOWED to do this with the NAME of the customer.  I frankly also find 
> nothing is served by hiding the e-mail address as well, since if the 
> customer wants they can use a privatized domain name that also reveals 
> nothing - but that is a minor quibble and not anywhere nearly as 
> important as explicitly stating the customer name, not the ISP name, 
> must be present in the SWIP.

I think that is a good clarification to make.  Aaron, if you have any 
trouble coming up with good clarification text, the AC will be happy to 
help draft it.

-Scott
>
>
> Ted
>
>> -Scott
>>
>> Ted Mittelstaedt wrote:
>>>
>>> We (my org) completely oppose this policy as it runs counter to
>>> the general privacy adoptions of the worldwide Domain Name System.
>>>
>>> In DNS you are allowed to hide the domain name holder's street
>>> address as well as e-mail but you are NOT allowed to hide the NAME
>>> of the holder.
>>>
>>> If ARIN is to adopt such a policy it should align with that used by 
>>> DNS.
>>>
>>> Ted
>>>
>>> Member Services wrote:
>>>> ARIN received the following policy proposal and is posting it to the
>>>> Public Policy Mailing List (PPML) in accordance with Policy 
>>>> Development
>>>> Process.
>>>>
>>>> This proposal is in the first stage of the Policy Development Process.
>>>> ARIN staff will perform the Clarity and Understanding step. Staff does
>>>> not evaluate the proposal at this time, their goal is to make sure 
>>>> that
>>>> they understand the proposal and believe the community will as well.
>>>> Staff will report their results to the ARIN Advisory Council (AC) 
>>>> within
>>>> 10 days.
>>>>
>>>> The AC will review the proposal at their next regularly scheduled
>>>> meeting (if the period before the next regularly scheduled meeting is
>>>> less than 10 days, then the period may be extended to the subsequent
>>>> regularly scheduled meeting). The AC will decide how to utilize the
>>>> proposal and announce the decision to the PPML.
>>>>
>>>> In the meantime, the AC invites everyone to comment on the proposal on
>>>> the PPML, particularly their support or non-support and the reasoning
>>>> behind their opinion. Such participation contributes to a thorough
>>>> vetting and provides important guidance to the AC in their 
>>>> deliberations.
>>>>
>>>> The ARIN Policy Development Process can be found at:
>>>> https://www.arin.net/policy/pdp.html
>>>>
>>>> Mailing list subscription information can be found
>>>> at:https://www.arin.net/mailing_lists/
>>>>
>>>> Regards,
>>>>
>>>> Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>>
>>>> ## * ##
>>>>
>>>>
>>>> 1. Policy Proposal Name: Customer Confidentiality
>>>>
>>>> 2. Proposal Originator: Aaron Wendel
>>>>
>>>> 3. Proposal Version: 1.0
>>>>
>>>> 4. Date: 9 June 2009
>>>>
>>>> 5. Proposal type: new
>>>>
>>>> 6. Policy term: permanent
>>>>
>>>> 7. Policy statement:
>>>>
>>>> ISPs may choose to enter their own address and phone number in
>>>> reassignments and reallocations in lieu of the customer's address and
>>>> phone number.  The customer's actual information must be provided to
>>>> ARIN on request and will be held in the strictest confidence.
>>>>
>>>> 8. Rationale:
>>>>
>>>> Customer contact lists are one of the most proprietary and 
>>>> confidential
>>>> pieces of information in any business.  The requirements for ISPs to
>>>> publish those lists via SWIP or RWHOIS runs contrary to good business
>>>> practices and invites competitors and others to solicit both 
>>>> individuals
>>>> and companies receiving reassignments and sub allocations from 
>>>> upstream
>>>> providers.
>>>>
>>>> 9. Timetable for implementation: immediate
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



From mysidia at gmail.com  Tue Jun  9 23:19:32 2009
From: mysidia at gmail.com (James Hess)
Date: Tue, 9 Jun 2009 22:19:32 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2EA88D.5030102@steadfast.net>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<4A2EA88D.5030102@steadfast.net>
Message-ID: <6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com>

[snip]
> Privacy of personal information is something our customers regularly ask
> us about because our system automatically publishes their information in
> rwhois. ?In many cases, these customers do not have the technical
[snip]
I oppose this policy, because sufficient privacy is already provided
by the NPRM under section 4.2.3.7.6
https://www.arin.net/policy/nrpm.html#four2376

If you are the responsible party for a business'  computer network,
your business contact information is not personal information.
And your organization's identity and address are not personal information.

For the reasons already mentioned by others, it is essential  that
public contact and address information be available  for  assignees of
IP space who participate in the public internet.


There are suitable means available to indicate on a WHOIS record that
the ISP should be contacted instead of the end-user.   A  "Comment"
and additional Abuse POC  can be entered on the record.

Current policy does not appear to say an ISP POC  cannot be listed as
an additional contact on an  end-user  re-allocated network record
either.


--
-J


From aaron at wholesaleinternet.net  Tue Jun  9 23:46:42 2009
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Tue, 9 Jun 2009 22:46:42 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>	<4A2EA88D.5030102@steadfast.net>
	<6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com>
Message-ID: <010201c9e97e$11497e30$33dc7a90$@net>

I think people are missing the point.

This is about a requirement that businesses publish customer lists in a
publically available forum where their competitors or anyone else who has no
business with the information can get to it.  This is a solution to stop the
********s out there from farming my SWIP information and calling my
customers to solicit their business.

If the customer wants to be responsible for the network then they can choose
to have the provider SWIP the IPs with their information.  This policy
simply gives the ISP a choice as to whether they want to publish their
customer information or not.

Nothing in this proposal's wording or intention removes any ISP from the
requirement that their information be available and accurate.

Aaron


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of James Hess
Sent: Tuesday, June 09, 2009 10:20 PM
To: Kevin Stange
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

[snip]
> Privacy of personal information is something our customers regularly ask
> us about because our system automatically publishes their information in
> rwhois. ?In many cases, these customers do not have the technical
[snip]
I oppose this policy, because sufficient privacy is already provided
by the NPRM under section 4.2.3.7.6
https://www.arin.net/policy/nrpm.html#four2376

If you are the responsible party for a business'  computer network,
your business contact information is not personal information.
And your organization's identity and address are not personal information.

For the reasons already mentioned by others, it is essential  that
public contact and address information be available  for  assignees of
IP space who participate in the public internet.


There are suitable means available to indicate on a WHOIS record that
the ISP should be contacted instead of the end-user.   A  "Comment"
and additional Abuse POC  can be entered on the record.

Current policy does not appear to say an ISP POC  cannot be listed as
an additional contact on an  end-user  re-allocated network record
either.


--
-J
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.



From bjohnson at drtel.com  Wed Jun 10 00:09:49 2009
From: bjohnson at drtel.com (Brian Johnson)
Date: Tue, 9 Jun 2009 23:09:49 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2B8@mail>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><005e01c9e939$31b54220$951fc660$@net><2C4FE2DF-DDCB-4000-A3BB-AD06451B2A4D@delong.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2B8@mail>
Message-ID: <29A54911243620478FF59F00EBB12F47017E36D3@ex01.drtel.lan>


<snip>
> >
> > For better or worse, we already have a huge exception for
residential
> > customer privacy. Extending this to allow ISPs to obscure whatever
> > data they want about their allocation/assignment practices is, in my
> > opinion, contrary to the public interest and certainly should apply
> to
> > any IPv4 assignment larger than a /27 or IPv6 assignment larger than
> > a /56. It further should not apply to any IPv4 or IPv6 allocation.
> >
> > This is just my own opinion.
> >
> > Owen
> 
> I like the idea of limiting this to long prefix assignments..
> 
> >
<snip>

What about multi-homed networks? Possibly some language that would be
either a prefix of x length or longer; or a multi-homed network. I
realize that, generally speaking, a multi-homed network will get space
directly from ARIN. But since this is not a requirement, the inclusion
seems reasonable to me.

- Brian



From bill at herrin.us  Wed Jun 10 00:24:44 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 10 Jun 2009 00:24:44 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <010201c9e97e$11497e30$33dc7a90$@net>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<4A2EA88D.5030102@steadfast.net>
	<6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com>
	<010201c9e97e$11497e30$33dc7a90$@net>
Message-ID: <3c3e3fca0906092124y325fa1abvd0402abb9052eadb@mail.gmail.com>

On Tue, Jun 9, 2009 at 11:46 PM, Aaron
Wendel<aaron at wholesaleinternet.net> wrote:
> I think people are missing the point.
>
> This is about a requirement that businesses publish customer lists in a
> publically available forum where their competitors or anyone else who has no
> business with the information can get to it. ?This is a solution to stop the
> ********s out there from farming my SWIP information and calling my
> customers to solicit their business.

Aaron,

Cry me a river. You have enough customer lock-in due to the
renumbering problem. Now you want the playing field tipped even more
in your favor? Maybe we should have a proposal that makes your
downstream allocations permanent until released the same way your
allocations are from ARIN, independent of whether or not they remain
your transit customer. Make you be a LIR in reality instead of just in
name.

IP addresses are like public right of ways. As an ISP you get to hold
lots of them in trust, but they aren't yours. They're ours, the
general public's, and while you hold them in trust you are accountable
for their use... not to ARIN but to the general public whose commons
you are so graciously being allowed to use at an almost negligible
cost.

Disclosure is a part of that price and it has been a part of that
price since before there was an ARIN. It's a central component, one
linchpin to the process through which the community keeps its members
honest so that unlike ICANN, we won't need an external USG influence
to maintain some semblance of fairness.

Competitors rudely calling and emailing your customers is an
unfortunate side effect of that process. There ought to be and
probably is some reasonable way to mitigate that problem. But
abandoning public disclosure, the essence of your proposal, is not the
answer.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From michael.dillon at bt.com  Wed Jun 10 02:18:42 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 07:18:42 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2EC512.8020503@steadfast.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801939197@E03MVZ2-UKDY.domain1.systemhost.net>

> Unless 
> there's a sizable transitional period or grandfathering, this 
> would be a nightmare for larger networks to accomplish.

You forgot the third option. Instead of the policy stating that
it is mandatory for ISPs to not publish customer contact info,
the policy could just say that ISPs do not have to publish
customer contact info, unless the customer requests it. That
is still a reasonable policy supporting privacy by default.

-- Michael Dillon


From michael.dillon at bt.com  Wed Jun 10 02:25:47 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 07:25:47 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800C08D993@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <28E139F46D45AF49A31950F88C497458019391A0@E03MVZ2-UKDY.domain1.systemhost.net>

> Do you think the community needs to know the details of every 
> user of the IP address space, or do they just need to know 
> the contact information of those that are responsible for its use?

When the current whois policies first came into play, back in
the days of the ARPAnet, it was important to know the details
of every user because there were annual budgets that had to
be justified. Now the world is a very different place, but we
still have this old ARPAnet policy hanging around.

--Michael Dillon


From michael.dillon at bt.com  Wed Jun 10 02:48:40 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 07:48:40 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2F0DDB.4070808@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C497458019391BC@E03MVZ2-UKDY.domain1.systemhost.net>


> It's my hope that the policy submitter will rewrite the 
> submission to make it more explicit.  

It's not his policy proposal any more. Once a proposal
is submitted, the AC own it and can make any changes 
they want based on the various inputs that we provide
to them.

There is no point in excessive wordsmithing until the
AC takes a crack at it first.

--Michael Dillon


From martin.hannigan at batelnet.bs  Wed Jun 10 07:46:10 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 10 Jun 2009 07:46:10 -0400
Subject: [arin-ppml] [arin-council] Returning Legacy Space to IANA.
	Attorney client communcation.
In-Reply-To: <m2r5xsdhzk.wl%randy@psg.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<m2r5xsdhzk.wl%randy@psg.com>
Message-ID: <4607e1d50906100446w2eaba0b7xb00471b1a60cc218@mail.gmail.com>

On Tue, Jun 9, 2009 at 8:56 PM, Randy Bush<randy at psg.com> wrote:
>> Most large service providers in the region don't believe we're going
>> to get a fair shake in the end.
>
> what is perceived as 'fair' differs widely. ?some think the largeer
> holders have fed sufficiently at the trough. ?some think the rich should
> get richer. ?ymmv.


Less Robin Hood and more St. Patrick would be most helpful.

Who can blame anyone for hoarding (if they really are) these days?
Most of the conversations here are mob mentality. The intelligent ones
are clearly taking place under NDA.

Best,

Martin


From farmer at umn.edu  Wed Jun 10 08:07:10 2009
From: farmer at umn.edu (David Farmer)
Date: Wed, 10 Jun 2009 07:07:10 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <010201c9e97e$11497e30$33dc7a90$@net>
References: <4A2E5BD2.8090708@arin.net>,
	<6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com>,
	<010201c9e97e$11497e30$33dc7a90$@net>
Message-ID: <4A2F5B9E.25712.72A48C8@farmer.umn.edu>

I appreciate your honesty and directness in stating your motivations for this 
proposal.  However, as I said before;

"If withholding such information is solely in the business interest of the agent 
or service provider, the ISP in this case, and especially if it in anyway 
damages the interest of client or customer, then I'm opposed to such 
policies."

To be equally as honest and direct as you have been;

If this is only about protecting the business interest of the ISPs then go away. 
However, if we can both protect the business interest of the ISPs and the 
privacy, confidentiality and other interests of Internet end users then maybe 
we can do something.  

If a customer has a business need to have the full information disclosed as it 
is in the current policy then they should have that right, as the end user of 
the address space their business need must out weigh your business need 
as the ISP.  The reason you have been allocated address space in the first 
place is to provide it to end users to meet their needs in connecting to the 
Internet. 

If we can find a way to disclose less information about the Internet end user 
and protect the interest of the ISP, the end user, and the public interest in 
proper use of address space then we will have a good proposal.

I believe this could be a useful proposal that I can support, but if it remains 
focused solely on the business interest of the ISPs then I will have to opose 
it. 

On 9 Jun 2009 Aaron Wendel wrote:

> I think people are missing the point.
> 
> This is about a requirement that businesses publish customer lists in
> a publically available forum where their competitors or anyone else
> who has no business with the information can get to it.  This is a
> solution to stop the ********s out there from farming my SWIP
> information and calling my customers to solicit their business.
> 
> If the customer wants to be responsible for the network then they can
> choose to have the provider SWIP the IPs with their information.  This
> policy simply gives the ISP a choice as to whether they want to
> publish their customer information or not.
> 
> Nothing in this proposal's wording or intention removes any ISP from
> the requirement that their information be available and accurate.
> 
> Aaron
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On Behalf Of James Hess Sent: Tuesday, June 09, 2009 10:20 PM To:
> Kevin Stange Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy
> Proposal: Customer Confidentiality
> 
> [snip]
> > Privacy of personal information is something our customers regularly
> > ask us about because our system automatically publishes their
> > information in rwhois. ?In many cases, these customers do not have
> > the technical
> [snip]
> I oppose this policy, because sufficient privacy is already provided
> by the NPRM under section 4.2.3.7.6
> https://www.arin.net/policy/nrpm.html#four2376
> 
> If you are the responsible party for a business'  computer network,
> your business contact information is not personal information. And
> your organization's identity and address are not personal information.
> 
> For the reasons already mentioned by others, it is essential  that
> public contact and address information be available  for  assignees of
> IP space who participate in the public internet.
> 
> 
> There are suitable means available to indicate on a WHOIS record that
> the ISP should be contacted instead of the end-user.   A  "Comment"
> and additional Abuse POC  can be entered on the record.
> 
> Current policy does not appear to say an ISP POC  cannot be listed as
> an additional contact on an  end-user  re-allocated network record
> either.
> 
> 
> --
> -J
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From steve at ibctech.ca  Wed Jun 10 08:36:09 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Wed, 10 Jun 2009 08:36:09 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AE@mail>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AE@mail>
Message-ID: <4A2FA8B9.9050309@ibctech.ca>

Kevin Kargel wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Milton L Mueller
>> Sent: Tuesday, June 09, 2009 1:36 PM
>> To: 'William Herrin'
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
>>
>> I don't understand how this is a consideration if the ISP continues to be
>> accurately identified in the whois. I don't understand how a third party's
>> suspicion of an ISP gives them a right to access a customers' data as
>> opposed to the ISP data. Recall that ARIN has access to the customer
>> information and would thus be accessible to any real fraud investigation.
> 
> To my mind the issue is not one of fraud investigation but one of abuse
> resolution.  It is all too easy for a network host to broadcast a number of
> types of storm traffic from innocent causes such as hardware or software
> failure or mis-configuration.  Even things as simple as routing loops can be
> debilitating to more than the end user in question.
> 
> The end user need not be identified, but a contact to an administrator who
> can deal with routing and traffic issues should be required.
> 
> I am all for privacy, but reachability of an effective PoC needs to be
> maintained.  A PoC who calls a contact who relays a message to someone who
> knows who the administrator is cannot be effective.

I agree with what Kevin is saying here.

In reality, if we can simply publish our own contact info in the SWIP
records, then why bother publishing SWIP information at all? My
aggregate block already has our contact info, so why take the time to
publish further info about smaller pieces of our space with the exact
same information?

The only reason I can see a privacy card being played would be in
sensitive services (military etc). Even in that case, the space could be
swip'ed to an individual responsible for the network.

I think that if something like this is to be ratified, it should focus
solely on privacy from a safety and security standpoint, and not out of
speculation of potential lost business.

Steve

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090610/a2952fb8/attachment.bin>

From dsd at servervault.com  Wed Jun 10 09:36:39 2009
From: dsd at servervault.com (Divins, David)
Date: Wed, 10 Jun 2009 09:36:39 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2FA8B9.9050309@ibctech.ca>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AE@mail>
	<4A2FA8B9.9050309@ibctech.ca>
Message-ID: <E7956D9775C98F4DB72321439A2F91A92630EA@mail1.dulles.sv.int>

It is this exact case that I support this proposal.  I don't care about
my customer list too much, as all the good ones are logo'd on my
website.

It's the sensitive reallocations that frankly is none of the public's
business especially when I am the appropriate abuse and technical
contact.  The reality is that LEA's and military organizations don't get
SWIPd as who they really are anyway (I mean, how many times does CIA
appear in WHOIS) so let's stop pretending that doesn't happen and make
our lives easier.

-dsd

David Divins
Principal Engineer
ServerVault Corp.
(703) 652-5955

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Steve Bertrand
Sent: Wednesday, June 10, 2009 8:36 AM
To: Kevin Kargel
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

Kevin Kargel wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
>> On Behalf Of Milton L Mueller
>> Sent: Tuesday, June 09, 2009 1:36 PM
>> To: 'William Herrin'
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
>>
>> I don't understand how this is a consideration if the ISP continues 
>> to be accurately identified in the whois. I don't understand how a 
>> third party's suspicion of an ISP gives them a right to access a 
>> customers' data as opposed to the ISP data. Recall that ARIN has 
>> access to the customer information and would thus be accessible to
any real fraud investigation.
> 
> To my mind the issue is not one of fraud investigation but one of 
> abuse resolution.  It is all too easy for a network host to broadcast 
> a number of types of storm traffic from innocent causes such as 
> hardware or software failure or mis-configuration.  Even things as 
> simple as routing loops can be debilitating to more than the end user
in question.
> 
> The end user need not be identified, but a contact to an administrator

> who can deal with routing and traffic issues should be required.
> 
> I am all for privacy, but reachability of an effective PoC needs to be

> maintained.  A PoC who calls a contact who relays a message to someone

> who knows who the administrator is cannot be effective.

I agree with what Kevin is saying here.

In reality, if we can simply publish our own contact info in the SWIP
records, then why bother publishing SWIP information at all? My
aggregate block already has our contact info, so why take the time to
publish further info about smaller pieces of our space with the exact
same information?

The only reason I can see a privacy card being played would be in
sensitive services (military etc). Even in that case, the space could be
swip'ed to an individual responsible for the network.

I think that if something like this is to be ratified, it should focus
solely on privacy from a safety and security standpoint, and not out of
speculation of potential lost business.

Steve



From mueller at syr.edu  Wed Jun 10 10:12:48 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 10 Jun 2009 10:12:48 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net>
	<E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7F1C@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Public actions have public accountability.  If you don't want your picture
> taken going in to a strip club then don't go to a strip club.
> 

This doctrine bears no relationship to actual law regarding privacy and freedom of association. Sorry, guys, but there's more at stake here than your convenience as network admins, and even as network admins there are appropriate limits to place on indiscriminate public access to sensitive information, especially when contractually agreed between provider and customer. When you get elected as a legislator, Kevin, then you and 250 other elected reps can change that under due process if you wish; until then, don't try to make law via ARIN. 

--MM


From mueller at syr.edu  Wed Jun 10 10:20:42 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 10 Jun 2009 10:20:42 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <28E139F46D45AF49A31950F88C497458018C32C3@E03MVZ2-UKDY.domain1.systemhost.net>
References: <75822E125BCB994F8446858C4B19F0D77B220A4F@SUEX07-MBX-04.ad.syr.edu>
	<28E139F46D45AF49A31950F88C497458018C32C3@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7F1E@SUEX07-MBX-04.ad.syr.edu>

Yes, I got that backwards. What I'd actually like to see is the ISP set the default (which in most cases would be private), and if customers want to be listed they can do so. In most cases, that would correspond to what privacy advocates call opt in. However, if the ISP chose as a default to list the customer, and the customer contractually agreed to this, they would have to opt-out to achieve privacy. Both scenarios are legitimate under U.S. law, though Canada may be different. 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of michael.dillon at bt.com
> Sent: Tuesday, June 09, 2009 4:17 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> 
> 
> > The policy should be amended to read, "If
> > the customer requests, ISPs may choose to enter their own
> > address and phone number in reassignments and reallocations
> > in lieu of the customer's address and..."
> 
> That is opt-in to privacy which I oppose. Privacy should be
> the default unless the customer opts-out of privacy and
> indicates their wish to participate in Internet operations.
> 
> --Michael Dillon
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From mueller at syr.edu  Wed Jun 10 10:34:06 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 10 Jun 2009 10:34:06 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <3c3e3fca0906091443w21470295g10c2a88da3338be1@mail.gmail.com>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<005e01c9e939$31b54220$951fc660$@net>
	<3c3e3fca0906091443w21470295g10c2a88da3338be1@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7F25@SUEX07-MBX-04.ad.syr.edu>

William,
As I said in an earlier message, if you want to argue that "the public" has rights regarding access to information, then take it up in the legistlative sphere. ARIN sets policies for the ISPs using the address space it allocates. ARIN policies should be confined to those issues. ARIN does not 

If you want to pursue the analogy to real estate information, ISPs are intermediaries, "owners" of large blocks of address space, their customers are not. You are saying, in effect, that you should be able to query a database about a sohpping mall or office building and find out the name and personal information of every tenant. Doesn't happen, anywhere. 

If you wish to argue that ARIN policies require open access to end user customer data then the case is not so clear, because ISPs have a legitimate claim to shield their customer information, and customers also have a legitimate claim to shield it. It is not as if the information becomes completely inaccessible - people with a legitimate need for it can still get it 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Tuesday, June 09, 2009 5:43 PM
> To: Aaron Wendel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> On Tue, Jun 9, 2009 at 3:33 PM, Aaron Wendel<aaron at wholesaleinternet.net>
> wrote:
> > My point in writing this policy was to protect information that is
> > proprietary to any business. ?Tell a realtor you know that you're
> thinking
> > about going into real estate and you'd like his customer list. Then tell
> him
> > that you actually need his customer list to make sure he's legit. ?If
> all he
> > does is laugh at you then you got off lucky. ?I can think of no other
> > private business that is required to publish customer information to the
> > public.
> 
> Aaron,
> 
> Since you brought it up, let's talk real estate. Do you own a house?
> If you do and I know your address then I know who you are and I know
> how much you paid for the house because your identity and quite a bit
> of information about you is published in the public tax records.
> 
> Go ahead and try it with the address in my sig:
> http://icare.fairfaxcounty.gov/Search/GenericSearch.aspx?mode=ADDRESS
> 
> As with land, the public has a bona fide interest in knowing who is
> using IP addresses in more than a transient way.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From mueller at syr.edu  Wed Jun 10 10:49:53 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 10 Jun 2009 10:49:53 -0400
Subject: [arin-ppml] [arin-council] Returning Legacy Space to
	IANA.	Attorney client communcation.
In-Reply-To: <4607e1d50906100446w2eaba0b7xb00471b1a60cc218@mail.gmail.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<m2r5xsdhzk.wl%randy@psg.com>
	<4607e1d50906100446w2eaba0b7xb00471b1a60cc218@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7F2B@SUEX07-MBX-04.ad.syr.edu>

Well, this conversation, inadvertently leaked from the Council was _not_ supposed to be public.... ;-)

> -----Original Message-----
> 
> Who can blame anyone for hoarding (if they really are) these days?
> Most of the conversations here are mob mentality. The intelligent ones
> are clearly taking place under NDA.
> 
> Best,


From Daniel_Alexander at Cable.Comcast.com  Wed Jun 10 10:56:04 2009
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Wed, 10 Jun 2009 10:56:04 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <28E139F46D45AF49A31950F88C497458019391A0@E03MVZ2-UKDY.domain1.systemhost.net>
References: <997BC128AE961E4A8B880CD7442D94800C08D993@NJCHLEXCMB01.cable.comcast.com>
	<28E139F46D45AF49A31950F88C497458019391A0@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <997BC128AE961E4A8B880CD7442D94800C08DCC6@NJCHLEXCMB01.cable.comcast.com>

We as a community need to answer a question. Do you think the community
needs to know the details of every user of the IP address space, or do
they just need to know the contact information of those that are
responsible for its use?

I see three recurring themes during whois discussions. The problem is
whois can only remotely serve the third item and definitely cannot meet
the needs of all three.

1)Provide a directory of all Internet users.
2)Usage transparency and validation for ARIN and the Internet.
3)Contact information for abuse, routing, etc.

The idea of whois as a directory of Internet users is ridiculous. Given
current policy, the number of public Internet users who connect through
DHCP, static IP assignments or /30 assignments that do not require swips
are in the 10's of millions. That large of a pool, not included in the
set, makes that purpose pointless.

I also disagree with the need for whois as a means of validation or
transparency for ARIN. ARIN can request whatever information they want
under the RSA. They do not need swips to confirm someone's utilization,
and if that were the only mechanism being used then we have bigger
problems to solve. If transparency is truly the goal, then it needs to
be an all or nothing, and whois has no chance of acting as a directory
for ALL Internet users.

The only purpose whois can serve, in today's world, is as a contact
directory for abuse or other issues, and this purpose has absolutely
nothing to do with the block being a /29 or larger, or whether the user
is residential or commercial. We continue to attach requirements to
swips that have nothing to do with the purpose whois can fulfill. 

Just my two cents.
Dan Alexander

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of michael.dillon at bt.com
Sent: Wednesday, June 10, 2009 2:26 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality

> Do you think the community needs to know the details of every 
> user of the IP address space, or do they just need to know 
> the contact information of those that are responsible for its use?

When the current whois policies first came into play, back in
the days of the ARPAnet, it was important to know the details
of every user because there were annual budgets that had to
be justified. Now the world is a very different place, but we
still have this old ARPAnet policy hanging around.

--Michael Dillon
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.


From tvest at pch.net  Wed Jun 10 11:01:50 2009
From: tvest at pch.net (Tom Vest)
Date: Wed, 10 Jun 2009 11:01:50 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7F1C@SUEX07-MBX-04.ad.syr.edu>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net>
	<E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>
	<75822E125BCB994F8446858C4B19F0D77B1A7F1C@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <226F30EF-E2D5-48F9-BE95-44A7E2DD5B46@pch.net>

On Jun 10, 2009, at 10:12 AM, Milton L Mueller wrote:

>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- 
>> bounces at arin.net] On
>> Public actions have public accountability.  If you don't want your  
>> picture
>> taken going in to a strip club then don't go to a strip club.
>>
>
> This doctrine bears no relationship to actual law regarding privacy  
> and freedom of association. Sorry, guys, but there's more at stake  
> here than your convenience as network admins, and even as network  
> admins there are appropriate limits to place on indiscriminate  
> public access to sensitive information, especially when  
> contractually agreed between provider and customer. When you get  
> elected as a legislator, Kevin, then you and 250 other elected reps  
> can change that under due process if you wish; until then, don't try  
> to make law via ARIN.
>
> --MM


Neither does "actual law" impose a strict, uniform interpretation on  
how information collected and maintained for *authorization and  
accountability purposes* can and cannot be used in all situations. An  
arguably relevant, if US-centric, illustration:

"HIPAA requires healthcare providers to obtain patients' authorization  
before disclosing their information to third parties for marketing  
purposes. However, healthcare providers do not need authorization to  
disclose information for marketing their own health-related services.  
HIPAA also allows disclosure of health-related information for a  
variety of social purposes such as public health activities, suspicion  
of abuse or neglect, health oversight activities, and for law  
enforcement purposes, along with a court order, subpoena, or  
"administrative request." HIPAA does not include a requirement to  
provide notice toconsumers in the event of a data breach. Finally,  
lawsuits to enforce HIPAA requirements can only be brought by the  
secretary of the Department of Health and Human Services and not by  
individuals."*

So, in some contexts at least, one man's "indiscriminate public  
access" may be another man's access/disclosure to fulfill a  
"legitimate social purpose."

If that doesn't suit you, you can always take your own advice and try  
to author some new "actual laws" that more closely fit your own views.

TV

*George H. Pike, "HIPAA Gets New Privacy Rules" (Information Today,  
April 1, 2009), p. 13.

An online version is available at:
http://goliath.ecnext.com/coms2/gi_0199-10387318/HIPAA-gets-new-privacy-rules.html 
  


From info at arin.net  Wed Jun 10 11:13:02 2009
From: info at arin.net (Member Services)
Date: Wed, 10 Jun 2009 11:13:02 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <4A2FCD7E.4080009@arin.net>

Policy Proposal 95
Customer Confidentiality

The proposal originator submitted a revised version of the proposal.

The AC will review this proposal at their next regularly scheduled
meeting and decide how to utilize the proposal. Their decision will be
announced to the PPML.

In the meantime, the AC invites everyone to comment on this proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
http://www.arin.net/policy/pdp.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


1. Policy Proposal Name: Customer Confidentiality

2. Proposal Originator: Aaron Wendel

3. Proposal Version: 2.0

4. Date: 10 June 2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

ISPs may choose to enter the customer's name along with the ISP's
address and phone number in reassignments and reallocations in lieu of
the customer's address and phone number.  The customer's actual
information must be provided to ARIN on request and will be held in the
strictest confidence.

8. Rationale:

Version 2.0 clarifies the need for the customer name to remain in the
SWIP and RWHOIS information.

Customer contact lists are one of the most proprietary and confidential
pieces of information in any business.  The requirements for ISPs to
publish those lists via SWIP or RWHOIS runs contrary to good business
practices and invites competitors and others to solicit both individuals
and companies receiving reassignments and sub allocations from upstream
providers.

9. Timetable for implementation: immediate






From kkargel at polartel.com  Wed Jun 10 11:31:43 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 10 Jun 2009 10:31:43 -0500
Subject: [arin-ppml] *Spam?* Re: Policy Proposal: Customer
	Confidentiality
In-Reply-To: <4A2EF944.1010604@impulse.net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>	<005e01c9e939$31b54220$951fc660$@net><2C4FE2DF-DDCB-4000-A3BB-AD06451B2A4D@delong.com>
	<4A2EF944.1010604@impulse.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BA@mail>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Jay Hennigan
> Sent: Tuesday, June 09, 2009 7:08 PM
> To: arin-ppml at arin.net
> Subject: *Spam?* Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> Owen DeLong wrote:
> 
> > The realtor is not connecting you to a global packet switched network.
> > To my knowledge, no other private business does that.
> 
> Cellular telephone companies do.  And they don't publish their customer
> lists.
> 
> Note that I said cellular which has been packet-switched since AMPS went
> away.  Landline telephone companies also connect you to a global
> switched network, which happens to be circuit-switched.  They may or may
> not publish some of their customer lists.  Telephone companies are in
> the unique position of charging extra for both unlisted numbers and
> extra listings.
> 
> Telephone companies also allow their customers to hide their source
> address from the recipient on a per-line or per-call basis.

It used to be that IP addresses were a public attribute.  Then I was very
much in favor of open disclosure.

Now that IP addresses are officially described as property that can be
bought and sold for money and hold value I think that privacy issues have
more precedent.


> 
> --
> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090610/82a556a2/attachment.bin>

From kkargel at polartel.com  Wed Jun 10 11:41:36 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 10 Jun 2009 10:41:36 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <3c3e3fca0906092124y325fa1abvd0402abb9052eadb@mail.gmail.com>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><4A2EA88D.5030102@steadfast.net><6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com><010201c9e97e$11497e30$33dc7a90$@net>
	<3c3e3fca0906092124y325fa1abvd0402abb9052eadb@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BB@mail>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Tuesday, June 09, 2009 11:25 PM
> To: Aaron Wendel
> 
> IP addresses are like public right of ways. As an ISP you get to hold
> lots of them in trust, but they aren't yours. They're ours, the
> general public's, and while you hold them in trust you are accountable
> for their use... not to ARIN but to the general public whose commons
> you are so graciously being allowed to use at an almost negligible
> cost.
> 

Ah, but things have changed, you can now buy, sell and trade IP's thanks to
powers vested by 2009-1.  I know that 2009-1 has words saying that the
intention is not to create property, but if it walks like a duck and quacks
like a duck...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090610/a1633fca/attachment.bin>

From tvest at pch.net  Wed Jun 10 12:01:30 2009
From: tvest at pch.net (Tom Vest)
Date: Wed, 10 Jun 2009 12:01:30 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BB@mail>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><4A2EA88D.5030102@steadfast.net><6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com><010201c9e97e$11497e30$33dc7a90$@net>
	<3c3e3fca0906092124y325fa1abvd0402abb9052eadb@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BB@mail>
Message-ID: <B68357FE-7268-4631-8849-0217034C34AD@pch.net>


On Jun 10, 2009, at 11:41 AM, Kevin Kargel wrote:

>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- 
>> bounces at arin.net] On
>> Behalf Of William Herrin
>> Sent: Tuesday, June 09, 2009 11:25 PM
>> To: Aaron Wendel
>>
>> IP addresses are like public right of ways. As an ISP you get to hold
>> lots of them in trust, but they aren't yours. They're ours, the
>> general public's, and while you hold them in trust you are  
>> accountable
>> for their use... not to ARIN but to the general public whose commons
>> you are so graciously being allowed to use at an almost negligible
>> cost.
>>
>
> Ah, but things have changed, you can now buy, sell and trade IP's  
> thanks to
> powers vested by 2009-1.  I know that 2009-1 has words saying that the
> intention is not to create property, but if it walks like a duck and  
> quacks
> like a duck...

Hi Kevin,

While your views about IP number resource privatization may (or may  
not) be borne out by changing circumstances, I think that the article  
that I quoted previously is relevant either way.  Recall that HIPAA =  
Health Information *Portability and Accountability*  Act. The overall  
goal of the legislation was to strike a practical balance between  
privacy and disclosure so that the option of insurance portability  
(individual autonomy, freedom of choice, competition, etc.) could be  
extended broadly *without* sacrificing "accountability," including the  
accountability of individuals and health service providers for the  
potential impacts that increasing patient/provider churn might have on  
the health of other individuals and society in general.

I think the parallels to our current circumstances and policy debates  
are pretty self-evident, but perhaps that's just me...

TV





From mueller at syr.edu  Wed Jun 10 12:08:06 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 10 Jun 2009 12:08:06 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <B68357FE-7268-4631-8849-0217034C34AD@pch.net>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><4A2EA88D.5030102@steadfast.net><6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com><010201c9e97e$11497e30$33dc7a90$@net>
	<3c3e3fca0906092124y325fa1abvd0402abb9052eadb@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BB@mail>
	<B68357FE-7268-4631-8849-0217034C34AD@pch.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7F39@SUEX07-MBX-04.ad.syr.edu>

Tom
The parallels with HIPAA are indeed there with respect to policy objectives. 
But I hope we don't use HIPAA notification and consent as a model for anything. Anyone confronted with the confusing deluge of consent forms at a doctor's office during the early stages of its implementation knows how meaningless the policy objectives became once they were operationalized. Also, note what happened to their attempt to create a unified identifier...

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Tom Vest
> that I quoted previously is relevant either way.  Recall that HIPAA =
> Health Information *Portability and Accountability*  Act. The overall
[snip]
> 
> I think the parallels to our current circumstances and policy debates
> are pretty self-evident, but perhaps that's just me...
> 


From mueller at syr.edu  Wed Jun 10 12:14:45 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 10 Jun 2009 12:14:45 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BB@mail>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><4A2EA88D.5030102@steadfast.net><6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com><010201c9e97e$11497e30$33dc7a90$@net>
	<3c3e3fca0906092124y325fa1abvd0402abb9052eadb@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BB@mail>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7F3B@SUEX07-MBX-04.ad.syr.edu>

Broadcast licenses have been regulated as public trustee model for decades, but they have also been bought and sold for decades. While there are tensions between transferability of a right and its status as a resource regulated under a public trustee model, there is not complete incompatibilty. Not that I support the public trustee model, in broadcasting it's been a disaster, but if you want scientific understanding of regulatory regimes, let's just get that right. 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Kevin Kargel
> Sent: Wednesday, June 10, 2009 11:42 AM
> To: William Herrin; Aaron Wendel
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of William Herrin
> > Sent: Tuesday, June 09, 2009 11:25 PM
> > To: Aaron Wendel
> >
> > IP addresses are like public right of ways. As an ISP you get to hold
> > lots of them in trust, but they aren't yours. They're ours, the
> > general public's, and while you hold them in trust you are accountable
> > for their use... not to ARIN but to the general public whose commons
> > you are so graciously being allowed to use at an almost negligible
> > cost.
> >
> 
> Ah, but things have changed, you can now buy, sell and trade IP's thanks
> to
> powers vested by 2009-1.  I know that 2009-1 has words saying that the
> intention is not to create property, but if it walks like a duck and
> quacks
> like a duck...


From petelists at templin.org  Wed Jun 10 12:05:58 2009
From: petelists at templin.org (Pete Templin)
Date: Wed, 10 Jun 2009 11:05:58 -0500
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
 Size
In-Reply-To: <4A2D636A.13087.F6F36CD@farmer.umn.edu>
References: <4A2D622E.4030208@arin.net>, <4A2D7D39.3050702@templin.org>
	<4A2D636A.13087.F6F36CD@farmer.umn.edu>
Message-ID: <4A2FD9E6.60105@templin.org>

David Farmer wrote:
> On 8 Jun 2009 Pete Templin wrote:
> 
> You have the right idea, but not the right numbers,  with the proposed one 
> quarter (1/4) ratio and starting at /8,  a geometric progression is created, 
> such that if all allocations were of a maximum size available at the time, it 
> would take 24 separate requests to wipe out the pool.  A ratio of one half 
> (1/2) would require 13 maximum size requests, a ratio of one eighth (1/8) 
> would require 44 maximum size requests, and a ratio one sixteenth (1/16) 
> would require 80 maximum size requests.
> 
> See the following Google Docs spread sheet from more details, there are 
> separate tabs for one half, one quarter, one eighth, and one sixteenth;
> 
> http://spreadsheets.google.com/ccc?key=r2IDwxI-feUNacGABcvopnQ
> 
> Please realize all requests will not be of a maximum size, the numbers above 
> are purely the worst case scenario.  Also, exactly how much ARIN has in the 
> IPv4 pool when this policy is triggered depends on when 10.4.2.2 is triggered 
> and if it is a request form ARIN that triggers it or a request from one of the 
> other RIRs.  I think in theory it could be as much as three (3) /8s or as little 
> as three (3) /10s receptively in the best or worst possible timing.  I suspect 
> something a little more than /8 is probably about right.  But to make the math 
> in the spread sheet easier I went with an exact /8 scenario.

I'm simply not following your suggestion of the numbers, which includes 
looking at the spreadsheet you've provided.  I'll base my discussions on 
the one quarter (1/4) ratio since that's what's written into the Policy 
Proposal.

Case study #1: ARIN has a /13 of space, also known as 524,288 addresses. 
  Four large-enough requests happen to be at the head of the line, and 
based on the one-quarter ratio they're eligible for a /15 of space per 
request.  Each request is issued a /15, also known as 131,072 addresses. 
  These 524,288 addresses in four allocations would wipe out the pool, 
not the 24 allocations that you present above.

Case study #2: ARIN has a /17 of space, also known as 32,768 addresses. 
  Four large-enough requests happen to be at the head of the line, and 
based on the one-quarter ratio they're eligible for a /19 of space per 
request.  Each request is issued a /19, also known as 8,192 addresses. 
These 32,768 addresses in four allocations would wipe out the pool, not 
the 24 allocations that you present above.

I acknowledge that current policy allows one large-enough request to 
wipe out all available-at-the-moment free-pool IPv4 within ARIN's 
bucket, and that distribution across more-than-one recipient is in the 
interest of fairness, even though we don't know how yet best to achieve 
some form of equitable fairness.  That said, this policy doesn't appear 
to be achieving much of the desired goal; I suspect it needs to be on 
the order of 6-10 bits (64-1024 allocations) before we're really 
achieving "distribution".

Pete



From woody at pch.net  Wed Jun 10 12:27:35 2009
From: woody at pch.net (Bill Woodcock)
Date: Wed, 10 Jun 2009 09:27:35 -0700 (PDT)
Subject: [arin-ppml] *Spam?* Re: Policy Proposal: Customer
	Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BA@mail>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<005e01c9e939$31b54220$951fc660$@net><2C4FE2DF-DDCB-4000-A3BB-AD06451B2A4D@delong.com>
	<4A2EF944.1010604@impulse.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BA@mail>
Message-ID: <Pine.SOC.4.61.0906100926140.25482@paixhost.pch.net>

      On Wed, 10 Jun 2009, Kevin Kargel wrote:
    > Now that IP addresses are officially described as property that can be
    > bought and sold for money and hold value I think that privacy issues have
    > more precedent.

Insofar as ARIN and the RIRs are the officiant here, IP addresses are 
officially _not_ property.

                                -Bill



From Skeeve at eintellego.net  Wed Jun 10 12:19:36 2009
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Thu, 11 Jun 2009 02:19:36 +1000
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <292AF25E62B8894C921B893B53A19D97394469E4A9@BUSINESSEX.business.ad>

Hey all,

As a non-ARIN member, but with interest in using information to perform our duties globally... I would like to make some comments.

I see two conflicting issues.

a) Trying to track down the contact details of someone doing DoS, SPAM, Criminal Acts or having technical problems and having US providers telling people outside the US like us to get lost when we ask for the details of who is using an IP range.

b) Protecting the identity of sensitive entities should they become targets if their addresses be known, and for the collection of customer base data


So b) is reasonable, but a) is more important day to do operationally.

If there was a method to have issues dealt with... i.e., we could contact ARIN and have them look into the matter then it would be fine.... but this is not what they do.  So what happens then?  Should it be written into the policy that CERT or some other organisation should be able to have the information disclosed to them?

The policy also does not state what happens if the ISP refuses to provide the information to ARIN, or is inaccurate, or they do not know it. "Sorry, it just has a pobox'.

The policy also does not state whom ARIN can disclose it to - just saying 'held in strictest confidence' doesn't actually mean anything.

So... basically.. with the above thoughts, the key question is:

What do we do, as a foreign company/entity, if we need to track down who is doing something (illegal/technical issue/etc) and the upstream ISP won't disclose it to us?

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
--
NOC, NOC, who's there?


> -----Original Message-----
>
> 7. Policy statement:
>
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number.  The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.
>
> 8. Rationale:
>
> Customer contact lists are one of the most proprietary and confidential
> pieces of information in any business.  The requirements for ISPs to
> publish those lists via SWIP or RWHOIS runs contrary to good business
> practices and invites competitors and others to solicit both
> individuals
> and companies receiving reassignments and sub allocations from upstream
> providers.
>
> 9. Timetable for implementation: immediate
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From tedm at ipinc.net  Wed Jun 10 12:48:17 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Jun 2009 09:48:17 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <010201c9e97e$11497e30$33dc7a90$@net>
References: <4A2E5BD2.8090708@arin.net>	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>	<4A2EA88D.5030102@steadfast.net>	<6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com>
	<010201c9e97e$11497e30$33dc7a90$@net>
Message-ID: <4A2FE3D1.2070004@ipinc.net>

Aaron Wendel wrote:
> I think people are missing the point.
> 
> This is about a requirement that businesses publish customer lists in a
> publically available forum where their competitors or anyone else who has no
> business with the information can get to it.  This is a solution to stop the
> ********s out there from farming my SWIP information and calling my
> customers to solicit their business.
> 

And what exactly prevents you from doing the same thing to the ********s 
out there?

The way it is right now it's a Mexican Standoff.  People don't raid 
customer lists via SWIP because they have their own lists out there and
can in turn be raided by the people they are raiding.

Keep in mind the DNS system went through this issue as well.  They
went to an opt-in privacy format, where ISP's had to indicate when 
registering a domain that it would be private, rather than ISP's having
to indicate that it would NOT be private.  Some ISPs did this but from
what I've seen today, very few ever did this because it results in more 
work for them since they now have to handle queries for customers.

The thought was that this would prevent companies like Domain Registry 
of America and other predatory registrars from hoovering up customers. 
But after time guess what happened - the general populace got burned 
enough that people nowadays all figure that anytime they get a domain 
registration renewal solicitation that it's a scam.  In other words, 
word got around.

You have to have some faith that your customers are smarter than the 
average stump.  And the fact of the matter is that the stupid customers 
almost always cost you more money in the long run than you ever make 
from them - you might as well let your competitors have them.

Ted


From ppml at rsuc.gweep.net  Wed Jun 10 12:50:26 2009
From: ppml at rsuc.gweep.net (Joe Provo)
Date: Wed, 10 Jun 2009 12:50:26 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
In-Reply-To: <4A2FCD7E.4080009@arin.net>
References: <4A2E5BD2.8090708@arin.net> <4A2FCD7E.4080009@arin.net>
Message-ID: <20090610165026.GA54829@gweep.net>

On Wed, Jun 10, 2009 at 11:13:02AM -0400, Member Services wrote:
[snip]
> In the meantime, the AC invites everyone to comment on this proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.

I'll go from "non-support" to "actively oppose".  As long as we have 
end-to-end connectivity, we need end-to-end accountability.  If an 
allocation is large enough to be registered, then the entity should 
be known.


-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE


From tedm at ipinc.net  Wed Jun 10 12:52:26 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Jun 2009 09:52:26 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <28E139F46D45AF49A31950F88C497458019391BC@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458019391BC@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A2FE4CA.8030706@ipinc.net>

michael.dillon at bt.com wrote:
>> It's my hope that the policy submitter will rewrite the 
>> submission to make it more explicit.  
> 
> It's not his policy proposal any more. Once a proposal
> is submitted, the AC own it and can make any changes 
> they want based on the various inputs that we provide
> to them.
> 
> There is no point in excessive wordsmithing until the
> AC takes a crack at it first.
> 

Michael, you've been at that obfuscated C code contest for too long, 
come up for air for a while, will ya?

Ted


From tedm at ipinc.net  Wed Jun 10 12:58:19 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Jun 2009 09:58:19 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7F1E@SUEX07-MBX-04.ad.syr.edu>
References: <75822E125BCB994F8446858C4B19F0D77B220A4F@SUEX07-MBX-04.ad.syr.edu>	<28E139F46D45AF49A31950F88C497458018C32C3@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D77B1A7F1E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A2FE62B.8050909@ipinc.net>

Milton L Mueller wrote:
> Yes, I got that backwards. What I'd actually like to see is the ISP set the default (which in most cases would be private), and if customers want to be listed they can do so. In most cases, that would correspond to what privacy advocates call opt in. However, if the ISP chose as a default to list the customer, and the customer contractually agreed to this, they would have to opt-out to achieve privacy. Both scenarios are legitimate under U.S. law, though Canada may be different. 
> 

I disagree with this completely.  There should be no default setting
at ARIN at any rate. ISP's use templates for SWIPS and if one wants to 
"default" the privacy bit they can do it in their shop.

How the ISP handles this between the customer and them is their own 
business, if they want to do an "opt-in" or "opt-out" privacy on SWIPs 
that is entirely within their own control.

But, each SWIP submittal to ARIN should be explicit as to how it's setup.

Ted


>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of michael.dillon at bt.com
>> Sent: Tuesday, June 09, 2009 4:17 PM
>> To: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
>>
>>
>>
>>> The policy should be amended to read, "If
>>> the customer requests, ISPs may choose to enter their own
>>> address and phone number in reassignments and reallocations
>>> in lieu of the customer's address and..."
>> That is opt-in to privacy which I oppose. Privacy should be
>> the default unless the customer opts-out of privacy and
>> indicates their wish to participate in Internet operations.
>>
>> --Michael Dillon
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From tedm at ipinc.net  Wed Jun 10 13:04:49 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Jun 2009 10:04:49 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <28E139F46D45AF49A31950F88C49745801939197@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745801939197@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A2FE7B1.3040301@ipinc.net>

michael.dillon at bt.com wrote:
>> Unless 
>> there's a sizable transitional period or grandfathering, this 
>> would be a nightmare for larger networks to accomplish.
> 
> You forgot the third option. Instead of the policy stating that
> it is mandatory for ISPs to not publish customer contact info,
> the policy could just say that ISPs do not have to publish
> customer contact info, unless the customer requests it. That
> is still a reasonable policy supporting privacy by default.
> 

This is insanity.  When I proposed my POC cleanup the original draft 
specified things like ARIN had to be aware of spamfiltering, etc. and
YOU, Michael, were complaining that this pushed too much directive
into operational details.

Now, your trying to do the exact same thing - your trying to push
operational details of filing SWIPS into the policy manual. This is 
extreme hypocrisy on your part.

The policy should merely state the ISP has the option of not
publishing street and e-mail contact info if they choose, PERIOD.
Meaning, privacy is OPTIONAL.

NOTHING EXTRA should be stuffed in there regarding whether or not
a customer is supposed to direct an ISP to opt-in or opt-out.


Ted


From bill at herrin.us  Wed Jun 10 13:13:49 2009
From: bill at herrin.us (William Herrin)
Date: Wed, 10 Jun 2009 13:13:49 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <E7956D9775C98F4DB72321439A2F91A92630EA@mail1.dulles.sv.int>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AE@mail>
	<4A2FA8B9.9050309@ibctech.ca>
	<E7956D9775C98F4DB72321439A2F91A92630EA@mail1.dulles.sv.int>
Message-ID: <3c3e3fca0906101013t311745d2jfa899909f2fe89f5@mail.gmail.com>

On Wed, Jun 10, 2009 at 9:36 AM, Divins, David<dsd at servervault.com> wrote:
> The reality is that LEA's and military organizations don't get
> SWIPd as who they really are anyway (I mean, how many times does CIA
> appear in WHOIS) so let's stop pretending that doesn't happen and make
> our lives easier.

David,

That argument is moot. Such organizations are typically unable to
reveal their identities to individuals who don't hold an SCI clearance
with the proper compartment and have a "need to know." This of course
excludes all of ARIN's staff, even under an NDA. With the proposal,
they will still be legally required to further obfuscate their
identities through third parties.


On Tue, Jun 9, 2009 at 12:41 PM, <lar at mwtcorp.net> wrote:
> If it is, the current policy would be in conflict with the FCC under some
> conditions.

Larry,

The FCC does not require you to publicly reveal information about your
telephone subscribers, but they do require you to let your customer
take their "network address" with them to the next service provider.
As an ISP, would you care to trade one privilege for the other?


On Wed, Jun 10, 2009 at 10:56 AM, Alexander,
Daniel<Daniel_Alexander at cable.comcast.com> wrote:
> I also disagree with the need for whois as a means of validation or
> transparency for ARIN. ARIN can request whatever information they want
> under the RSA. They do not need swips to confirm someone's utilization,
> and if that were the only mechanism being used then we have bigger
> problems to solve. If transparency is truly the goal, then it needs to
> be an all or nothing, and whois has no chance of acting as a directory
> for ALL Internet users.

Straw man Dan. Transparency in internet use would require a directory
of all internet users. Transparency in the address assignment process
requires at the very most a directory of only those users with a
static IP address. And as Owen pointed out, even that much isn't
necessary; you don't need to know every last /32; you only need to
know who is holding nontrivial amounts of space.


On Wed, Jun 10, 2009 at 11:41 AM, Kevin Kargel<kkargel at polartel.com> wrote:
> Ah, but things have changed, you can now buy, sell and trade IP's thanks to
> powers vested by 2009-1.  I know that 2009-1 has words saying that the
> intention is not to create property, but if it walks like a duck and quacks
> like a duck...

Then make it a market Kevin. Paid redaction: Greater of $1 per address
or the market rate for address trades per year to ARIN for each
redacted entry. Payment is made in lieu of providing any information
at all about the block other than its range and which ISP holds it.


On Wed, Jun 10, 2009 at 12:19 PM, Skeeve Stevens<Skeeve at eintellego.net> wrote:
> What do we do, as a foreign company/entity, if we need
> to track down who is doing something (illegal/technical
> issue/etc) and the upstream ISP won't disclose it to us?

File a John Doe suit and subpoena the information, like the RIAA does.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jay at impulse.net  Wed Jun 10 13:18:08 2009
From: jay at impulse.net (Jay Hennigan)
Date: Wed, 10 Jun 2009 10:18:08 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2F5B9E.25712.72A48C8@farmer.umn.edu>
References: <4A2E5BD2.8090708@arin.net>,
	<6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com>,
	<010201c9e97e$11497e30$33dc7a90$@net>
	<4A2F5B9E.25712.72A48C8@farmer.umn.edu>
Message-ID: <4A2FEAD0.2050800@impulse.net>

David Farmer wrote:

> To be equally as honest and direct as you have been;
> 
> If this is only about protecting the business interest of the ISPs then go away. 
> However, if we can both protect the business interest of the ISPs and the 
> privacy, confidentiality and other interests of Internet end users then maybe 
> we can do something.  
> 
> If a customer has a business need to have the full information disclosed as it 
> is in the current policy then they should have that right, as the end user of 
> the address space their business need must out weigh your business need 
> as the ISP.  The reason you have been allocated address space in the first 
> place is to provide it to end users to meet their needs in connecting to the 
> Internet. 
> 
> If we can find a way to disclose less information about the Internet end user 
> and protect the interest of the ISP, the end user, and the public interest in 
> proper use of address space then we will have a good proposal.
> 
> I believe this could be a useful proposal that I can support, but if it remains 
> focused solely on the business interest of the ISPs then I will have to oppose 
> it. 

I view it as doing both, as well as in most cases assisting in the abuse 
resolution process.

* It prevents harvesting of customer contact addresses by spammers, 
telemarketers (*cough-Neustar-cough*), etc., thus enhancing customer 
privacy.

* It is more likely to result in abuse complaints being routed to an 
entity technically able to deal with them.  This is both because the ISP 
is likely to have more technical expertise and because the end-user SWIP 
contact is likely to be stale and/or poisoned with junk going to that 
address.  These contacts are often an individual email address rather 
than a role account, as it's collected when IP addresses are first 
assigned and the end-user isn't likely to have put much thought into it.

* It protects the ISP's proprietary customer lists to some extent.  IMHO 
this is the least significant.  If an ISP's customer relationships are 
that fragile there are likely to be other problems.  However, customer 
resentment towards the ISP when an ISP publishes end-user SWIP/RWHOIS 
data and the customer gets spammed and telemarketed could be a problem. 
  I'm thinking of the "How dare you sell my phone and email to these 
sleazebags!?!" type of thing.


I agree that end-users who choose to have their information published 
should have that ability, but they should also be able to choose 
privacy.  IMHO, privacy should be the default but I'd leave that to each 
ISP to decide.


-- 
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV


From petelists at templin.org  Wed Jun 10 13:18:30 2009
From: petelists at templin.org (Pete Templin)
Date: Wed, 10 Jun 2009 12:18:30 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
In-Reply-To: <20090610165026.GA54829@gweep.net>
References: <4A2E5BD2.8090708@arin.net> <4A2FCD7E.4080009@arin.net>
	<20090610165026.GA54829@gweep.net>
Message-ID: <4A2FEAE6.4060202@templin.org>

Joe Provo wrote:

> I'll go from "non-support" to "actively oppose".  As long as we have 
> end-to-end connectivity, we need end-to-end accountability.  If an 
> allocation is large enough to be registered, then the entity should 
> be known.

The entity will be known (customer name will still have to appear), but 
the contact information, if desired, would be the only data that would 
show ISP-data instead of customer-data.  Does that change your position 
at all?

Pete


From bonomi at mail.r-bonomi.com  Wed Jun 10 14:13:49 2009
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Wed, 10 Jun 2009 13:13:49 -0500 (CDT)
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
Message-ID: <200906101813.n5AIDnlV025641@mail.r-bonomi.com>

>
> Policy Proposal 95
>
> 1. Policy Proposal Name: Customer Confidentiality
>
> 2. Proposal Originator: Aaron Wendel
>
> 3. Proposal Version: 2.0
>
> 4. Date: 10 June 2009
>
> 5. Proposal type: new
>
> 6. Policy term: permanent
>
> 7. Policy statement:
>
> ISPs may choose to enter the customer's name along with the ISP's
> address and phone number in reassignments and reallocations in lieu of
> the customer's address and phone number.  The customer's actual
> information must be provided to ARIN on request and will be held in the
> strictest confidence.


I oppose this policy proposal _as_written_.

I do not believe that this should be the sole prerogative of the ISP.

Change the wording to something like:

  "An ISP may, _at_their_customer's_request_, enter the following information:
     {customer's actual name}
     C/O {the ISP's NAME and address}
     {the ISP's phone number}
   in lieu of the customer's address and phone number.  The customer's actual
   information must be provided to ARIN on request and will be held in the
   strictest confidence."


And I can support that.


Rationale:

  The ISP does not, contrary to what some may think "own" the customer, the
  customer is an independant party, and has a right to self-identification,
  _IF_ the customer so desires.  If the customer _chooses_ to have the ISP 
  act as 'agent' for contact purposes, I have no problem with that.  Allowing
  the ISP to intercept and possibly destroy communications intended for the
  customer, for _whatever_ reason, is asking for all sorts of trouble.o
  
  The "C/O ISP NAME" is necessary, regardless, to ensure 'deliverability' of
  postal communications to the ISP acting 'on behalf of' the client.  Mail
  _addressed to_  the customer at the address of another business has a 
  significant probability of _not_ being delivered to that address -- rather
  getting 'return to sender, not at that address' handling by the post office.
  
  
  It is also worth noting that the proposed action does _NOTHING_ to discourage
  postal solicitations of the ISP's customer base.  It is a FELONY to not 
  deliver on to the customer such a solication that shows up at the ISP's
  mail address with the customer's name on it.  See 18 USC 1702 and 18 USC 1703.
  (note: addressed "to" the company, "attn: {person}" is a differnt story.)
  
  The ISP can act as a 'blind' mail forwarding service, but they get in _LOTS_ 
  of trouble if they make any attempt to censor -- or even _open_, let alone
  *read* -- anything they get, which is addressed to the customer.
  



From bicknell at ufp.org  Wed Jun 10 13:31:33 2009
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 10 Jun 2009 13:31:33 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <20090610173133.GA21718@ussenterprise.ufp.org>


I have an amazing sense of deja vu reading this thread.

99% of what I have read has been written on ppml before, or said
in a meeting in response to one of at least 5 previous proposals I
can remember off the top of my head.

There is one thing I feel is different, which is how this interacts
with IPv6.  That has not been discussed that much before, but is
becoming more important by the second.

In the IPv4 world, we've decided that anyone with a /29 needs to
be in whois.  Anyone with more than 6 computers needs to be in
Whois.

In the IPv6 world, we've decided that anyone with a /56 and larger
needs to be in whois.  That's potentially 2^72 computers.

So if I am a home user, small business, or whatever and have 20
computers, I must be in SWIP if I get static IPv4, but if I get
static IPv6 in the form of a /64 (or even a /60), then I am not.

This makes no sense to me.  Either the 20 computer user should need
to be in whois in both cases, or not in whois in both cases.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090610/0c379748/attachment.sig>

From tedm at ipinc.net  Wed Jun 10 13:36:45 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Jun 2009 10:36:45 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
In-Reply-To: <4A2FCD7E.4080009@arin.net>
References: <4A2E5BD2.8090708@arin.net> <4A2FCD7E.4080009@arin.net>
Message-ID: <4A2FEF2D.6090304@ipinc.net>

This is a much better proposal but there is one thing that EVERYONE
NEEDS to consider before supporting it, PARTICULARLY if you feel, as
I do, that the single most important reason for the existence of the
WHOIS database is to provide a contact to reach in abuse cases.

Currently, for ALL IP ADDRESSES under RSA, the ISP filing the SWIP is
CONTRACTUALLY OBLIGATED to supply NON-BOGUS contact info.

Thus, if a problem exists with a netblock, and you go to e-mail the
contact on the netblock, and you discover the e-mail address is
something like santa at north.pole.com, you can now go to the parent
block and complain.

If they ignore you, you can go to ARIN and complain.  And ARIN can,
using the POC-cleanup language just added to the policy manual,
invalidate the SWIP entry.

This might come at a very bad time for the parent block - such as right
in the middle of their justification attempt to get more IPv4.  Thus,
it is FAR MORE LIKELY that the threat of doing this will, in fact, get
the parent block to refile the SWIP with correct info, and if the block
holder CONTINUES to fail to respond to mails to the new, allegedly
valid, e-mail contact info, why then the parent block holder can STILL
have the SWIP invalidated by ARIN.

In other words, the way it is right now, ARIN has a big club to use
against the ISP/parent block holder that effectively forces them to
make sure that anyone they hand IP addressing out to, WILL in fact,
respond to complaints.

This policy change in effect gives up that club.  Under it, if the
parent block holder/ISP uses their own contact info, and you send an
e-mail complaint to that contact info, and get no response - well then
ARIN cannot do anything to pull that SWIP since they would have to
pull ALL SWIPS using that unresponsive POC.  And clearly they aren't 
going to do that.

Thus the threat of losing the SWIP is gone, and we have less ability
to rein in those ISP's and netblocks who are out there DELIBERATELY
harboring spammers and network attackers.

I would feel a lot better about this proposal if additional language
was added that preserved that club.

Ted


Member Services wrote:
> Policy Proposal 95
> Customer Confidentiality
> 
> The proposal originator submitted a revised version of the proposal.
> 
> The AC will review this proposal at their next regularly scheduled
> meeting and decide how to utilize the proposal. Their decision will be
> announced to the PPML.
> 
> In the meantime, the AC invites everyone to comment on this proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> http://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> #####
> 
> 
> 1. Policy Proposal Name: Customer Confidentiality
> 
> 2. Proposal Originator: Aaron Wendel
> 
> 3. Proposal Version: 2.0
> 
> 4. Date: 10 June 2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> ISPs may choose to enter the customer's name along with the ISP's
> address and phone number in reassignments and reallocations in lieu of
> the customer's address and phone number.  The customer's actual
> information must be provided to ARIN on request and will be held in the
> strictest confidence.
> 
> 8. Rationale:
> 
> Version 2.0 clarifies the need for the customer name to remain in the
> SWIP and RWHOIS information.
> 
> Customer contact lists are one of the most proprietary and confidential
> pieces of information in any business.  The requirements for ISPs to
> publish those lists via SWIP or RWHOIS runs contrary to good business
> practices and invites competitors and others to solicit both individuals
> and companies receiving reassignments and sub allocations from upstream
> providers.
> 
> 9. Timetable for implementation: immediate
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From jmaimon at chl.com  Wed Jun 10 13:38:29 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 10 Jun 2009 13:38:29 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2E5BD2.8090708@arin.net>
References: <4A2E5BD2.8090708@arin.net>
Message-ID: <4A2FEF95.8070609@chl.com>



Member Services wrote:

> 
> ISPs may choose to enter their own address and phone number in
> reassignments and reallocations in lieu of the customer's address and
> phone number.  The customer's actual information must be provided to
> ARIN on request and will be held in the strictest confidence.

Last I checked residential customers the ISP has the option to put in 
private residence in their swip record. Residential privacy concerns 
assuaged.

> 
> 8. Rationale:
> 
> Customer contact lists are one of the most proprietary and confidential

Cooperation takes precedence over competition.

Its been that since inception and I see no compelling reason to change it.

Customer contact lists have never been considered proprietary on the 
internet, this statement is false on its face.

I dont support changing things to further protect incumbents against 
competition.

> pieces of information in any business.  The requirements for ISPs to
> publish those lists via SWIP or RWHOIS runs contrary to good business
> practices 

Allowing your customers to ever leave you runs contrary to good business 
practices, but we dont permit customers to be held hostage either.

> and invites competitors and others to solicit both individuals
> and companies receiving reassignments and sub allocations from upstream
> providers.

Good. Thats actually good for competition overall, come to think of it.

Not brought up is privacy concerns for non-residential customers.

On the whole, I dont empathize with that sentiment for non residential 
cusotmers either, but notably absent from rational is any legitimate 
privacy concerns.


-1


From tedm at ipinc.net  Wed Jun 10 13:50:36 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Jun 2009 10:50:36 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <20090610173133.GA21718@ussenterprise.ufp.org>
References: <4A2E5BD2.8090708@arin.net>
	<20090610173133.GA21718@ussenterprise.ufp.org>
Message-ID: <4A2FF26C.4070604@ipinc.net>

Leo Bicknell wrote:
> I have an amazing sense of deja vu reading this thread.
> 
> 99% of what I have read has been written on ppml before, or said
> in a meeting in response to one of at least 5 previous proposals I
> can remember off the top of my head.
> 
> There is one thing I feel is different, which is how this interacts
> with IPv6.  That has not been discussed that much before, but is
> becoming more important by the second.
> 
> In the IPv4 world, we've decided that anyone with a /29 needs to
> be in whois.  Anyone with more than 6 computers needs to be in
> Whois.
> 
> In the IPv6 world, we've decided that anyone with a /56 and larger
> needs to be in whois.  That's potentially 2^72 computers.
> 
> So if I am a home user, small business, or whatever and have 20
> computers, I must be in SWIP if I get static IPv4, but if I get
> static IPv6 in the form of a /64 (or even a /60), then I am not.
> 
> This makes no sense to me.  Either the 20 computer user should need
> to be in whois in both cases, or not in whois in both cases.
> 


With the IPv4 world, there's 2 obvious justifications for WHOIS:

1) providing contact info for the rest of the Internet in case of problems

2) Providing assurance to the rest of the Internet that an ISP isn't 
hoarding IPv4 that they aren't using.


With an IPv6 world, #2 reason is gone.  #1 reason remains.

The sticky problem, though, is that both of these justifications are 
intertwined.

An ISP that deliberately wants to shield Bad People has lots of 
incentive to NOT provide contact info for #1.  However, they do this at 
risk of failing to provide assurance that they aren't hoarding - and 
thus run the rick of not obtaining new allocations, or even having 
existing allocations pulled.  This is reason #2

In an IPv6 world, since #2 is pointless, you now no longer have 
incentive to get the ISP who deliberately wants to shield Bad People
from prying eyes, to not do this, because the community now no
longer cares that they are hoarding.  If they want to hoard IPv6,
let them hoard!  If they never get another IPv6 allocation, so what -
that /32 will provide them with centuries of numbers to hand out to
their spammy, slimeball customers.

It's obvious that as IPv6 moves forward, ultimately, ARIN is going to 
have to take a more activist role in uncovering those ISP's who want to 
shield evildoers.

I personally don't thing the community is ready to sign off on this
yet.  Most of them are still comfortably unaware of the lengths that
truly amoral and evil criminals will go to.  But, one day, they will
understand, to their sorrow, and you will see it come about.

Ted




From tedm at ipinc.net  Wed Jun 10 13:53:27 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Jun 2009 10:53:27 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
In-Reply-To: <200906101813.n5AIDnlV025641@mail.r-bonomi.com>
References: <200906101813.n5AIDnlV025641@mail.r-bonomi.com>
Message-ID: <4A2FF317.3030303@ipinc.net>

Robert Bonomi wrote:
>> Policy Proposal 95
>>
>> 1. Policy Proposal Name: Customer Confidentiality
>>
>> 2. Proposal Originator: Aaron Wendel
>>
>> 3. Proposal Version: 2.0
>>
>> 4. Date: 10 June 2009
>>
>> 5. Proposal type: new
>>
>> 6. Policy term: permanent
>>
>> 7. Policy statement:
>>
>> ISPs may choose to enter the customer's name along with the ISP's
>> address and phone number in reassignments and reallocations in lieu of
>> the customer's address and phone number.  The customer's actual
>> information must be provided to ARIN on request and will be held in the
>> strictest confidence.
> 
> 
> I oppose this policy proposal _as_written_.
> 
> I do not believe that this should be the sole prerogative of the ISP.
> 
> Change the wording to something like:
> 
>   "An ISP may, _at_their_customer's_request_, enter the following information:
>      {customer's actual name}
>      C/O {the ISP's NAME and address}
>      {the ISP's phone number}
>    in lieu of the customer's address and phone number.  The customer's actual
>    information must be provided to ARIN on request and will be held in the
>    strictest confidence."
> 

This is intrusion of operational details into the NRPM and has 
historically been opposed by the community.

Nothing in the proposal prevents the ISP from telling all their 
customers that by default, SWIP data will contain the ISP's data, unless 
a customer opts-out.

If you want to run your ISP like this, fine.

Just don't tell me how to run my ISP.

Ted


From farmer at umn.edu  Wed Jun 10 14:02:11 2009
From: farmer at umn.edu (David Farmer)
Date: Wed, 10 Jun 2009 13:02:11 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2FEAD0.2050800@impulse.net>
References: <4A2E5BD2.8090708@arin.net>,
	<4A2F5B9E.25712.72A48C8@farmer.umn.edu>,
	<4A2FEAD0.2050800@impulse.net>
Message-ID: <4A2FAED3.3387.86F4E1A@farmer.umn.edu>

On 10 Jun 2009 Jay Hennigan wrote:

> David Farmer wrote:
> 
> > I believe this could be a useful proposal that I can support, but if
> > it remains focused solely on the business interest of the ISPs then
> > I will have to oppose it. 
> 
> I view it as doing both, as well as in most cases assisting in the
> abuse resolution process.
>
> * It prevents harvesting of customer contact addresses by spammers,
> telemarketers (*cough-Neustar-cough*), etc., thus enhancing customer
> privacy.
> 
> * It is more likely to result in abuse complaints being routed to an
> entity technically able to deal with them.  This is both because the
> ISP is likely to have more technical expertise and because the
> end-user SWIP contact is likely to be stale and/or poisoned with junk
> going to that address.  These contacts are often an individual email
> address rather than a role account, as it's collected when IP
> addresses are first assigned and the end-user isn't likely to have put
> much thought into it.
> 
> * It protects the ISP's proprietary customer lists to some extent. 
> IMHO this is the least significant.  If an ISP's customer
> relationships are that fragile there are likely to be other problems. 
> However, customer resentment towards the ISP when an ISP publishes
> end-user SWIP/RWHOIS data and the customer gets spammed and
> telemarketed could be a problem. 
>   I'm thinking of the "How dare you sell my phone and email to these
> sleazebags!?!" type of thing.
> 
> 
> I agree that end-users who choose to have their information published
> should have that ability, but they should also be able to choose
> privacy.  IMHO, privacy should be the default but I'd leave that to
> each ISP to decide.
> 
> 
> -- 
> Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
> Impulse Internet Service  -  http://www.impulse.net/ Your local
> telephone and internet company - 805 884-6323 - WB6RDV

I think I agree with all your points, but those points need to be 
in the rational section too, otherwise this proposal is focused 
only on the business interest of the ISPs.  Additionally your last 
bit needs to be explict in the policy statement too, an ISP must 
have a obligation to publish or not publish as requested by the 
customer, which ever default the ISP chooses.  This needs to 
befitt the actual customers, the Internet end users, too, not just 
the ISPs, and with a little bit of work it think it can easily do 
that. 
 


===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From bonomi at mail.r-bonomi.com  Wed Jun 10 15:00:18 2009
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Wed, 10 Jun 2009 14:00:18 -0500 (CDT)
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
Message-ID: <200906101900.n5AJ0Ixq026096@mail.r-bonomi.com>

> Date: Wed, 10 Jun 2009 10:53:27 -0700
> From: Ted Mittelstaedt <tedm at ipinc.net>
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
>
> > I do not believe that this should be the sole prerogative of the ISP.
> > 
> > Change the wording to something like:
> > 
> >   "An ISP may, _at_their_customer's_request_, enter the following information:
> >      {customer's actual name}
> >      C/O {the ISP's NAME and address}
> >      {the ISP's phone number}
> >    in lieu of the customer's address and phone number.  The customer's actual
> >    information must be provided to ARIN on request and will be held in the
> >    strictest confidence."
> > 
>
> This is intrusion of operational details into the NRPM and has 
> historically been opposed by the community.
>
> Nothing in the proposal prevents the ISP from telling all their 
> customers that by default, SWIP data will contain the ISP's data, unless 
> a customer opts-out.

I don't want the ISP _requiring_ the listing that way, regardless of
customer opinio

> If you want to run your ISP like this, fine.
>
> Just don't tell me how to run my ISP.

It says 'may'.  

It says you have to have the customer's consent, to intercept their mail
and phone calls.

And regardless of what the NPRM says, an ISP who does so, has to worry about
18 USC 1700, and nearby sections.



From farmer at umn.edu  Wed Jun 10 14:13:18 2009
From: farmer at umn.edu (David Farmer)
Date: Wed, 10 Jun 2009 13:13:18 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <20090610173133.GA21718@ussenterprise.ufp.org>
References: <4A2E5BD2.8090708@arin.net>,
	<20090610173133.GA21718@ussenterprise.ufp.org>
Message-ID: <4A2FB16E.18455.8797DF4@farmer.umn.edu>

Maybe I'm just saying what you said Leo using different words, I had the 
follow thought after reading your note:

Maybe we should figure out the way we want the world to be in IPv6 and 
work our way back to what that should be for IPv4.  Putting effort into figuring 
out IPv6 would be a good use of effort.  I'm not sure rehashing this again for 
IPv4 is useful effort.  Especially with the number of things the AC has on its 
plate.

On 10 Jun 2009 Leo Bicknell wrote:

> I have an amazing sense of deja vu reading this thread.
> 
> 99% of what I have read has been written on ppml before, or said
> in a meeting in response to one of at least 5 previous proposals I can
> remember off the top of my head.
> 
> There is one thing I feel is different, which is how this interacts
> with IPv6.  That has not been discussed that much before, but is
> becoming more important by the second.
> 
> In the IPv4 world, we've decided that anyone with a /29 needs to
> be in whois.  Anyone with more than 6 computers needs to be in
> Whois.
> 
> In the IPv6 world, we've decided that anyone with a /56 and larger
> needs to be in whois.  That's potentially 2^72 computers.
> 
> So if I am a home user, small business, or whatever and have 20
> computers, I must be in SWIP if I get static IPv4, but if I get
> static IPv6 in the form of a /64 (or even a /60), then I am not.
> 
> This makes no sense to me.  Either the 20 computer user should need to
> be in whois in both cases, or not in whois in both cases.
> 
> -- 
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/
> 



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From michael.dillon at bt.com  Wed Jun 10 14:14:15 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 19:14:15 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7F1E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <28E139F46D45AF49A31950F88C49745801939F20@E03MVZ2-UKDY.domain1.systemhost.net>

> However, if the ISP chose as a default 
> to list the customer, and the customer contractually agreed 
> to this, they would have to opt-out to achieve privacy. Both 
> scenarios are legitimate under U.S. law, though Canada may be 
> different. 

I have no problem with that scenario, if ARIN makes it clear
that ARIN is not forcing the ISP to publish by default.
On balance, I don't think that scenario is needed and I also
think that it could cause more garbage info to be published.
Since I view this proposal partly as a clean up of the
whois directory data, I would prefer to see a policy that
discourages publication of useless contact info.

My definition of a useful contact is one that is ready willing
and able to take action upon notification of an Internet
operational issue, 24 hours per day, 365 days a year.

--Michael Dillon


From spiffnolee at yahoo.com  Wed Jun 10 14:25:57 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Wed, 10 Jun 2009 11:25:57 -0700 (PDT)
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7F1C@SUEX07-MBX-04.ad.syr.edu>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net>
	<E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>
	<75822E125BCB994F8446858C4B19F0D77B1A7F1C@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <294649.33761.qm@web63305.mail.re1.yahoo.com>


M. Mueller said:
> This doctrine bears no relationship to actual law regarding privacy and freedom 
> of association. 

I am unaware of any laws describing WHOIS, but IANAL.  If there are laws in 
relevant jurisdictions, please cite them by number.

Also, it would be handy for you to disclose your legal credentials when providing
legal advice.

Lee


[IANAL] = I am not a lawyer.



      



From michael.dillon at bt.com  Wed Jun 10 14:27:26 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 19:27:26 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800C08DCC6@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <28E139F46D45AF49A31950F88C49745801939F26@E03MVZ2-UKDY.domain1.systemhost.net>

 
> We as a community need to answer a question. Do you think the 
> community needs to know the details of every user of the IP 
> address space, or do they just need to know the contact 
> information of those that are responsible for its use?

Personally, I would like to see certain details that are
not currently published. I don't want to know names,
addresses, phone numbers or email addresses. But I would
like to see NAICS codes <http://www.census.gov/eos/www/naics/>,
number of employees at this site, date of first Internet
connection to this site, and similar data. For private residences 
there would be no NAICS code, just private residence, number
of people living at the address, date of first connection, etc.

This type of info would actually be of some use to the
"community" if you interpret that word to mean all of the
inhabitants of the ARIN region collectively.

> The idea of whois as a directory of Internet users is 
> ridiculous.

That's the ARPANET legacy. Back then it was not ridiculous,
in fact it was necessary to justify budget allocations. Back
then most people used multiuser systems, and every individual
account was counted.

> That large of a pool, not included 
> in the set, makes that purpose pointless.

The people who really need that kind of data are making alternate
arrangements to get it from ISPs. There is no longer a role for
a central database (SWIP) or even a centralised database search
mechanism (RWHOIS).

> ARIN can request 
> whatever information they want under the RSA.

And sometimes the hostmasters just prefer to take a database
dump in a spreadsheet or access db, instead of looking in 
whois. Errors can creep in between the translation of an ISP's
internal databases into SWIP/RWHOIS. And let's stop pretending
that SWIP and RWHOIS are cool technology. They are utter crap
that may have been cool back in the teenage days of the Internet
but should have been replaced long ago. Reform is needed at
many levels, including both policy and technology.

> The only purpose whois can serve, in today's world, is as a 
> contact directory for abuse or other issues,

And I would like to see this purpose take center stage, be
recognized in policy, and implemented in both technology and
ARIN processes. The processes would be involved with constantly
revalidating the data in the directory to make sure that it
can actually be used for Internet operational issues.

--Michael Dillon


From michael.dillon at bt.com  Wed Jun 10 14:33:46 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 19:33:46 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
In-Reply-To: <4A2FCD7E.4080009@arin.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801939F2B@E03MVZ2-UKDY.domain1.systemhost.net>

> ISPs may choose to enter the customer's name along with the 
> ISP's address and phone number in reassignments and 
> reallocations in lieu of the customer's address and phone 
> number.

This convoluted sentence is not plain English.


>  The customer's actual information must be provided 
> to ARIN on request and will be held in the strictest confidence.

This is already covered by the RSA and does not belong in
ARIN policy.

--Michael Dillon

P.S. I'm beginning to think that the discussion would go better if there
were another policy proposal that included everything, broken down into
separate points, so that we could come to quicker consensus on which
bits are generall supported, which are generally opposed, etc.


From tedm at ipinc.net  Wed Jun 10 14:44:27 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Jun 2009 11:44:27 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
In-Reply-To: <200906101900.n5AJ0Ixq026096@mail.r-bonomi.com>
References: <200906101900.n5AJ0Ixq026096@mail.r-bonomi.com>
Message-ID: <4A2FFF0B.8050000@ipinc.net>

Robert Bonomi wrote:
>> Date: Wed, 10 Jun 2009 10:53:27 -0700
>> From: Ted Mittelstaedt <tedm at ipinc.net>
>> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality - revised
>>
>>> I do not believe that this should be the sole prerogative of the ISP.
>>>
>>> Change the wording to something like:
>>>
>>>   "An ISP may, _at_their_customer's_request_, enter the following information:
>>>      {customer's actual name}
>>>      C/O {the ISP's NAME and address}
>>>      {the ISP's phone number}
>>>    in lieu of the customer's address and phone number.  The customer's actual
>>>    information must be provided to ARIN on request and will be held in the
>>>    strictest confidence."
>>>
>> This is intrusion of operational details into the NRPM and has 
>> historically been opposed by the community.
>>
>> Nothing in the proposal prevents the ISP from telling all their 
>> customers that by default, SWIP data will contain the ISP's data, unless 
>> a customer opts-out.
> 
> I don't want the ISP _requiring_ the listing that way, regardless of
> customer opinio
> 
>> If you want to run your ISP like this, fine.
>>
>> Just don't tell me how to run my ISP.
> 
> It says 'may'.  
> 

The proposal is
effectively modifying one of the terms of the RSA - which is that 
previously the RSA required the ISP to supply contact data that could
be published to the general public.  With the proposal the RSA would 
only require the ISP to supply contact data that can be seen by ARIN, 
without the requirement that it can be seen by the general public

Your wording suggestion extends the proposal way beyond a modification
of the RSA terms to the ISP, into an operational detail of 
ISP-to-customer relations.

> It says you have to have the customer's consent, to intercept their mail
> and phone calls.
> 
> And regardless of what the NPRM says, an ISP who does so, has to worry about
> 18 USC 1700, and nearby sections.
> 

No doubt.  But, why does ARIN and the policy manual need to worry about 
that?

Ted


From tvest at pch.net  Wed Jun 10 14:54:50 2009
From: tvest at pch.net (Tom Vest)
Date: Wed, 10 Jun 2009 14:54:50 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7F39@SUEX07-MBX-04.ad.syr.edu>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><4A2EA88D.5030102@steadfast.net><6eb799ab0906092019l3aaa7cbbx8aa0f53a3c218ce6@mail.gmail.com><010201c9e97e$11497e30$33dc7a90$@net>
	<3c3e3fca0906092124y325fa1abvd0402abb9052eadb@mail.gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BB@mail>
	<B68357FE-7268-4631-8849-0217034C34AD@pch.net>
	<75822E125BCB994F8446858C4B19F0D77B1A7F39@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <BD052800-166D-4B04-B0F5-5BCEC49CF5DF@pch.net>

Hi Milton,

At last we agree on something :-)
My point in offering this reference was not to advocate any new  
requirements, confusing, deluge-like, or otherwise. Our method for  
handling authorization and accountability-related information is  
already fully operationalized, is generally well understood by most if  
not all stakeholders, and works pretty well. Moreover, the system of  
"unified identifiers" that facilitate the management of authorization  
and accountability-related records in this industry is identical to,  
and shares fate with, the unique identifiers that are the subjects of  
the records themselves. I believe that that's an administrative  
advantage that we'd all very much like to preserve.

I don't understand how the goal of permitting insurance portability  
was rendered (any more) meaninglessness by the fact of additional  
paperwork. If health insurance is still not as portable as it might be  
under current circumstances, I seriously doubt that HIPAA could be  
blamed. To be portable, something must exist first -- but let's not go  
down that road here.

Cheers,

TV

On Jun 10, 2009, at 12:08 PM, Milton L Mueller wrote:

> Tom
> The parallels with HIPAA are indeed there with respect to policy  
> objectives.
> But I hope we don't use HIPAA notification and consent as a model  
> for anything. Anyone confronted with the confusing deluge of consent  
> forms at a doctor's office during the early stages of its  
> implementation knows how meaningless the policy objectives became  
> once they were operationalized. Also, note what happened to their  
> attempt to create a unified identifier...


> On Jun 10, 2009, at 11:41 AM, Kevin Kargel wrote:
>
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- 
>>> bounces at arin.net] On
>>> Behalf Of William Herrin
>>> Sent: Tuesday, June 09, 2009 11:25 PM
>>> To: Aaron Wendel
>>>
>>> IP addresses are like public right of ways. As an ISP you get to  
>>> hold
>>> lots of them in trust, but they aren't yours. They're ours, the
>>> general public's, and while you hold them in trust you are  
>>> accountable
>>> for their use... not to ARIN but to the general public whose commons
>>> you are so graciously being allowed to use at an almost negligible
>>> cost.
>>
>> Ah, but things have changed, you can now buy, sell and trade IP's  
>> thanks to
>> powers vested by 2009-1.  I know that 2009-1 has words saying that  
>> the
>> intention is not to create property, but if it walks like a duck  
>> and quacks
>> like a duck...
>
> Hi Kevin,
>
> While your views about IP number resource privatization may (or may  
> not) be borne out by changing circumstances, I think that the  
> article that I quoted previously is relevant either way.  Recall  
> that HIPAA = Health Information *Portability and Accountability*   
> Act. The overall goal of the legislation was to strike a practical  
> balance between privacy and disclosure so that the option of  
> insurance portability (individual autonomy, freedom of choice,  
> competition, etc.) could be extended broadly *without* sacrificing  
> "accountability," including the accountability of individuals and  
> health service providers for the potential impacts that increasing  
> patient/provider churn might have on the health of other individuals  
> and society in general.
>
> I think the parallels to our current circumstances and policy  
> debates are pretty self-evident, but perhaps that's just me...
>
> TV



> On Jun 10, 2009, at 10:12 AM, Milton L Mueller wrote:
>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- 
>>> bounces at arin.net] On
>>> Public actions have public accountability.  If you don't want your  
>>> picture
>>> taken going in to a strip club then don't go to a strip club.
>>>
>>
>> This doctrine bears no relationship to actual law regarding privacy  
>> and freedom of association. Sorry, guys, but there's more at stake  
>> here than your convenience as network admins, and even as network  
>> admins there are appropriate limits to place on indiscriminate  
>> public access to sensitive information, especially when  
>> contractually agreed between provider and customer. When you get  
>> elected as a legislator, Kevin, then you and 250 other elected reps  
>> can change that under due process if you wish; until then, don't  
>> try to make law via ARIN.
>>
>> --MM
>
>
> Neither does "actual law" impose a strict, uniform interpretation on  
> how information collected and maintained for *authorization and  
> accountability purposes* can and cannot be used in all situations.  
> An arguably relevant, if US-centric, illustration:
>
> "HIPAA requires healthcare providers to obtain patients'  
> authorization before disclosing their information to third parties  
> for marketing purposes. However, healthcare providers do not need  
> authorization to disclose information for marketing their own health- 
> related services. HIPAA also allows disclosure of health-related  
> information for a variety of social purposes such as public health  
> activities, suspicion of abuse or neglect, health oversight  
> activities, and for law enforcement purposes, along with a court  
> order, subpoena, or "administrative request." HIPAA does not include  
> a requirement to provide notice toconsumers in the event of a data  
> breach. Finally, lawsuits to enforce HIPAA requirements can only be  
> brought by the secretary of the Department of Health and Human  
> Services and not by individuals."*
>
> So, in some contexts at least, one man's "indiscriminate public  
> access" may be another man's access/disclosure to fulfill a  
> "legitimate social purpose."
>
> If that doesn't suit you, you can always take your own advice and  
> try to author some new "actual laws" that more closely fit your own  
> views.
>
> TV
>
> *George H. Pike, "HIPAA Gets New Privacy Rules" (Information Today,  
> April 1, 2009), p. 13.
>
> An online version is available at:
> http://goliath.ecnext.com/coms2/gi_0199-10387318/HIPAA-gets-new-privacy-rules.html



From michael.dillon at bt.com  Wed Jun 10 14:59:11 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 19:59:11 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <292AF25E62B8894C921B893B53A19D97394469E4A9@BUSINESSEX.business.ad>
Message-ID: <28E139F46D45AF49A31950F88C49745801939F3B@E03MVZ2-UKDY.domain1.systemhost.net>

> a) Trying to track down the contact details of someone doing 
> DoS, SPAM, Criminal Acts or having technical problems and 
> having US providers telling people outside the US like us to 
> get lost when we ask for the details of who is using an IP range.

There may actually be a role here for ARIN to act as
a kind of clearinghouse for this type of reporting.
For instance, have a webpage where people can fill
in some fields and check some boxes. Then send the 
ISPs a daily or hourly report with stats of what
was reported. The ISP can drill down into the details
on the website if they want to.

The problem is that when abuse crosses international
borders, it is difficult to find the right place to
make a report. And when report volume gets too high,
the recipients cease to respond to it.

> If there was a method to have issues dealt with... i.e., we 
> could contact ARIN and have them look into the matter then it 
> would be fine.... but this is not what they do.  So what 
> happens then?  Should it be written into the policy that CERT 
> or some other organisation should be able to have the 
> information disclosed to them?

Formally, I think that this could be handled via suggestions
but try not to cover too many things in one suggestion.
<https://www.arin.net/participate/acsp/index.html>

> The policy also does not state whom ARIN can disclose it to - 
> just saying 'held in strictest confidence' doesn't actually 
> mean anything.

The RSA covers all of this already.

--Michael Dillon


From leo.vegoda at icann.org  Wed Jun 10 15:05:43 2009
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Wed, 10 Jun 2009 12:05:43 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <20090610173133.GA21718@ussenterprise.ufp.org>
References: <4A2E5BD2.8090708@arin.net>,
	<20090610173133.GA21718@ussenterprise.ufp.org>
Message-ID: <05B243F724B2284986522B6ACD0504D78921C0B1F2@EXVPMBX100-1.exc.icann.org>

Leo Bicknell wrote:

[...]

> In the IPv6 world, we've decided that anyone with a /56 and larger
> needs to be in whois.  That's potentially 2^72 computers.

That's not what the policy says. It actually says:

   6.5.4.4. Registration of Assignments

   All /56 and larger assignments to end sites are required to be 
   registered either by the LIR or its subordinate ISPs in such a 
   way that the RIR/NIR can properly evaluate the HD-Ratio when 
   a subsequent allocation becomes necessary.

It makes no mention of whois and does not specify a method, just that
ARIN needs to be able to evaluate your request for more addresses. In
most cases that should mean that you keep a good internal record
of the way you have assigned IPv6 prefixes to your customers.

Effectively, the policy in now place says that for IPv6, whois 
registration is only for ISPs or anyone with a direct assignment from 
ARIN. ISPs may choose to register their customers' address 
assignments in ARIN's whois server but are not required to do so.

Regards,

Leo Vegoda

From lar at mwtcorp.net  Wed Jun 10 15:07:42 2009
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Wed, 10 Jun 2009 13:07:42 -0600
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
Message-ID: <web-1011043@be1.mail.trib.com>

      Larry,

     The FCC does not require you to publicly reveal information about your
     telephone subscribers, but they do require you to let your customer
     take their "network address" with them to the next service provider.
     As an ISP, would you care to trade one privilege for the other?

My point was the the FCC prohibited me from making some information public.
(Not IP at this time)
Even I am not allowed to use some information I have to market unrelated 
services
to my customers.

My point was better expressed by others. What ARIN wants doesn't
make much difference to me if it would put me in violation of Regulators or
when requested by a customer that has a legitimate reason for the request.
A Home for Battered Women has requested that I not publish their address
anywhere to protect the safety of their clients. I don't care what the 
policy
is I'm not publishing that address. I don't think you have a need to know in 
this
case.

I feel the proposal aligns ARIN's policy more closely with real practice. 
Build
guidelines if you want but I think it would be too messy to be of much 
value.

Don't kid about IP number portability. I fully expect some congressman to 
decide
that it's a right. After all if the phone company can do it why not the 
internet?
Anything is possible all you have to do is pass a law.

Larry Ash
Network Administrator
Mountain West Telephone
400 East 1st St.
Casper, WY 82601
Office 307 233-8387


From kloch at kl.net  Wed Jun 10 15:11:16 2009
From: kloch at kl.net (Kevin Loch)
Date: Wed, 10 Jun 2009 15:11:16 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <997BC128AE961E4A8B880CD7442D94800C08DCC6@NJCHLEXCMB01.cable.comcast.com>
References: <997BC128AE961E4A8B880CD7442D94800C08D993@NJCHLEXCMB01.cable.comcast.com>	<28E139F46D45AF49A31950F88C497458019391A0@E03MVZ2-UKDY.domain1.systemhost.net>
	<997BC128AE961E4A8B880CD7442D94800C08DCC6@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <4A300554.3050408@kl.net>

Alexander, Daniel wrote:

> I also disagree with the need for whois as a means of validation or
> transparency for ARIN. ARIN can request whatever information they want
> under the RSA. They do not need swips to confirm someone's utilization,
> and if that were the only mechanism being used then we have bigger
> problems to solve. If transparency is truly the goal, then it needs to
> be an all or nothing, and whois has no chance of acting as a directory
> for ALL Internet users.

It does not have to be all or nothing.  Any requirement to document
reassignments does help discourage abuse (hoarding) and verification
by ARIN for new requests.

It is my belief that for most applicants ARIN uses only the swip/rwhois
data to verify requests for additional space and only when there is
reason or history to suspect fraud do they dig for more.  This has
the benefit of requiring ISPs to have internal systems that manage
and document customer assignments accurately.  How many small/medium
ISPs/hosts would completely mismanage this if it were not for the
ARIN reporting requirement?

I don't care if customer assignments are made public but I strongly
support keeping the requirement that reassignments be reported to
ARIN as they are made.

I would support a policy that would allow restricting of rwhois server
access to ARIN only and allowing a "non-published" option on swip
templates to prevent it from showing in public whois queries.

I prefer to see all abuse complaints for my customers anyway (using
rwhois instead of swip generally encourages this) so I am aware of any
problem customers as soon as possible.

- Kevin



From michael.dillon at bt.com  Wed Jun 10 15:12:26 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 20:12:26 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A2FE7B1.3040301@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801939F41@E03MVZ2-UKDY.domain1.systemhost.net>

> Now, your trying to do the exact same thing - your trying to 
> push operational details of filing SWIPS into the policy 
> manual. This is extreme hypocrisy on your part.

Nope.

I am ignoring SWIPS, just stating what I think the policy
should cover. Implementation is a separate issue. One way
to implement would be to do away with SWIPs entirely, and
provide a different mechanism for ISPs to update the much
smaller, and more accurate and more useful whois directory.

> The policy should merely state the ISP has the option of not 
> publishing street and e-mail contact info if they choose, PERIOD.
> Meaning, privacy is OPTIONAL.

I prefer to take a more global view than just focusing on
specific nits in the current policy language. My approach would
be to write a whois policy for the 21st century, then comb
through the NRPM looking for clauses that need to be updated,
and then to formally propose the specific deletions, changes 
and additions needed to reach the vision.

--Michael Dillon.


From michael.dillon at bt.com  Wed Jun 10 15:18:50 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 20:18:50 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <20090610173133.GA21718@ussenterprise.ufp.org>
Message-ID: <28E139F46D45AF49A31950F88C49745801939F44@E03MVZ2-UKDY.domain1.systemhost.net>

> In the IPv6 world, we've decided that anyone with a /56 and 
> larger needs to be in whois.  That's potentially 2^72 computers.

Wrong! That is a single residential address. The number of computers
is unknown and irrelevant and will certainly be a lot less than
the number you quote, even if you take into account that there 
could be one or more CPUs at each control point, e.g. lightswitch,
in the home.

However, I see no reason why every /56, i.e. every private 
residence, needs to be in the whois directory.

--Michael Dillon


From tedm at ipinc.net  Wed Jun 10 15:26:58 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 10 Jun 2009 12:26:58 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <28E139F46D45AF49A31950F88C49745801939F44@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745801939F44@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A300902.2080006@ipinc.net>

michael.dillon at bt.com wrote:
>> In the IPv6 world, we've decided that anyone with a /56 and 
>> larger needs to be in whois.  That's potentially 2^72 computers.
> 
> Wrong! That is a single residential address.

I thought a /48 was a single residential address

Ted


From michael.dillon at bt.com  Wed Jun 10 15:33:14 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 10 Jun 2009 20:33:14 +0100
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <4A300902.2080006@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801939F4D@E03MVZ2-UKDY.domain1.systemhost.net>

> > Wrong! That is a single residential address.
> 
> I thought a /48 was a single residential address

A /48 is a single end-site which COULD be a residential address, or it
could be a corporate campus, or a small shop or anything. But a /56 is
unlikely to be anything but a private residence.

--Michael Dillon


From scottleibrand at gmail.com  Wed Jun 10 15:37:31 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 10 Jun 2009 12:37:31 -0700
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
 Size
In-Reply-To: <4A2FD9E6.60105@templin.org>
References: <4A2D622E.4030208@arin.net>,
	<4A2D7D39.3050702@templin.org>	<4A2D636A.13087.F6F36CD@farmer.umn.edu>
	<4A2FD9E6.60105@templin.org>
Message-ID: <4A300B7B.4050609@gmail.com>

Pete Templin wrote:
>
> I'm simply not following your suggestion of the numbers, which 
> includes looking at the spreadsheet you've provided.  I'll base my 
> discussions on the one quarter (1/4) ratio since that's what's written 
> into the Policy Proposal.
>
> Case study #1: ARIN has a /13 of space, also known as 524,288 
> addresses.  Four large-enough requests happen to be at the head of the 
> line, and based on the one-quarter ratio they're eligible for a /15 of 
> space per request.  Each request is issued a /15, also known as 
> 131,072 addresses.  These 524,288 addresses in four allocations would 
> wipe out the pool, not the 24 allocations that you present above.

If ARIN has a /13 of space, the first large-enough request to come in 
could get a /15 based on a 1/4 ratio.  That would take ARIN's space down 
to /14+/15, meaning that the second large-enough request could get a 
/16.  That leaves /14+/15+16, which means the next few also get a /16.  
Once the /14 gets broken up, leaving /15+16, then the next few requests 
can only get /17, until the /15 gets broken up, at which point it goes 
to /18, etc. etc. until you get to the minimum allocation size.
>
> Case study #2: ARIN has a /17 of space, also known as 32,768 
> addresses.  Four large-enough requests happen to be at the head of the 
> line, and based on the one-quarter ratio they're eligible for a /19 of 
> space per request.  Each request is issued a /19, also known as 8,192 
> addresses. These 32,768 addresses in four allocations would wipe out 
> the pool, not the 24 allocations that you present above.

Same deal.  First gets a /19, leaving /18+19, so next 4 get /20s, next 4 
after that get /21s, etc.

-Scott
>
> I acknowledge that current policy allows one large-enough request to 
> wipe out all available-at-the-moment free-pool IPv4 within ARIN's 
> bucket, and that distribution across more-than-one recipient is in the 
> interest of fairness, even though we don't know how yet best to 
> achieve some form of equitable fairness.  That said, this policy 
> doesn't appear to be achieving much of the desired goal; I suspect it 
> needs to be on the order of 6-10 bits (64-1024 allocations) before 
> we're really achieving "distribution".
>
> Pete
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From mueller at syr.edu  Wed Jun 10 16:05:11 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 10 Jun 2009 16:05:11 -0400
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <294649.33761.qm@web63305.mail.re1.yahoo.com>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net>
	<E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>
	<75822E125BCB994F8446858C4B19F0D77B1A7F1C@SUEX07-MBX-04.ad.syr.edu>
	<294649.33761.qm@web63305.mail.re1.yahoo.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A62@SUEX07-MBX-04.ad.syr.edu>



Lee, 
1. IANAL, too
2. you don't need to have passed a bar exam to know that there are laws pertaining to privacy, or to discuss them. 
3. i've co-authored policy papers, some in refereed journals, with legal professionals about dns whois, including an international comparison of privacy laws and their relevance to whois
4. privacy laws don't need to reference whois specifically to be relevant to whois. 
5. some laws do specifically reference it, e.g., in the bilateral trade agreements in which the U.S. tried to impose a specific approach to DNS Whois upon small trading partners (Peru, Singapore, etc.). Those countries responded by invoking their national privacy laws and saying that any whois service had to comply with them. q.e.d.

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org
 

> -----Original Message-----
> From: Lee Howard [mailto:spiffnolee at yahoo.com] 
> 
> M. Mueller said:
> > This doctrine bears no relationship to actual law regarding 
> privacy and freedom 
> > of association. 
> 
> I am unaware of any laws describing WHOIS, but IANAL.  If 
> there are laws in 
> relevant jurisdictions, please cite them by number.
> 
> Also, it would be handy for you to disclose your legal 
> credentials when providing
> legal advice.
> 
> Lee
> 
> 
> [IANAL] = I am not a lawyer.
> 
> 
> 
>       
> 
> 

From petelists at templin.org  Wed Jun 10 16:46:11 2009
From: petelists at templin.org (Pete Templin)
Date: Wed, 10 Jun 2009 15:46:11 -0500
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
 Size
In-Reply-To: <4A300B7B.4050609@gmail.com>
References: <4A2D622E.4030208@arin.net>,
	<4A2D7D39.3050702@templin.org>	<4A2D636A.13087.F6F36CD@farmer.umn.edu>
	<4A2FD9E6.60105@templin.org> <4A300B7B.4050609@gmail.com>
Message-ID: <4A301B93.1040208@templin.org>

Scott Leibrand wrote:
> Pete Templin wrote:
>>
>> I'm simply not following your suggestion of the numbers, which 
>> includes looking at the spreadsheet you've provided.  I'll base my 
>> discussions on the one quarter (1/4) ratio since that's what's written 
>> into the Policy Proposal.
>>
>> Case study #1: ARIN has a /13 of space, also known as 524,288 
>> addresses.  Four large-enough requests happen to be at the head of the 
>> line, and based on the one-quarter ratio they're eligible for a /15 of 
>> space per request.  Each request is issued a /15, also known as 
>> 131,072 addresses.  These 524,288 addresses in four allocations would 
>> wipe out the pool, not the 24 allocations that you present above.
> 
> If ARIN has a /13 of space, the first large-enough request to come in 
> could get a /15 based on a 1/4 ratio.  That would take ARIN's space down 
> to /14+/15, meaning that the second large-enough request could get a 
> /16.  That leaves /14+/15+16, which means the next few also get a /16.  
> Once the /14 gets broken up, leaving /15+16, then the next few requests 
> can only get /17, until the /15 gets broken up, at which point it goes 
> to /18, etc. etc. until you get to the minimum allocation size.

OK, now I understand the intentions.  That said, the first paragraph of 
the proposed policy needs a complete re-write, or at least the first 
sentence: "When ARIN receives its last /8, by IANA implementing section 
10.4.2.2, a maximum allocation and assignment size will be put into 
effect."  This needs to be completely redone to reflect the dynamic 
nature of the ideas you're batting around.  Ideas like "sliding scale", 
"dynamic allocation/assignment size", etc. come to mind.

That said, I think this policy proposal leads to a highly-unpredictable 
run-out model at a micro (i.e. per-request) level - there would be 
essentially no way to predict how much of an assignment/allocation a 
requester might get unless there was a public status board, reports 
(rumors?) on mailing lists (yesterday I got a /X!!!), etc.  It's 
predictable run-out at a macro level, but quite unpredictable at a micro 
level.

Pete



From spiffnolee at yahoo.com  Wed Jun 10 17:10:05 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Wed, 10 Jun 2009 14:10:05 -0700 (PDT)
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A62@SUEX07-MBX-04.ad.syr.edu>
References: <4A2E5BD2.8090708@arin.net>
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net>
	<E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail>
	<75822E125BCB994F8446858C4B19F0D77B1A7F1C@SUEX07-MBX-04.ad.syr.edu>
	<294649.33761.qm@web63305.mail.re1.yahoo.com>
	<75822E125BCB994F8446858C4B19F0D77B220A62@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <400206.32348.qm@web63305.mail.re1.yahoo.com>


Pointers welcomed.  I would like to read the precedents myself.

Lee



----- Original Message ----
> From: Milton L Mueller <mueller at syr.edu>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Sent: Wednesday, June 10, 2009 4:05:11 PM
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> 
> 
> Lee, 
> 1. IANAL, too
> 2. you don't need to have passed a bar exam to know that there are laws 
> pertaining to privacy, or to discuss them. 
> 3. i've co-authored policy papers, some in refereed journals, with legal 
> professionals about dns whois, including an international comparison of privacy 
> laws and their relevance to whois
> 4. privacy laws don't need to reference whois specifically to be relevant to 
> whois. 
> 5. some laws do specifically reference it, e.g., in the bilateral trade 
> agreements in which the U.S. tried to impose a specific approach to DNS Whois 
> upon small trading partners (Peru, Singapore, etc.). Those countries responded 
> by invoking their national privacy laws and saying that any whois service had to 
> comply with them. q.e.d.
> 
> Milton Mueller
> Professor, Syracuse University School of Information Studies
> XS4All Professor, Delft University of Technology
> ------------------------------
> Internet Governance Project:
> http://internetgovernance.org
> 
> 
> > -----Original Message-----
> > From: Lee Howard [mailto:spiffnolee at yahoo.com] 
> > 
> > M. Mueller said:
> > > This doctrine bears no relationship to actual law regarding 
> > privacy and freedom 
> > > of association. 
> > 
> > I am unaware of any laws describing WHOIS, but IANAL.  If 
> > there are laws in 
> > relevant jurisdictions, please cite them by number.
> > 
> > Also, it would be handy for you to disclose your legal 
> > credentials when providing
> > legal advice.
> > 
> > Lee
> > 
> > 
> > [IANAL] = I am not a lawyer.
> > 
> > 
> > 
> >      
> > 
> > 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



      



From kkargel at polartel.com  Wed Jun 10 17:25:23 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 10 Jun 2009 16:25:23 -0500
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A62@SUEX07-MBX-04.ad.syr.edu>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net><E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int><70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail><75822E125BCB994F8446858C4B19F0D77B1A7F1C@SUEX07-MBX-04.ad.syr.edu><294649.33761.qm@web63305.mail.re1.yahoo.com>
	<75822E125BCB994F8446858C4B19F0D77B220A62@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BC@mail>

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Milton L Mueller
> Sent: Wednesday, June 10, 2009 3:05 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> 
> 
> Lee,
> 1. IANAL, too
> 2. you don't need to have passed a bar exam to know that there are laws
> pertaining to privacy, or to discuss them.
> 3. i've co-authored policy papers, some in refereed journals, with legal
> professionals about dns whois, including an international comparison of
> privacy laws and their relevance to whois
> 4. privacy laws don't need to reference whois specifically to be relevant
> to whois.
> 5. some laws do specifically reference it, e.g., in the bilateral trade
> agreements in which the U.S. tried to impose a specific approach to DNS
> Whois upon small trading partners (Peru, Singapore, etc.). Those countries
> responded by invoking their national privacy laws and saying that any
> whois service had to comply with them. q.e.d.
> 


Privacy-schmivacy..  I don't care whether or not the real end user is
publically listed as a POC, but there DOES need to be a real live contact
that can handle problems for the network.  

There needs to be a functional administrative contact and a functional
technical contact.  Those contacts cannot just be someone who knows someone
who knows who to call.

If there is not going to be both an administrative and technical contact
listed that actually has something to do with the network then I suggest we
might as well abandon whois and swip entirely and just rely on registration
records. It would save a lot of work and money.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090610/c1b9ee5c/attachment.bin>

From sethm at rollernet.us  Wed Jun 10 17:48:47 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 10 Jun 2009 14:48:47 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BC@mail>
References: <4A2E5BD2.8090708@arin.net><3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com><75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu><4A2EAE43.9060702@kl.net><E7956D9775C98F4DB72321439A2F91A926302B@mail1.dulles.sv.int><70DE64CEFD6E9A4EB7FAF3A06314106601B4B2AF@mail><75822E125BCB994F8446858C4B19F0D77B1A7F1C@SUEX07-MBX-04.ad.syr.edu><294649.33761.qm@web63305.mail.re1.yahoo.com>	<75822E125BCB994F8446858C4B19F0D77B220A62@SUEX07-MBX-04.ad.syr.edu>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BC@mail>
Message-ID: <4A302A3F.7000403@rollernet.us>

Kevin Kargel wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Milton L Mueller
>> Sent: Wednesday, June 10, 2009 3:05 PM
>> To: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
>>
>>
>>
>> Lee,
>> 1. IANAL, too
>> 2. you don't need to have passed a bar exam to know that there are laws
>> pertaining to privacy, or to discuss them.
>> 3. i've co-authored policy papers, some in refereed journals, with legal
>> professionals about dns whois, including an international comparison of
>> privacy laws and their relevance to whois
>> 4. privacy laws don't need to reference whois specifically to be relevant
>> to whois.
>> 5. some laws do specifically reference it, e.g., in the bilateral trade
>> agreements in which the U.S. tried to impose a specific approach to DNS
>> Whois upon small trading partners (Peru, Singapore, etc.). Those countries
>> responded by invoking their national privacy laws and saying that any
>> whois service had to comply with them. q.e.d.
>>
> 
> 
> Privacy-schmivacy..  I don't care whether or not the real end user is
> publically listed as a POC, but there DOES need to be a real live contact
> that can handle problems for the network.  
> 
> There needs to be a functional administrative contact and a functional
> technical contact.  Those contacts cannot just be someone who knows someone
> who knows who to call.
> 
> If there is not going to be both an administrative and technical contact
> listed that actually has something to do with the network then I suggest we
> might as well abandon whois and swip entirely and just rely on registration
> records. It would save a lot of work and money.
> 

I can tell you that I'm the admin and tech POC for two networks of a
technically-inept company. Whenever I get calls about it I pretty much
tell the caller "I don't care".

I also know of a former employer who wiped all of their SWIP records (I
had once spent months reconciling them to be accurate) probably because
they had fallen out of date again and nobody wanted to do the work to
fix it.

Useful information should be the goal irrespective of privacy.

~Seth


From martin.hannigan at batelnet.bs  Wed Jun 10 18:16:32 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Wed, 10 Jun 2009 18:16:32 -0400
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
	Size
In-Reply-To: <4A2D622E.4030208@arin.net>
References: <4A2D622E.4030208@arin.net>
Message-ID: <4607e1d50906101516n7b45f06bra19a874a865083d1@mail.gmail.com>

Based on the recent discussions here I think that the language should
be modified to include reference to inventory that ARIN may hold. For
example, if someone does return a /8 and there is a need, the policy
should possibly not be in effect unless there is only "one" /8
available for allocation. I have some issues with justification time
frames as well, but interested to hear the response on the inventory
question.

Best,

Martin

On Mon, Jun 8, 2009 at 3:10 PM, Member Services<info at arin.net> wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
>
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.
>
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
>
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> 1. Policy Proposal: Predicable IPv4 Run Out by Prefix Size
>
> 2. Proposal Originator: David Farmer
>
> 3. Proposal Version: 1.0
>
> 4. Date: 8 June 2009
>
> 5. Proposal type: new
>
> 6. Policy term: permanent
>
> 7. Policy statement:
>
> Create a new subsection in section 4 of the NRPM;
>
> 4.X Maximum Allocation or Assignment during and after Run-Out
>
> When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a
> maximum allocation and assignment size will be put into effect. ?The
> maximum allocation or assignment will be the next whole CIDR prefix less
> than or equal to one quarter (1/4) of the total unrestricted IPv4
> resources available to ARIN for allocation or assignment at the time,
> but no longer than the applicable minimum allocation or assignment. ?All
> other allocation and assignment rules, requirements, or procedures apply
> in addition.
>
> If this maximum allocation or assignment provides insufficient
> resources, additional resources may be request after a three (3) month
> waiting period.
>
> This section (4.x) is applicable to allocations and assignments from
> ARIN's unrestricted IPv4 resources only, and is explicitly not
> applicable to resources received through Transfers to Specified
> Recipients per section 8.3, or any other specially designated resources.
>
> 8. Rationale:
>
> This proposal is intended to insure an equitable distribution of the
> remaining unrestricted IPv4 number resources available to ARIN once such
> resources are no longer abundantly available from IANA. ?Equity is
> achieved by insuring the available resources are spread among multiple
> entities and that no single entity may monopolize all of the resources
> available through a single request, at least until the maximum equals
> the minimum allocation or assignment size.
>
> Reducing the maximum allocation or assignment size in proportion to the
> amount of resources available should minimize, or possibly eliminate,
> the need to fulfill requests with multiple smaller blocks.
>
> Beyond providing predictability and order during the run out phase, this
> proposal provides an equitable means of distribution of resources if or
> when additional resources become available after ARIN has initially
> exhausted such resources. ?Such as if resources are returned, recovered
> by other means, or further resources are obtained from IANA.
>
> Other ratios, such as one half (1/2) or one eighth (1/8) could be
> considered. ?One eighth (1/8) would provide greater assurance of
> eliminating the need to use multiple blocks to fulfill requests and
> insure a greater number of entities receive resources. ?However, one
> eighth (1/8) is more likely to be seen as rationing and an attempt to
> artificially extend the lifetime of IPv4. ?During the ARIN XXIII policy
> discussion there seemed to be a consensus that attempts to extend the
> lifetime IPv4 resources would be undesirable. ?While on the other hand,
> one half (1/2) is less likely to ration the resources, it would likely
> result in the resource being spread across significantly fewer entities
> and increase the need to use multiple blocks to fulfill requests.
> Therefore, the ratio one quarter (1/4) is proposed as a compromise
> between competing sets of goals.
>
> 9. Timetable for implementation: ?Immediate
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From ipgoddess.arin at gmail.com  Wed Jun 10 20:07:00 2009
From: ipgoddess.arin at gmail.com (Stacy Hughes)
Date: Wed, 10 Jun 2009 17:07:00 -0700
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
	Size
In-Reply-To: <4A301B93.1040208@templin.org>
References: <4A2D622E.4030208@arin.net>, <4A2D7D39.3050702@templin.org>
	<4A2D636A.13087.F6F36CD@farmer.umn.edu>
	<4A2FD9E6.60105@templin.org> <4A300B7B.4050609@gmail.com>
	<4A301B93.1040208@templin.org>
Message-ID: <4004B797-C252-4AAF-A950-917800CC2477@gmail.com>

I agree with Pete.  The operational result will not be in line with  
the intent of the proposal.
Stacy

On Jun 10, 2009, at 1:46 PM, Pete Templin <petelists at templin.org> wrote:

> Scott Leibrand wrote:
>> Pete Templin wrote:
>>>
>>> I'm simply not following your suggestion of the numbers, which  
>>> includes looking at the spreadsheet you've provided.  I'll base my  
>>> discussions on the one quarter (1/4) ratio since that's what's  
>>> written into the Policy Proposal.
>>>
>>> Case study #1: ARIN has a /13 of space, also known as 524,288  
>>> addresses.  Four large-enough requests happen to be at the head of  
>>> the line, and based on the one-quarter ratio they're eligible for  
>>> a /15 of space per request.  Each request is issued a /15, also  
>>> known as 131,072 addresses.  These 524,288 addresses in four  
>>> allocations would wipe out the pool, not the 24 allocations that  
>>> you present above.
>> If ARIN has a /13 of space, the first large-enough request to come  
>> in could get a /15 based on a 1/4 ratio.  That would take ARIN's  
>> space down to /14+/15, meaning that the second large-enough request  
>> could get a /16.  That leaves /14+/15+16, which means the next few  
>> also get a /16.  Once the /14 gets broken up, leaving /15+16, then  
>> the next few requests can only get /17, until the /15 gets broken  
>> up, at which point it goes to /18, etc. etc. until you get to the  
>> minimum allocation size.
>
> OK, now I understand the intentions.  That said, the first paragraph  
> of the proposed policy needs a complete re-write, or at least the  
> first sentence: "When ARIN receives its last /8, by IANA  
> implementing section 10.4.2.2, a maximum allocation and assignment  
> size will be put into effect."  This needs to be completely redone  
> to reflect the dynamic nature of the ideas you're batting around.   
> Ideas like "sliding scale", "dynamic allocation/assignment size",  
> etc. come to mind.
>
> That said, I think this policy proposal leads to a highly- 
> unpredictable run-out model at a micro (i.e. per-request) level -  
> there would be essentially no way to predict how much of an  
> assignment/allocation a requester might get unless there was a  
> public status board, reports (rumors?) on mailing lists (yesterday I  
> got a /X!!!), etc.  It's predictable run-out at a macro level, but  
> quite unpredictable at a micro level.
>
> Pete
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From farmer at umn.edu  Wed Jun 10 21:38:26 2009
From: farmer at umn.edu (David Farmer)
Date: Wed, 10 Jun 2009 20:38:26 -0500
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
	Size
In-Reply-To: <4A301B93.1040208@templin.org>
References: <4A2D622E.4030208@arin.net>, <4A300B7B.4050609@gmail.com>,
	<4A301B93.1040208@templin.org>
Message-ID: <4A3019C2.27705.A110691@farmer.umn.edu>

On 10 Jun 2009 Pete Templin wrote:

> Scott Leibrand wrote:
> > Pete Templin wrote:
> >>
> >> I'm simply not following your suggestion of the numbers, which
> >> includes looking at the spreadsheet you've provided.  I'll base my
> >> discussions on the one quarter (1/4) ratio since that's what's
> >> written into the Policy Proposal.
> >>
> >> Case study #1: ARIN has a /13 of space, also known as 524,288
> >> addresses.  Four large-enough requests happen to be at the head of
> >> the line, and based on the one-quarter ratio they're eligible for a
> >> /15 of space per request.  Each request is issued a /15, also known
> >> as 131,072 addresses.  These 524,288 addresses in four allocations
> >> would wipe out the pool, not the 24 allocations that you present
> >> above.
> > 
> > If ARIN has a /13 of space, the first large-enough request to come
> > in could get a /15 based on a 1/4 ratio.  That would take ARIN's
> > space down to /14+/15, meaning that the second large-enough request
> > could get a /16.  That leaves /14+/15+16, which means the next few
> > also get a /16.  Once the /14 gets broken up, leaving /15+16, then
> > the next few requests can only get /17, until the /15 gets broken
> > up, at which point it goes to /18, etc. etc. until you get to the
> > minimum allocation size.

Yes that is the intended sequence.  I found a different problem in my spread 
sheet, I'm reworking it, once I update it the same URL should work.

> OK, now I understand the intentions.  That said, the first paragraph
> of the proposed policy needs a complete re-write, or at least the
> first sentence: "When ARIN receives its last /8, by IANA implementing
> section 10.4.2.2, a maximum allocation and assignment size will be put
> into effect."  This needs to be completely redone to reflect the
> dynamic nature of the ideas you're batting around.  Ideas like
> "sliding scale", "dynamic allocation/assignment size", etc. come to
> mind.

I thought that was clear from the second sentence "one quarter (1/4) of the 
total unrestricted IPv4 resources available to ARIN for allocation or 
assignment AT THE TIME".   But, I'm happy to clarify it, sometimes you just 
need someone else to read it, especially someone who wasn't part of the 20 
or so emails that lead up to its creation. 

"When ARIN receives its last /8, by IANA implementing section 10.4.2.2, a 
proportionally decreasing maximum allocation and assignment size will be 
put into effect.  The maximum allocation or assignment will be the next whole 
CIDR prefix less than or equal to one quarter (1/4) of the total unrestricted 
IPv4 resources available to ARIN at the time of each allocation or 
assignment, but no longer than the applicable minimum allocation or 
assignment.  All other allocation and assignment rules, requirements, or 
procedures apply in addition."

Does that rewrite of the first paragraph better communicate the intent?

If you think that is good, I'll submit that and some other grammar fixes.

> That said, I think this policy proposal leads to a
> highly-unpredictable run-out model at a micro (i.e. per-request) level
> - there would be essentially no way to predict how much of an
> assignment/allocation a requester might get unless there was a public
> status board, reports (rumors?) on mailing lists (yesterday I got a
> /X!!!), etc.  It's predictable run-out at a macro level, but quite
> unpredictable at a micro level.

Realize most requests are for the smaller blocks, so most people won't have 
this unpredictability until the very end.  What ever our run out looks like ARIN 
will probably need some kind of real-time status of what is left.

It boils down to there will be unpredictability no matter what, this proposal, 
trades some additional unpredictability in the size block you will get for more 
predictability in the availability of a block at all.  While trying to avoid rationing 
as much as possible, and ensuring there is some minimal dispersion of the 
resources.

But I agree it creates uncertainty in the size block that is available when you 
make a request, and that troubles me, but it was clear from the discussion in 
San Antonio that people really didn't like rationing.  2009-2 which basically 
gave everyone a /20 when ARIN got down to /9 didn't go over well.  With that 
proposal there was good certainty on the size of the blocks and the 
availability of blocks, but it rationed.  Whereas this proposal doesn't ration, 
has some certainty of availability of blocks, but creates uncertainty in the size 
blocks available at any moment, other than it will be going down.

A possible middle ground could to, create set of ranges of resources 
available to ARIN with associated maximum allocation or assignment size.  A 
hybrid between 2009-2 and this proposal.  

Just throwing out an idea here;

ARIN has less than a /8, but more than /11, the max is /12
ARIN has less than a /11, but more than /15, the max is /16
ARIN has less than a /15, but more than /20, the max is /20

This third option has good certainty on the size of the blocks, expect near the 
boundaries, and the availability of blocks, however it would necessitate some 
rationing.  

Is this a better option?  I'd be willing to start over with something more like 
this.

> Pete
> 



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From farmer at umn.edu  Wed Jun 10 21:46:36 2009
From: farmer at umn.edu (David Farmer)
Date: Wed, 10 Jun 2009 20:46:36 -0500
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
	Size
In-Reply-To: <4004B797-C252-4AAF-A950-917800CC2477@gmail.com>
References: <4A2D622E.4030208@arin.net>, <4A301B93.1040208@templin.org>,
	<4004B797-C252-4AAF-A950-917800CC2477@gmail.com>
Message-ID: <4A301BAC.16384.A188266@farmer.umn.edu>

On 10 Jun 2009 Stacy Hughes wrote:

> I agree with Pete.  The operational result will not be in line with 
> the intent of the proposal. Stacy

I think it is consistent with the intent of the proposal as stated in the rational.  
But, I'm not sure the title of the proposal is correct though, and probably 
should be changed if it goes to the Draft Policy stage.

Maybe the title should be "Equitable IPv4 Run Out by Prefix Size", focusing 
less on the predictability and more on equity.
 


===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From joelja at bogus.com  Thu Jun 11 02:24:52 2009
From: joelja at bogus.com (Joel Jaeggli)
Date: Wed, 10 Jun 2009 23:24:52 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A2E95D7.2090802@sprunk.org>
References: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>	<4A2E7E07.2000407@temk.in>
	<4A2E95D7.2090802@sprunk.org>
Message-ID: <4A30A334.4000002@bogus.com>



Stephen Sprunk wrote:
> Dave Temkin wrote:
>> I went the other route, as suggested by many people, and attempted to
>> submit my application as a LIR, given that we run a separate
>> transport/transit backbone from our content serving network (two
>> separate AS's, one providing transit services to the other).  I was
>> told that we don't meet section 6.5.1.4 of the NRPM -
>>
>> "be an existing, known ISP in the ARIN region or have a plan for
>> making at least 200 end-site assignments to other organizations within
>> 5 years.", however when pressed as to how 10310 or 15169 meet that
>> requirement (specifically 200 end-site assignments to other
>> organizations), I got no answer.  The reality of it is that neither
>> fit that description - Yahoo and Google provide transit services to
>> themselves only, and while they may have 200 end sites, they are
>> definitely *not* other organizations.  I do not understand why ARIN
>> management would have made exceptions for these two companies (and
>> probably many others).
> 
> IIRC, the /32s issued to end-user orgs like Yahoo, Google, Cisco, IBM,
> etc. are from well before the direct-assignment policy was adopted, and
> at that time it was apparently accepted that "really big" end users
> could claim to be LIRs.

With all due respect you're expressing an extremely superficial
understanding of how these entities and other's who recieved direct
assignments use numbering resources.

At the very least, the one that I worked with in the recent past could
trivially write an LIR justification Today just as it did in 2001.

> Now that there is a specific policy for all end
> users, though, that hole has been closed and those few prior exceptions
> have been grandfathered -- though IMHO they shouldn't be, as the legal
> situation is quite different from IPv4 legacy space and moving those
> companies into end-user blocks would also eventually put pressure on
> certain ISPs that are still choosing to filter at /32 in the /48 block...
> 
> Also, keep in mind that the maintenance fees for being an LIR are
> significantly higher than for end-user orgs; waiting a few months for
> the Multiple Discrete Networks policy may test your patience, but it's
> worth it financially.
> 
> S
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From farmer at umn.edu  Thu Jun 11 03:11:29 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 11 Jun 2009 02:11:29 -0500
Subject: [arin-ppml] Policy Proposal: Predicable IPv4 Run Out by Prefix
	Size
In-Reply-To: <4607e1d50906101516n7b45f06bra19a874a865083d1@mail.gmail.com>
References: <4A2D622E.4030208@arin.net>,
	<4607e1d50906101516n7b45f06bra19a874a865083d1@mail.gmail.com>
Message-ID: <4A3067D1.31583.F84530@farmer.umn.edu>

On 10 Jun 2009 Martin Hannigan wrote:

> Based on the recent discussions here I think that the language should
> be modified to include reference to inventory that ARIN may hold. For
> example, if someone does return a /8 and there is a need, the policy
> should possibly not be in effect unless there is only "one" /8
> available for allocation. 

In the rationale I do talk about returns, etc...  But lets dig in a little, if by some 
miracle more /8s are returned or recovered I think the policy still works fairly 
reasonably as stated.  For the sake of this discussion lets say ARIN got back 
several /8s and kept them, I'm not say that will or should happen, I'm just 
playing what-if with this policy.

ARIN's inventory of /8s is I, maximum allocation size would be M, then; 
8 > I >= 4; M = /8;
4 > I >= 2; M = /9;
2 > I >= 1; M = /10;

Even if very large inventories of IPv4 addresses were returned, the policy still 
produces what seem like reasonable limits to me.  

Even if we were to assume something completely silly like IANA were to give 
all the currently available IPv4 addresses to ARIN and implement 10.4.2.2 
today then, ARIN would have an inventory of 28 /8s or so;

32 > I >= 16; M = 4 /8s
16 > I >=  8; M = 2 /8s 

So even with crazy large inventories it seems to work ok.

If those limits really created a problem for anyone it wouldn't be that hard to 
remove the policy.

> I have some issues with justification time
> frames as well, but interested to hear the response on the inventory
> question.

What do you me by "justification time frames"?  Do you mean the other 
proposal "Predictable IPv4 Run Out by Allocation Window"?  Or, do you 
mean the that 10.4.2.2 is the trigger for this policy?

> Best,
> 
> Martin

Anyway it is getting late and crazy thoughts are running through me head like 
the Maya calendar ending on Dec 21, 2012, so IPv4 should almost last to the 
end of the world anyway.  Or even crazier, the Maya knew when we need to 
go to 128 bit addresses to start the new IPv6 world.  

(switch register overflow -  PANIC!) 

bye



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From jrhett at svcolo.com  Thu Jun 11 02:57:12 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Wed, 10 Jun 2009 23:57:12 -0700
Subject: [arin-ppml] [arin-council] Returning Legacy Space to IANA.
	Attorney client communcation.
In-Reply-To: <4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
Message-ID: <4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>

On Jun 9, 2009, at 5:49 PM, Martin Hannigan wrote:
> Most large service providers in the region don't believe we're going
> to get a fair shake in the end. Hopefully, the AC and BoT realize
> that.


Martin, I know you are clueful.    So I'm assuming that this response  
can't possibly be what it means on its face.

Can you name a large service provider in the ARIN region who doesn't  
have miles and miles (on any yardstick of your choice) of extra  
lenient space they are paying nothing for?    That the people who have  
gotten the most for free are afraid that they might lose some of that  
advantage isn't surprising.

That this could be seen as a Bad Thing surprises me.

And let's be honest, they might at most lose some miniscule amount of  
their advantage.  They certainly won't lose even 1/100th of their  
advantage, and certainly never even come close to a level playing  
field.  What do they really have to lose?   And why do you express  
this as a bad thing?

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550





From jrhett at svcolo.com  Thu Jun 11 03:01:48 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Thu, 11 Jun 2009 00:01:48 -0700
Subject: [arin-ppml] Policy Proposal: Customer Confidentiality
In-Reply-To: <00ba01c9e94f$0dd71f20$29855d60$@net>
References: <4A2E5BD2.8090708@arin.net>	
	<3c3e3fca0906090751i3de042f0i8ba77683c177329@mail.gmail.com>	
	<75822E125BCB994F8446858C4B19F0D77B220A50@SUEX07-MBX-04.ad.syr.edu>	
	<005e01c9e939$31b54220$951fc660$@net>
	<3c3e3fca0906091443w21470295g10c2a88da3338be1@mail.gmail.com>
	<00ba01c9e94f$0dd71f20$29855d60$@net>
Message-ID: <1A3F239F-D7C4-4416-9ADF-23D38C110D24@svcolo.com>

On Jun 9, 2009, at 3:10 PM, Aaron Wendel wrote:
> I do own my primary residence but searching public records will get  
> you
> nowhere.  There is no mortgage filing/interest in my house.  The  
> name on the
> property records is a trust and the original sale records show a  
> single
> dollar received in consideration for the filing of the deed.


So could any IP recipient also request those IPs through a trust and  
thus hide their name.

They can do this today, without your proposal.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550





From spiffnolee at yahoo.com  Thu Jun 11 09:26:44 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Thu, 11 Jun 2009 06:26:44 -0700 (PDT)
Subject: [arin-ppml] large vs small?
In-Reply-To: <4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
Message-ID: <624960.88403.qm@web63306.mail.re1.yahoo.com>


Jo Rhett said (in a differently-names thread):
> Can you name a large service provider in the ARIN region who doesn't have miles 
> and miles (on any yardstick of your choice) of extra lenient space they are 
> paying nothing for?    

I can't "name" them, because I'd be disclosing information that is non-public and
potentially material.
I know of two largish providers who have legacy Class A's.  I know of one large
provider who hasn't requested space in a while because they've been able to 
reclaim internally.  I know of several large providers who have used RFC1918
several times over internally, to keep from using public space.

I don't know of anyone with whom ARIN is "extra lenient."

I don't understand why people at small ISPs think people at large ISPs are
trying to set anticompetitive policies.   I can think of cases where large ISP
folks have said, "Such-and-such kind of practice would break my network,"
but I can't think of any case where large ISPs have unduly influenced the
process.

> That the people who have gotten the most for free are 
> afraid that they might lose some of that advantage isn't surprising.

I don't see any advantage.  ARIN will be unable to fill requests for /13s
before they're unable to fill requests for /20s.   I think every large ISP has
a plan for IPv6, but of course they wouldn't disclose those plans.


> And let's be honest, they might at most lose some miniscule amount of their 
> advantage.  They certainly won't lose even 1/100th of their advantage, and 
> certainly never even come close to a level playing field.  What do they really 
> have to lose?   And why do you express this as a bad thing?

In the past, I've posted analyses of who posts to PPML, by company size.
In the past 24 hours there have been many posts--but very very few from 
large ISP employees.  We've talked about who participates at meetings, and 
representation on the Board and AC.  I've looked and looked for evidence 
that the process is prejudiced toward large ISPs, and I can't find it.  Please 
support your assertion that large ISPs have an advantage.

Lee



      



From mueller at syr.edu  Thu Jun 11 10:11:42 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Thu, 11 Jun 2009 10:11:42 -0400
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <4A30A334.4000002@bogus.com>
References: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A2E7E07.2000407@temk.in>
	<4A2E95D7.2090802@sprunk.org>,<4A30A334.4000002@bogus.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B233E85@SUEX07-MBX-04.ad.syr.edu>


> Also, keep in mind that the maintenance fees for being an LIR are
> significantly higher than for end-user orgs; waiting a few months for
> the Multiple Discrete Networks policy may test your patience, but it's
> worth it financially.

Can someone explain to me what is the policy rationale for this price discrimination? and for maintaining the distinction between LIRs and end users? 
This is a real question, not a rhetorical one. 

--MM

From michael.dillon at bt.com  Thu Jun 11 11:02:52 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 11 Jun 2009 16:02:52 +0100
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B233E85@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <28E139F46D45AF49A31950F88C497458019B9F05@E03MVZ2-UKDY.domain1.systemhost.net>

> Can someone explain to me what is the policy rationale for 
> this price discrimination? and for maintaining the 
> distinction between LIRs and end users? 
> This is a real question, not a rhetorical one. 

Policy rationale? The prices are set by the members and
not by policy. I believe that the LIRs dominate the active
ARIN membership and they have preferred to keep the burden 
of the costs on themselves because they make much more use
of ARIN's services. In a sense, LIRs pay more as insurance
to see that ARIN remains a stable and functioning organization.

--Michael Dillon


From spiffnolee at yahoo.com  Thu Jun 11 11:12:33 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Thu, 11 Jun 2009 08:12:33 -0700 (PDT)
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B233E85@SUEX07-MBX-04.ad.syr.edu>
References: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A2E7E07.2000407@temk.in> <4A2E95D7.2090802@sprunk.org>,
	<4A30A334.4000002@bogus.com>
	<75822E125BCB994F8446858C4B19F0D77B233E85@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <587399.96295.qm@web63302.mail.re1.yahoo.com>


> From: Milton L Mueller <mueller at syr.edu>

>
> Can someone explain to me what is the policy rationale for this price 
> discrimination? and for maintaining the distinction between LIRs and end users? 
> This is a real question, not a rhetorical one. 

Sure.  In general, ISPs (LIRs) generate more work for ARIN, so they pay more
of the costs.  ISPs typically have more address requests, which require mre
evaluation by staff, and which are usually more complicated to evaluate.  They 
are also required to SWIP, which generates load on parsers and servers.  Their
space also generates a higher proportion of queries against ARIN's whois and
DNS servers.

The structure was created when ARIN was formed.  The Finance Committee
reviews it roughly annually, and considers alternatives consistent with their
fiduciary duty to the mission and members.  There are other models that 
would be consistent with that duty, which would be an excellent topic for
the member list (arin-discuss).

Lee


      



From owen at delong.com  Thu Jun 11 15:47:23 2009
From: owen at delong.com (Owen DeLong)
Date: Thu, 11 Jun 2009 12:47:23 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B233E85@SUEX07-MBX-04.ad.syr.edu>
References: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A2E7E07.2000407@temk.in> <4A2E95D7.2090802@sprunk.org>,
	<4A30A334.4000002@bogus.com>
	<75822E125BCB994F8446858C4B19F0D77B233E85@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <5D6C6786-4C0C-4B94-B574-0B47C9598BF5@delong.com>


On Jun 11, 2009, at 7:11 AM, Milton L Mueller wrote:

>
>> Also, keep in mind that the maintenance fees for being an LIR are
>> significantly higher than for end-user orgs; waiting a few months for
>> the Multiple Discrete Networks policy may test your patience, but  
>> it's
>> worth it financially.
>
> Can someone explain to me what is the policy rationale for this  
> price discrimination? and for maintaining the distinction between  
> LIRs and end users?
> This is a real question, not a rhetorical one.
>
In part, because ARIN fees are based on cost recovery and LIRs have  
vastly more interaction with
ARIN per IP block than do end users.  An end-user receives their  
block, and, in most cases, that's
pretty much it.  Occasionally they may come back for an additional  
block.  They pay more for initial
assignments of blocks each time, but, absent that, their interaction  
with ARIN is limited to a very
rare POC update and that's about it.

ISPs/LIRs OTOH, are constantly interacting with ARIN on a variety of  
things.  They don't pay additional
fees for additional allocations (unless they cross a size boundary at  
which point they pay the
difference between their current tier and the next tier).

Additionally, ISP/LIR organizations receive membership in ARIN as part  
of their fees (end users
do not).

Owen



From tedm at ipinc.net  Thu Jun 11 19:14:54 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Thu, 11 Jun 2009 16:14:54 -0700
Subject: [arin-ppml] large vs small?
In-Reply-To: <624960.88403.qm@web63306.mail.re1.yahoo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com>
	<m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<624960.88403.qm@web63306.mail.re1.yahoo.com>
Message-ID: <4A318FEE.9090904@ipinc.net>

Lee Howard wrote:
> Jo Rhett said (in a differently-names thread):
>> Can you name a large service provider in the ARIN region who doesn't have miles 
>> and miles (on any yardstick of your choice) of extra lenient space they are 
>> paying nothing for?    
> 
> I can't "name" them, because I'd be disclosing information that is non-public and
> potentially material.
> I know of two largish providers who have legacy Class A's.  I know of one large
> provider who hasn't requested space in a while because they've been able to 
> reclaim internally.  I know of several large providers who have used RFC1918
> several times over internally, to keep from using public space.
> 
> I don't know of anyone with whom ARIN is "extra lenient."
> 
> I don't understand why people at small ISPs think people at large ISPs are
> trying to set anticompetitive policies.   I can think of cases where large ISP
> folks have said, "Such-and-such kind of practice would break my network,"
> but I can't think of any case where large ISPs have unduly influenced the
> process.
> 

I don't think the large ISP's are trying to set anticompetitive 
practices.  I just think that they are getting a break on the pricing.

I've heard the arguments that supposedly it takes less work for ARIN to
manage large allocations than small allocations.  Then I look at the 
work that ARIN has done for us over the years on our small allocation 
(ie: nothing since originally issuing it) and I cannot understand why 
anyone would say this.  How can ARIN do negative work?  Less work than 
nothing is negative.

Cost per IP is much less for large allocations than small allocations.

I might feel differently if I had heard that ARIN was spending months
fighting with small IPv4 holders over the phone for them to release
resources.  But then I'd wonder how exactly doing this would free up
significant IPv4

When a large ISP gets an IPv4 address for less money than a small ISP
that is anticompetitive.  The only reason the community hasn't revolted 
is the expenditures work out to pennies per year per IP and people think 
that a bunch of very tiny expenditures are somehow less interesting than 
one very large expenditure.

>> That the people who have gotten the most for free are 
>> afraid that they might lose some of that advantage isn't surprising.
> 
> I don't see any advantage.  ARIN will be unable to fill requests for /13s
> before they're unable to fill requests for /20s.   I think every large ISP has
> a plan for IPv6, but of course they wouldn't disclose those plans.
> 
> 
>> And let's be honest, they might at most lose some miniscule amount of their 
>> advantage.  They certainly won't lose even 1/100th of their advantage, and 
>> certainly never even come close to a level playing field.  What do they really 
>> have to lose?   And why do you express this as a bad thing?
> 
> In the past, I've posted analyses of who posts to PPML, by company size.
> In the past 24 hours there have been many posts--but very very few from 
> large ISP employees.  We've talked about who participates at meetings, and 
> representation on the Board and AC.  I've looked and looked for evidence 
> that the process is prejudiced toward large ISPs, and I can't find it.  Please 
> support your assertion that large ISPs have an advantage.
> 

I'd assume large ISP's don't participate because any of their technical
people who understand the issues are under orders to say nothing 
publically without vetting it with a company lawyer.  That's one reason 
I don't work for a large company, frankly.

I do think it's a mistake to assume the large ISP's aren't paying 
attention to what goes on here.  I'm sure if we did something that hurt 
them you would suddenly find out how much they would participate.

That's probably why fees are not under the control of this list. ;-)

Ted


From martin.hannigan at batelnet.bs  Thu Jun 11 20:27:48 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Thu, 11 Jun 2009 20:27:48 -0400
Subject: [arin-ppml] [arin-council] Returning Legacy Space to IANA.
	Attorney client communcation.
In-Reply-To: <4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
Message-ID: <4607e1d50906111727l66f41e83o9afbe21ae4177a0e@mail.gmail.com>

On Thu, Jun 11, 2009 at 2:57 AM, Jo Rhett<jrhett at svcolo.com> wrote:
> On Jun 9, 2009, at 5:49 PM, Martin Hannigan wrote:
>>
>> Most large service providers in the region don't believe we're going
>> to get a fair shake in the end. Hopefully, the AC and BoT realize
>> that.
>
>
> Martin, I know you are clueful. ? ?So I'm assuming that this response can't
> possibly be what it means on its face.
>
> Can you name a large service provider in the ARIN region who doesn't have
> miles and miles (on any yardstick of your choice) of extra lenient space
> they are paying nothing for? ? ?That the people who have gotten the most for
> free are afraid that they might lose some of that advantage isn't
> surprising.

You think someone who has and is using a /8 is stressing over the $18K
yearly fee? Cost is probably the least interesting argument.

I can't define excess space because I don't know the specifics as to
why space that someone may have isn't being utilized. Wearing
sunglasses at night blinds you to most everything around you except
the bright lights and here we have what appears to be excess space as
that light.

>
> That this could be seen as a Bad Thing surprises me.

See 2009-3 thread. There were some fairly interesting fairness
comments that are relevant to the participants in this region.

>
> And let's be honest, they might at most lose some miniscule amount of their
> advantage. ?They certainly won't lose even 1/100th of their advantage, and
> certainly never even come close to a level playing field. ?What do they
> really have to lose? ? And why do you express this as a bad thing?
>

It's not about advantage until the allocation policies become slanted
towards percentages of fulfillment. If my competitors can fulfill 100%
of their needs and I can only fill 10%, that's not fair. I don't know
how anyone thinks it could be fair. If I'm being obtuse, I apologize.


From mueller at syr.edu  Fri Jun 12 01:15:36 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 12 Jun 2009 01:15:36 -0400
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <587399.96295.qm@web63302.mail.re1.yahoo.com>
References: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A2E7E07.2000407@temk.in> <4A2E95D7.2090802@sprunk.org>,
	<4A30A334.4000002@bogus.com>
	<75822E125BCB994F8446858C4B19F0D77B233E85@SUEX07-MBX-04.ad.syr.edu>
	<587399.96295.qm@web63302.mail.re1.yahoo.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A7FCF@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Sure.  In general, ISPs (LIRs) generate more work for ARIN, so they pay
> more of the costs.  

Got it, thanks. Will this still hold true with the large IPv6 allocations? 

 


From info at arin.net  Fri Jun 12 10:47:34 2009
From: info at arin.net (Member Services)
Date: Fri, 12 Jun 2009 10:47:34 -0400
Subject: [arin-ppml] Policy Proposal: Transfer listing service
Message-ID: <4A326A86.8060004@arin.net>

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with Policy Development
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does
not evaluate the proposal at this time, their goal is to make sure that
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within
10 days.

The AC will review the proposal at their next regularly scheduled
meeting (if the period before the next regularly scheduled meeting is
less than 10 days, then the period may be extended to the subsequent
regularly scheduled meeting). The AC will decide how to utilize the
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at:https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

1. Policy Proposal Name: Transfer listing service

2. Proposal Originator: Scott Leibrand       

3. Proposal Version: 1.0

4. Date: 6/11/2009

5. Proposal type: new    

6. Policy term: permanent

7. Policy statement:

 Add new subsection 8.3.1:

  8.3.1  Listing service

  ARIN will develop and operate a listing service to provide a
  Centralized location to post information about IPv4 blocks available from
  Authorized resource holders and IPv4 blocks needed by potential transfer
  recipients. Participation in the listing service is voluntary.

8. Rationale:

   The proposal would have ARIN develop and operate a listing service
   to facilitate transfers and provide an authoritative central source 
of information
   on space available and requested for transfer. It would still allow 
private party
   transactions, but would encourage both parties to begin working with 
ARIN
   in advance, which will cut down on any surprises when they ask ARIN 
to process
   the transfer.
 
   ARIN staff has indicated that they do not intend to provide a listing 
service as a part
   of their implementation of the 2009-1 transfer policy, but could do 
so if directed by additional policy.

9. Timetable for implementation: Immediate (as soon as practical).











From kkargel at polartel.com  Fri Jun 12 11:34:07 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 12 Jun 2009 10:34:07 -0500
Subject: [arin-ppml] Policy Proposal: Transfer listing service
In-Reply-To: <4A326A86.8060004@arin.net>
References: <4A326A86.8060004@arin.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BD@mail>

A listing service will not be a trivial implementation.  How are you
proposing we fund and staff it?


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Member Services
> Sent: Friday, June 12, 2009 9:48 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal: Transfer listing service
> 
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.
> 
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> ## * ##
> 
> 1. Policy Proposal Name: Transfer listing service
> 
> 2. Proposal Originator: Scott Leibrand
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 6/11/2009
> 
> 5. Proposal type: new
> 
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
>  Add new subsection 8.3.1:
> 
>   8.3.1  Listing service
> 
>   ARIN will develop and operate a listing service to provide a
>   Centralized location to post information about IPv4 blocks available
> from
>   Authorized resource holders and IPv4 blocks needed by potential transfer
>   recipients. Participation in the listing service is voluntary.
> 
> 8. Rationale:
> 
>    The proposal would have ARIN develop and operate a listing service
>    to facilitate transfers and provide an authoritative central source
> of information
>    on space available and requested for transfer. It would still allow
> private party
>    transactions, but would encourage both parties to begin working with
> ARIN
>    in advance, which will cut down on any surprises when they ask ARIN
> to process
>    the transfer.
> 
>    ARIN staff has indicated that they do not intend to provide a listing
> service as a part
>    of their implementation of the 2009-1 transfer policy, but could do
> so if directed by additional policy.
> 
> 9. Timetable for implementation: Immediate (as soon as practical).
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090612/5a2f3e54/attachment.bin>

From michael.dillon at bt.com  Fri Jun 12 11:57:49 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 12 Jun 2009 16:57:49 +0100
Subject: [arin-ppml] [arin-announce] Policy Proposal: Transfer listing
	service
In-Reply-To: <4A326B3A.6000406@arin.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>

>  ARIN will develop and operate ...

This seems to have nothing to do with policy.

The suggestion box is thataway
<https://www.arin.net/participate/acsp/index.html>

--Michael Dillon

P.S. I would not like to see ARIN get involved in market making.


From scottleibrand at gmail.com  Fri Jun 12 12:09:15 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 12 Jun 2009 09:09:15 -0700
Subject: [arin-ppml] [arin-announce] Policy Proposal: Transfer listing
	service
In-Reply-To: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>

That might work too, but ARIN counsel, the AC, and others involved  
thought it belonged in the 2008-2 transfer policy, and the CEO has  
said they don't plan to do a listing service without policy directing  
them to do so.

What do you think of the idea itself?

-Scott

On Jun 12, 2009, at 8:57 AM, <michael.dillon at bt.com> wrote:

>> ARIN will develop and operate ...
>
> This seems to have nothing to do with policy.
>
> The suggestion box is thataway
> <https://www.arin.net/participate/acsp/index.html>
>
> --Michael Dillon
>
> P.S. I would not like to see ARIN get involved in market making.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From kkargel at polartel.com  Fri Jun 12 12:24:58 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 12 Jun 2009 11:24:58 -0500
Subject: [arin-ppml] [arin-announce] Policy Proposal: Transfer
	listingservice
In-Reply-To: <508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>
	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BE@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Scott Leibrand
> Sent: Friday, June 12, 2009 11:09 AM
> To: <michael.dillon at bt.com>
> Cc: <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
> listingservice
> 
> That might work too, but ARIN counsel, the AC, and others involved
> thought it belonged in the 2008-2 transfer policy, and the CEO has
> said they don't plan to do a listing service without policy directing
> them to do so.
> 
> What do you think of the idea itself?

Personally I do not want to see ARIN getting in to the broker business,
which is directly where a listing service is heading.  If we take this
initial step we might as well go ahead and fire up IP-Bay ..  

Once ARIN gets involved in this it will be a pandora's box of regulations,
litigations, tax accounting --  all sorts of odious stuff..  and that's just
in the US..  my poor brain can't even start to comprehend the international
implications.


> 
> -Scott
> 
> On Jun 12, 2009, at 8:57 AM, <michael.dillon at bt.com> wrote:
> 
> >> ARIN will develop and operate ...
> >
> > This seems to have nothing to do with policy.
> >
> > The suggestion box is thataway
> > <https://www.arin.net/participate/acsp/index.html>
> >
> > --Michael Dillon
> >
> > P.S. I would not like to see ARIN get involved in market making.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090612/aad8bcd1/attachment.bin>

From kkargel at polartel.com  Fri Jun 12 12:28:14 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 12 Jun 2009 11:28:14 -0500
Subject: [arin-ppml] [arin-announce] Policy Proposal: Transfer
	listingservice
In-Reply-To: <508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>
	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BF@mail>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Scott Leibrand
> Sent: Friday, June 12, 2009 11:09 AM
> To: <michael.dillon at bt.com>
> Cc: <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
> listingservice
> 
> That might work too, but ARIN counsel, the AC, and others involved
> thought it belonged in the 2008-2 transfer policy, and the CEO has
> said they don't plan to do a listing service without policy directing
> them to do so.
> 
> What do you think of the idea itself?
> 
> -Scott
> 

I probably should have mentioned that it is a nifty idea if it was just us
NetOps working with each other and the lawyers and governments would keep
out of it.  I just don't see much hope that the litigators and regulators
will keep their fingers out of the pie.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090612/57ba154c/attachment.bin>

From tvest at pch.net  Fri Jun 12 13:13:21 2009
From: tvest at pch.net (Tom Vest)
Date: Fri, 12 Jun 2009 13:13:21 -0400
Subject: [arin-ppml] [arin-announce] Policy Proposal: Transfer
	listingservice
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BF@mail>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>
	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BF@mail>
Message-ID: <48B27EA6-74E9-4B6E-8761-BF6798491025@pch.net>


On Jun 12, 2009, at 12:28 PM, Kevin Kargel wrote:

>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- 
>> bounces at arin.net] On
>> Behalf Of Scott Leibrand
>> Sent: Friday, June 12, 2009 11:09 AM
>> To: <michael.dillon at bt.com>
>> Cc: <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
>> listingservice
>>
>> That might work too, but ARIN counsel, the AC, and others involved
>> thought it belonged in the 2008-2 transfer policy, and the CEO has
>> said they don't plan to do a listing service without policy directing
>> them to do so.
>>
>> What do you think of the idea itself?
>>
>> -Scott
>>
>
> I probably should have mentioned that it is a nifty idea if it was  
> just us
> NetOps working with each other and the lawyers and governments would  
> keep
> out of it.  I just don't see much hope that the litigators and  
> regulators
> will keep their fingers out of the pie.

Hi Kevin,

Out of curiosity, do you think that litigators and regulators are more  
likely (or maybe very likely) to keep their fingers out if, after  
enabling the emergence of commercial IPv4 transfers, the RIRs take no  
further actions of any kind related to any IPv4 markets that emerge  
thereafter? Are your views on that probability-of-intervention  
question based on any particular expectation about whether and how  
IPv4 markets will actually work, or are they independent of all such  
expectations (i.e., no matter how things turn out, it would be better  
in all cases for the RIRs to take no position / no action at all)?

TV 


From Fred.Wettling at Bechtel.com  Fri Jun 12 13:05:17 2009
From: Fred.Wettling at Bechtel.com (Wettling, Fred)
Date: Fri, 12 Jun 2009 13:05:17 -0400
Subject: [arin-ppml] Call for Community Consultation - ARIN's DNSSEC
	Deployment Plan
In-Reply-To: <1C40CB80-0D1A-4249-AFB6-C67C0A17EF65@delong.com>
References: <4A24158A.4070305@arin.net>
	<1C40CB80-0D1A-4249-AFB6-C67C0A17EF65@delong.com>
Message-ID: <F6EF0617A25EBB43BFB93175FBB913F9667FC8@ASHS00094.amers.ibechtel.com>

On Jun 1, 2009, at 10:53 AM, Member Services wrote:
ARIN has published a proposed plan for DNSSEC deployment and is seeking
community review and comment. The document is available at
https://www.arin.net/about_us/dnssec/

On June 3, 2009 at 4:46 PM, Owen DeLong wrote:
I would strongly encourage ARIN to work with ICANN/IANA to get the in-
addr.arpa and ip6.arpa TLDs signed and obtain a proper subordinate
key/certificate for signing the ARIN zones within those spaces.

It is utterly absurd that the RIRs and ICANN (a mere 6 bodies) cannot
resolve such a trivial issue amongst themselves.

Any signing of in-addr.arpa should also be made available to ip6.arpa at the
same time.

--------------------------------
Reply from Fred Wettling
DNS security is not just and IPv4 issue. I fully agree with Owen's comments
in engaging the RIRs and ICANN on the IPv6 implementation requirements for
DNSSEC.  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6040 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090612/8bb8cd16/attachment.bin>

From jrhett at svcolo.com  Fri Jun 12 13:23:42 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Fri, 12 Jun 2009 10:23:42 -0700
Subject: [arin-ppml] large vs small?
In-Reply-To: <624960.88403.qm@web63306.mail.re1.yahoo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<624960.88403.qm@web63306.mail.re1.yahoo.com>
Message-ID: <E43BE48B-C85C-44E7-A334-463136DCFD81@svcolo.com>

On Jun 11, 2009, at 6:26 AM, Lee Howard wrote:
> I don't understand why people at small ISPs think people at large  
> ISPs are
> trying to set anticompetitive policies.   I can think of cases where  
> large ISP
> ....
> I've looked and looked for evidence
> that the process is prejudiced toward large ISPs, and I can't find  
> it.  Please
> support your assertion that large ISPs have an advantage.


Hi, Lee.   This is kindof funny in that you are making my point for  
me.  You quoted everything I said, but failed to quote what I was  
responding to -- which was Martin's assertion that large providers  
aren't getting a fair shake ;-)

I was likewise arguing that there's no prejudice *against* large  
providers -- and that the only thing that might happen is that they no  
longer continue to have the extra lenient rules that were applied to  
pre-ARIN allocations as their working standard.  And I just don't see  
them losing that as something we as a community should waste many  
tears on.

There is something where ARIN is biased towards large and against  
small, but it wasn't in this thread and I'll address it separately  
sometime for amusement, to watch all the providers with legacy space  
come out and cry a trail of tears over their "Rights" ;-)

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550





From info at arin.net  Fri Jun 12 13:26:53 2009
From: info at arin.net (Member Services)
Date: Fri, 12 Jun 2009 13:26:53 -0400
Subject: [arin-ppml] Polciy Proposal: Waiting list for unmet IPv4 requests
Message-ID: <4A328FDD.5010504@arin.net>

ARIN received the following policy proposal and is posting it to the 
Public Policy Mailing List (PPML) in accordance with Policy Development 
Process.

This proposal is in the first stage of the Policy Development Process.
ARIN staff will perform the Clarity and Understanding step. Staff does 
not evaluate the proposal at this time, their goal is to make sure that 
they understand the proposal and believe the community will as well.
Staff will report their results to the ARIN Advisory Council (AC) within 
10 days.

The AC will review the proposal at their next regularly scheduled 
meeting (if the period before the next regularly scheduled meeting is 
less than 10 days, then the period may be extended to the subsequent 
regularly scheduled meeting). The AC will decide how to utilize the 
proposal and announce the decision to the PPML.

In the meantime, the AC invites everyone to comment on the proposal on 
the PPML, particularly their support or non-support and the reasoning 
behind their opinion. Such participation contributes to a thorough 
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)

## * ##

1. Policy Proposal Name: Waiting list for unmet IPv4 requests

2. Proposal Originator: Scott Leibrand

3. Proposal Version: 1.0

4. Date: 6/11/2009

5. Proposal type: new    

6. Policy term: permanent     

7. Policy statement:
 
Replace 4.1.6 with:

4.1.6. Aggregation

In order to preserve aggregation, ARIN issues blocks of addresses on
appropriate "CIDR-supported" bit boundaries. 
ARIN will make all allocations and assignments as a single continuous 
range of addresses.

Add new section 4.1.8:

4.1.8 Unmet requests

In the event that ARIN does not have a contiguous block of addresses of 
sufficient size to fulfill a qualified request, ARIN will provide the 
requesting organization with the option to either modify their request 
and request a smaller size block, or be placed on a waiting list of 
pre-qualified recipients.  Repeated requests, in a manner that would 
circumvent 4.1.6, are not allowed. Qualified requesters whose request 
cannot be immediately met will also be advised of the availability of 
the transfer mechanism in section 8.3 as an alternative mechanism to 
obtain IPv4 addresses.

4.1.8.1 Waiting list

The position of each qualified request on the waiting list will be 
determined by the date it was approved. ARIN may provide a validity 
duration on each qualification, in which case the requester may renew 
their request  prior to its expiration to preserve their position on the 
waiting list.  Each organization may have one approved request on the 
waiting list at a time.  Any requests met through a transfer will be 
removed from the waiting list.

4.1.8.2 Fulfilling unmet needs

As address blocks become available for allocation, ARIN will fulfill 
requests on a first-approved basis, subject to the size of each 
available address block.  Requests will not be partially filled.

8. Rationale:

ARIN will soon be unable to meet all approved requests for IPv4 address 
space.  In the absence of a policy like this, it is unclear what ARIN 
should do with subsequent requests.

This policy would allocate reclaimed address blocks (and the last of the 
ARIN free pool) on a first-come-first-served basis, while preserving 
aggregation to the degree possible.  As the free pool shrinks, requests 
larger than the largest block left would  be placed on a waiting list, 
while smaller requests would use up the rest of it, until all requests 
have to go on the waiting list. As additional reclaimed addresses become 
available, the requests that have been waiting the longest would be met 
first.  If a requester gets the addresses they need via transfer, then 
they would be removed from the waiting list and would need to wait and 
submit a new request for additional address space, either directly or 
via transfer.

This policy does not attempt to ration addresses, define maximum 
allocations, or otherwise manage how much address space any given 
organization may request.  As such, it is completely independent of any 
"Predictable IPv4 Run Out" proposals.

9. Timetable for implementation: Immediate.






From jrhett at svcolo.com  Fri Jun 12 13:39:15 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Fri, 12 Jun 2009 10:39:15 -0700
Subject: [arin-ppml] [arin-council] Returning Legacy Space to IANA.
	Attorney client communcation.
In-Reply-To: <4607e1d50906111727l66f41e83o9afbe21ae4177a0e@mail.gmail.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<4607e1d50906111727l66f41e83o9afbe21ae4177a0e@mail.gmail.com>
Message-ID: <313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>

On Jun 11, 2009, at 5:27 PM, Martin Hannigan wrote:

>> On Jun 9, 2009, at 5:49 PM, Martin Hannigan wrote:
>>> Most large service providers in the region don't believe we're going
>>> to get a fair shake in the end. Hopefully, the AC and BoT realize
>>> that.
>>

> On Thu, Jun 11, 2009 at 2:57 AM, Jo Rhett<jrhett at svcolo.com> wrote:
>> Martin, I know you are clueful.    So I'm assuming that this  
>> response can't
>> possibly be what it means on its face.
>>
>> Can you name a large service provider in the ARIN region who  
>> doesn't have
>> miles and miles (on any yardstick of your choice) of extra lenient  
>> space
>> they are paying nothing for?    That the people who have gotten the  
>> most for
>> free are afraid that they might lose some of that advantage isn't
>> surprising.
>
> You think someone who has and is using a /8 is stressing over the $18K
> yearly fee? Cost is probably the least interesting argument.

I wasn't thinking of cost, so yes I agree.

> I can't define excess space because I don't know the specifics as to
> why space that someone may have isn't being utilized. Wearing
> sunglasses at night blinds you to most everything around you except
> the bright lights and here we have what appears to be excess space as
> that light.

Leaving the direct insult aside, it appears you are trying to say that  
I don't know what the problem they fear is.  Yes, that is true.  Could  
you skip the insult and instead be specific about what these providers  
don't think they are getting a fair shake on?

>> That this could be seen as a Bad Thing surprises me.
>
> See 2009-3 thread. There were some fairly interesting fairness
> comments that are relevant to the participants in this region.

I have looked in several threaded archives and it's not clear to me  
what the issue is.  Could you explain or provide a specific pointer?

> It's not about advantage until the allocation policies become slanted
> towards percentages of fulfillment. If my competitors can fulfill 100%
> of their needs and I can only fill 10%, that's not fair. I don't know
> how anyone thinks it could be fair. If I'm being obtuse, I apologize.


There are lots of benchmarks for fairness.  I believe the large  
providers have good ground in IPv6 rollout, most specifically that  
they can absolutely prevent the small providers from using IPv6  
effectively until the large providers do.   Since the large providers  
are holding the strings the small providers dance on... let's talk  
about fair?  There's nothing fair there.

And honestly, I am looking forward with pleasure to the day when  
providers with legions of legacy space run out.  Why?  Because I'm  
sick and SICK AND SICK of refusing IP allocation requests that have  
insufficient justification, only to have the customer complain through  
management that I'm not doing my job, and offer as proof that Cogent  
or someone else gave them a /24 just for asking, no justification  
required.  (note that these are never "almost" cases -- this is  
usually someone with a half cabinet and 3 hosts in it, etc)

You want fairness?  Let's make the environment truly fair:  before  
Cogent or any other provider with legacy space can get any more  
allocations, they have to demonstrate 80% usage of ALL of their space,  
including all legacy blocks.  *THAT* would be fair.  But we both know  
that ARIN has no stomach for this, and it won't happen.   Fair?  No.   
Certainly a large provider advantage.

So yeah, Martin -- I'm just not seeing anything at all that really  
hurts large providers.   The only thing I could maybe see is that  
large providers hit the wall first, and frankly even if none of these  
policies pass they're going to hit the wall first anyway.

Now if they went and applied strict ARIN allocation policy to ALL of  
their space, I'll bet they have years of space already in their  
possession...

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550





From tedm at ipinc.net  Fri Jun 12 13:50:20 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 12 Jun 2009 10:50:20 -0700
Subject: [arin-ppml] [Fwd: Re: [arin-announce] Policy Proposal: Waiting list
 for unmet IPv4 requests]
Message-ID: <4A32955C.8050205@ipinc.net>



I'm sorry to report that I'm against this proposal as written.

I like the idea of a waiting list, and I had assumed ARIN would
do this post-IPv4 runout.

However, I feel that if the number resources become available
more than 3 months AFTER the date of the initial request, that
the waiting org must be re-qualified.

They should be allows to "keep their place in line" but they should
not be allowed to qualify then keep the qualification as good for
an indefinite period.

Keep in mind that once ARIN issues a qualification to an org,
that qualification becomes an asset.  Supposing for example the
ISP is purchased by another ISP with adequate IPv4.  Why should
they be able to get even more?

Or, if you think that scenario is unlikely, then suppose the
ISP puts in a IPv4 request, is denied, goes on the waiting list,
then 3 months later executes a "private buy" with another org
for a directed IPv4 transfer, and gets more numbers.  Then, 3
months after that, IPv4 becomes available for the next org up
on the wait list, and this ISP is the next in line.

They no longer meet utilization requirements because they paid
money out for the directed transfer 3 months earlier - but since
they are prequalifed on the wait list, they can now get even more
IPv4 under the rules.  Which of course they are going to want to
do so they can turn around and "sell it" on the open market - to
cover their cost from 3 months earlier of paying for IPv4 on the
transfer market.

If the proposal was rewritten to force re qualification I'd probably
support it.

Ted


Member Services wrote:
> Please be advised that the following policy proposal has been posted to 
> the ARIN Public Policy Mailing List. All discussion of the proposal must 
> take place on the PPML
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> ## * ##
> 1. Policy Proposal Name: Waiting list for unmet IPv4 requests
> 
> 2. Proposal Originator: Scott Leibrand
> 
> 3. Proposal Version: 1.0
> 
> 4. Date: 6/11/2009
> 
> 5. Proposal type: new   
> 6. Policy term: permanent    
> 7. Policy statement:
> 
> Replace 4.1.6 with:
> 
> 4.1.6. Aggregation
> 
> In order to preserve aggregation, ARIN issues blocks of addresses on
> appropriate "CIDR-supported" bit boundaries. ARIN will make all 
> allocations and assignments as a single continuous range of addresses.
> 
> Add new section 4.1.8:
> 
> 4.1.8 Unmet requests
> 
> In the event that ARIN does not have a contiguous block of addresses of 
> sufficient size to fulfill a qualified request, ARIN will provide the 
> requesting organization with the option to either modify their request 
> and request a smaller size block, or be placed on a waiting list of 
> pre-qualified recipients.  Repeated requests, in a manner that would 
> circumvent 4.1.6, are not allowed. Qualified requesters whose request 
> cannot be immediately met will also be advised of the availability of 
> the transfer mechanism in section 8.3 as an alternative mechanism to 
> obtain IPv4 addresses.
> 
> 4.1.8.1 Waiting list
> 
> The position of each qualified request on the waiting list will be 
> determined by the date it was approved. ARIN may provide a validity 
> duration on each qualification, in which case the requester may renew 
> their request  prior to its expiration to preserve their position on the 
> waiting list.  Each organization may have one approved request on the 
> waiting list at a time.  Any requests met through a transfer will be 
> removed from the waiting list.
> 
> 4.1.8.2 Fulfilling unmet needs
> 
> As address blocks become available for allocation, ARIN will fulfill 
> requests on a first-approved basis, subject to the size of each 
> available address block.  Requests will not be partially filled.
> 
> 8. Rationale:
> 
> ARIN will soon be unable to meet all approved requests for IPv4 address 
> space.  In the absence of a policy like this, it is unclear what ARIN 
> should do with subsequent requests.
> 
> This policy would allocate reclaimed address blocks (and the last of the 
> ARIN free pool) on a first-come-first-served basis, while preserving 
> aggregation to the degree possible.  As the free pool shrinks, requests 
> larger than the largest block left would  be placed on a waiting list, 
> while smaller requests would use up the rest of it, until all requests 
> have to go on the waiting list. As additional reclaimed addresses become 
> available, the requests that have been waiting the longest would be met 
> first.  If a requester gets the addresses they need via transfer, then 
> they would be removed from the waiting list and would need to wait and 
> submit a new request for additional address space, either directly or 
> via transfer.
> 
> This policy does not attempt to ration addresses, define maximum 
> allocations, or otherwise manage how much address space any given 
> organization may request.  As such, it is completely independent of any 
> "Predictable IPv4 Run Out" proposals.
> 
> 9. Timetable for implementation: Immediate.
> 
> 
> 
> 
> _______________________________________________
> ARIN-Announce
> You are receiving this message because you are subscribed to
> the ARIN Announce Mailing List (ARIN-announce at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-announce
> Please contact info at arin.net if you experience any issues.




From tedm at ipinc.net  Fri Jun 12 14:04:53 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 12 Jun 2009 11:04:53 -0700
Subject: [arin-ppml] Policy Proposal: Transfer listing service
In-Reply-To: <4A326A86.8060004@arin.net>
References: <4A326A86.8060004@arin.net>
Message-ID: <4A3298C5.7040007@ipinc.net>


We (my org) oppose this.

I would strongly encourage the proposal author to register the
domain name
"scotts-ipv4-list.org and setup a wiki on it, or maybe beg
craigslist.org for a copy of their software.  If he can get
this online now, and make it free, word-of-mouth should publicize
it and make it the de-facto "free IPv4 block listing service"

I strongly feel that such a free, voluntary, listing service
SHOULD exist for ipv4.  However, the Internet has a long history of
individuals seeing a need then filling a need, and this need
is EXACTLY the kind of thing that can be easily filled by
someone operating a server out of their garage.

As long as there's no erotic section on it, it should
be able to avoid the problems craigslist has run into. ;-)

 From a policy perspective, if ARIN is to get involved in
transfers they need to get fully involved, which means for
starters creating policy that prohibits 3rd party brokers and
speculators, then ARIN needs to setup a mechanism to fill that
role.  However, unless these transfers would be needed for the
good of the entire Internet, ARIN has no business spending
funding of ALL ARIN members, including those proceeding full
speed ahead on IPv6 deployments, to support a small minority
of ISP's who will be satisfied with IPv4 from a transfer market.

Ted

Member Services wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with Policy Development
> Process.
> 
> This proposal is in the first stage of the Policy Development Process.
> ARIN staff will perform the Clarity and Understanding step. Staff does
> not evaluate the proposal at this time, their goal is to make sure that
> they understand the proposal and believe the community will as well.
> Staff will report their results to the ARIN Advisory Council (AC) within
> 10 days.
> 
> The AC will review the proposal at their next regularly scheduled
> meeting (if the period before the next regularly scheduled meeting is
> less than 10 days, then the period may be extended to the subsequent
> regularly scheduled meeting). The AC will decide how to utilize the
> proposal and announce the decision to the PPML.
> 
> In the meantime, the AC invites everyone to comment on the proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Mailing list subscription information can be found
> at:https://www.arin.net/mailing_lists/
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> ## * ##
> 
> 1. Policy Proposal Name: Transfer listing service
> 
> 2. Proposal Originator: Scott Leibrand      
> 3. Proposal Version: 1.0
> 
> 4. Date: 6/11/2009
> 
> 5. Proposal type: new   
> 6. Policy term: permanent
> 
> 7. Policy statement:
> 
> Add new subsection 8.3.1:
> 
>  8.3.1  Listing service
> 
>  ARIN will develop and operate a listing service to provide a
>  Centralized location to post information about IPv4 blocks available from
>  Authorized resource holders and IPv4 blocks needed by potential transfer
>  recipients. Participation in the listing service is voluntary.
> 
> 8. Rationale:
> 
>   The proposal would have ARIN develop and operate a listing service
>   to facilitate transfers and provide an authoritative central source of 
> information
>   on space available and requested for transfer. It would still allow 
> private party
>   transactions, but would encourage both parties to begin working with ARIN
>   in advance, which will cut down on any surprises when they ask ARIN to 
> process
>   the transfer.
> 
>   ARIN staff has indicated that they do not intend to provide a listing 
> service as a part
>   of their implementation of the 2009-1 transfer policy, but could do so 
> if directed by additional policy.
> 
> 9. Timetable for implementation: Immediate (as soon as practical).
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From scottleibrand at gmail.com  Fri Jun 12 14:16:51 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 12 Jun 2009 11:16:51 -0700
Subject: [arin-ppml] Efficient use of legacy space required when applying
 for additional space
In-Reply-To: <313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com>
	<m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>	<4607e1d50906111727l66f41e83o9afbe21ae4177a0e@mail.gmail.com>
	<313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
Message-ID: <4A329B93.4080801@gmail.com>

Jo Rhett wrote:
> Let's make the environment truly fair:  before ... any ... provider 
> with legacy space can get any more allocations, they have to 
> demonstrate 80% usage of ALL of their space, including all legacy 
> blocks.  *THAT* would be fair.

Jo,

As I read the policy manual 
(https://www.arin.net/policy/nrpm.html#four24 for example), it already 
requires that "ISPs must have efficiently utilized all previous 
allocations and at least 80% of their most recent allocation in order to 
receive additional space. This includes all space reassigned to their 
customers"

Do you feel this isn't strict enough?  Is there another hole in the 
policy that allows ISPs with legacy space to get around this requirement?

Recently other RIRs have adopted similar policies, such as APNIC's 
recently-adopted prop-066 
(http://www.apnic.net/__data/assets/text_file/0004/7870/prop-066-v004.txt), 
noting that "ARIN and LACNIC always ask for utilisation for all previous 
allocations and assignments, including all legacy holdings."  A similar 
proposal is pending in RIPE, 2008-07 
(http://www.ripe.net/ripe/policies/proposals/2008-07.html).

> But we both know that ARIN has no stomach for this, and it won't happen.  

If there is a deficiency in policy here, I think there actually would be 
consensus to level the playing field further. 

-Scott


From jrhett at svcolo.com  Fri Jun 12 14:24:57 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Fri, 12 Jun 2009 11:24:57 -0700
Subject: [arin-ppml] Efficient use of legacy space required when
	applying for additional space
In-Reply-To: <4A329B93.4080801@gmail.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com>
	<m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>	<4607e1d50906111727l66f41e83o9afbe21ae4177a0e@mail.gmail.com>
	<313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
	<4A329B93.4080801@gmail.com>
Message-ID: <2D358C0D-3819-4619-B041-7E20509BBD4A@svcolo.com>

On Jun 12, 2009, at 11:16 AM, Scott Leibrand wrote:
> Jo Rhett wrote:
>> Let's make the environment truly fair:  before ... any ... provider  
>> with legacy space can get any more allocations, they have to  
>> demonstrate 80% usage of ALL of their space, including all legacy  
>> blocks.  *THAT* would be fair.
>
> Jo,
>
> As I read the policy manual (https://www.arin.net/policy/nrpm.html#four24 
>  for example), it already requires that "ISPs must have efficiently  
> utilized all previous allocations and at least 80% of their most  
> recent allocation in order to receive additional space. This  
> includes all space reassigned to their customers"
>
> Do you feel this isn't strict enough?  Is there another hole in the  
> policy that allows ISPs with legacy space to get around this  
> requirement?


There must be.  It's only providers with large legacy blocks who can  
piss away IPv4 /24s like that...

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550





From scottleibrand at gmail.com  Fri Jun 12 14:33:15 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 12 Jun 2009 11:33:15 -0700
Subject: [arin-ppml] Efficient use of legacy space required when
 applying for additional space
In-Reply-To: <2D358C0D-3819-4619-B041-7E20509BBD4A@svcolo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com>
	<m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>	<4607e1d50906111727l66f41e83o9afbe21ae4177a0e@mail.gmail.com>
	<313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
	<4A329B93.4080801@gmail.com>
	<2D358C0D-3819-4619-B041-7E20509BBD4A@svcolo.com>
Message-ID: <4A329F6B.40002@gmail.com>

Jo Rhett wrote:
> On Jun 12, 2009, at 11:16 AM, Scott Leibrand wrote:
>> Jo Rhett wrote:
>>> Let's make the environment truly fair:  before ... any ... provider 
>>> with legacy space can get any more allocations, they have to 
>>> demonstrate 80% usage of ALL of their space, including all legacy 
>>> blocks.  *THAT* would be fair.
>>
>> Jo,
>>
>> As I read the policy manual 
>> (https://www.arin.net/policy/nrpm.html#four24 for example), it 
>> already requires that "ISPs must have efficiently utilized all 
>> previous allocations and at least 80% of their most recent allocation 
>> in order to receive additional space. This includes all space 
>> reassigned to their customers"
>>
>> Do you feel this isn't strict enough?  Is there another hole in the 
>> policy that allows ISPs with legacy space to get around this 
>> requirement?
>
>
> There must be.  It's only providers with large legacy blocks who can 
> piss away IPv4 /24s like that...

I had always assumed that would just be because they have enough 
addresses (such as a legacy class A) to not have to worry about coming 
back to ARIN for more addresses before the free pool is exhausted.

Can you find any cases where a provider who is giving space out 
inefficiently got a subsequent allocation from ARIN?  I'm not interested 
in attacking anyone here on the public list, but would like to dig into 
any such examples and identify what policies might need to be tightened 
up to ensure that everyone getting addresses from ARIN is reassigning 
them efficiently.

-Scott


From scottleibrand at gmail.com  Fri Jun 12 14:28:22 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 12 Jun 2009 11:28:22 -0700
Subject: [arin-ppml] [Fwd: Re: [arin-announce] Policy Proposal: Waiting
 list for unmet IPv4 requests]
In-Reply-To: <4A32955C.8050205@ipinc.net>
References: <4A32955C.8050205@ipinc.net>
Message-ID: <4A329E46.1040304@gmail.com>

Good comments, thanks.  Replies inline...

Ted Mittelstaedt wrote:
>
>
> I'm sorry to report that I'm against this proposal as written.
>
> I like the idea of a waiting list, and I had assumed ARIN would
> do this post-IPv4 runout.
>
> However, I feel that if the number resources become available
> more than 3 months AFTER the date of the initial request, that
> the waiting org must be re-qualified.
>
> They should be allows to "keep their place in line" but they should
> not be allowed to qualify then keep the qualification as good for
> an indefinite period.

I agree that renewal should not be automatic.  Perhaps I should word it 
something like this?

ARIN may provide a validity duration on each qualification.  In that 
case, the requester may re-apply to renew their request prior to its 
expiration and preserve their position on the waiting list.

The assumption here is that ARIN's operational procedure would be to 
validate that all of the information on the initial application is still 
valid, and that the org still qualifies for space, before renewing the 
request.

>
> Keep in mind that once ARIN issues a qualification to an org,
> that qualification becomes an asset.  Supposing for example the
> ISP is purchased by another ISP with adequate IPv4.  Why should
> they be able to get even more?
>
> Or, if you think that scenario is unlikely, then suppose the
> ISP puts in a IPv4 request, is denied, goes on the waiting list,
> then 3 months later executes a "private buy" with another org
> for a directed IPv4 transfer, and gets more numbers.  Then, 3
> months after that, IPv4 becomes available for the next org up
> on the wait list, and this ISP is the next in line.
>
> They no longer meet utilization requirements because they paid
> money out for the directed transfer 3 months earlier - but since
> they are prequalifed on the wait list, they can now get even more
> IPv4 under the rules.  Which of course they are going to want to
> do so they can turn around and "sell it" on the open market - to
> cover their cost from 3 months earlier of paying for IPv4 on the
> transfer market.

There is also the clause that "Any requests met through a transfer will 
be removed from the waiting list.", which should address this case.

> If the proposal was rewritten to force re qualification I'd probably
> support it.

LMK if the changes above constitute a sufficient change to address your 
concerns.

Thanks,
Scott

> Member Services wrote:
>> Please be advised that the following policy proposal has been posted 
>> to the ARIN Public Policy Mailing List. All discussion of the 
>> proposal must take place on the PPML
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>> ## * ##
>> 1. Policy Proposal Name: Waiting list for unmet IPv4 requests
>>
>> 2. Proposal Originator: Scott Leibrand
>>
>> 3. Proposal Version: 1.0
>>
>> 4. Date: 6/11/2009
>>
>> 5. Proposal type: new   6. Policy term: permanent    7. Policy 
>> statement:
>>
>> Replace 4.1.6 with:
>>
>> 4.1.6. Aggregation
>>
>> In order to preserve aggregation, ARIN issues blocks of addresses on
>> appropriate "CIDR-supported" bit boundaries. ARIN will make all 
>> allocations and assignments as a single continuous range of addresses.
>>
>> Add new section 4.1.8:
>>
>> 4.1.8 Unmet requests
>>
>> In the event that ARIN does not have a contiguous block of addresses 
>> of sufficient size to fulfill a qualified request, ARIN will provide 
>> the requesting organization with the option to either modify their 
>> request and request a smaller size block, or be placed on a waiting 
>> list of pre-qualified recipients.  Repeated requests, in a manner 
>> that would circumvent 4.1.6, are not allowed. Qualified requesters 
>> whose request cannot be immediately met will also be advised of the 
>> availability of the transfer mechanism in section 8.3 as an 
>> alternative mechanism to obtain IPv4 addresses.
>>
>> 4.1.8.1 Waiting list
>>
>> The position of each qualified request on the waiting list will be 
>> determined by the date it was approved. ARIN may provide a validity 
>> duration on each qualification, in which case the requester may renew 
>> their request  prior to its expiration to preserve their position on 
>> the waiting list.  Each organization may have one approved request on 
>> the waiting list at a time.  Any requests met through a transfer will 
>> be removed from the waiting list.
>>
>> 4.1.8.2 Fulfilling unmet needs
>>
>> As address blocks become available for allocation, ARIN will fulfill 
>> requests on a first-approved basis, subject to the size of each 
>> available address block.  Requests will not be partially filled.
>>
>> 8. Rationale:
>>
>> ARIN will soon be unable to meet all approved requests for IPv4 
>> address space.  In the absence of a policy like this, it is unclear 
>> what ARIN should do with subsequent requests.
>>
>> This policy would allocate reclaimed address blocks (and the last of 
>> the ARIN free pool) on a first-come-first-served basis, while 
>> preserving aggregation to the degree possible.  As the free pool 
>> shrinks, requests larger than the largest block left would  be placed 
>> on a waiting list, while smaller requests would use up the rest of 
>> it, until all requests have to go on the waiting list. As additional 
>> reclaimed addresses become available, the requests that have been 
>> waiting the longest would be met first.  If a requester gets the 
>> addresses they need via transfer, then they would be removed from the 
>> waiting list and would need to wait and submit a new request for 
>> additional address space, either directly or via transfer.
>>
>> This policy does not attempt to ration addresses, define maximum 
>> allocations, or otherwise manage how much address space any given 
>> organization may request.  As such, it is completely independent of 
>> any "Predictable IPv4 Run Out" proposals.
>>
>> 9. Timetable for implementation: Immediate.
>>
>>
>>
>>
>> _______________________________________________
>> ARIN-Announce
>> You are receiving this message because you are subscribed to
>> the ARIN Announce Mailing List (ARIN-announce at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-announce
>> Please contact info at arin.net if you experience any issues.
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From jrhett at svcolo.com  Fri Jun 12 14:33:40 2009
From: jrhett at svcolo.com (Jo Rhett)
Date: Fri, 12 Jun 2009 11:33:40 -0700
Subject: [arin-ppml] Number of routes, IPv6 vrs IPv4.
In-Reply-To: <20090531161152.GB51278@ussenterprise.ufp.org>
References: <20090531161152.GB51278@ussenterprise.ufp.org>
Message-ID: <8577D2B8-00A2-4EAE-A7E1-B66766B28DD3@svcolo.com>

On May 31, 2009, at 9:11 AM, Leo Bicknell wrote:
> If we can give everyone with an ASN an appropriate sized block so
> they only need 1 block we likely can reduce the size of the roting
> table by up to 9.67 times.  Folks are announcing multiple blocks


You are forgetting that many providers have both and ASN and a block  
per location, and don't have backbones between those locations.  So  
this won't actually map to "1 announcement per organization" but just  
"1 announcement per site" for any content provider without their own  
backbone.

-- 
Jo Rhett
senior geek

Silicon Valley Colocation
Support Phone: 408-400-0550





From woody at pch.net  Fri Jun 12 15:39:56 2009
From: woody at pch.net (Bill Woodcock)
Date: Fri, 12 Jun 2009 12:39:56 -0700 (PDT)
Subject: [arin-ppml] Policy Proposal: Transfer listing service
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BD@mail>
References: <4A326A86.8060004@arin.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BD@mail>
Message-ID: <Pine.SOC.4.61.0906121238360.26586@paixhost.pch.net>

      On Fri, 12 Jun 2009, Kevin Kargel wrote:
    > A listing service will not be a trivial implementation.  How are you
    > proposing we fund and staff it?

I'd be curious to hear people's thoughts on whether a listing service is 
more appropriate for ARIN to implement internally, or more appropriate for 
ARIN to leave to third-party service providers, whether they be 
larger-scope folks like eBay, or startups specific to this particular 
task.

                                -Bill



From Fred.Wettling at Bechtel.com  Fri Jun 12 15:46:06 2009
From: Fred.Wettling at Bechtel.com (Wettling, Fred)
Date: Fri, 12 Jun 2009 15:46:06 -0400
Subject: [arin-ppml] Policy Proposal: Transfer listing service
In-Reply-To: <4A3298C5.7040007@ipinc.net>
References: <4A326A86.8060004@arin.net> <4A3298C5.7040007@ipinc.net>
Message-ID: <F6EF0617A25EBB43BFB93175FBB913F9668027@ASHS00094.amers.ibechtel.com>

On June 12, 2009 10:48 AM, ARIN Member Services posted: 
Proposed new subsection 8.3.1: Listing service
ARIN will develop and operate a listing service to provide a Centralized
location to post information about IPv4 blocks available from Authorized
resource holders and IPv4 blocks needed by potential transfer
recipients. Participation in the listing service is voluntary.

On June 12, 2009 2:05 PM, Ted Mittelstaedt wrote:
<snip>
I would strongly encourage the proposal author to register the domain
name "scotts-ipv4-list.org and setup a wiki on it, or maybe beg
craigslist.org for a copy of their software.  If he can get this online
now, and make it free, word-of-mouth should publicize it and make it the
de-facto "free IPv4 block listing service"
<snip>

Reply from Fred Wettling
I oppose ARIN or public listing service services for number resources. 
Policy section 8.1. Principles
[https://www.arin.net/policy/nrpm.html#eight1] is clear that assignments
is based on need.  "... It should be understood that number resources
are not 'sold' under ARIN administration. Rather, number resources are
assigned to an organization for its exclusive use for the purpose stated
in the request, provided the terms of the Registration Services
Agreement continue to be met and the stated purpose for the number
resources remains the same... Number resources are issued, based on
justified need, to organizations, not to individuals representing those
organizations."

Rational for opposition:
1. The listing service "like Craig's list" implies something is
available or "for sale".  Not the case with number resources.
2. The allocation decision is ARIN's responsibility based on need of the
requesting organization
3. Additional administrative burden for maintaining / policing the
listings.  For example, software development maintenance /security and
verification of whom within an organization is authorized to post
available resources.
4. Policy section 8.3 is adequate for special transfer requests and does
not require any additional administrative overhead.

Suggested alternative (if there is really value in a listing)
a. ARIN could clearly list/display the individual blocks in ARIN's
available pool using simple CIDR notation.  
b. Reclaimed resources would be added to the list.  Assigned resources
would be removed.
c. Simple maintenance based on existing ARIN records

Regards - Fred


From tedm at ipinc.net  Fri Jun 12 16:22:39 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 12 Jun 2009 13:22:39 -0700
Subject: [arin-ppml] [Fwd: Re: [arin-announce] Policy Proposal: Waiting
 list for unmet IPv4 requests]
In-Reply-To: <4A329E46.1040304@gmail.com>
References: <4A32955C.8050205@ipinc.net> <4A329E46.1040304@gmail.com>
Message-ID: <4A32B90F.10905@ipinc.net>

Hi Scott,

   I would recommend you scratch the "any requests met through a
transfer" line and scratch the "ARIN may provide a validity duration"
line and simply state that the request will be revalidated.  I
would also suggest scratching the expiration language - if your
not going to require ARIN to put an expiration on the requests then
don't suggest it in policy.  Requiring revalidation makes
an expiration a moot issue, as well.

Scratching out all 3 of these would make the proposal a lot
simpler and easier to understand.

If the transfer allowance is revoked in the future, or a sunset
clause applied and it goes away, you now will have some dead language
in this proposal.  Since it isn't necessary, why do it?

revalidation should not be a problem once an org makes a request,
since they will have all the paperwork on file that they did for
the initial request.  If nothing has changed from the time they
filed to the time the numbers become available, the org just tells
the hostmaster "nothing changed" and that is that.  And if something
did change, then the revalidation will prompt them to disclose that
on the request.


Ted

Scott Leibrand wrote:
> Good comments, thanks.  Replies inline...
> 
> Ted Mittelstaedt wrote:
>>
>>
>> I'm sorry to report that I'm against this proposal as written.
>>
>> I like the idea of a waiting list, and I had assumed ARIN would
>> do this post-IPv4 runout.
>>
>> However, I feel that if the number resources become available
>> more than 3 months AFTER the date of the initial request, that
>> the waiting org must be re-qualified.
>>
>> They should be allows to "keep their place in line" but they should
>> not be allowed to qualify then keep the qualification as good for
>> an indefinite period.
> 
> I agree that renewal should not be automatic.  Perhaps I should word it 
> something like this?
> 
> ARIN may provide a validity duration on each qualification.  In that 
> case, the requester may re-apply to renew their request prior to its 
> expiration and preserve their position on the waiting list.
> 
> The assumption here is that ARIN's operational procedure would be to 
> validate that all of the information on the initial application is still 
> valid, and that the org still qualifies for space, before renewing the 
> request.
> 
>>
>> Keep in mind that once ARIN issues a qualification to an org,
>> that qualification becomes an asset.  Supposing for example the
>> ISP is purchased by another ISP with adequate IPv4.  Why should
>> they be able to get even more?
>>
>> Or, if you think that scenario is unlikely, then suppose the
>> ISP puts in a IPv4 request, is denied, goes on the waiting list,
>> then 3 months later executes a "private buy" with another org
>> for a directed IPv4 transfer, and gets more numbers.  Then, 3
>> months after that, IPv4 becomes available for the next org up
>> on the wait list, and this ISP is the next in line.
>>
>> They no longer meet utilization requirements because they paid
>> money out for the directed transfer 3 months earlier - but since
>> they are prequalifed on the wait list, they can now get even more
>> IPv4 under the rules.  Which of course they are going to want to
>> do so they can turn around and "sell it" on the open market - to
>> cover their cost from 3 months earlier of paying for IPv4 on the
>> transfer market.
> 
> There is also the clause that "Any requests met through a transfer will 
> be removed from the waiting list.", which should address this case.
> 
>> If the proposal was rewritten to force re qualification I'd probably
>> support it.
> 
> LMK if the changes above constitute a sufficient change to address your 
> concerns.
> 
> Thanks,
> Scott
> 
>> Member Services wrote:
>>> Please be advised that the following policy proposal has been posted 
>>> to the ARIN Public Policy Mailing List. All discussion of the 
>>> proposal must take place on the PPML
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>> ## * ##
>>> 1. Policy Proposal Name: Waiting list for unmet IPv4 requests
>>>
>>> 2. Proposal Originator: Scott Leibrand
>>>
>>> 3. Proposal Version: 1.0
>>>
>>> 4. Date: 6/11/2009
>>>
>>> 5. Proposal type: new   6. Policy term: permanent    7. Policy 
>>> statement:
>>>
>>> Replace 4.1.6 with:
>>>
>>> 4.1.6. Aggregation
>>>
>>> In order to preserve aggregation, ARIN issues blocks of addresses on
>>> appropriate "CIDR-supported" bit boundaries. ARIN will make all 
>>> allocations and assignments as a single continuous range of addresses.
>>>
>>> Add new section 4.1.8:
>>>
>>> 4.1.8 Unmet requests
>>>
>>> In the event that ARIN does not have a contiguous block of addresses 
>>> of sufficient size to fulfill a qualified request, ARIN will provide 
>>> the requesting organization with the option to either modify their 
>>> request and request a smaller size block, or be placed on a waiting 
>>> list of pre-qualified recipients.  Repeated requests, in a manner 
>>> that would circumvent 4.1.6, are not allowed. Qualified requesters 
>>> whose request cannot be immediately met will also be advised of the 
>>> availability of the transfer mechanism in section 8.3 as an 
>>> alternative mechanism to obtain IPv4 addresses.
>>>
>>> 4.1.8.1 Waiting list
>>>
>>> The position of each qualified request on the waiting list will be 
>>> determined by the date it was approved. ARIN may provide a validity 
>>> duration on each qualification, in which case the requester may renew 
>>> their request  prior to its expiration to preserve their position on 
>>> the waiting list.  Each organization may have one approved request on 
>>> the waiting list at a time.  Any requests met through a transfer will 
>>> be removed from the waiting list.
>>>
>>> 4.1.8.2 Fulfilling unmet needs
>>>
>>> As address blocks become available for allocation, ARIN will fulfill 
>>> requests on a first-approved basis, subject to the size of each 
>>> available address block.  Requests will not be partially filled.
>>>
>>> 8. Rationale:
>>>
>>> ARIN will soon be unable to meet all approved requests for IPv4 
>>> address space.  In the absence of a policy like this, it is unclear 
>>> what ARIN should do with subsequent requests.
>>>
>>> This policy would allocate reclaimed address blocks (and the last of 
>>> the ARIN free pool) on a first-come-first-served basis, while 
>>> preserving aggregation to the degree possible.  As the free pool 
>>> shrinks, requests larger than the largest block left would  be placed 
>>> on a waiting list, while smaller requests would use up the rest of 
>>> it, until all requests have to go on the waiting list. As additional 
>>> reclaimed addresses become available, the requests that have been 
>>> waiting the longest would be met first.  If a requester gets the 
>>> addresses they need via transfer, then they would be removed from the 
>>> waiting list and would need to wait and submit a new request for 
>>> additional address space, either directly or via transfer.
>>>
>>> This policy does not attempt to ration addresses, define maximum 
>>> allocations, or otherwise manage how much address space any given 
>>> organization may request.  As such, it is completely independent of 
>>> any "Predictable IPv4 Run Out" proposals.
>>>
>>> 9. Timetable for implementation: Immediate.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> ARIN-Announce
>>> You are receiving this message because you are subscribed to
>>> the ARIN Announce Mailing List (ARIN-announce at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-announce
>>> Please contact info at arin.net if you experience any issues.
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.



From scottleibrand at gmail.com  Fri Jun 12 16:37:51 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 12 Jun 2009 13:37:51 -0700
Subject: [arin-ppml] Policy Proposal: Waiting list for unmet IPv4
	requests
In-Reply-To: <4A32B90F.10905@ipinc.net>
References: <4A32955C.8050205@ipinc.net> <4A329E46.1040304@gmail.com>
	<4A32B90F.10905@ipinc.net>
Message-ID: <4A32BC9F.8040209@gmail.com>

Ah, ok.  So you're saying that the request must be revalidated only at 
the time the numbers become available?  That actually is simpler, and I 
hadn't thought of it.  Thanks.

The only possible downside I can think of is that someone might think 
that they've already gotten approved for addresses, and then be 
surprised when the addresses come available that they no longer qualify 
because something has changed.  That should be manageable with 
reasonable expectations-setting, though...

I'm not sure we want to completely remove the transfer clause.  For 
example, consider an entity that qualifies for a /18 of space.  They 
only ask for a /20, though, and get put on the waiting list.  If they 
subsequently go get a /19 through transfer, they would still qualify for 
a /20, but IMO they should lose their place on the waiting list and have 
to re-apply.

So the resulting language might look something like this?

4.1.8.1 Waiting list

The position of each qualified request on the waiting list will be 
determined by the date it was approved. Each organization may have one 
approved request on the waiting list at a time. 

4.1.8.2 Fulfilling unmet needs

As address blocks become available for allocation, ARIN will fulfill 
requests on a first-approved basis, subject to the size of each 
available address block and a re-validation of the original request.  
Requests will not be partially filled. Any requests met through a 
transfer will be considered fulfilled and removed from the waiting list.

Thoughts?

-Scott

Ted Mittelstaedt wrote:
> Hi Scott,
>
>   I would recommend you scratch the "any requests met through a
> transfer" line and scratch the "ARIN may provide a validity duration"
> line and simply state that the request will be revalidated.  I
> would also suggest scratching the expiration language - if your
> not going to require ARIN to put an expiration on the requests then
> don't suggest it in policy.  Requiring revalidation makes
> an expiration a moot issue, as well.
>
> Scratching out all 3 of these would make the proposal a lot
> simpler and easier to understand.
>
> If the transfer allowance is revoked in the future, or a sunset
> clause applied and it goes away, you now will have some dead language
> in this proposal.  Since it isn't necessary, why do it?
>
> revalidation should not be a problem once an org makes a request,
> since they will have all the paperwork on file that they did for
> the initial request.  If nothing has changed from the time they
> filed to the time the numbers become available, the org just tells
> the hostmaster "nothing changed" and that is that.  And if something
> did change, then the revalidation will prompt them to disclose that
> on the request.
>
>
> Ted
>
> Scott Leibrand wrote:
>> Good comments, thanks.  Replies inline...
>>
>> Ted Mittelstaedt wrote:
>>>
>>>
>>> I'm sorry to report that I'm against this proposal as written.
>>>
>>> I like the idea of a waiting list, and I had assumed ARIN would
>>> do this post-IPv4 runout.
>>>
>>> However, I feel that if the number resources become available
>>> more than 3 months AFTER the date of the initial request, that
>>> the waiting org must be re-qualified.
>>>
>>> They should be allows to "keep their place in line" but they should
>>> not be allowed to qualify then keep the qualification as good for
>>> an indefinite period.
>>
>> I agree that renewal should not be automatic.  Perhaps I should word 
>> it something like this?
>>
>> ARIN may provide a validity duration on each qualification.  In that 
>> case, the requester may re-apply to renew their request prior to its 
>> expiration and preserve their position on the waiting list.
>>
>> The assumption here is that ARIN's operational procedure would be to 
>> validate that all of the information on the initial application is 
>> still valid, and that the org still qualifies for space, before 
>> renewing the request.
>>
>>>
>>> Keep in mind that once ARIN issues a qualification to an org,
>>> that qualification becomes an asset.  Supposing for example the
>>> ISP is purchased by another ISP with adequate IPv4.  Why should
>>> they be able to get even more?
>>>
>>> Or, if you think that scenario is unlikely, then suppose the
>>> ISP puts in a IPv4 request, is denied, goes on the waiting list,
>>> then 3 months later executes a "private buy" with another org
>>> for a directed IPv4 transfer, and gets more numbers.  Then, 3
>>> months after that, IPv4 becomes available for the next org up
>>> on the wait list, and this ISP is the next in line.
>>>
>>> They no longer meet utilization requirements because they paid
>>> money out for the directed transfer 3 months earlier - but since
>>> they are prequalifed on the wait list, they can now get even more
>>> IPv4 under the rules.  Which of course they are going to want to
>>> do so they can turn around and "sell it" on the open market - to
>>> cover their cost from 3 months earlier of paying for IPv4 on the
>>> transfer market.
>>
>> There is also the clause that "Any requests met through a transfer 
>> will be removed from the waiting list.", which should address this case.
>>
>>> If the proposal was rewritten to force re qualification I'd probably
>>> support it.
>>
>> LMK if the changes above constitute a sufficient change to address 
>> your concerns.
>>
>> Thanks,
>> Scott
>>
>>> Member Services wrote:
>>>> Please be advised that the following policy proposal has been 
>>>> posted to the ARIN Public Policy Mailing List. All discussion of 
>>>> the proposal must take place on the PPML
>>>>
>>>> Regards,
>>>>
>>>> Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>> ## * ##
>>>> 1. Policy Proposal Name: Waiting list for unmet IPv4 requests
>>>>
>>>> 2. Proposal Originator: Scott Leibrand
>>>>
>>>> 3. Proposal Version: 1.0
>>>>
>>>> 4. Date: 6/11/2009
>>>>
>>>> 5. Proposal type: new   6. Policy term: permanent    7. Policy 
>>>> statement:
>>>>
>>>> Replace 4.1.6 with:
>>>>
>>>> 4.1.6. Aggregation
>>>>
>>>> In order to preserve aggregation, ARIN issues blocks of addresses on
>>>> appropriate "CIDR-supported" bit boundaries. ARIN will make all 
>>>> allocations and assignments as a single continuous range of addresses.
>>>>
>>>> Add new section 4.1.8:
>>>>
>>>> 4.1.8 Unmet requests
>>>>
>>>> In the event that ARIN does not have a contiguous block of 
>>>> addresses of sufficient size to fulfill a qualified request, ARIN 
>>>> will provide the requesting organization with the option to either 
>>>> modify their request and request a smaller size block, or be placed 
>>>> on a waiting list of pre-qualified recipients.  Repeated requests, 
>>>> in a manner that would circumvent 4.1.6, are not allowed. Qualified 
>>>> requesters whose request cannot be immediately met will also be 
>>>> advised of the availability of the transfer mechanism in section 
>>>> 8.3 as an alternative mechanism to obtain IPv4 addresses.
>>>>
>>>> 4.1.8.1 Waiting list
>>>>
>>>> The position of each qualified request on the waiting list will be 
>>>> determined by the date it was approved. ARIN may provide a validity 
>>>> duration on each qualification, in which case the requester may 
>>>> renew their request  prior to its expiration to preserve their 
>>>> position on the waiting list.  Each organization may have one 
>>>> approved request on the waiting list at a time.  Any requests met 
>>>> through a transfer will be removed from the waiting list.
>>>>
>>>> 4.1.8.2 Fulfilling unmet needs
>>>>
>>>> As address blocks become available for allocation, ARIN will 
>>>> fulfill requests on a first-approved basis, subject to the size of 
>>>> each available address block.  Requests will not be partially filled.
>>>>
>>>> 8. Rationale:
>>>>
>>>> ARIN will soon be unable to meet all approved requests for IPv4 
>>>> address space.  In the absence of a policy like this, it is unclear 
>>>> what ARIN should do with subsequent requests.
>>>>
>>>> This policy would allocate reclaimed address blocks (and the last 
>>>> of the ARIN free pool) on a first-come-first-served basis, while 
>>>> preserving aggregation to the degree possible.  As the free pool 
>>>> shrinks, requests larger than the largest block left would  be 
>>>> placed on a waiting list, while smaller requests would use up the 
>>>> rest of it, until all requests have to go on the waiting list. As 
>>>> additional reclaimed addresses become available, the requests that 
>>>> have been waiting the longest would be met first.  If a requester 
>>>> gets the addresses they need via transfer, then they would be 
>>>> removed from the waiting list and would need to wait and submit a 
>>>> new request for additional address space, either directly or via 
>>>> transfer.
>>>>
>>>> This policy does not attempt to ration addresses, define maximum 
>>>> allocations, or otherwise manage how much address space any given 
>>>> organization may request.  As such, it is completely independent of 
>>>> any "Predictable IPv4 Run Out" proposals.
>>>>
>>>> 9. Timetable for implementation: Immediate.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ARIN-Announce
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Announce Mailing List (ARIN-announce at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-announce
>>>> Please contact info at arin.net if you experience any issues.
>>>
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>


From stephen at sprunk.org  Fri Jun 12 16:57:40 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 12 Jun 2009 15:57:40 -0500
Subject: [arin-ppml] [arin-announce] Policy Proposal:
	Transfer	listingservice
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BE@mail>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BE@mail>
Message-ID: <4A32C144.7090800@sprunk.org>

Kevin Kargel wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Scott Leibrand
>> Sent: Friday, June 12, 2009 11:09 AM
>> To: <michael.dillon at bt.com>
>> Cc: <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
>> listingservice
>>
>> That might work too, but ARIN counsel, the AC, and others involved thought it belonged in the 2008-2 transfer policy, and the CEO has said they don't plan to do a listing service without policy directing them to do so.
>>
>> What do you think of the idea itself?
>>     
>
> Personally I do not want to see ARIN getting in to the broker business,
> which is directly where a listing service is heading. 

I am against ARIN becoming a broker as well, and part of 2009-1 was
intended to keep ARIN clear of that mess.

However, a listing service does not a broker make.  It is no different
than putting up a bulletin board where people can post "want to buy" and
"want to sell" notes; it does not make ARIN a broker, who is actually a
party to each transaction.

> If we take this initial step we might as well go ahead and fire up IP-Bay ..  
>   

As others have noted, it may be more appropriate for an external party
to run the listing service.  However, multiple services would appear and
be inconsistent with each other as each service tries to compete for
profits on the fees they'd charge, and that leads to economic
inefficiency, confusion, arbitrage, speculation, etc. -- all the things
we know we need to try to avoid.

> Once ARIN gets involved in this it will be a pandora's box of regulations,
> litigations, tax accounting --  all sorts of odious stuff..  and that's just in the US..  my poor brain can't even start to comprehend the international implications.
>   

While I understand the concern, I will reserve comment on these issues
because IANAL; ARIN has counsel and a Board to make sure our policies do
not run afoul in such areas, and we have been instructed to make the
policies we want and let them worry about the consequences -- and stop
us or modify the policies if required to avoid problems.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090612/b6025667/attachment.bin>

From tedm at ipinc.net  Fri Jun 12 17:00:04 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 12 Jun 2009 14:00:04 -0700
Subject: [arin-ppml] Policy Proposal: Waiting list for unmet IPv4
	requests
In-Reply-To: <4A32BC9F.8040209@gmail.com>
References: <4A32955C.8050205@ipinc.net> <4A329E46.1040304@gmail.com>
	<4A32B90F.10905@ipinc.net> <4A32BC9F.8040209@gmail.com>
Message-ID: <4A32C1D4.8030303@ipinc.net>

Scott Leibrand wrote:
> Ah, ok.  So you're saying that the request must be revalidated only at 
> the time the numbers become available?  That actually is simpler, and I 
> hadn't thought of it.  Thanks.
> 

Yes, that's precisely it.

> The only possible downside I can think of is that someone might think 
> that they've already gotten approved for addresses, and then be 
> surprised when the addresses come available that they no longer qualify 
> because something has changed.
> That should be manageable with 
> reasonable expectations-setting, though...
> 
> I'm not sure we want to completely remove the transfer clause.  For 
> example, consider an entity that qualifies for a /18 of space.  They 
> only ask for a /20, though, and get put on the waiting list.  If they 
> subsequently go get a /19 through transfer, they would still qualify for 
> a /20, but IMO they should lose their place on the waiting list and have 
> to re-apply.
> 

The wait list should specify that they should ask for the max they
need and only best-effort will be made to meet the request - if they ask
for a /18 and are next in line and ARIN has a /20 come up, they should
be offered the /20 and stay on the wait list until the order is filled.

Besides the fact I think most orgs will ask for the max anyhow if they
are going to be on a wait list, here's how I think the scenario you
illustrate would play out.

So this org goes on the waitlist, while waiting for their /18 they
buy a /19 through transfer.

6 months later the /18 comes available.  Normally they would no longer
qualify BUT what ARIN does in this case is they offer them the /18
IN EXCHANGE for a trade-in of the /19 that they "bought" from transfer.
(or a trade-in of the partial /20 that was given to them)

The benefits are obvious - ARIN can aggregate the /19 (if possible) or 
give it to another org that only requested a /19.  Also, the org that
bought the /19 through transfer gets a unified contiguous /18 not 
another discontiguous /19

And finally, this is the best part - since the /19 is traded in to ARIN,
it doesn't go right back on to the transfer market and is then sold by
a broker to someone else - thus we are helping to discourage growth
of transfer brokering.

> So the resulting language might look something like this?
> 
> 4.1.8.1 Waiting list
> 
> The position of each qualified request on the waiting list will be 
> determined by the date it was approved. Each organization may have one 
> approved request on the waiting list at a time.
> 4.1.8.2 Fulfilling unmet needs
> 
> As address blocks become available for allocation, ARIN will fulfill 
> requests on a first-approved basis, subject to the size of each 
> available address block and a re-validation of the original request.  
> Requests will not be partially filled.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  strike thiat

Requests will be partially filled only on condition the requesting
org agrees to return the partial allocation in exchange for a
larger allocation, should a larger allocation become available
that would fill the original request.

  Any requests met through a
> transfer will be considered fulfilled and removed from the waiting list.
> 

strike the last bit.

Ted

> Thoughts?
> 
> -Scott
> 
> Ted Mittelstaedt wrote:
>> Hi Scott,
>>
>>   I would recommend you scratch the "any requests met through a
>> transfer" line and scratch the "ARIN may provide a validity duration"
>> line and simply state that the request will be revalidated.  I
>> would also suggest scratching the expiration language - if your
>> not going to require ARIN to put an expiration on the requests then
>> don't suggest it in policy.  Requiring revalidation makes
>> an expiration a moot issue, as well.
>>
>> Scratching out all 3 of these would make the proposal a lot
>> simpler and easier to understand.
>>
>> If the transfer allowance is revoked in the future, or a sunset
>> clause applied and it goes away, you now will have some dead language
>> in this proposal.  Since it isn't necessary, why do it?
>>
>> revalidation should not be a problem once an org makes a request,
>> since they will have all the paperwork on file that they did for
>> the initial request.  If nothing has changed from the time they
>> filed to the time the numbers become available, the org just tells
>> the hostmaster "nothing changed" and that is that.  And if something
>> did change, then the revalidation will prompt them to disclose that
>> on the request.
>>
>>
>> Ted
>>
>> Scott Leibrand wrote:
>>> Good comments, thanks.  Replies inline...
>>>
>>> Ted Mittelstaedt wrote:
>>>>
>>>>
>>>> I'm sorry to report that I'm against this proposal as written.
>>>>
>>>> I like the idea of a waiting list, and I had assumed ARIN would
>>>> do this post-IPv4 runout.
>>>>
>>>> However, I feel that if the number resources become available
>>>> more than 3 months AFTER the date of the initial request, that
>>>> the waiting org must be re-qualified.
>>>>
>>>> They should be allows to "keep their place in line" but they should
>>>> not be allowed to qualify then keep the qualification as good for
>>>> an indefinite period.
>>>
>>> I agree that renewal should not be automatic.  Perhaps I should word 
>>> it something like this?
>>>
>>> ARIN may provide a validity duration on each qualification.  In that 
>>> case, the requester may re-apply to renew their request prior to its 
>>> expiration and preserve their position on the waiting list.
>>>
>>> The assumption here is that ARIN's operational procedure would be to 
>>> validate that all of the information on the initial application is 
>>> still valid, and that the org still qualifies for space, before 
>>> renewing the request.
>>>
>>>>
>>>> Keep in mind that once ARIN issues a qualification to an org,
>>>> that qualification becomes an asset.  Supposing for example the
>>>> ISP is purchased by another ISP with adequate IPv4.  Why should
>>>> they be able to get even more?
>>>>
>>>> Or, if you think that scenario is unlikely, then suppose the
>>>> ISP puts in a IPv4 request, is denied, goes on the waiting list,
>>>> then 3 months later executes a "private buy" with another org
>>>> for a directed IPv4 transfer, and gets more numbers.  Then, 3
>>>> months after that, IPv4 becomes available for the next org up
>>>> on the wait list, and this ISP is the next in line.
>>>>
>>>> They no longer meet utilization requirements because they paid
>>>> money out for the directed transfer 3 months earlier - but since
>>>> they are prequalifed on the wait list, they can now get even more
>>>> IPv4 under the rules.  Which of course they are going to want to
>>>> do so they can turn around and "sell it" on the open market - to
>>>> cover their cost from 3 months earlier of paying for IPv4 on the
>>>> transfer market.
>>>
>>> There is also the clause that "Any requests met through a transfer 
>>> will be removed from the waiting list.", which should address this case.
>>>
>>>> If the proposal was rewritten to force re qualification I'd probably
>>>> support it.
>>>
>>> LMK if the changes above constitute a sufficient change to address 
>>> your concerns.
>>>
>>> Thanks,
>>> Scott
>>>
>>>> Member Services wrote:
>>>>> Please be advised that the following policy proposal has been 
>>>>> posted to the ARIN Public Policy Mailing List. All discussion of 
>>>>> the proposal must take place on the PPML
>>>>>
>>>>> Regards,
>>>>>
>>>>> Member Services
>>>>> American Registry for Internet Numbers (ARIN)
>>>>>
>>>>> ## * ##
>>>>> 1. Policy Proposal Name: Waiting list for unmet IPv4 requests
>>>>>
>>>>> 2. Proposal Originator: Scott Leibrand
>>>>>
>>>>> 3. Proposal Version: 1.0
>>>>>
>>>>> 4. Date: 6/11/2009
>>>>>
>>>>> 5. Proposal type: new   6. Policy term: permanent    7. Policy 
>>>>> statement:
>>>>>
>>>>> Replace 4.1.6 with:
>>>>>
>>>>> 4.1.6. Aggregation
>>>>>
>>>>> In order to preserve aggregation, ARIN issues blocks of addresses on
>>>>> appropriate "CIDR-supported" bit boundaries. ARIN will make all 
>>>>> allocations and assignments as a single continuous range of addresses.
>>>>>
>>>>> Add new section 4.1.8:
>>>>>
>>>>> 4.1.8 Unmet requests
>>>>>
>>>>> In the event that ARIN does not have a contiguous block of 
>>>>> addresses of sufficient size to fulfill a qualified request, ARIN 
>>>>> will provide the requesting organization with the option to either 
>>>>> modify their request and request a smaller size block, or be placed 
>>>>> on a waiting list of pre-qualified recipients.  Repeated requests, 
>>>>> in a manner that would circumvent 4.1.6, are not allowed. Qualified 
>>>>> requesters whose request cannot be immediately met will also be 
>>>>> advised of the availability of the transfer mechanism in section 
>>>>> 8.3 as an alternative mechanism to obtain IPv4 addresses.
>>>>>
>>>>> 4.1.8.1 Waiting list
>>>>>
>>>>> The position of each qualified request on the waiting list will be 
>>>>> determined by the date it was approved. ARIN may provide a validity 
>>>>> duration on each qualification, in which case the requester may 
>>>>> renew their request  prior to its expiration to preserve their 
>>>>> position on the waiting list.  Each organization may have one 
>>>>> approved request on the waiting list at a time.  Any requests met 
>>>>> through a transfer will be removed from the waiting list.
>>>>>
>>>>> 4.1.8.2 Fulfilling unmet needs
>>>>>
>>>>> As address blocks become available for allocation, ARIN will 
>>>>> fulfill requests on a first-approved basis, subject to the size of 
>>>>> each available address block.  Requests will not be partially filled.
>>>>>
>>>>> 8. Rationale:
>>>>>
>>>>> ARIN will soon be unable to meet all approved requests for IPv4 
>>>>> address space.  In the absence of a policy like this, it is unclear 
>>>>> what ARIN should do with subsequent requests.
>>>>>
>>>>> This policy would allocate reclaimed address blocks (and the last 
>>>>> of the ARIN free pool) on a first-come-first-served basis, while 
>>>>> preserving aggregation to the degree possible.  As the free pool 
>>>>> shrinks, requests larger than the largest block left would  be 
>>>>> placed on a waiting list, while smaller requests would use up the 
>>>>> rest of it, until all requests have to go on the waiting list. As 
>>>>> additional reclaimed addresses become available, the requests that 
>>>>> have been waiting the longest would be met first.  If a requester 
>>>>> gets the addresses they need via transfer, then they would be 
>>>>> removed from the waiting list and would need to wait and submit a 
>>>>> new request for additional address space, either directly or via 
>>>>> transfer.
>>>>>
>>>>> This policy does not attempt to ration addresses, define maximum 
>>>>> allocations, or otherwise manage how much address space any given 
>>>>> organization may request.  As such, it is completely independent of 
>>>>> any "Predictable IPv4 Run Out" proposals.
>>>>>
>>>>> 9. Timetable for implementation: Immediate.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ARIN-Announce
>>>>> You are receiving this message because you are subscribed to
>>>>> the ARIN Announce Mailing List (ARIN-announce at arin.net).
>>>>> Unsubscribe or manage your mailing list subscription at:
>>>>> http://lists.arin.net/mailman/listinfo/arin-announce
>>>>> Please contact info at arin.net if you experience any issues.
>>>>
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>



From kkargel at polartel.com  Fri Jun 12 17:06:49 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 12 Jun 2009 16:06:49 -0500
Subject: [arin-ppml] [arin-announce] Policy Proposal: Transfer
	listingservice
In-Reply-To: <48B27EA6-74E9-4B6E-8761-BF6798491025@pch.net>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>
	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BF@mail>
	<48B27EA6-74E9-4B6E-8761-BF6798491025@pch.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2C0@mail>



> -----Original Message-----
> From: Tom Vest [mailto:tvest at pch.net]
> Sent: Friday, June 12, 2009 12:13 PM
> To: Kevin Kargel
> Cc: Scott Leibrand; michael.dillon at bt.com; arin-ppml at arin.net
> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
> listingservice
> 
> 
> On Jun 12, 2009, at 12:28 PM, Kevin Kargel wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-
> >> bounces at arin.net] On
> >> Behalf Of Scott Leibrand
> >> Sent: Friday, June 12, 2009 11:09 AM
> >> To: <michael.dillon at bt.com>
> >> Cc: <arin-ppml at arin.net>
> >> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
> >> listingservice
> >>
> >> That might work too, but ARIN counsel, the AC, and others involved
> >> thought it belonged in the 2008-2 transfer policy, and the CEO has
> >> said they don't plan to do a listing service without policy directing
> >> them to do so.
> >>
> >> What do you think of the idea itself?
> >>
> >> -Scott
> >>
> >
> > I probably should have mentioned that it is a nifty idea if it was
> > just us
> > NetOps working with each other and the lawyers and governments would
> > keep
> > out of it.  I just don't see much hope that the litigators and
> > regulators
> > will keep their fingers out of the pie.
> 
> Hi Kevin,
> 
> Out of curiosity, do you think that litigators and regulators are more
> likely (or maybe very likely) to keep their fingers out if, after
> enabling the emergence of commercial IPv4 transfers, the RIRs take no
> further actions of any kind related to any IPv4 markets that emerge
> thereafter? Are your views on that probability-of-intervention
> question based on any particular expectation about whether and how
> IPv4 markets will actually work, or are they independent of all such
> expectations (i.e., no matter how things turn out, it would be better
> in all cases for the RIRs to take no position / no action at all)?
> 
> TV

My expectation is now that we have valuated IP addresses that value and/or
the 'ownership' of that value will be contested in courts which will bring
in litigators.  Litigators will establish precedents and points in law that
will now have to be considered in all matters.  Record keeping requirements
will be much stricter to defend against legal actions.  

My expectation is also now that there is a quantifiable value assigned to IP
addresses that governments will find a way to tax them, at the very least
with sales tax on the exchange or transfer of a valued property, possibly
also with a use tax and/or a recurring property tax.  Once governments have
their pinkies in the mix then special interest groups will push government
to regulate the distribution and use of IP addresses and the governments
will be anxious to regulate the product in order to justify the taxes.  

I fear that 2009-1 has doomed us to a future of cost, cost controls and
regulation and there is nothing we can do about it now.  The sleeping bear
has been nudged and will soon awake.  This is beyond our control anymore.

The best course of action we can take is to tread softly, make minimal
changes and not arouse the bear any faster than we have to.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090612/5422ec1f/attachment.bin>

From mueller at syr.edu  Fri Jun 12 17:08:01 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 12 Jun 2009 17:08:01 -0400
Subject: [arin-ppml] Policy Proposal: Transfer listing service
In-Reply-To: <4A326A86.8060004@arin.net>
References: <4A326A86.8060004@arin.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B220A7B@SUEX07-MBX-04.ad.syr.edu>

Why not list all transfers? Will ARIN keep track of designated tansfers under 2009-1 in any other way? 

> -----Original Message-----
>   recipients. Participation in the listing service is voluntary.
> 


From tedm at ipinc.net  Fri Jun 12 17:13:25 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 12 Jun 2009 14:13:25 -0700
Subject: [arin-ppml] [arin-announce] Policy
	Proposal:	Transfer	listingservice
In-Reply-To: <4A32C144.7090800@sprunk.org>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BE@mail>
	<4A32C144.7090800@sprunk.org>
Message-ID: <4A32C4F5.4090404@ipinc.net>

Stephen Sprunk wrote:
> Kevin Kargel wrote:
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>>> Behalf Of Scott Leibrand
>>> Sent: Friday, June 12, 2009 11:09 AM
>>> To: <michael.dillon at bt.com>
>>> Cc: <arin-ppml at arin.net>
>>> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
>>> listingservice
>>>
>>> That might work too, but ARIN counsel, the AC, and others involved thought it belonged in the 2008-2 transfer policy, and the CEO has said they don't plan to do a listing service without policy directing them to do so.
>>>
>>> What do you think of the idea itself?
>>>     
>> Personally I do not want to see ARIN getting in to the broker business,
>> which is directly where a listing service is heading. 
> 
> I am against ARIN becoming a broker as well, and part of 2009-1 was
> intended to keep ARIN clear of that mess.
> 
> However, a listing service does not a broker make.  It is no different
> than putting up a bulletin board where people can post "want to buy" and
> "want to sell" notes; it does not make ARIN a broker, who is actually a
> party to each transaction.
> 
>> If we take this initial step we might as well go ahead and fire up IP-Bay ..  
>>   
> 
> As others have noted, it may be more appropriate for an external party
> to run the listing service.  However, multiple services would appear and
> be inconsistent with each other as each service tries to compete for
> profits on the fees they'd charge, and that leads to economic
> inefficiency, confusion, arbitrage, speculation, etc. -- all the things
> we know we need to try to avoid.
> 

I disagree that this would happen.  It COULD happen but I don't think so.

For starters, any listing service that offers FREE posting is going to
immediately dominate

A listing website that does free posting will get a lot of traffic and
can EASILY make plenty of money off advertising.  Also, since the
listing service isn't making money with the buyer/sellers, it does not
get entwined with people suing each other over misrepresentation, fraud,
etc.

During the housing boom of 2004-2006, I saw (in my own neighborhood)
a number of For Sale By Owner homes going through craigslist - they
NEVER touched the "official" multiple listing service, never paid
any fees for that, never paid any fees to any Realtor, never paid
fees to craigslist.  All I saw is a FSBO sign on the front lawn and
a month later new owners.

If the market hadn't crashed, I think it would be more and more common
for people to do this with housing.

Typically you only pay a broker when your trying to sell something that
there's a LOT of already out there.  For example, have you ever tried
selling a 5-10 year old business telephone system?

The broker then acts as a salesdog to rep. your old phone system or
whatever other thing to potential buyers.

But in IPv4 market, you have a precious commodity that everybody wants -
why pay a broker to sit on his a s s and take phone calls?  If a central
listing service got going early on, charging no fees, it would rapidly 
dominate - since buyers don't want to hunt all over the country looking
for IPv4, and sellers aren't going to want to pay a huge commission to
a broker.


Ted

>> Once ARIN gets involved in this it will be a pandora's box of regulations,
>> litigations, tax accounting --  all sorts of odious stuff..  and that's just in the US..  my poor brain can't even start to comprehend the international implications.
>>   
> 
> While I understand the concern, I will reserve comment on these issues
> because IANAL; ARIN has counsel and a Board to make sure our policies do
> not run afoul in such areas, and we have been instructed to make the
> policies we want and let them worry about the consequences -- and stop
> us or modify the policies if required to avoid problems.
> 
> S
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From schnizlein at isoc.org  Fri Jun 12 17:15:54 2009
From: schnizlein at isoc.org (John Schnizlein)
Date: Fri, 12 Jun 2009 17:15:54 -0400
Subject: [arin-ppml] [arin-announce] Policy Proposal:
	Transfer	listingservice
In-Reply-To: <4A32C144.7090800@sprunk.org>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BE@mail>
	<4A32C144.7090800@sprunk.org>
Message-ID: <7C78500B-BE88-4363-AFB4-0147CCADDCE6@isoc.org>

In context below:

On 2009Jun12, at 4:57 PM, Stephen Sprunk wrote:

> Kevin Kargel wrote:
>>>
>>> Behalf Of Scott Leibrand
>>> ...
>>>
>>> That might work too, but ARIN counsel, the AC, and others involved  
>>> thought it belonged in the 2008-2 transfer policy, and the CEO has  
>>> said they don't plan to do a listing service without policy  
>>> directing them to do so.
>>>
>>> What do you think of the idea itself?
>>
>> Personally I do not want to see ARIN getting in to the broker  
>> business,
>> which is directly where a listing service is heading.
>
> I am against ARIN becoming a broker as well, and part of 2009-1 was
> intended to keep ARIN clear of that mess.
>
> However, a listing service does not a broker make.  It is no different
> than putting up a bulletin board where people can post "want to buy"  
> and
> "want to sell" notes; it does not make ARIN a broker, who is  
> actually a
> party to each transaction.

That particular horse may already be out of the barn.  The adopted  
policy includes this, which makes ARIN party to each transaction:

8.3 Transfers to Specified Recipients
Number resources may be released, in whole or in part, to ARIN for  
transfer to another specified organizational recipient, by any  
authorized resource holder within the ARIN region.  ...

John


From scottleibrand at gmail.com  Fri Jun 12 17:16:11 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 12 Jun 2009 14:16:11 -0700
Subject: [arin-ppml] Policy Proposal: Transfer listing service
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A7B@SUEX07-MBX-04.ad.syr.edu>
References: <4A326A86.8060004@arin.net>
	<75822E125BCB994F8446858C4B19F0D77B220A7B@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A32C59B.2080105@gmail.com>

The listing service is for people wishing to engage in a transfer.  That 
is separate from recording transfers that actually occur.  For the 
former, participation in ARIN's listing service should be voluntary.  
But for the latter, ARIN should publicly record all transfers and make 
that data available like they do today for registration data.

-Scott

Milton L Mueller wrote:
> Why not list all transfers? Will ARIN keep track of designated tansfers under 2009-1 in any other way? 
>
>   
>> -----Original Message-----
>>   recipients. Participation in the listing service is voluntary.
>>
>>     
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   


From tedm at ipinc.net  Fri Jun 12 17:29:33 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 12 Jun 2009 14:29:33 -0700
Subject: [arin-ppml] [arin-announce] Policy Proposal:
	Transfer	listingservice
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2C0@mail>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BF@mail>	<48B27EA6-74E9-4B6E-8761-BF6798491025@pch.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2C0@mail>
Message-ID: <4A32C8BD.1040105@ipinc.net>

Kevin Kargel wrote:
> 
>> -----Original Message-----
>> From: Tom Vest [mailto:tvest at pch.net]
>> Sent: Friday, June 12, 2009 12:13 PM
>> To: Kevin Kargel
>> Cc: Scott Leibrand; michael.dillon at bt.com; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
>> listingservice
>>
>>
>> On Jun 12, 2009, at 12:28 PM, Kevin Kargel wrote:
>>
>>>
>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-
>>>> bounces at arin.net] On
>>>> Behalf Of Scott Leibrand
>>>> Sent: Friday, June 12, 2009 11:09 AM
>>>> To: <michael.dillon at bt.com>
>>>> Cc: <arin-ppml at arin.net>
>>>> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
>>>> listingservice
>>>>
>>>> That might work too, but ARIN counsel, the AC, and others involved
>>>> thought it belonged in the 2008-2 transfer policy, and the CEO has
>>>> said they don't plan to do a listing service without policy directing
>>>> them to do so.
>>>>
>>>> What do you think of the idea itself?
>>>>
>>>> -Scott
>>>>
>>> I probably should have mentioned that it is a nifty idea if it was
>>> just us
>>> NetOps working with each other and the lawyers and governments would
>>> keep
>>> out of it.  I just don't see much hope that the litigators and
>>> regulators
>>> will keep their fingers out of the pie.
>> Hi Kevin,
>>
>> Out of curiosity, do you think that litigators and regulators are more
>> likely (or maybe very likely) to keep their fingers out if, after
>> enabling the emergence of commercial IPv4 transfers, the RIRs take no
>> further actions of any kind related to any IPv4 markets that emerge
>> thereafter? Are your views on that probability-of-intervention
>> question based on any particular expectation about whether and how
>> IPv4 markets will actually work, or are they independent of all such
>> expectations (i.e., no matter how things turn out, it would be better
>> in all cases for the RIRs to take no position / no action at all)?
>>
>> TV
> 
> My expectation is now that we have valuated IP addresses that value and/or
> the 'ownership' of that value will be contested in courts which will bring
> in litigators.  Litigators will establish precedents and points in law that
> will now have to be considered in all matters.  Record keeping requirements
> will be much stricter to defend against legal actions.  
> 
> My expectation is also now that there is a quantifiable value assigned to IP
> addresses that governments will find a way to tax them, at the very least
> with sales tax on the exchange or transfer of a valued property, possibly
> also with a use tax and/or a recurring property tax.  Once governments have
> their pinkies in the mix then special interest groups will push government
> to regulate the distribution and use of IP addresses and the governments
> will be anxious to regulate the product in order to justify the taxes.  
> 
> I fear that 2009-1 has doomed us to a future of cost, cost controls and
> regulation and there is nothing we can do about it now.  The sleeping bear
> has been nudged and will soon awake.  This is beyond our control anymore.

Kevin there is a political component to all of this your missing.

The large ISP's clearly have it in their power to force IPv6 on the
Internet if they simply get together and unify against the customers
who don't want to pay for upgrades and the content providers who
don't want to buy new servers.

Right now the economic balance is that if your a large ISP there is 
little to no cost to continue to provide IPv4 to customers who already
have it and to new customers that want it.  But there's a lot of cost in
lost customers if you try to force customers to take IPv6

If government regulates and taxes IPv4 then now suddenly the ISP's
are on a see-saw, on one hand they lose money by dealing with the
government if they keep IPv4, on the other hand they lose money if
they tell customers to switch to IPv6 and the customers leave.

If government interference becomes too expensive, it suddenly is cheaper 
to tell customers the big ISP is dropping IPv4 and let chips fall where 
they may.  If all the large ISP's drop IPv4 at the same time, then they 
won't even have the customer loss - the customers will just have to suck 
it up.

Take for example the auto tire industry.  Bias-ply auto tires are 
cheaper to manufacture, cheaper to sell.  Yet we are all driving on 
radials now in a passenger car - because all of the tire manufacturers 
basically got together and agreed to stop selling bias ply tires in
passenger car sizes.  It
was not a customer-driven decision because there's always customers who
would have bought the cheaper bias ply tires simply because they were
cheaper.  And us customers had to suck it up and take it.

There are numerous examples of industries dominated by a few major
brands who colluded against customers and got their way.  It either
saved them money to do this or it caused average product prices to
rise, and they made more money on the margins.

Take the soft drink industry.  Soft drinks made with real sugar taste 
better - it's why Coca Cola is still made with sugar in Mexico.

But sugar is a lot more expensive than HFC's.  Both Coke and Pepsi
knew that if one of them switched to HFC's and the other didn't, then
the one that kept using sugar would get all of the customers.

So, Coke and Pepsi got together and both switched to HFC's at the same 
time - and neither one lowered prices - and as a result, the customers
had no choice but to start drinking HFCs.

Ted


From martin.hannigan at batelnet.bs  Fri Jun 12 20:37:06 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Fri, 12 Jun 2009 20:37:06 -0400
Subject: [arin-ppml] [arin-council] Returning Legacy Space to IANA.
	Attorney client communcation.
In-Reply-To: <313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<4607e1d50906111727l66f41e83o9afbe21ae4177a0e@mail.gmail.com>
	<313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
Message-ID: <4607e1d50906121737m45767018m936e91cc7f61bb39@mail.gmail.com>

On Fri, Jun 12, 2009 at 1:39 PM, Jo Rhett<jrhett at svcolo.com> wrote:
> On Jun 11, 2009, at 5:27 PM, Martin Hannigan wrote:
>
>>> On Jun 9, 2009, at 5:49 PM, Martin Hannigan wrote:
>>>>
>>>> Most large service providers in the region don't believe we're going
>>>> to get a fair shake in the end. Hopefully, the AC and BoT realize
>>>> that.
>>>
>
>> On Thu, Jun 11, 2009 at 2:57 AM, Jo Rhett<jrhett at svcolo.com> wrote:
>>>
>>> Martin, I know you are clueful. ? ?So I'm assuming that this response
>>> can't
>>> possibly be what it means on its face.
>>>
>>> Can you name a large service provider in the ARIN region who doesn't have
>>> miles and miles (on any yardstick of your choice) of extra lenient space
>>> they are paying nothing for? ? ?That the people who have gotten the most
>>> for
>>> free are afraid that they might lose some of that advantage isn't
>>> surprising.
>>
>> You think someone who has and is using a /8 is stressing over the $18K
>> yearly fee? Cost is probably the least interesting argument.
>
> I wasn't thinking of cost, so yes I agree.


Let me restate, they are not stressing over _current_ costs.


>
>> I can't define excess space because I don't know the specifics as to
>> why space that someone may have isn't being utilized. Wearing
>> sunglasses at night blinds you to most everything around you except
>> the bright lights and here we have what appears to be excess space as
>> that light.
>
> Leaving the direct insult aside, it appears you are trying to say that I
> don't know what the problem they fear is. ?Yes, that is true. ?Could you
> skip the insult and instead be specific about what these providers don't
> think they are getting a fair shake on?

That's not an insult, that's an analogy. I apologize if it offended you.

Best Regards,

-M<


From owen at delong.com  Fri Jun 12 21:40:08 2009
From: owen at delong.com (Owen DeLong)
Date: Fri, 12 Jun 2009 18:40:08 -0700
Subject: [arin-ppml] Large hole in IPv6 assignment logic
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A7FCF@SUEX07-MBX-04.ad.syr.edu>
References: <28E139F46D45AF49A31950F88C497458018C2649@E03MVZ2-UKDY.domain1.systemhost.net>
	<4A2E7E07.2000407@temk.in> <4A2E95D7.2090802@sprunk.org>,
	<4A30A334.4000002@bogus.com>
	<75822E125BCB994F8446858C4B19F0D77B233E85@SUEX07-MBX-04.ad.syr.edu>
	<587399.96295.qm@web63302.mail.re1.yahoo.com>
	<75822E125BCB994F8446858C4B19F0D77B1A7FCF@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <E859546C-AC6B-44AF-83E3-FEDE0C45E2ED@delong.com>


On Jun 11, 2009, at 10:15 PM, Milton L Mueller wrote:

>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- 
>> bounces at arin.net] On
>> Sure.  In general, ISPs (LIRs) generate more work for ARIN, so they  
>> pay
>> more of the costs.
>
> Got it, thanks. Will this still hold true with the large IPv6  
> allocations?
>
>
Even more so.  End users are going to be far less likely to come back  
for additional
space and ISPs will still be filing just as many or more SWIPs and  
other such
transactions.

Owen



From owen at delong.com  Fri Jun 12 22:32:24 2009
From: owen at delong.com (Owen DeLong)
Date: Fri, 12 Jun 2009 19:32:24 -0700
Subject: [arin-ppml] [arin-announce] Policy Proposal: Transfer
	listingservice
In-Reply-To: <48B27EA6-74E9-4B6E-8761-BF6798491025@pch.net>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>
	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BF@mail>
	<48B27EA6-74E9-4B6E-8761-BF6798491025@pch.net>
Message-ID: <FB814C97-F234-41CC-9985-603DAFFC61B5@delong.com>


On Jun 12, 2009, at 10:13 AM, Tom Vest wrote:

>
> On Jun 12, 2009, at 12:28 PM, Kevin Kargel wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- 
>>> bounces at arin.net] On
>>> Behalf Of Scott Leibrand
>>> Sent: Friday, June 12, 2009 11:09 AM
>>> To: <michael.dillon at bt.com>
>>> Cc: <arin-ppml at arin.net>
>>> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
>>> listingservice
>>>
>>> That might work too, but ARIN counsel, the AC, and others involved
>>> thought it belonged in the 2008-2 transfer policy, and the CEO has
>>> said they don't plan to do a listing service without policy  
>>> directing
>>> them to do so.
>>>
>>> What do you think of the idea itself?
>>>
>>> -Scott
>>>
>>
>> I probably should have mentioned that it is a nifty idea if it was  
>> just us
>> NetOps working with each other and the lawyers and governments  
>> would keep
>> out of it.  I just don't see much hope that the litigators and  
>> regulators
>> will keep their fingers out of the pie.
>
> Hi Kevin,
>
> Out of curiosity, do you think that litigators and regulators are  
> more likely (or maybe very likely) to keep their fingers out if,  
> after enabling the emergence of commercial IPv4 transfers, the RIRs  
> take no further actions of any kind related to any IPv4 markets that  
> emerge thereafter? Are your views on that probability-of- 
> intervention question based on any particular expectation about  
> whether and how IPv4 markets will actually work, or are they  
> independent of all such expectations (i.e., no matter how things  
> turn out, it would be better in all cases for the RIRs to take no  
> position / no action at all)?
>
IANAL, but, I think they are far less likely to name ARIN as defendants.

Owen



From owen at delong.com  Fri Jun 12 23:32:22 2009
From: owen at delong.com (Owen DeLong)
Date: Fri, 12 Jun 2009 20:32:22 -0700
Subject: [arin-ppml] Policy Proposal: Transfer listing service
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B220A7B@SUEX07-MBX-04.ad.syr.edu>
References: <4A326A86.8060004@arin.net>
	<75822E125BCB994F8446858C4B19F0D77B220A7B@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <6288804E-3999-4260-8D10-3AB08B95F2E9@delong.com>

The listing service proposed would be intended to list blocks  
available/blocks wanted
like a stock listing service.

ARIN will be tracking all transfers, although I am not sure to what  
extent they will be
disclosed.  I believe the disclosure provisions of 2008-2 went away  
with 2008-6/2009-1.

Owen

On Jun 12, 2009, at 2:08 PM, Milton L Mueller wrote:

> Why not list all transfers? Will ARIN keep track of designated  
> tansfers under 2009-1 in any other way?
>
>> -----Original Message-----
>>  recipients. Participation in the listing service is voluntary.
>>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From tvest at pch.net  Sat Jun 13 03:24:51 2009
From: tvest at pch.net (Tom Vest)
Date: Sat, 13 Jun 2009 03:24:51 -0400
Subject: [arin-ppml] [arin-announce] Policy Proposal: Transfer
	listingservice
In-Reply-To: <FB814C97-F234-41CC-9985-603DAFFC61B5@delong.com>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>
	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BF@mail>
	<48B27EA6-74E9-4B6E-8761-BF6798491025@pch.net>
	<FB814C97-F234-41CC-9985-603DAFFC61B5@delong.com>
Message-ID: <755FA9E6-07DD-43BD-82DB-EF2B2D5B90C5@pch.net>


On Jun 12, 2009, at 10:32 PM, Owen DeLong wrote:

>
> On Jun 12, 2009, at 10:13 AM, Tom Vest wrote:
>
>>
>> On Jun 12, 2009, at 12:28 PM, Kevin Kargel wrote:
>>
>>>> -----Original Message-----
>>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml- 
>>>> bounces at arin.net] On
>>>> Behalf Of Scott Leibrand
>>>> Sent: Friday, June 12, 2009 11:09 AM
>>>> To: <michael.dillon at bt.com>
>>>> Cc: <arin-ppml at arin.net>
>>>> Subject: Re: [arin-ppml] [arin-announce] Policy Proposal: Transfer
>>>> listingservice
>>>>
>>>> That might work too, but ARIN counsel, the AC, and others involved
>>>> thought it belonged in the 2008-2 transfer policy, and the CEO has
>>>> said they don't plan to do a listing service without policy  
>>>> directing
>>>> them to do so.
>>>>
>>>> What do you think of the idea itself?
>>>>
>>>> -Scott
>>>>
>>>
>>> I probably should have mentioned that it is a nifty idea if it was  
>>> just us
>>> NetOps working with each other and the lawyers and governments  
>>> would keep
>>> out of it.  I just don't see much hope that the litigators and  
>>> regulators
>>> will keep their fingers out of the pie.
>>
>> Hi Kevin,
>>
>> Out of curiosity, do you think that litigators and regulators are  
>> more likely (or maybe very likely) to keep their fingers out if,  
>> after enabling the emergence of commercial IPv4 transfers, the RIRs  
>> take no further actions of any kind related to any IPv4 markets  
>> that emerge thereafter? Are your views on that probability-of- 
>> intervention question based on any particular expectation about  
>> whether and how IPv4 markets will actually work, or are they  
>> independent of all such expectations (i.e., no matter how things  
>> turn out, it would be better in all cases for the RIRs to take no  
>> position / no action at all)?

> IANAL, but, I think they are far less likely to name ARIN as  
> defendants.
>
> Owen

I agree entirely on that count, but wonder if that should be the  
primary determinant for which way to come down on this question (?).

If Kevin is right, then both ARIN the institution and "the industry"  
-- including every ARIN member -- is facing a choice much like  
Pascal's Wager:

1. What does (my company) stand to gain, or alternately lose, by  
assuming the best possible outcome and acting accordingly (i.e., doing  
nothing)?
2. What does (my company) stand to gain, or alternately lose, by  
taking positive action sooner rather than later, to hedge against  
something other than the best possible outcome?

3,4...? Repeat as necessary, replacing "my company" with any other  
nouns for which the same questions would seem to apply (e.g., the  
industry, the Internet, ARIN, future generations, etc.)...

I don't know, maybe all relevant questions have already been answered,  
or rendered moot, by the transfer decision itself. However, Scott's  
recent proposals seem to suggest otherwise.

TV





From martin.hannigan at batelnet.bs  Sat Jun 13 10:40:40 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Sat, 13 Jun 2009 10:40:40 -0400
Subject: [arin-ppml] [arin-council] Returning Legacy Space to IANA.
	Attorney client communcation.
In-Reply-To: <313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<4607e1d50906111727l66f41e83o9afbe21ae4177a0e@mail.gmail.com>
	<313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
Message-ID: <4607e1d50906130740m63a4bba4ud517ef243a3b3cf4@mail.gmail.com>

On Fri, Jun 12, 2009 at 1:39 PM, Jo Rhett<jrhett at svcolo.com> wrote:
> On Jun 11, 2009, at 5:27 PM, Martin Hannigan wrote:


[ clip ]

>
> You want fairness? ?Let's make the environment truly fair: ?before Cogent or
> any other provider with legacy space can get any more allocations, they have
> to demonstrate 80% usage of ALL of their space, including all legacy blocks.
> ?*THAT* would be fair. ?But we both know that ARIN has no stomach for this,
> and it won't happen. ? Fair? ?No. ?Certainly a large provider advantage.

It's not hard to show 80% utilization. It's harder to show that it is efficient.

[ clip ]

>
> Now if they went and applied strict ARIN allocation policy to ALL of their
> space, I'll bet they have years of space already in their possession...

We've got north of 500 posts related to 2009-3. IMHO, this is the
small stuff and the issue of whether we return space to the IANA
probably has little to do with large provider utilization. We've
diverged from the point of fairness and regional responsibility.

Getting back on topic, I think it's reasonable to conclude that
returning space to the IANA through global policy is likely to a) be
met with fierce resistance in this regoin, b) fuel the conditions that
are allowing an ip address market (through whatever vehicle you prefer
i.e. asset purchases, M&A, etc.) to flourish, and c) that the lawyers
will ultimately become involved (AC NDA's).

Best,

Martin


From mueller at syr.edu  Sat Jun 13 13:06:50 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Sat, 13 Jun 2009 13:06:50 -0400
Subject: [arin-ppml] Policy Proposal: Transfer listing service
In-Reply-To: <6288804E-3999-4260-8D10-3AB08B95F2E9@delong.com>
References: <4A326A86.8060004@arin.net>
	<75822E125BCB994F8446858C4B19F0D77B220A7B@SUEX07-MBX-04.ad.syr.edu>
	<6288804E-3999-4260-8D10-3AB08B95F2E9@delong.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A8019@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]


> I believe the disclosure provisions of 2008-2 went away
> with 2008-6/2009-1.

I think we can all agree this is not good. 
Given the controversial nature of the transfers they should be publicly tracked. There are many gradations of tracking, of course. One can identify the number of trades and the size of the blocks traded (minimal), identify the specific blocks traded and the parties, etc. 

--MM
 


From farmer at umn.edu  Sat Jun 13 14:04:58 2009
From: farmer at umn.edu (David Farmer)
Date: Sat, 13 Jun 2009 13:04:58 -0500
Subject: [arin-ppml] Policy Proposal: Transfer listing service
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A8019@SUEX07-MBX-04.ad.syr.edu>
References: <4A326A86.8060004@arin.net>,
	<6288804E-3999-4260-8D10-3AB08B95F2E9@delong.com>,
	<75822E125BCB994F8446858C4B19F0D77B1A8019@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A33A3FA.29611.D9B7E89@farmer.umn.edu>

On 13 Jun 2009 Milton L Mueller wrote:

> > From: Owen DeLong [mailto:owen at delong.com]
> > I believe the disclosure provisions of 2008-2 went away
> > with 2008-6/2009-1.
> 
> I think we can all agree this is not good. 
> Given the controversial nature of the transfers they should be
> publicly tracked. There are many gradations of tracking, of course.
> One can identify the number of trades and the size of the blocks
> traded (minimal), identify the specific blocks traded and the parties,
> etc. 

I believe that tracking and reporting of transfers is necessary, 
but I don't believe it is fatal that it is not in the policy, much of 
the reporting ARIN currently does is not in policy.  So, one 
could argue that it is mostly and operational issue.  I would 
recommend that if you have specific suggestions on how 
transfers should be tracked and how the information should be 
presented to the community that you make a suggestion 
through the ACSP.

https://www.arin.net/participate/acsp/index.html

With the ACSP suggestions are tracked and at least a initial 
response will be provided in 10 business days.


===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From michael.dillon at bt.com  Sat Jun 13 15:25:41 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sat, 13 Jun 2009 20:25:41 +0100
Subject: [arin-ppml] [arin-announce]
	PolicyProposal:	Transfer	listingservice
In-Reply-To: <4A32C4F5.4090404@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801A2115A@E03MVZ2-UKDY.domain1.systemhost.net>

> During the housing boom of 2004-2006, I saw (in my own 
> neighborhood) a number of For Sale By Owner homes going 
> through craigslist - they NEVER touched the "official" 
> multiple listing service, never paid any fees for that, never 
> paid any fees to any Realtor, never paid fees to craigslist.  

I think that we have now established that a listing service
for IP address blocks already does exist, so there is no
point in any further discussions about creating one. If anyone
out there wants to try to compete with craigslist, they are
welcome to try.

I still oppose ARIN getting involved in any listing service
or brokerage or any activity that facilitates address
buyers and sellers from getting together. At most, ARIN
could maintain a list on a webpage indicating which listing
services are understood to have address blocks available.

--Michael Dillon

P.S. craigslist and Ebay have cornered the market in listing
items for resale. Why does anyone think that there is any
point in duplicating their work, but limiting the commodity
to only spare ARIN IPv4 address blocks?





From kkargel at polartel.com  Mon Jun 15 11:36:17 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 15 Jun 2009 10:36:17 -0500
Subject: [arin-ppml] [arin-announce] Policy Proposal: Transfer
	listingservice
In-Reply-To: <FB814C97-F234-41CC-9985-603DAFFC61B5@delong.com>
References: <28E139F46D45AF49A31950F88C49745801A21027@E03MVZ2-UKDY.domain1.systemhost.net>
	<508361B9-C22E-415F-8E49-41E4A2F56E73@gmail.com>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2BF@mail>
	<48B27EA6-74E9-4B6E-8761-BF6798491025@pch.net>
	<FB814C97-F234-41CC-9985-603DAFFC61B5@delong.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2C9@mail>

> >
> > Hi Kevin,
> >
> > Out of curiosity, do you think that litigators and regulators are
> > more likely (or maybe very likely) to keep their fingers out if,
> > after enabling the emergence of commercial IPv4 transfers, the RIRs
> > take no further actions of any kind related to any IPv4 markets that
> > emerge thereafter? Are your views on that probability-of-
> > intervention question based on any particular expectation about
> > whether and how IPv4 markets will actually work, or are they
> > independent of all such expectations (i.e., no matter how things
> > turn out, it would be better in all cases for the RIRs to take no
> > position / no action at all)?
> >
> IANAL, but, I think they are far less likely to name ARIN as defendants.
> 
> Owen

I am not worried so much about ARIN becoming a defendant as I am about how
it will affect the normal course of business.  However, as has been stated,
the barn doors are open and the cows are out, it just remains to see where
they go.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090615/12ca755c/attachment.bin>

From kkargel at polartel.com  Mon Jun 15 11:47:06 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 15 Jun 2009 10:47:06 -0500
Subject: [arin-ppml]
	[arin-announce]PolicyProposal:	Transfer	listingservice
In-Reply-To: <28E139F46D45AF49A31950F88C49745801A2115A@E03MVZ2-UKDY.domain1.systemhost.net>
References: <4A32C4F5.4090404@ipinc.net>
	<28E139F46D45AF49A31950F88C49745801A2115A@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2CA@mail>

> 
> --Michael Dillon
> 
> P.S. craigslist and Ebay have cornered the market in listing
> items for resale. Why does anyone think that there is any
> point in duplicating their work, but limiting the commodity
> to only spare ARIN IPv4 address blocks?
> 
> 
> 
I agree that CL and Ebay have a very efficient and somewhat sorted out
system and that reinventing the wheel is not necessary and would probably be
futile.

If/when and active market develops I would not be surprised to see eBay
develop a specialized brokerage such as they have for vehicles.  All it will
take is enough traffic for it to be profitable for them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090615/dc4b98ca/attachment.bin>

From tedm at ipinc.net  Mon Jun 15 13:40:14 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 15 Jun 2009 10:40:14 -0700
Subject: [arin-ppml]
	[arin-announce]PolicyProposal:	Transfer	listingservice
In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2CA@mail>
References: <4A32C4F5.4090404@ipinc.net>	<28E139F46D45AF49A31950F88C49745801A2115A@E03MVZ2-UKDY.domain1.systemhost.net>
	<70DE64CEFD6E9A4EB7FAF3A06314106601B4B2CA@mail>
Message-ID: <4A36877E.1080206@ipinc.net>

Kevin Kargel wrote:
>> --Michael Dillon
>>
>> P.S. craigslist and Ebay have cornered the market in listing
>> items for resale. Why does anyone think that there is any
>> point in duplicating their work, but limiting the commodity
>> to only spare ARIN IPv4 address blocks?
>>
>>
>>
> I agree that CL and Ebay have a very efficient and somewhat sorted out
> system and that reinventing the wheel is not necessary and would probably be
> futile.
> 
> If/when and active market develops I would not be surprised to see eBay
> develop a specialized brokerage such as they have for vehicles.  All it will
> take is enough traffic for it to be profitable for them.
> 

That won't ever happen.  Ebay is large enough now that they are 
beginning to get worried about anti-trust actions against them, so
they have quietly been scraping off a large percentage of their
low-dollar sellers in the last few years

One of the first to go were the crafters, these are the 60-year-old
grandmaws and such knitting sweaters and doilies - today if you want
to get any of that, you have to go to etsy  (www.etsy.com)  Ebay
changed T&C to the point that those sellers can't deal with Ebay
any longer.  (and trust me those sellers are pretty POed about it)

If you google up unhappy ebay sellers you will end up with a list of
the major alternative online auction sites - every one of them is
specializing in some type of product, and vacuuming away the Ebay
sellers from Ebay that deal with those products.

There's no question if Ebay wanted they could put those places out
of business - but they are doing the same thing Microsoft is doing
with Linux - allowing the low-dollar markets to fall away and keeping
the cherry ones.

Vehicles and vehicle sales are way too profitable to let go - which is
why they have a special marketplace.  IPv4 sales, even though there may
be some spectacularly expensive ones for a while - can't hold a candle
to vehicle and vehicle parts sales.

If nobody sets up a specialized listing service for IPv4 then those
will take place on ebay and CL - but it's a market ripe for a small 
specialized listing service.

Ted


From bjohnson at drtel.com  Mon Jun 15 13:51:12 2009
From: bjohnson at drtel.com (Brian Johnson)
Date: Mon, 15 Jun 2009 12:51:12 -0500
Subject: [arin-ppml] large vs small?
In-Reply-To: <4A318FEE.9090904@ipinc.net>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com><m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com><624960.88403.qm@web63306.mail.re1.yahoo.com>
	<4A318FEE.9090904@ipinc.net>
Message-ID: <29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>



- Brian

<snip>
>
> I've heard the arguments that supposedly it takes less work for ARIN
to
> manage large allocations than small allocations.  Then I look at the
> work that ARIN has done for us over the years on our small allocation
> (ie: nothing since originally issuing it) and I cannot understand why
> anyone would say this.  How can ARIN do negative work?  Less work than
> nothing is negative.

So you are assuming that ARIN has to do "work" on the larger
allocations? Please explain what work needs to be done on an allocation,
post it being allocated. Also explain what the difference in allocation
size has to do with doing such work.

> 
> Cost per IP is much less for large allocations than small allocations.

I don't understand this argument. YOU DO NOT PAY FOR IP ADDRESSES. THE
FEE IS A MEMBERSHIP FEE.

> 
> I might feel differently if I had heard that ARIN was spending months
> fighting with small IPv4 holders over the phone for them to release
> resources.  But then I'd wonder how exactly doing this would free up
> significant IPv4
> 
> When a large ISP gets an IPv4 address for less money than a small ISP
> that is anticompetitive.  The only reason the community hasn't
revolted
> is the expenditures work out to pennies per year per IP and people
> think
> that a bunch of very tiny expenditures are somehow less interesting
> than
> one very large expenditure.

The annual fee to a large ISP is more than it is to a small ISP. If you
are trying to make it an even playing field, let's make the fee the same
for every member... oops that doesn't help your argument does it. :) The
"cost per IP" is a non-starter in my mind because YOU DO NOT PAY FOR IP
ADDRESSES TO BEGIN WITH.

<snip>
> 
> I'd assume large ISP's don't participate because any of their
technical
> people who understand the issues are under orders to say nothing
> publically without vetting it with a company lawyer.  That's one
reason
> I don't work for a large company, frankly.
> 
> I do think it's a mistake to assume the large ISP's aren't paying
> attention to what goes on here.  I'm sure if we did something that
hurt
> them you would suddenly find out how much they would participate.
> 
> That's probably why fees are not under the control of this list. ;-)

<sarcasm>I love hyperbole and "class-warfare".</sarcasm>

- Brian



From petelists at templin.org  Mon Jun 15 14:42:24 2009
From: petelists at templin.org (Pete Templin)
Date: Mon, 15 Jun 2009 14:42:24 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com><m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com><624960.88403.qm@web63306.mail.re1.yahoo.com>	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
Message-ID: <4A369610.5090408@templin.org>

Brian Johnson wrote:

> The annual fee to a large ISP is more than it is to a small ISP. If you
> are trying to make it an even playing field, let's make the fee the same
> for every member... oops that doesn't help your argument does it. :) The
> "cost per IP" is a non-starter in my mind because YOU DO NOT PAY FOR IP
> ADDRESSES TO BEGIN WITH.

I recently had to learn the ins and outs of ARIN fees, and although ARIN 
updated their fee language in conjunction with their site refresh, it's 
still not that clear in my humble opinion.  Regardless, having learned 
the ins and outs, I think it's important to make clear, with regard only 
to IPv4 fees:

The annual fee to an ISP who received a "large" amount of v4 address 
space in at least one anniversary year, but not an "x-large" amount of 
v4 space in any anniversary year, is more than the annual fee to an ISP 
who has received a "small" amount of v4 address space in at least one 
anniversary year, but not a "medium" amount of v4 space in any 
anniversary year.

Long story short, the annual fee is not tied to the total amount of v4 
space issued to an organization.

pt


From tedm at ipinc.net  Mon Jun 15 15:59:35 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 15 Jun 2009 12:59:35 -0700
Subject: [arin-ppml] large vs small?
In-Reply-To: <29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com><m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com><624960.88403.qm@web63306.mail.re1.yahoo.com>	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
Message-ID: <4A36A827.9070503@ipinc.net>

Brian Johnson wrote:
> 
> - Brian
> 
> <snip>
>> I've heard the arguments that supposedly it takes less work for ARIN
> to
>> manage large allocations than small allocations.  Then I look at the
>> work that ARIN has done for us over the years on our small allocation
>> (ie: nothing since originally issuing it) and I cannot understand why
>> anyone would say this.  How can ARIN do negative work?  Less work than
>> nothing is negative.
> 
> So you are assuming that ARIN has to do "work" on the larger
> allocations? Please explain what work needs to be done on an allocation,
> post it being allocated. Also explain what the difference in allocation
> size has to do with doing such work.

Your confusing ISSUE costs with MAINTAINENCE costs.

ARIN fees do not currently discriminate when it's also clearly obvious
that most of ARIN's work goes into making ISSUES of numbering.  Very 
little of their work goes into MAINTAINING issues that have already
been made.

If a large OR a small org doesn't bother ARIN for additional numbering
then costs to maintain that issue are very small.

Essentially what is going on right now is that the orgs, both large
or small, that are MAINTAINING their allocations, and NOT requesting
new, additional, ones, these orgs are SUBSIDIZING the expenses
of making IP issues to the orgs who ARE doing a lot of IP requests.

And, MOST of the expenses are associated with IPv4 - NOT IPv6 - because
of the rule that says that if you have an existing IPv4 allocation
that you qualify for an IPv6 allocation.  Most IPv6 allocations are
to orgs that already have IPv4 so they are basically just rubber stamped.

The mandated POC cleanup will change this a bit - but, mainly it will 
make it so that orgs that maintain correct POC's will be subsidizing
the naughty orgs who don't maintain their POCs

> 
>> Cost per IP is much less for large allocations than small allocations.
> 
> I don't understand this argument. YOU DO NOT PAY FOR IP ADDRESSES. THE
> FEE IS A MEMBERSHIP FEE.
> 

This is like Costco claiming that their price
on tires is lower than anyone else and they have a better warranty
than the tire place down the street which tacks on an extra $175 for
the extended 5 year warranty that's comparable to Costco's

When, in order to retain the 5 year warranty on your Costco tires, you 
must continue to pay your yearly $35 membership fee.

Your membership argument is nothing more than marketing nonsense.  The
yearly membership fee is required to be paid to maintain allocations,
thus it is a fee for the IP numbers in those allocations.

>> I might feel differently if I had heard that ARIN was spending months
>> fighting with small IPv4 holders over the phone for them to release
>> resources.  But then I'd wonder how exactly doing this would free up
>> significant IPv4
>>
>> When a large ISP gets an IPv4 address for less money than a small ISP
>> that is anticompetitive.  The only reason the community hasn't
> revolted
>> is the expenditures work out to pennies per year per IP and people
>> think
>> that a bunch of very tiny expenditures are somehow less interesting
>> than
>> one very large expenditure.
> 
> The annual fee to a large ISP is more than it is to a small ISP. If you
> are trying to make it an even playing field, let's make the fee the same
> for every member...

No, let's make the fee the same for every IP address regardless of who
owns what netblock it's in.

  oops that doesn't help your argument does it. :) The
> "cost per IP" is a non-starter in my mind because YOU DO NOT PAY FOR IP
> ADDRESSES TO BEGIN WITH.
> 

Your very confused here.

The ONLY large orgs that really and truly cost ARIN -LESS- money on
a cost-per-IP basis are the large orgs who are requesting large 
allocations, repeatedly.

Meaning, large orgs that are growing in leaps and bounds.

Large orgs who's current large allocations were obtained from a
series of small allocation requests, which were then aggregated
together, cost ARIN the same amount as a bunch of small
orgs who got their numbers then haven't bothered ARIN since.

You also are (conveniently) ignoring NAT in the equation.
Growth in ARIN's region for additional IP addressing comes from
3 sources:

a) people unconnected to the Internet, connecting

b) people connected to the Internet adding devices to be connected

c) poorly run ISP's going bankrupt and releasing their connected
customers to the wild, which are then picked up by competitors

Right now, variable a is a factor of population growth and market 
penetration - and both have slowed.  variable c has also decreased
as the maturing market has weeded out many ISPs.  variable b has
also dropped due to the increase in NAT devices.

If nat does not take hold with IPv6 then variable b may become
higher.  If it does, then variable b will not.

In short, the likelihood is once market penetration is completed
to the extent that, for example, the telephone network has, we
will see an overall drop in demand for new IP allocations and will
enter a period of time that most ISP's will be living with what they
already have and not asking for more.

In which case, ARIN's costs SHOULD drop unless ARIN is tasked with
additional mandates.

But, much more importantly, ARIN expense difference between large and 
small orgs will shrink to little or nothing.

Frankly, I think that the majority of orgs in the US have
already entered or are soon going to enter the maintainence
mode of their business

Which basically means most US ISP's will be subsidizing the
rest of the ARIN region ISP's where growth is happening.


> <snip>
>> I'd assume large ISP's don't participate because any of their
> technical
>> people who understand the issues are under orders to say nothing
>> publically without vetting it with a company lawyer.  That's one
> reason
>> I don't work for a large company, frankly.
>>
>> I do think it's a mistake to assume the large ISP's aren't paying
>> attention to what goes on here.  I'm sure if we did something that
> hurt
>> them you would suddenly find out how much they would participate.
>>
>> That's probably why fees are not under the control of this list. ;-)
> 
> <sarcasm>I love hyperbole and "class-warfare".</sarcasm>
> 

Well, it's a common debate tactic to use emotional labels to try to
obscure the real issues.  Which you are doing here.

The fact is that the fee discussion is purely an accounting argument.
ARIN has chosen one way to interpret it's expenses, when there are
several other equally and I think more valid, ways of interpreting
them.

Your basically arguing everyone should pay the same amount.  I invite
you to try that argument out on your insurance agent for car insurance
the next time you talk to him.  I doubt you will get very far.

Ted


From spiffnolee at yahoo.com  Mon Jun 15 16:22:26 2009
From: spiffnolee at yahoo.com (Lee Howard)
Date: Mon, 15 Jun 2009 13:22:26 -0700 (PDT)
Subject: [arin-ppml] large vs small?
In-Reply-To: <4A36A827.9070503@ipinc.net>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com><m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com><624960.88403.qm@web63306.mail.re1.yahoo.com>
	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<4A36A827.9070503@ipinc.net>
Message-ID: <345306.5579.qm@web63301.mail.re1.yahoo.com>


Ted Mittelstaedt replied to Brian Johnson:



> > So you are assuming that ARIN has to do "work" on the larger
> > allocations? Please explain what work needs to be done on an allocation,
> > post it being allocated. Also explain what the difference in allocation
> > size has to do with doing such work.
> 
> Your confusing ISSUE costs with MAINTAINENCE costs.
>
> ARIN fees do not currently discriminate when it's also clearly obvious
> that most of ARIN's work goes into making ISSUES of numbering.  Very little of 
> their work goes into MAINTAINING issues that have already
> been made.

Earlier this month I listed many of the services ARIN provides, few of which
were issuance costs.
http://lists.arin.net/pipermail/arin-ppml/2009-June/014336.html

Evaluating requests for address space is only one very important part of
ARIN's services.  Facilitating the policy process, development of services,
education on IPv6 and other technologies, and coordination with other
organizations are all expensive activities.  The costs for those activities might
be allocated differently than direct evaluation of applications.

> > I don't understand this argument. YOU DO NOT PAY FOR IP ADDRESSES. THE
> > FEE IS A MEMBERSHIP FEE.
> > 
> 
> This is like Costco claiming that their price
> on tires is lower than anyone else ... you must 
> continue to pay your yearly $35 membership fee.
>
> Your membership argument is nothing more than marketing nonsense.  The
> yearly membership fee is required to be paid to maintain allocations,
> thus it is a fee for the IP numbers in those allocations.

But that allocation is not the only service you get from ARIN.
(Nor do most people buy nothing but one set of tires from Costco, but I
shouldn't even play with analogies).

> Well, it's a common debate tactic to use emotional labels to try to
> obscure the real issues.  Which you are doing here.

Irony.  I get it.
Please lose your caps lock key.

> The fact is that the fee discussion is purely an accounting argument.
> ARIN has chosen one way to interpret it's expenses, when there are
> several other equally and I think more valid, ways of interpreting
> them.

For the record, I neither oppose nor support alternate fee structures.
I simply want arguments to be well-formed, well-informed, and 
held on arin-discuss.

> Ted

Lee, who is risking over-posting 



      



From mueller at syr.edu  Mon Jun 15 16:23:23 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 15 Jun 2009 16:23:23 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com><m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com><624960.88403.qm@web63306.mail.re1.yahoo.com>
	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A809A@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----

> YOU DO NOT PAY FOR IP ADDRESSES. THE
> FEE IS A MEMBERSHIP FEE.

That is the claim, and to some extent the claim squares with the ARIN fee structure. In other ways it does not. 

The problem is that ARIN (and other RIRs) calibrate the size of the membership fee based on the size of the address block allocated.  

If the "membership fee" was based on revenues it would lend more support to the claim that the fee is not for IP addresses.

An interesting question in this regard: if someone does not pay their ARIN "membership" fees, do they lose their allocation? Or do they just lose their membership-only services? 

On the other hand, we might well ask, what is wrong with paying more for more addresses? Is it legitimate to use fees as a conservation device? This would certainly increase the incentive to reclaim unused addresses. 

--MM 


From tedm at ipinc.net  Mon Jun 15 16:51:26 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 15 Jun 2009 13:51:26 -0700
Subject: [arin-ppml] large vs small?
In-Reply-To: <345306.5579.qm@web63301.mail.re1.yahoo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com><m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com><624960.88403.qm@web63306.mail.re1.yahoo.com>
	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<4A36A827.9070503@ipinc.net>
	<345306.5579.qm@web63301.mail.re1.yahoo.com>
Message-ID: <4A36B44E.6050300@ipinc.net>

Lee Howard wrote:
> Ted Mittelstaedt replied to Brian Johnson:
> 
> 
> 
>>> So you are assuming that ARIN has to do "work" on the larger
>>> allocations? Please explain what work needs to be done on an allocation,
>>> post it being allocated. Also explain what the difference in allocation
>>> size has to do with doing such work.
>> Your confusing ISSUE costs with MAINTAINENCE costs.
>>
>> ARIN fees do not currently discriminate when it's also clearly obvious
>> that most of ARIN's work goes into making ISSUES of numbering.  Very little of 
>> their work goes into MAINTAINING issues that have already
>> been made.
> 
> Earlier this month I listed many of the services ARIN provides, few of which
> were issuance costs.
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014336.html
> 
> Evaluating requests for address space is only one very important part of
> ARIN's services.  Facilitating the policy process, development of services,
> education on IPv6 and other technologies, and coordination with other
> organizations are all expensive activities.  The costs for those activities might
> be allocated differently than direct evaluation of applications.
> 

Every other one of those activities you listed is used more by orgs that
have more IP addressing allocated to them

In fact, the APPLICATION FEE is one of the few fees that is more closely
"fair" among different-sized orgs, ironically enough.

Yes' I've read the claims that small orgs participate more in the policy
development process.  But that is a red herring since the long-term
cost dwarfs the cost to develop the policy.  The resultant policies have
a far, far greater effect on orgs that hold large allocations than on
orgs that hold small allocations.

For example, the whois POC verification.  Large orgs have more SWIPs, 
more POCs in whois.  ARIN will be spending a heck of a lot more time
cleaning up SWIPS related to large orgs than small ones.

IPv6 outreach also has more effect on large orgs - as the large orgs
HAVE to move to IPv6 simply because there's not enough IPv4 numbers
for them even if all IPv4 allocations were ONLY made to large orgs.

I'm NOT condemning the other activities that ARIN does as bad.  I'm
just saying that large orgs gain more from the entire process than
small orgs do.  Thus, I see it as fundamentally sound that they pay
more money.  If your going to disagree with that conclusion, please
say so.

I ALSO feel they do NOT pay as much as they should.  However, I also
understand that this is typical of many things in life.  For example,
in the US, the fuel tax is equally assessed on passenger cars and on
trucks.  Yet, heavier trucks do most of the road damage.  Thus, the
passenger car drivers end up subsidizing the truck drivers.  That is
the situation with ARIN fees, the large orgs do more to wipe out our
remaining stock of IPv4 than the small orgs do. (if you want to extend
the analogy to the point of silliness)

Whether ARIN will ever decide to DO anything about it, is a different
question.  But, Lee, I recall you asked WHY the small orgs don't
trust the large orgs - well, here's your answer.  Sorry you don't like
it.  Just please have a little respect for the small orgs and quit 
trying to convince them that it's "fair".

Ted


From michael.dillon at bt.com  Mon Jun 15 18:30:10 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 15 Jun 2009 23:30:10 +0100
Subject: [arin-ppml] large vs small?
In-Reply-To: <4A36A827.9070503@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801AA7ED0@E03MVZ2-UKDY.domain1.systemhost.net>


>  The yearly membership fee is required to be paid 
> to maintain allocations, thus it is a fee for the IP numbers 
> in those allocations.

You're wrong. The fee is required to be a member in good
standing, and it is only the members of a non-profit who
have a vote on things like Board of Trustee members, and
the by-laws of the organization. The fees are structured
the way they are because the members want it that way.
ARIN policy does not affect the by-laws or the membership
structure or any ARIN fees. 

> No, let's make the fee the same for every IP address 
> regardless of who owns what netblock it's in.

No, let's wake up to the fact that PPML has no say
in ARIN fees. The public policy mailing list does have
a say in ARIN's number allocation policies, but not in
its fees or fee structure. That's the way it is.

> In which case, ARIN's costs SHOULD drop unless ARIN is tasked 
> with additional mandates.

Which is up to the ARIN members to deal with, not you.

> The fact is that the fee discussion is purely an accounting argument.
> ARIN has chosen one way to interpret it's expenses, when 
> there are several other equally and I think more valid, ways 
> of interpreting them.

No, ARIN's members have chosen...

--Michael Dillon

P.S. There are no fees per IP address because it doesn't make
any sense from an accounting point of view.


From tedm at ipinc.net  Mon Jun 15 18:41:44 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 15 Jun 2009 15:41:44 -0700
Subject: [arin-ppml] large vs small?
In-Reply-To: <28E139F46D45AF49A31950F88C49745801AA7ED0@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745801AA7ED0@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A36CE28.2040406@ipinc.net>

michael.dillon at bt.com wrote:
>>  The yearly membership fee is required to be paid 
>> to maintain allocations, thus it is a fee for the IP numbers 
>> in those allocations.
> 
> You're wrong. 

OK, so if we stop paying our fees then our allocation won't
be pulled?

Please point to where it says this in the NRPM.

> 
> No, let's wake up to the fact that PPML has no say
> in ARIN fees. The public policy mailing list does have
> a say in ARIN's number allocation policies, but not in
> its fees or fee structure. That's the way it is.
>

Did I say it did?  Much it is you assume...


>> In which case, ARIN's costs SHOULD drop unless ARIN is tasked 
>> with additional mandates.
> 
> Which is up to the ARIN members to deal with, not you.
> 

Fear is the path to the Dark Side. Fear leads to anger, anger leads to 
hate, hate leads to suffering.

I sense much fear in you...

Ted


From stephen at sprunk.org  Mon Jun 15 22:56:06 2009
From: stephen at sprunk.org (Stephen Sprunk)
Date: Mon, 15 Jun 2009 21:56:06 -0500
Subject: [arin-ppml] [arin-council] Returning Legacy Space to
 IANA.	Attorney client communcation.
In-Reply-To: <313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<Pine.LNX.4.44.0906051023140.9239-100000@networking.stanford.edu>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com>
	<m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>	<4607e1d50906111727l66f41e83o9afbe21ae4177a0e@mail.gmail.com>
	<313CEC7F-0417-4DF3-BF9D-109F5E192872@svcolo.com>
Message-ID: <4A3709C6.3040509@sprunk.org>

Jo Rhett wrote:
> You want fairness?  Let's make the environment truly fair:  before
> Cogent or any other provider with legacy space can get any more
> allocations, they have to demonstrate 80% usage of ALL of their space,
> including all legacy blocks.  *THAT* would be fair.  But we both know
> that ARIN has no stomach for this, and it won't happen.   Fair?  No. 
> Certainly a large provider advantage.

That was (part of) the intent of 2007-14, which is now NRPM ?12:
https://www.arin.net/policy/nrpm.html#twelve

Note in particular ?12.2(a), ?12.4, and ?12.8, which I think address
your point when combined.  If you think that the language is lacking,
please submit a proposal to fix it.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090615/6e88fe80/attachment.bin>

From mueller at syr.edu  Mon Jun 15 23:37:01 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 15 Jun 2009 23:37:01 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <28E139F46D45AF49A31950F88C49745801AA7ED0@E03MVZ2-UKDY.domain1.systemhost.net>
References: <4A36A827.9070503@ipinc.net>
	<28E139F46D45AF49A31950F88C49745801AA7ED0@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A80A9@SUEX07-MBX-04.ad.syr.edu>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> 
> The fee is required to be a member in good
> standing, and it is only the members of a non-profit who
> have a vote on things like Board of Trustee members, and
> the by-laws of the organization. The fees are structured
> the way they are because the members want it that way.
> ARIN policy does not affect the by-laws or the membership
> structure or any ARIN fees.
> 

You've made this statement many times before, Michael; I get it. I also understand that, in a technical legal sense, you are more or less right about the way ARIN fees are set and about who sets them. But from a common sense point of view, fees and public policy are going to become ever more intimately entwined. And when we talk about fees and how they affect policy (e.g., conservation, incentives to switch to v6, address block allocation sizes, etc.) we are not "setting" fees we are talking about how fees affect or undermine policy. Which is legit. So I will continue doing it until someone throws me off the list. ;-)

--MM



From michael.dillon at bt.com  Tue Jun 16 02:00:34 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 16 Jun 2009 07:00:34 +0100
Subject: [arin-ppml] large vs small?
In-Reply-To: <4A36CE28.2040406@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801AA7EE6@E03MVZ2-UKDY.domain1.systemhost.net>


> OK, so if we stop paying our fees then our allocation won't be pulled?
> 
> Please point to where it says this in the NRPM.

Fees are not covered by ARIN policy, therefore they are not in
the NRPM. If you want to know what happens to a member who
stops paying fees, you should start by looking in the RSA.

> >> In which case, ARIN's costs SHOULD drop unless ARIN is tasked with 
> >> additional mandates.
> > 
> > Which is up to the ARIN members to deal with, not you.
> > 
> 
> Fear is the path to the Dark Side. Fear leads to anger, anger 
> leads to hate, hate leads to suffering.
> 
> I sense much fear in you...

That type of personal attack is not allowed on PPML.

--Michael Dillon


From tedm at ipinc.net  Tue Jun 16 13:09:09 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 16 Jun 2009 10:09:09 -0700
Subject: [arin-ppml] large vs small?
In-Reply-To: <28E139F46D45AF49A31950F88C49745801AA7EE6@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745801AA7EE6@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4A37D1B5.1000305@ipinc.net>

michael.dillon at bt.com wrote:

> That type of personal attack is not allowed on PPML.
> 

I'm glad you are aware of that, Mr. "Which is up to the ARIN members to 
deal with, not you."


Ted


From bill at herrin.us  Tue Jun 16 14:12:53 2009
From: bill at herrin.us (William Herrin)
Date: Tue, 16 Jun 2009 14:12:53 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<624960.88403.qm@web63306.mail.re1.yahoo.com>
	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
Message-ID: <3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>

On Mon, Jun 15, 2009 at 1:51 PM, Brian Johnson<bjohnson at drtel.com> wrote:
>> Cost per IP is much less for large allocations than small allocations.
>
> I don't understand this argument. YOU DO NOT PAY FOR IP ADDRESSES. THE
> FEE IS A MEMBERSHIP FEE.

Brian,

You pay because by jumping through the hoops and paying the fee you
get IP addresses. The rest is more or less a "legal fiction." It's
useful but not sacrosanct. Make no mistake: that we pay ARIN for IP
addresses is a correct description in every other respect.

However we may architect it for legal purposes, the dog still wags the
tail: we buy IP addresses from ARIN and receive the rest of the
services in the package (whether we want to or not!)

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bjohnson at drtel.com  Tue Jun 16 14:43:53 2009
From: bjohnson at drtel.com (Brian Johnson)
Date: Tue, 16 Jun 2009 13:43:53 -0500
Subject: [arin-ppml] large vs small?
In-Reply-To: <3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<g363fagt8a.fsf@nsa.vix.com>
	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com> <m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<624960.88403.qm@web63306.mail.re1.yahoo.com>
	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
Message-ID: <29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>

> -----Original Message-----
> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of
William
> Herrin
> Sent: Tuesday, June 16, 2009 1:13 PM
> To: Brian Johnson
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] large vs small?
> 
> On Mon, Jun 15, 2009 at 1:51 PM, Brian Johnson<bjohnson at drtel.com>
> wrote:
> >> Cost per IP is much less for large allocations than small
> allocations.
> >
> > I don't understand this argument. YOU DO NOT PAY FOR IP ADDRESSES.
> THE
> > FEE IS A MEMBERSHIP FEE.
> 
> Brian,
> 
> You pay because by jumping through the hoops and paying the fee you
> get IP addresses. The rest is more or less a "legal fiction." It's
> useful but not sacrosanct. Make no mistake: that we pay ARIN for IP
> addresses is a correct description in every other respect.
> 
> However we may architect it for legal purposes, the dog still wags the
> tail: we buy IP addresses from ARIN and receive the rest of the
> services in the package (whether we want to or not!)
> 
> Regards,
> Bill Herrin

This is a fruitless argument and I have no idea how I got myself into
this. I disagree that you "buy" anything by being a member of ARIN with
IP addresses being assigned to you. If you want to talk like you know
better, go ahead and do it. I'm out of energy arguing the point.

-Brian



From kkargel at polartel.com  Tue Jun 16 14:54:22 2009
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 16 Jun 2009 13:54:22 -0500
Subject: [arin-ppml] large vs small?
In-Reply-To: <3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com><g363fagt8a.fsf@nsa.vix.com><20090606004337.GA87863@ussenterprise.ufp.org><g31vpygjk3.fsf@nsa.vix.com>
	<m24ouunjkz.wl%randy@psg.com><4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com><4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com><624960.88403.qm@web63306.mail.re1.yahoo.com><4A318FEE.9090904@ipinc.net><29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4B2CE@mail>

=> However we may architect it for legal purposes, the dog still wags the
> tail: we buy IP addresses from ARIN and receive the rest of the
> services in the package (whether we want to or not!)
> 
> Regards,
> Bill Herrin
> 
> 

Careful Bill, remember that anything you buy they can tax you for..

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090616/e88c6d71/attachment.bin>

From tedm at ipinc.net  Tue Jun 16 14:57:18 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Tue, 16 Jun 2009 11:57:18 -0700
Subject: [arin-ppml] large vs small?
In-Reply-To: <29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com>
	<m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>	<624960.88403.qm@web63306.mail.re1.yahoo.com>	<4A318FEE.9090904@ipinc.net>	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>
Message-ID: <4A37EB0E.4010309@ipinc.net>

Brian Johnson wrote:

> 
> This is a fruitless argument and I have no idea how I got myself into
> this. I disagree that you "buy" anything by being a member of ARIN with
> IP addresses being assigned to you. If you want to talk like you know
> better, go ahead and do it. I'm out of energy arguing the point.
> 

We don't "buy" them we "rent" them.

I can understand how the concept would be alien to a Legacy IP
holder, who has an IPv4 allocation that will not revert back to
ARIN if they stop paying the membership fees.

Once you get your IPv6 allocation I'm sure you will understand.

Ted


From owen at delong.com  Tue Jun 16 18:45:04 2009
From: owen at delong.com (Owen DeLong)
Date: Tue, 16 Jun 2009 15:45:04 -0700
Subject: [arin-ppml] large vs small?
In-Reply-To: <4A37EB0E.4010309@ipinc.net>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com>
	<m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>	<624960.88403.qm@web63306.mail.re1.yahoo.com>	<4A318FEE.9090904@ipinc.net>	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>
	<4A37EB0E.4010309@ipinc.net>
Message-ID: <6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>


On Jun 16, 2009, at 11:57 AM, Ted Mittelstaedt wrote:

> Brian Johnson wrote:
>
>> This is a fruitless argument and I have no idea how I got myself into
>> this. I disagree that you "buy" anything by being a member of ARIN  
>> with
>> IP addresses being assigned to you. If you want to talk like you know
>> better, go ahead and do it. I'm out of energy arguing the point.
>
> We don't "buy" them we "rent" them.
>
> I can understand how the concept would be alien to a Legacy IP
> holder, who has an IPv4 allocation that will not revert back to
> ARIN if they stop paying the membership fees.
>
> Once you get your IPv6 allocation I'm sure you will understand.

IP Addresses are neither purchased nor leased, rented, etc. from ARIN.

No more so than License Plate Numbers are purchased/rented/etc. from
the DMV* (or whatever your government structural equivalent).

ARIN provides number resources which are known to be globally unique
among the cooperating entities collectively known as the RIR system  
which
includes IANA, 5 RIRs, and a significant portion of the ISPs and end  
users
who subscribe to services from the RIRs and choose not to attempt to use
addresses on the global internet which were not assigned to them by an  
RIR
or someone who received an allocation via an RIR (directly or  
indirectly).

That and the policy fora, outreach, and other services are what ARIN  
does.
Not leases, not sales, etc.

Some people choose to regard this guarantee of uniqueness as a right
to use license, but, in reality, ARIN cannot give you the right to use a
number on the internet since ARIN does not control routers through which
you connect to the internet.  The fact that most ISPs subscribe to the  
RIR
system and route accordingly certainly makes the internet function  
better.
However, they do that voluntarily because it works, not because ARIN
has any way to prevent them from doing something else.

Owen




*DMV -- In California and many other states, the Department of Motor  
Vehicles.



From jmaimon at chl.com  Tue Jun 16 21:57:22 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Tue, 16 Jun 2009 21:57:22 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>	<g31vpygjk3.fsf@nsa.vix.com>	<m24ouunjkz.wl%randy@psg.com>	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>	<624960.88403.qm@web63306.mail.re1.yahoo.com>	<4A318FEE.9090904@ipinc.net>	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>	<4A37EB0E.4010309@ipinc.net>
	<6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>
Message-ID: <4A384D82.7000107@chl.com>



Owen DeLong wrote:
>   The fact that most ISPs subscribe to the RIR
> system and route accordingly certainly makes the internet function better.
> However, they do that voluntarily because it works, not because ARIN
> has any way to prevent them from doing something else.
> 
> Owen

Thank you, Owen.

Sometimes this seems to be overlooked. Very reassuring to hear it being 
explicitly stressed, especially from a respected persona as yourself.

The registries function as well as they do because of buy-in by their users.

They do not have a natural or government granted monopoly. (Contractual 
relationships notwithstanding)

This is the model of the internet for the things that work best and that 
is what we should spend our effort on maintaining. A Nashian 
Equilibrium, to my understanding.

That doesnt change the my belief that fees, or more specifically, 
perceived unfairness in the imbalance of fees, are worthy of discussion, 
whether on policy list or on general discussion. Of course they are.

The money paid is best viewed as a pay to play, a membership fee, which 
is actually exactly what it is. Quibbling over tangibles received is 
quite secondary.

It is disingenuous to pretend money doesnt matter. Money quantifies 
"matter", that is what we use it for.

In fact, big boy buy in is worth much more to registries than small 
boys. Thats another potential explanation for the discount.

15% revenue for 80% utilization. 500x difference between smallest and 
largest, on paper.

Somebody should stop me if I am repeating incorrect data.

There is no way to escape this. Large organizations {will|must} have 
advantages over small ones - it is the nature of organisms. To properly 
manage those advantages is in all our best interests. The question 
becomes to what degree and in which instances.

Is this the best and most correct way it can be done?

I think fees, and the larger topic of imbalances, perceived or real, is 
worthy of consideration. Preferably before potential axe grinders seize 
upon it as their casus belli.

In fact, were this consideration not to be persistently on the BoT and 
AC viewscreens, I would be most disappointed, to the extent that matters.

Joe


From mueller at syr.edu  Wed Jun 17 10:06:52 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 17 Jun 2009 10:06:52 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com>	<m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<624960.88403.qm@web63306.mail.re1.yahoo.com>	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>
	<4A37EB0E.4010309@ipinc.net>
	<6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
 
> IP Addresses are neither purchased nor leased, rented, etc. from ARIN.

RFC 2008: 
'An "address lending" policy means that an organization gets its addresses on a "loan" basis. For the length of the loan, the lender cannot lend the addresses to any other borrower.'

There is the official party line, the ideology of RIRs, and there is the economic and operational reality. Don't confuse the two. Since RFC 2008, RIRs have leased -- by any common-sensical notion of the term - address blocks to end users. The rationale for this leasing approach was not the evils of private property or an attempt to maintain some communal nirvana, but simply the scaling properties of routing. Provider-based route aggregation required the address lending approach. If it weren't for route aggregation problems in the mid-1990s and such technical interdependencies between routing and addressing, there could have been and probably would have been a trading market for ipv4 addresses.

I am not sure why the official priesthood of the RIRs insist on using words in this specific way now. It is possible that their lawyers tell them to, or it is possible that the ideology of nonownership of addresses has become fetishized and taken on a life of its own. That does happen. 

But it is difficult to have an intelligent conversation about the policies, fees, and conservation of address blocks when the priesthood insists on playing word games and one cannot call a cat a cat or a mouse a mouse. 

> No more so than License Plate Numbers are purchased/rented/etc. from
> the DMV* (or whatever your government structural equivalent).

This is nonsense, and not only because many states allow you to buy vanity plates, sometimes even in auctions, but because the number of license plates is not a fixed resource that requires conservation policies. At any rate, no DMV will have any trouble telling you that you pay a fee for the license plate and if you want X vehicle registrations you pay X*<the fee>



From michael.dillon at bt.com  Wed Jun 17 10:34:38 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 17 Jun 2009 15:34:38 +0100
Subject: [arin-ppml] large vs small?
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <28E139F46D45AF49A31950F88C49745801B313FD@E03MVZ2-UKDY.domain1.systemhost.net>

> > IP Addresses are neither purchased nor leased, rented, etc. 
> from ARIN.
> 
> RFC 2008: 
> 'An "address lending" policy means that an organization gets 
> its addresses on a "loan" basis. For the length of the loan, 
> the lender cannot lend the addresses to any other borrower.'

That RFC was just an engineering view of current best practice in 1996,
possibly published because RFC 1466 hadn't been updated. Not long after,
RFC 2050 was published by the RIRs collectively and that has been the
basis for RIR policy ever since.

Remember that RFC means Request For Comment, it isn't a legal document
or even a policy document.

> There is the official party line, the ideology of RIRs,

They are the ones who officially have control of the various Internet
number spaces, delegated to them by IANA. And like any political
party, they change their policies to reflect public input.

> Since RFC 2008, RIRs have leased -- by any 
> common-sensical notion of the term - address blocks to end 
> users. 

A lease is a contract in which an asset user agrees to pay
regular payments to an asset owner, and to give up control
of the asset at the end of the lease, or buy out the ownership
of the asset for a price which is agreed as part of the lease
package. If there is no payment then there is no contract and
consequently there is no lease. IP addresses clearly are not
being leased by anybody.

You can't really apply commercial terminology to the relationship
between IP address registries and IP address holders, which is
no doubt why the authors of RFC 2008 used quotes to indicate that
they did not literally mean address lending and loan, but something
that superficially appears to be similar to those things.

> I am not sure why the official priesthood of the RIRs insist 
> on using words in this specific way now. It is possible that 
> their lawyers tell them to, or it is possible that the 
> ideology of nonownership of addresses has become fetishized 
> and taken on a life of its own.

It's because there is a chain of delegation from the Defense Department
to the Department of Commerce to IANA to the RIRs, and the power that
the RIR have inherited is limited by those earlier agreements. RIRs
simply do not have the right to monetize the IP address space, which
is why those in favor of allowing "sale" of IP addresses have come up
with such a convoluted process to enable the possibility of such
transactions.


> This is nonsense, and not only because many states allow you 
> to buy vanity plates, sometimes even in auctions, but because 
> the number of license plates is not a fixed resource that 
> requires conservation policies. 

I think that you will find there is a legally required size for
licence plates as well as a legally required minimum size for the
numbers/letters, both of which do create a fixed bounded resource.
For instance vanity plates in California can have a maximum of
7 characters which happens to also be the length of the longest
licence plate numbers currently in use, also in California.

> At any rate, no DMV will have 
> any trouble telling you that you pay a fee for the license 
> plate and if you want X vehicle registrations you pay X*<the fee>

But IP address registrations are not the same as licence plate 
registrations. In fact they are not the same as primary school
registration
or voter registration either. You can only take an anlogy so far.

--Michael Dillon


From tvest at pch.net  Wed Jun 17 10:37:20 2009
From: tvest at pch.net (Tom Vest)
Date: Wed, 17 Jun 2009 10:37:20 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<g363fagt8a.fsf@nsa.vix.com>	<20090606004337.GA87863@ussenterprise.ufp.org>
	<g31vpygjk3.fsf@nsa.vix.com>	<m24ouunjkz.wl%randy@psg.com>
	<4607e1d50906091749i4a04d222w44d72d1ea66cfd51@mail.gmail.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<624960.88403.qm@web63306.mail.re1.yahoo.com>	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>
	<4A37EB0E.4010309@ipinc.net>
	<6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>
	<75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <50F9A38F-0D1E-466D-A3AD-5390EB413412@pch.net>


On Jun 17, 2009, at 10:06 AM, Milton L Mueller wrote:

>
>> -----Original Message-----
>
>> IP Addresses are neither purchased nor leased, rented, etc. from  
>> ARIN.
>
> RFC 2008:
> 'An "address lending" policy means that an organization gets its  
> addresses on a "loan" basis. For the length of the loan, the lender  
> cannot lend the addresses to any other borrower.'
>
> There is the official party line, the ideology of RIRs, and there is  
> the economic and operational reality. Don't confuse the two. Since  
> RFC 2008, RIRs have leased -- by any common-sensical notion of the  
> term - address blocks to end users. The rationale for this leasing  
> approach was not the evils of private property or an attempt to  
> maintain some communal nirvana, but simply the scaling properties of  
> routing. Provider-based route aggregation required the address  
> lending approach. If it weren't for route aggregation problems in  
> the mid-1990s and such technical interdependencies between routing  
> and addressing, there could have been and probably would have been a  
> trading market for ipv4 addresses.
>
> I am not sure why the official priesthood of the RIRs insist on  
> using words in this specific way now. It is possible that their  
> lawyers tell them to, or it is possible that the ideology of  
> nonownership of addresses has become fetishized and taken on a life  
> of its own. That does happen.

Milton, do you really want to go down this path *again*?
If you really, truly want or need to speculate about the ideological  
fetishes of others, I will be happy to respond in kind, albeit with  
documented, factual evidence rather than speculations.
There are world views in which "private property" is not the natural  
or ideal status of all things in the world, where the price mechanism  
is not the only motivator of human action in all cases.
Perhaps your own world view does not allow for that possibility, but  
in this community there are many houses.

> But it is difficult to have an intelligent conversation about the  
> policies, fees, and conservation of address blocks when the  
> priesthood insists on playing word games and one cannot call a cat a  
> cat or a mouse a mouse.

Spoken like a true orthodox adherent of a competing fundamentalist  
creed.

Peace, or not; you decide.

TV


>> No more so than License Plate Numbers are purchased/rented/etc. from
>> the DMV* (or whatever your government structural equivalent).
>
> This is nonsense, and not only because many states allow you to buy  
> vanity plates, sometimes even in auctions, but because the number of  
> license plates is not a fixed resource that requires conservation  
> policies. At any rate, no DMV will have any trouble telling you that  
> you pay a fee for the license plate and if you want X vehicle  
> registrations you pay X*<the fee>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From dogwallah at gmail.com  Wed Jun 17 15:11:28 2009
From: dogwallah at gmail.com (McTim)
Date: Wed, 17 Jun 2009 15:11:28 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<624960.88403.qm@web63306.mail.re1.yahoo.com>
	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>
	<4A37EB0E.4010309@ipinc.net>
	<6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>
	<75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <f65fb55e0906171211p5ddf4486j8418616e9dc8ac3f@mail.gmail.com>

Milton,

On Wed, Jun 17, 2009 at 10:06 AM, Milton L Mueller<mueller at syr.edu> wrote:
>
>> -----Original Message-----
>
<snip>

> I am not sure why the official priesthood of the RIRs

Oh Please! I have explained to you (on another list) that RIRs do NOT
make policy, the RIR community makes policy. I have explained this to
you many times.

Despite the fact that you are now a member of the ARIN policy making
community, you persist in the notion that RIR staff somehow make
policy. In fact, you somehow doubt the existence of said community
even though you are now an active member of same.

Can you explain how you can deny the existence of something in which
you are an active participant?  It doesn't seem very logical to me.

I have been an employee of an RIR, and I assure you, they take their
marching orders from the community.  I can also assure you there are
no "altars of non-ownership" that "priests" worship upon in RIR
offices.

Perhaps if toned down your rhetoric, you might be taken more
seriously.  If you have a policy proposal that is germaine to this
thread (large vs. small), I'd like to hear it.
<sarcasm>If not, I'd like to get back to my 4 byte ASN catechism now.
</sarcasm>.

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


From mueller at syr.edu  Wed Jun 17 15:45:24 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 17 Jun 2009 15:45:24 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <f65fb55e0906171211p5ddf4486j8418616e9dc8ac3f@mail.gmail.com>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<624960.88403.qm@web63306.mail.re1.yahoo.com>	
	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>
	<4A37EB0E.4010309@ipinc.net>
	<6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>
	<75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>
	<f65fb55e0906171211p5ddf4486j8418616e9dc8ac3f@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A813E@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> From: McTim [mailto:dogwallah at gmail.com]
> 
> Oh Please! I have explained to you (on another list) that RIRs do NOT
> make policy, the RIR community makes policy. I have explained this to
> you many times.

And I have explained to you equally as many times why no social scientist familiar with policy making processes would ever buy that argument. Apparently we're talking past each other. Anyway, that debate is not relevant to my exchanges with Owen, Michael and Ted about fees, so let's drop it.

My point was that it is difficult to have a coherent and productive discussion about the appropriate level of fees to be charged for IP address blocks when, for reasons that I can only tag as "religious," key figures insist that ARIN fees have nothing to do with access to address blocks. 

Obviously, if you've been following this thread, I am not the only one who resists that ideology.

The troubles compound when others insist that we can't even talk about fees here because they don't constitute policy. 

I am not criticizing ARIN staff, the Board or anything like that. I am "criticizing" or, more accurately, probing the validity of, a particular viewpoint. I find these anomalies quite interesting. And revealing. 

> I can also assure you there are
> no "altars of non-ownership" that "priests" worship upon in RIR
> offices.

Good to know. My experience has been a bit different.

> If you have a policy proposal that is germaine to this
> thread (large vs. small), I'd like to hear it.

Stay tuned


From tedm at ipinc.net  Wed Jun 17 18:10:26 2009
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Wed, 17 Jun 2009 15:10:26 -0700
Subject: [arin-ppml] large vs small?
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A813E@SUEX07-MBX-04.ad.syr.edu>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>	<624960.88403.qm@web63306.mail.re1.yahoo.com>		<4A318FEE.9090904@ipinc.net>	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>	<4A37EB0E.4010309@ipinc.net>	<6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>	<75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>	<f65fb55e0906171211p5ddf4486j8418616e9dc8ac3f@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A813E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A3969D2.8000804@ipinc.net>

Milton L Mueller wrote:
>> -----Original Message-----
>> From: McTim [mailto:dogwallah at gmail.com]
>>
>> Oh Please! I have explained to you (on another list) that RIRs do NOT
>> make policy, the RIR community makes policy. I have explained this to
>> you many times.
> 
> And I have explained to you equally as many times why no social scientist familiar with policy making processes would ever buy that argument. Apparently we're talking past each other. Anyway, that debate is not relevant to my exchanges with Owen, Michael and Ted about fees, so let's drop it.
> 
> My point was that it is difficult to have a coherent and productive discussion about the appropriate level
 > of fees to be charged for IP address blocks when, for reasons that I 
can only tag as "religious," key figures
 > insist that ARIN fees have nothing to do with access to address blocks.
> 

The key figures are not blocking fee discussions BECAUSE of the semantic 
games your describing.

The key figures are attempting to block fee discussions simply because
they don't want to talk about fees, period.  They use the semantic games
to distract the audience from the real issue - fee fairness.

If you or I used absolutely proper and correct terminology
regarding IP allocations the key figures would simply find even more
ridiculous nonsense to use to distract the audience from having a
fee discussion.

> Obviously, if you've been following this thread, I am not the only one who resists that ideology.
> 

Correct.  Notice how the anti-fee-discussion faction continues to
ignore that fact.

> The troubles compound when others insist that we can't even talk about fees here because they don't constitute policy. 
> 

Agreed.

> I am not criticizing ARIN staff, the Board or anything like that. I am "criticizing" or, more accurately, probing the
 > validity of, a particular viewpoint.

As have I.

Here is how ARIN fee discussions go:

1) The ARIN Board claims their particular methodology, ie: rule 1, to 
assess fees is valid

2) Subject A calls the validity of rule 1 into question.

3) The anti-fee-discussion faction attacks Subject A with a claim that
fee discussion is out of order and refers Subject A to the suggestion box

4) Subject A submits a fee suggestion.

5) The ARIN board takes up the suggestion and states it's invalid,
and directs Subject A back to rule 1


Repeat until Subject A gets tired and goes away.

> I find these anomalies quite interesting. And revealing. 
> 

I find them interesting but not particularly revealing.  Many of
the anti-fee-discussion faction work for orgs that would stand to 
benefit by an overhaul of fees and recognition of what the yearly fees 
are actually paying for, so they are essentially arguing against their 
own selfish-self interest.

I think the real issue is that these folks have regarded fees as
inviolate for so long that they have ceased thinking about them.
Since they all work for companies and orgs and none of them own 
controlling stock in those companies or organizations, it's not their 
money that's being spent, and they aren't used to questioning
dollar amounts.

Bean-counters they ain't.  If they were, Cisco and Juniper probably
wouldn't exist.

Ted

PS  Followups set to arin-discuss since this thread really shouldn't
have been started in arin-ppml in the first place.


>> I can also assure you there are
>> no "altars of non-ownership" that "priests" worship upon in RIR
>> offices.
> 
> Good to know. My experience has been a bit different.
> 
>> If you have a policy proposal that is germaine to this
>> thread (large vs. small), I'd like to hear it.
> 
> Stay tuned
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From lar at mwtcorp.net  Wed Jun 17 18:19:22 2009
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Wed, 17 Jun 2009 16:19:22 -0600
Subject: [arin-ppml] large vs small?
In-Reply-To: <4A3969D2.8000804@ipinc.net>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<4D65CB24-1333-4DA1-ABDE-2F3BC0F8AA5B@svcolo.com>
	<624960.88403.qm@web63306.mail.re1.yahoo.com>
	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>
	<4A37EB0E.4010309@ipinc.net>
	<6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>
	<75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>
	<f65fb55e0906171211p5ddf4486j8418616e9dc8ac3f@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A813E@SUEX07-MBX-04.ad.syr.edu>
	<4A3969D2.8000804@ipinc.net>
Message-ID: <web-981787@be2.mail.trib.com>

Enough already. This mouse has been miked dry.


  Ted Mittelstaedt <tedm at ipinc.net> wrote:
> Milton L Mueller wrote:
>>> -----Original Message-----
>>> From: McTim [mailto:dogwallah at gmail.com]
>>>
>>> Oh Please! I have explained to you (on another list) that RIRs do NOT
>>> make policy, the RIR community makes policy. I have explained this to
>>> you many times.
>> 
>> And I have explained to you equally as many times why no social scientist 
>>familiar with policy making processes would ever buy that argument. 
>>Apparently we're talking past each other. Anyway, that debate is not 
>>relevant to my exchanges with Owen, Michael and Ted about fees, so let's 
>>drop it.
>> 
>> My point was that it is difficult to have a coherent and productive 
>>discussion about the appropriate level
> > of fees to be charged for IP address blocks when, for reasons that I 
> can only tag as "religious," key figures
> > insist that ARIN fees have nothing to do with access to address blocks.
>> 
> 
> The key figures are not blocking fee discussions BECAUSE of the semantic 
>games your describing.
> 
> The key figures are attempting to block fee discussions simply because
> they don't want to talk about fees, period.  They use the semantic games
> to distract the audience from the real issue - fee fairness.
> 
> If you or I used absolutely proper and correct terminology
> regarding IP allocations the key figures would simply find even more
> ridiculous nonsense to use to distract the audience from having a
> fee discussion.
> 
>> Obviously, if you've been following this thread, I am not the only one who 
>>resists that ideology.
>> 
> 
> Correct.  Notice how the anti-fee-discussion faction continues to
> ignore that fact.
> 
>> The troubles compound when others insist that we can't even talk about 
>>fees here because they don't constitute policy. 
>> 
> 
> Agreed.
> 
>> I am not criticizing ARIN staff, the Board or anything like that. I am 
>>"criticizing" or, more accurately, probing the
> > validity of, a particular viewpoint.
> 
> As have I.
> 
> Here is how ARIN fee discussions go:
> 
> 1) The ARIN Board claims their particular methodology, ie: rule 1, to 
>assess fees is valid
> 
> 2) Subject A calls the validity of rule 1 into question.
> 
> 3) The anti-fee-discussion faction attacks Subject A with a claim that
> fee discussion is out of order and refers Subject A to the suggestion box
> 
> 4) Subject A submits a fee suggestion.
> 
> 5) The ARIN board takes up the suggestion and states it's invalid,
> and directs Subject A back to rule 1
> 
> 
> Repeat until Subject A gets tired and goes away.
> 
>> I find these anomalies quite interesting. And revealing. 
>> 
> 
> I find them interesting but not particularly revealing.  Many of
> the anti-fee-discussion faction work for orgs that would stand to benefit 
>by an overhaul of fees and recognition of what the yearly fees are actually 
>paying for, so they are essentially arguing against their own selfish-self 
>interest.
> 
> I think the real issue is that these folks have regarded fees as
> inviolate for so long that they have ceased thinking about them.
> Since they all work for companies and orgs and none of them own 
>controlling stock in those companies or organizations, it's not their money 
>that's being spent, and they aren't used to questioning
> dollar amounts.
> 
> Bean-counters they ain't.  If they were, Cisco and Juniper probably
> wouldn't exist.
> 
> Ted
> 
> PS  Followups set to arin-discuss since this thread really shouldn't
> have been started in arin-ppml in the first place.
> 
> 
>>> I can also assure you there are
>>> no "altars of non-ownership" that "priests" worship upon in RIR
>>> offices.
>> 
>> Good to know. My experience has been a bit different.
>> 
>>> If you have a policy proposal that is germaine to this
>>> thread (large vs. small), I'd like to hear it.
>> 
>> Stay tuned
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

Larry Ash
Network Administrator
Mountain West Telephone
400 East 1st St.
Casper, WY 82601
Office 307 233-8387


From dogwallah at gmail.com  Wed Jun 17 22:39:50 2009
From: dogwallah at gmail.com (McTim)
Date: Wed, 17 Jun 2009 22:39:50 -0400
Subject: [arin-ppml] large vs small?
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B1A813E@SUEX07-MBX-04.ad.syr.edu>
References: <00F34B532FAD814DB8CD222DC86BA3DE895284CA95@ERCEVS06.na.lan.mwe.com>
	<4A318FEE.9090904@ipinc.net>
	<29A54911243620478FF59F00EBB12F47017E3873@ex01.drtel.lan>
	<3c3e3fca0906161112wcc761c5v76e9691fee01c372@mail.gmail.com>
	<29A54911243620478FF59F00EBB12F47017E3907@ex01.drtel.lan>
	<4A37EB0E.4010309@ipinc.net>
	<6F31521B-AB6C-4DAE-B47C-2DA8F51B7FE2@delong.com>
	<75822E125BCB994F8446858C4B19F0D77B1A8120@SUEX07-MBX-04.ad.syr.edu>
	<f65fb55e0906171211p5ddf4486j8418616e9dc8ac3f@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D77B1A813E@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <f65fb55e0906171939h2201823fq27cd6f80f46a41cf@mail.gmail.com>

<apologies for keeping this thread alive>

On Wed, Jun 17, 2009 at 3:45 PM, Milton L Mueller<mueller at syr.edu> wrote:
>
>> -----Original Message-----
>> From: McTim [mailto:dogwallah at gmail.com]
>>
>> Oh Please! I have explained to you (on another list) that RIRs do NOT
>> make policy, the RIR community makes policy. I have explained this to
>> you many times.
>
> And I have explained to you equally as many times why no social scientist familiar with policy making processes would ever buy that argument.

Yet you participate, thus validating the concept you eschew?


Apparently we're talking past each other. Anyway, that debate is not
relevant to my exchanges with Owen, Michael and Ted about fees, so
let's drop it.
>
> My point was that it is difficult to have a coherent and productive discussion about the appropriate level of fees to be charged for IP address blocks when, for reasons that I can only tag as "religious," key figures insist that ARIN fees have nothing to do with access to address blocks.


So you want to use RIR membership fees as a policy lever? In theory
you could do this IF fees were set by the RIR policy making community.
 Unfortunately, they aren't, they are determined by the members of the
association. the two sets of people, while overlapping, are not the
same.

-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel


From michael.dillon at bt.com  Thu Jun 18 08:21:33 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 18 Jun 2009 13:21:33 +0100
Subject: [arin-ppml] large vs small?
In-Reply-To: <4A3969D2.8000804@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801B31EA1@E03MVZ2-UKDY.domain1.systemhost.net>


> to distract the audience from the real issue - fee fairness.

Fee fairness is an important issue. But it is the ARIN members
who set the fees, and who make the rules around fees, not
the public. Therefore if you think fees are unfair then you
should take it up with the ARIN membership. Most ARIN members
do not participate in this forum, and the Advisory Council,
who does participate, has no say in the ARIN fee structure.

> > The troubles compound when others insist that we can't even 
> talk about fees here because they don't constitute policy. 
> > 
> 
> Agreed.

Now you are talking about ARIN's charter and by-laws which are
also not subject to change by the AC or even the BoT. Again,
it is ARIN members who control all of this. If you believe
that it is important for the members to change something, then
you should start by getting at least one member on board, and
ask them to raise the issue on the ARIN members mailing list.

> 1) The ARIN Board claims their particular methodology, ie: rule 1, to 
> assess fees is valid

I looked at <https://www.arin.net/fees/index.html> and I can find
no mention of rule 1 in the Overview or the fee schedule. 
Article V c. of the ARIN by-laws does state:

The Board of Trustees shall have the power to establish and designate
other classifications of memberships, dues formulae, fees, or other
charges. 

so it is pretty clear that under US law, the board is entitled to assess
fees by whatever methodology they deem fit. But the board is elected by
the ARIN members so if members called for a change, either the board
would change, or new board members would be elected. It all starts with
the members.

> 4) Subject A submits a fee suggestion.
> 
> 5) The ARIN board takes up the suggestion and states it's invalid,
> and directs Subject A back to rule 1

Have you actually submitted a formal suggestion for a different fee
structure? <https://www.arin.net/app/suggestion/>
The evidence suggests that the board seriously considers these
suggestions
<https://www.arin.net/participate/acsp/suggestions/2008-8.html>
Probably a better way to approach it would be to suggest that
the board consult or poll the ARIN membership about changing
the fee structure to one in which the magnitude of the fee is
roughly comparable to the total size of the IP address allocation.

But, again, the PPML and the AC cannot do anything about fees.

> I find them interesting but not particularly revealing.  Many of
> the anti-fee-discussion faction work for orgs that would stand to 
> benefit by an overhaul of fees and recognition of what the 
> yearly fees 
> are actually paying for, so they are essentially arguing 
> against their 
> own selfish-self interest.

How would we benefit from a change in our $18000 annual fee?
It could only go up because we have a lot of addresses. That
means that ARIN would have a greater dependence on the timely
payment of fees from a SMALLER number of big organizations.
That could only result in greater control of ARIN by those
organizations. 

> I think the real issue is that these folks have regarded fees as
> inviolate for so long that they have ceased thinking about them.

Fees are discussed at every members meeting, and they do change
from time to time.

> Since they all work for companies and orgs and none of them own 
> controlling stock in those companies or organizations, it's not their 
> money that's being spent, and they aren't used to questioning
> dollar amounts.

If my company's board of directors took an issue about a measly
$18,000 annual fee to the shareholders they would probably all
be fired by those same shareholders. Believe me, the shareholders
of large companies are not worried by such small sums of money.
Perhaps you should read the annual reports of some of the larger
ISPs (all publicly traded companies) and see the kind of sums that
do warrant mention to the shareholders.

The bottom line is that some very ethereal things are very valuable
to large publicly traded network operators such as my employer. 
A stable and fairly run ARIN is one of those things. Fair fees are
important to us, and we have supported things like the fee waivers
to help remove barriers to IPv6 introduction. Note that this means
we have supported changes to the actual fees charged and would
likely support other fee changes, if they could be shown to make
the fee structure fairer. But vague complaints about cost-per-IP
address, are not the kind of thing that will gain our support. I 
would welcome a critical analysis of the ARIN fee structure with
input from economists, but I would want some balanced set of analyses
rather than a single one-sided analysis.

> PS  Followups set to arin-discuss since this thread really shouldn't
> have been started in arin-ppml in the first place.

If you want to discuss fees on the ARIN members list, then you'll 
have to open a new thread there yourself. 

--Michael Dillon


From info at arin.net  Thu Jun 18 13:58:33 2009
From: info at arin.net (Member Services)
Date: Thu, 18 Jun 2009 13:58:33 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out by Prefix
	Size - Revised
Message-ID: <4A3A8049.90103@arin.net>

Policy Proposal 93
Predicable IPv4 Run Out by Prefix Size

The proposal originator submitted a revised version of the proposal.

The AC will review this proposal at their next regularly scheduled
meeting and decide how to utilize the proposal. Their decision will be
announced to the PPML.

In the meantime, the AC invites everyone to comment on this proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Policy Development Process can be found at:
http://www.arin.net/policy/pdp.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


#####


1. Policy Proposal Name: Predicable IPv4 Run Out by Prefix Size

2. Proposal Originator:  David Farmer

3. Proposal Version: 1.1

4. Date: 18 June 2009

5. Proposal type: new

6. Policy term: permanent

7. Policy statement:

Create a new subsection in section 4 of the NRPM;

4.X Maximum Allocation or Assignment during and following
Run-Out

When ARIN receives its last /8, by IANA implementing section
10.4.2.2, a proportionally decreasing maximum allocation, and
assignment, size will be put into effect.  The maximum
allocation will be the next whole CIDR prefix less than or equal
to one quarter (1/4) of the total ARIN free pool available at the
time of each allocation, but no longer than the applicable
minimum allocation.

An OrgID may request additional resources when it can
demonstrate it has properly utilized all previous allocations per
applicable policies.  However, the total of all allocations
received within the last three (3) month period and the current
request, cannot exceed the current maximum allocation size.

This maximum allocation size is applicable to allocations from
the ARIN free pool only, and is explicitly not applicable to
resources received through Transfers to Specified Recipients
per section 8.3, or any other specially designated resources.

8. Rationale:

This proposal is intended to ensure an equitable distribution of
the remaining ARIN free pool resources once additional
resources are no longer abundantly available from IANA.
Equity is achieved by ensuring the available resources are
spread among multiple organizations and that no single
organization may monopolize all of the resources available
through a single request, at least until the maximum allocation
size has been reduced down to the minimum allocation size.

Reducing the maximum allocation size in proportion to the
amount of resources available should minimize, or possibly
eliminate, the need to fulfill requests with multiple smaller
blocks.

The maximum allocation size is intended to apply to both ISP
allocations and End-user assignments.

The current maximum allocation size should be publish in real-
time on the ARIN website, as it may change rapidly as the
ARIN free pool resources are exhausted.

Following the run-out phase, this proposal provides an
equitable means of distribution of resources if or when
additional resources become available after ARIN has initially
exhausted such resources.  Such as if resources are returned,
recovered by other means, or additional resources are
obtained from IANA.  Further, whenever ARIN receives a
sufficiently large amount of resources, this policy intends for
the maximum allocation size to be increased accordingly.

The intent of the second paragraph is to normally limit an
organization to a single maximum allocation within a three
month period.  However, saying it that simply opens the policy
to gamesmanship in requesting less than a maximum
allocation.  Requiring a maximum allocation to cover new
requests and all allocations received in the previous three
month period, should eliminate this kind of gamesmanship.

There is a beneficial side effect of the second paragraph as
stated, in the special situation when the maximum allocation
size is increased, due to ARIN obtaining a sufficiently large
amount of additional resources, an organization may receive
additional resources earlier than the normal three month
period.  But, only in this special situation and when an
organization properly utilizes a previous maximum allocation in
less than three months, may an organization receive additional
resources in less than the normal three month period.

Other ratios, such as one half (1/2) or one eighth (1/8) could be
considered.  One eighth (1/8) would provide greater assurance
of eliminating the need to use multiple blocks to fulfill requests
and ensure a greater number of organizations receive
resources.  However, one eighth (1/8) is more likely to be seen
as rationing and an attempt to artificially extend the lifetime of
IPv4.  During the ARIN XXIII policy discussion there seemed to
be a consensus that attempts to extend the lifetime of IPv4
resources would be undesirable.  While on the other hand, one
half (1/2) is even less likely to ration resources, it would likely
result in the resource being spread across significantly fewer
organizations and increase the need to use multiple blocks to
fulfill requests.

Finally, combining the 3 month period with the one quarter
(1/4) ratio provides roughly an annualized equivalent of the
whole ARIN free pool being made available to a single
organization.  While it is not possible for a single organization
to receive the whole ARIN free pool within one year under this
policy, it is a virtual certainty that multiple organization will be
requesting resources, and that the ARIN free pool will not likely
last a full year following the exhaustion of the IANA free pool
anyway.  Therefore, the ratio one quarter (1/4) seems to strike
a balance between making resources available with as little
restriction as possible and ensuring an equitable distribution of
those resources during and following the run-out phase.

9. Timetable for implementation:  Immediate



From martin.hannigan at batelnet.bs  Thu Jun 18 17:42:43 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Thu, 18 Jun 2009 17:42:43 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out by
	Prefix Size - Revised
In-Reply-To: <4A3A8049.90103@arin.net>
References: <4A3A8049.90103@arin.net>
Message-ID: <4607e1d50906181442x5dfffb14y8e3fffba711700e3@mail.gmail.com>

Not in favor. Any change from first and first out based on the current
minimum allocation unit is a mid game change which is patently unfair.
Automatically changing the allocation size is quite different than
requiring a policy proposal _based on current conditions_.
Circumstances may chance the popularity of such a proposal. One could
argue that it too could be changed. Why not simply change the
allocation unit from meet to meet?>

Best,

Martin

On Thu, Jun 18, 2009 at 1:58 PM, Member Services<info at arin.net> wrote:
> Policy Proposal 93
> Predicable IPv4 Run Out by Prefix Size
>
> The proposal originator submitted a revised version of the proposal.
>
> The AC will review this proposal at their next regularly scheduled
> meeting and decide how to utilize the proposal. Their decision will be
> announced to the PPML.
>
> In the meantime, the AC invites everyone to comment on this proposal on
> the PPML, particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
>
> The ARIN Policy Development Process can be found at:
> http://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found at:
> http://www.arin.net/mailing_lists/
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> #####
>
>
> 1. Policy Proposal Name: Predicable IPv4 Run Out by Prefix Size
>
> 2. Proposal Originator: ?David Farmer
>
> 3. Proposal Version: 1.1
>
> 4. Date: 18 June 2009
>
> 5. Proposal type: new
>
> 6. Policy term: permanent
>
> 7. Policy statement:
>
> Create a new subsection in section 4 of the NRPM;
>
> 4.X Maximum Allocation or Assignment during and following
> Run-Out
>
> When ARIN receives its last /8, by IANA implementing section
> 10.4.2.2, a proportionally decreasing maximum allocation, and
> assignment, size will be put into effect. ?The maximum
> allocation will be the next whole CIDR prefix less than or equal
> to one quarter (1/4) of the total ARIN free pool available at the
> time of each allocation, but no longer than the applicable
> minimum allocation.
>
> An OrgID may request additional resources when it can
> demonstrate it has properly utilized all previous allocations per
> applicable policies. ?However, the total of all allocations
> received within the last three (3) month period and the current
> request, cannot exceed the current maximum allocation size.
>
> This maximum allocation size is applicable to allocations from
> the ARIN free pool only, and is explicitly not applicable to
> resources received through Transfers to Specified Recipients
> per section 8.3, or any other specially designated resources.
>
> 8. Rationale:
>
> This proposal is intended to ensure an equitable distribution of
> the remaining ARIN free pool resources once additional
> resources are no longer abundantly available from IANA.
> Equity is achieved by ensuring the available resources are
> spread among multiple organizations and that no single
> organization may monopolize all of the resources available
> through a single request, at least until the maximum allocation
> size has been reduced down to the minimum allocation size.
>
> Reducing the maximum allocation size in proportion to the
> amount of resources available should minimize, or possibly
> eliminate, the need to fulfill requests with multiple smaller
> blocks.
>
> The maximum allocation size is intended to apply to both ISP
> allocations and End-user assignments.
>
> The current maximum allocation size should be publish in real-
> time on the ARIN website, as it may change rapidly as the
> ARIN free pool resources are exhausted.
>
> Following the run-out phase, this proposal provides an
> equitable means of distribution of resources if or when
> additional resources become available after ARIN has initially
> exhausted such resources. ?Such as if resources are returned,
> recovered by other means, or additional resources are
> obtained from IANA. ?Further, whenever ARIN receives a
> sufficiently large amount of resources, this policy intends for
> the maximum allocation size to be increased accordingly.
>
> The intent of the second paragraph is to normally limit an
> organization to a single maximum allocation within a three
> month period. ?However, saying it that simply opens the policy
> to gamesmanship in requesting less than a maximum
> allocation. ?Requiring a maximum allocation to cover new
> requests and all allocations received in the previous three
> month period, should eliminate this kind of gamesmanship.
>
> There is a beneficial side effect of the second paragraph as
> stated, in the special situation when the maximum allocation
> size is increased, due to ARIN obtaining a sufficiently large
> amount of additional resources, an organization may receive
> additional resources earlier than the normal three month
> period. ?But, only in this special situation and when an
> organization properly utilizes a previous maximum allocation in
> less than three months, may an organization receive additional
> resources in less than the normal three month period.
>
> Other ratios, such as one half (1/2) or one eighth (1/8) could be
> considered. ?One eighth (1/8) would provide greater assurance
> of eliminating the need to use multiple blocks to fulfill requests
> and ensure a greater number of organizations receive
> resources. ?However, one eighth (1/8) is more likely to be seen
> as rationing and an attempt to artificially extend the lifetime of
> IPv4. ?During the ARIN XXIII policy discussion there seemed to
> be a consensus that attempts to extend the lifetime of IPv4
> resources would be undesirable. ?While on the other hand, one
> half (1/2) is even less likely to ration resources, it would likely
> result in the resource being spread across significantly fewer
> organizations and increase the need to use multiple blocks to
> fulfill requests.
>
> Finally, combining the 3 month period with the one quarter
> (1/4) ratio provides roughly an annualized equivalent of the
> whole ARIN free pool being made available to a single
> organization. ?While it is not possible for a single organization
> to receive the whole ARIN free pool within one year under this
> policy, it is a virtual certainty that multiple organization will be
> requesting resources, and that the ARIN free pool will not likely
> last a full year following the exhaustion of the IANA free pool
> anyway. ?Therefore, the ratio one quarter (1/4) seems to strike
> a balance between making resources available with as little
> restriction as possible and ensuring an equitable distribution of
> those resources during and following the run-out phase.
>
> 9. Timetable for implementation: ?Immediate
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>


From scottleibrand at gmail.com  Thu Jun 18 17:49:45 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 18 Jun 2009 14:49:45 -0700
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out by
 Prefix Size - Revised
In-Reply-To: <4607e1d50906181442x5dfffb14y8e3fffba711700e3@mail.gmail.com>
References: <4A3A8049.90103@arin.net>
	<4607e1d50906181442x5dfffb14y8e3fffba711700e3@mail.gmail.com>
Message-ID: <4A3AB679.4090807@gmail.com>

Martin Hannigan wrote:
> Not in favor. Any change from first and first out based on the current
> minimum allocation unit is a mid game change which is patently unfair.
> Automatically changing the allocation size is quite different than
> requiring a policy proposal _based on current conditions_.
> Circumstances may chance the popularity of such a proposal. One could
> argue that it too could be changed. Why not simply change the
> allocation unit from meet to meet?>
>   

Just addressing the practical, rather than philosophical, question, I 
think things will be changing fast enough at run-out that a maximum 
allocation unit changed by policy every 6 months will not have a 
beneficial effect.

-Scott

> On Thu, Jun 18, 2009 at 1:58 PM, Member Services<info at arin.net> wrote:
>   
>> Policy Proposal 93
>> Predicable IPv4 Run Out by Prefix Size
>>
>> The proposal originator submitted a revised version of the proposal.
>>
>> The AC will review this proposal at their next regularly scheduled
>> meeting and decide how to utilize the proposal. Their decision will be
>> announced to the PPML.
>>
>> In the meantime, the AC invites everyone to comment on this proposal on
>> the PPML, particularly their support or non-support and the reasoning
>> behind their opinion. Such participation contributes to a thorough
>> vetting and provides important guidance to the AC in their deliberations.
>>
>> The ARIN Policy Development Process can be found at:
>> http://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> #####
>>
>>
>> 1. Policy Proposal Name: Predicable IPv4 Run Out by Prefix Size
>>
>> 2. Proposal Originator:  David Farmer
>>
>> 3. Proposal Version: 1.1
>>
>> 4. Date: 18 June 2009
>>
>> 5. Proposal type: new
>>
>> 6. Policy term: permanent
>>
>> 7. Policy statement:
>>
>> Create a new subsection in section 4 of the NRPM;
>>
>> 4.X Maximum Allocation or Assignment during and following
>> Run-Out
>>
>> When ARIN receives its last /8, by IANA implementing section
>> 10.4.2.2, a proportionally decreasing maximum allocation, and
>> assignment, size will be put into effect.  The maximum
>> allocation will be the next whole CIDR prefix less than or equal
>> to one quarter (1/4) of the total ARIN free pool available at the
>> time of each allocation, but no longer than the applicable
>> minimum allocation.
>>
>> An OrgID may request additional resources when it can
>> demonstrate it has properly utilized all previous allocations per
>> applicable policies.  However, the total of all allocations
>> received within the last three (3) month period and the current
>> request, cannot exceed the current maximum allocation size.
>>
>> This maximum allocation size is applicable to allocations from
>> the ARIN free pool only, and is explicitly not applicable to
>> resources received through Transfers to Specified Recipients
>> per section 8.3, or any other specially designated resources.
>>
>> 8. Rationale:
>>
>> This proposal is intended to ensure an equitable distribution of
>> the remaining ARIN free pool resources once additional
>> resources are no longer abundantly available from IANA.
>> Equity is achieved by ensuring the available resources are
>> spread among multiple organizations and that no single
>> organization may monopolize all of the resources available
>> through a single request, at least until the maximum allocation
>> size has been reduced down to the minimum allocation size.
>>
>> Reducing the maximum allocation size in proportion to the
>> amount of resources available should minimize, or possibly
>> eliminate, the need to fulfill requests with multiple smaller
>> blocks.
>>
>> The maximum allocation size is intended to apply to both ISP
>> allocations and End-user assignments.
>>
>> The current maximum allocation size should be publish in real-
>> time on the ARIN website, as it may change rapidly as the
>> ARIN free pool resources are exhausted.
>>
>> Following the run-out phase, this proposal provides an
>> equitable means of distribution of resources if or when
>> additional resources become available after ARIN has initially
>> exhausted such resources.  Such as if resources are returned,
>> recovered by other means, or additional resources are
>> obtained from IANA.  Further, whenever ARIN receives a
>> sufficiently large amount of resources, this policy intends for
>> the maximum allocation size to be increased accordingly.
>>
>> The intent of the second paragraph is to normally limit an
>> organization to a single maximum allocation within a three
>> month period.  However, saying it that simply opens the policy
>> to gamesmanship in requesting less than a maximum
>> allocation.  Requiring a maximum allocation to cover new
>> requests and all allocations received in the previous three
>> month period, should eliminate this kind of gamesmanship.
>>
>> There is a beneficial side effect of the second paragraph as
>> stated, in the special situation when the maximum allocation
>> size is increased, due to ARIN obtaining a sufficiently large
>> amount of additional resources, an organization may receive
>> additional resources earlier than the normal three month
>> period.  But, only in this special situation and when an
>> organization properly utilizes a previous maximum allocation in
>> less than three months, may an organization receive additional
>> resources in less than the normal three month period.
>>
>> Other ratios, such as one half (1/2) or one eighth (1/8) could be
>> considered.  One eighth (1/8) would provide greater assurance
>> of eliminating the need to use multiple blocks to fulfill requests
>> and ensure a greater number of organizations receive
>> resources.  However, one eighth (1/8) is more likely to be seen
>> as rationing and an attempt to artificially extend the lifetime of
>> IPv4.  During the ARIN XXIII policy discussion there seemed to
>> be a consensus that attempts to extend the lifetime of IPv4
>> resources would be undesirable.  While on the other hand, one
>> half (1/2) is even less likely to ration resources, it would likely
>> result in the resource being spread across significantly fewer
>> organizations and increase the need to use multiple blocks to
>> fulfill requests.
>>
>> Finally, combining the 3 month period with the one quarter
>> (1/4) ratio provides roughly an annualized equivalent of the
>> whole ARIN free pool being made available to a single
>> organization.  While it is not possible for a single organization
>> to receive the whole ARIN free pool within one year under this
>> policy, it is a virtual certainty that multiple organization will be
>> requesting resources, and that the ARIN free pool will not likely
>> last a full year following the exhaustion of the IANA free pool
>> anyway.  Therefore, the ratio one quarter (1/4) seems to strike
>> a balance between making resources available with as little
>> restriction as possible and ensuring an equitable distribution of
>> those resources during and following the run-out phase.
>>
>> 9. Timetable for implementation:  Immediate
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>     
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>   


From martin.hannigan at batelnet.bs  Thu Jun 18 18:31:34 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Thu, 18 Jun 2009 18:31:34 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out by
	Prefix Size - Revised
In-Reply-To: <4A3AB679.4090807@gmail.com>
References: <4A3A8049.90103@arin.net>
	<4607e1d50906181442x5dfffb14y8e3fffba711700e3@mail.gmail.com>
	<4A3AB679.4090807@gmail.com>
Message-ID: <4607e1d50906181531i7d748f24v6bb94ff594af91e4@mail.gmail.com>

Scott,

That is a belief that we don't share. I think we have another one of
those 'fierce resistance' issues, IMHO. YMMV, of course.

Best,

Martin



On 6/18/09, Scott Leibrand <scottleibrand at gmail.com> wrote:
> Martin Hannigan wrote:
>> Not in favor. Any change from first and first out based on the current
>> minimum allocation unit is a mid game change which is patently unfair.
>> Automatically changing the allocation size is quite different than
>> requiring a policy proposal _based on current conditions_.
>> Circumstances may chance the popularity of such a proposal. One could
>> argue that it too could be changed. Why not simply change the
>> allocation unit from meet to meet?>
>>
>
> Just addressing the practical, rather than philosophical, question, I
> think things will be changing fast enough at run-out that a maximum
> allocation unit changed by policy every 6 months will not have a
> beneficial effect.
>
> -Scott
>
>> On Thu, Jun 18, 2009 at 1:58 PM, Member Services<info at arin.net> wrote:
>>
>>> Policy Proposal 93
>>> Predicable IPv4 Run Out by Prefix Size
>>>
>>> The proposal originator submitted a revised version of the proposal.
>>>
>>> The AC will review this proposal at their next regularly scheduled
>>> meeting and decide how to utilize the proposal. Their decision will be
>>> announced to the PPML.
>>>
>>> In the meantime, the AC invites everyone to comment on this proposal on
>>> the PPML, particularly their support or non-support and the reasoning
>>> behind their opinion. Such participation contributes to a thorough
>>> vetting and provides important guidance to the AC in their deliberations.
>>>
>>> The ARIN Policy Development Process can be found at:
>>> http://www.arin.net/policy/pdp.html
>>>
>>> Mailing list subscription information can be found at:
>>> http://www.arin.net/mailing_lists/
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> #####
>>>
>>>
>>> 1. Policy Proposal Name: Predicable IPv4 Run Out by Prefix Size
>>>
>>> 2. Proposal Originator:  David Farmer
>>>
>>> 3. Proposal Version: 1.1
>>>
>>> 4. Date: 18 June 2009
>>>
>>> 5. Proposal type: new
>>>
>>> 6. Policy term: permanent
>>>
>>> 7. Policy statement:
>>>
>>> Create a new subsection in section 4 of the NRPM;
>>>
>>> 4.X Maximum Allocation or Assignment during and following
>>> Run-Out
>>>
>>> When ARIN receives its last /8, by IANA implementing section
>>> 10.4.2.2, a proportionally decreasing maximum allocation, and
>>> assignment, size will be put into effect.  The maximum
>>> allocation will be the next whole CIDR prefix less than or equal
>>> to one quarter (1/4) of the total ARIN free pool available at the
>>> time of each allocation, but no longer than the applicable
>>> minimum allocation.
>>>
>>> An OrgID may request additional resources when it can
>>> demonstrate it has properly utilized all previous allocations per
>>> applicable policies.  However, the total of all allocations
>>> received within the last three (3) month period and the current
>>> request, cannot exceed the current maximum allocation size.
>>>
>>> This maximum allocation size is applicable to allocations from
>>> the ARIN free pool only, and is explicitly not applicable to
>>> resources received through Transfers to Specified Recipients
>>> per section 8.3, or any other specially designated resources.
>>>
>>> 8. Rationale:
>>>
>>> This proposal is intended to ensure an equitable distribution of
>>> the remaining ARIN free pool resources once additional
>>> resources are no longer abundantly available from IANA.
>>> Equity is achieved by ensuring the available resources are
>>> spread among multiple organizations and that no single
>>> organization may monopolize all of the resources available
>>> through a single request, at least until the maximum allocation
>>> size has been reduced down to the minimum allocation size.
>>>
>>> Reducing the maximum allocation size in proportion to the
>>> amount of resources available should minimize, or possibly
>>> eliminate, the need to fulfill requests with multiple smaller
>>> blocks.
>>>
>>> The maximum allocation size is intended to apply to both ISP
>>> allocations and End-user assignments.
>>>
>>> The current maximum allocation size should be publish in real-
>>> time on the ARIN website, as it may change rapidly as the
>>> ARIN free pool resources are exhausted.
>>>
>>> Following the run-out phase, this proposal provides an
>>> equitable means of distribution of resources if or when
>>> additional resources become available after ARIN has initially
>>> exhausted such resources.  Such as if resources are returned,
>>> recovered by other means, or additional resources are
>>> obtained from IANA.  Further, whenever ARIN receives a
>>> sufficiently large amount of resources, this policy intends for
>>> the maximum allocation size to be increased accordingly.
>>>
>>> The intent of the second paragraph is to normally limit an
>>> organization to a single maximum allocation within a three
>>> month period.  However, saying it that simply opens the policy
>>> to gamesmanship in requesting less than a maximum
>>> allocation.  Requiring a maximum allocation to cover new
>>> requests and all allocations received in the previous three
>>> month period, should eliminate this kind of gamesmanship.
>>>
>>> There is a beneficial side effect of the second paragraph as
>>> stated, in the special situation when the maximum allocation
>>> size is increased, due to ARIN obtaining a sufficiently large
>>> amount of additional resources, an organization may receive
>>> additional resources earlier than the normal three month
>>> period.  But, only in this special situation and when an
>>> organization properly utilizes a previous maximum allocation in
>>> less than three months, may an organization receive additional
>>> resources in less than the normal three month period.
>>>
>>> Other ratios, such as one half (1/2) or one eighth (1/8) could be
>>> considered.  One eighth (1/8) would provide greater assurance
>>> of eliminating the need to use multiple blocks to fulfill requests
>>> and ensure a greater number of organizations receive
>>> resources.  However, one eighth (1/8) is more likely to be seen
>>> as rationing and an attempt to artificially extend the lifetime of
>>> IPv4.  During the ARIN XXIII policy discussion there seemed to
>>> be a consensus that attempts to extend the lifetime of IPv4
>>> resources would be undesirable.  While on the other hand, one
>>> half (1/2) is even less likely to ration resources, it would likely
>>> result in the resource being spread across significantly fewer
>>> organizations and increase the need to use multiple blocks to
>>> fulfill requests.
>>>
>>> Finally, combining the 3 month period with the one quarter
>>> (1/4) ratio provides roughly an annualized equivalent of the
>>> whole ARIN free pool being made available to a single
>>> organization.  While it is not possible for a single organization
>>> to receive the whole ARIN free pool within one year under this
>>> policy, it is a virtual certainty that multiple organization will be
>>> requesting resources, and that the ARIN free pool will not likely
>>> last a full year following the exhaustion of the IANA free pool
>>> anyway.  Therefore, the ratio one quarter (1/4) seems to strike
>>> a balance between making resources available with as little
>>> restriction as possible and ensuring an equitable distribution of
>>> those resources during and following the run-out phase.
>>>
>>> 9. Timetable for implementation:  Immediate
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>


From farmer at umn.edu  Thu Jun 18 19:14:53 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 18 Jun 2009 18:14:53 -0500
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out by
	Prefix Size - Revised
In-Reply-To: <4607e1d50906181442x5dfffb14y8e3fffba711700e3@mail.gmail.com>
References: <4A3A8049.90103@arin.net>,
	<4607e1d50906181442x5dfffb14y8e3fffba711700e3@mail.gmail.com>
Message-ID: <4A3A841D.15461.479CD9F@farmer.umn.edu>

On 18 Jun 2009 Martin Hannigan wrote:

> Not in favor. Any change from first and first out based on the current
> minimum allocation unit is a mid game change which is patently unfair.

This does nothing to change first-in-first out, does nothing to change 
minimum allocation units at all only sets a maximum allocation unit, a ceiling 
based on the total available resources in the ARIN free pool.  If there are a 
lot of resources you can still get a lot, you just can't clean ARIN out with a 
singe request.  

> Automatically changing the allocation size is quite different than
> requiring a policy proposal _based on current conditions_.
> Circumstances may chance the popularity of such a proposal. One could
> argue that it too could be changed. Why not simply change the
> allocation unit from meet to meet?>

If you want to put in a conservative Maximum allocation unit in like everyone 
only gets a /20 when ARIN get to some point then OK.  But, in 2009-2 people 
called that rationing and didn't like it.

I don't want NYBISP (Name Your Big ISP) taking the last /10 ARIN has and 
cleaning out the free pool.  This will create a political @#$$% storm, if that 
happens.  If it happens, it will not be NYBISP's fault it will be ours because 
they will only be doing what we are telling them to do.  Big ISP are not evil, 
they are Big and use lots of addresses, if you tell them they should clean out 
ARIN they can, will, and should, because it is what we are telling them they 
should do.

In the example above instead of NYBISP get the last /10, they would get a 
/12 and could come back in 3 month if there is anything left, this maximum 
goes down and down until you get to a /20 and them someone big or small 
get the last /20 then ARIN runs out. 

I was trying to find a way make the end-game work without rationing, that is 
what people seemed to want comming out of San Antonio.

If you don't like this way what do you suggest?

> Best,
> 
> Martin
> 


===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From martin.hannigan at batelnet.bs  Thu Jun 18 20:13:11 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Thu, 18 Jun 2009 20:13:11 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out by
	Prefix Size - Revised
In-Reply-To: <4A3A841D.15461.479CD9F@farmer.umn.edu>
References: <4A3A8049.90103@arin.net>
	<4607e1d50906181442x5dfffb14y8e3fffba711700e3@mail.gmail.com>
	<4A3A841D.15461.479CD9F@farmer.umn.edu>
Message-ID: <4607e1d50906181713l55a2525cx8a1d72759388e5a6@mail.gmail.com>

On Thu, Jun 18, 2009 at 7:14 PM, David Farmer<farmer at umn.edu> wrote:
> On 18 Jun 2009 Martin Hannigan wrote:


[ snip ]

>
> I don't want NYBISP (Name Your Big ISP) taking the last /10 ARIN has and
> cleaning out the free pool. ?This will create a political @#$$% storm, if that
> happens.


What will create a larger political storm is if we dramatically change
our policy to be lopsided towards one party or another.

If "big ISP" has the need for a /10 why shouldn't they be able to
acquire it after justification?

>If it happens, it will not be NYBISP's fault it will be ours because
> they will only be doing what we are telling them to do. ?Big ISP are not evil,
> they are Big and use lots of addresses, if you tell them they should clean out
> ARIN they can, will, and should, because it is what we are telling them they
> should do.

We have policy. That policy is followed by our members. If our members
have a need, they make a request. They request what they need. We
review their requests for allocations against our policy. Analysts
then determine that there is indeed a need. We've implemented checks
and balance and even officer certifications.

How do these ISP's or others expect to clean us out again?

>
> In the example above instead of NYBISP get the last /10, they would get a
> /12 and could come back in 3 month if there is anything left, this maximum
> goes down and down until you get to a /20 and them someone big or small
> get the last /20 then ARIN runs out.

Right, but again we're faced with one requester[1] fulfilling 100% of
their need and another fulfilling 1%. This is a situation very much
like the one with the recent global policy trying to return space to
the IANA from within the region[2].

>
> I was trying to find a way make the end-game work without rationing, that is
> what people seemed to want comming out of San Antonio.
>
> If you don't like this way what do you suggest?
>

I suggest that we instead change the minimum allocation unit as we
always have on a meeting to meeting basis and avoid creating a
specific policy with automatic triggers.

So, in order to [attempt to] avoid another five hundred post thread,
let me summarize:

1. Not in favor
2. Unfair to change mid-game
3. Creates an unfair condition where some get satisfied and others don't.
4. Could create an unfair advantage for competitors[3]
5. Invites BoT emergency power action since it has automatic triggers
that could fail on [unknown] existing conditions at any time.

I'd rather see the BoT invoke their emergency powers for something
that we "missed", not created.


Best,

Martin

1. Not all requests are from service providers. There are big
enterprises and infrastructure players who have large amounts of space
as well and are likely to have continued needs.

2. I'm still baffled as to why the lawyers agreed with me when I
stated the same thing re unfair and lopsided fulfillment with this
policy, but disagreed with me on another, similarly functioning
regional policy

3. IANAL, but seems to at least offer a whiff of anti-trust i.e.
restraint of free trade.


From jmaimon at chl.com  Thu Jun 18 20:46:29 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 18 Jun 2009 20:46:29 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out
 by	Prefix Size - Revised
In-Reply-To: <4607e1d50906181713l55a2525cx8a1d72759388e5a6@mail.gmail.com>
References: <4A3A8049.90103@arin.net>	<4607e1d50906181442x5dfffb14y8e3fffba711700e3@mail.gmail.com>	<4A3A841D.15461.479CD9F@farmer.umn.edu>
	<4607e1d50906181713l55a2525cx8a1d72759388e5a6@mail.gmail.com>
Message-ID: <4A3ADFE5.9070005@chl.com>



Martin Hannigan wrote:

> 
> What will create a larger political storm is if we dramatically change
> our policy to be lopsided towards one party or another.

If there is to be a political firestorm, the lopsidedness cited is going 
to be the one that goes far far far far in the other direction of 
keeping some crumbs out of the voracious mouths of the few.

Is not 80% of all ARIN IP space enough for those mouths?

At a bare minimum, new entrants must be safeguarded.

> If "big ISP" has the need for a /10 why shouldn't they be able to
> acquire it after justification?

Because satisfying the longer terms needs of the many is more important 
   and more equitable than satisfying the very short term needs of the 
extremely few.

The large consumers are also coincidentally the ones I would hold most 
accountable for the state of ipv6 deployment, were I to be playing the 
blame game.

If anyone had the means and opportunity to make it happen, it was them.

Let them lie in the bed of their own making FIRST.

To hear them come up and complain about these crumbs is fairly disturbing.

> 
>> If it happens, it will not be NYBISP's fault it will be ours because
>> they will only be doing what we are telling them to do.  Big ISP are not evil,
>> they are Big and use lots of addresses, if you tell them they should clean out
>> ARIN they can, will, and should, because it is what we are telling them they
>> should do.
> 
> We have policy. That policy is followed by our members.

And its always been followed, and its always been in the favor of the 
larger consumers and its high time some equity is restored.

And now members want to change it. You cant cite policy in your 
opposition to policy proposals.

Joe


From farmer at umn.edu  Thu Jun 18 21:19:19 2009
From: farmer at umn.edu (David Farmer)
Date: Thu, 18 Jun 2009 20:19:19 -0500
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out by
	Prefix Size - Revised
In-Reply-To: <4607e1d50906181713l55a2525cx8a1d72759388e5a6@mail.gmail.com>
References: <4A3A8049.90103@arin.net>, <4A3A841D.15461.479CD9F@farmer.umn.edu>,
	<4607e1d50906181713l55a2525cx8a1d72759388e5a6@mail.gmail.com>
Message-ID: <4A3AA147.9232.4EBBBA3@farmer.umn.edu>

On 18 Jun 2009 Martin Hannigan wrote:

> On Thu, Jun 18, 2009 at 7:14 PM, David Farmer<farmer at umn.edu> wrote: >
> On 18 Jun 2009 Martin Hannigan wrote:
>
> [ snip ] 
>
> > I don't want NYBISP (Name Your Big ISP) taking the last /10 ARIN has
> > and cleaning out the free pool. ?This will create a political @#$$%
> > storm, if that happens.
> 
> What will create a larger political storm is if we dramatically change
> our policy to be lopsided towards one party or another.
> 
> If "big ISP" has the need for a /10 why shouldn't they be able to
> acquire it after justification?

Tell me how big ISP2 gets a /10 when ARIN has nothing left because big ISP 
1 cleaned out ARIN getting a /10, 5 minutes before?

With this policy big ISP1 gets a /12, big ISP2 gets a /12, big ISP3 gets a /12, 
big ISP4 gets a /13, big ISP5 gets a /13, big ISP6 gets a /13, big ISP7 gets a 
/14 ... big ISP30 get a /20

So 29 other big ISPs get partially filled along with big ISP1.

Under this policy maybe big ISP1 sues for not getting the whole /10.  But that 
is one case for ARIN to defend, and one judge to convince that ARIN was a 
good steward of resources. 

Under the current policy why wouldn't big ISP2-30 sue ARIN for getting 
noting.  But, now you have 29 case to defend and 29 judges to convince that 
ARIN was a good steward of resources.

This isn't about the big guys or the little guys it about how we approch 0 
resources available.

> >If it happens, it will not be NYBISP's fault it will be ours because
> > they will only be doing what we are telling them to do. ?Big ISP are
> > not evil, they are Big and use lots of addresses, if you tell them
> > they should clean out ARIN they can, will, and should, because it is
> > what we are telling them they should do.
>
> We have policy. That policy is followed by our members. If our members
> have a need, they make a request. They request what they need. We
> review their requests for allocations against our policy. Analysts
> then determine that there is indeed a need. We've implemented checks
> and balance and even officer certifications.

The current policies are based on an assumption you just go get more when 
ARIN runs low.  When ARIN can't more the assumption the policy is based 
on breaks.
 
> How do these ISP's or others expect to clean us out again?
> 
> >
> > In the example above instead of NYBISP get the last /10, they would
> > get a /12 and could come back in 3 month if there is anything left,
> > this maximum goes down and down until you get to a /20 and them
> > someone big or small get the last /20 then ARIN runs out.
> 
> Right, but again we're faced with one requester[1] fulfilling 100% of
> their need and another fulfilling 1%. This is a situation very much
> like the one with the recent global policy trying to return space to
> the IANA from within the region[2].

So your suggestion will fill 100% of everyones until we can fill 0% of 
everyone elses


> > I was trying to find a way make the end-game work without rationing,
> > that is what people seemed to want comming out of San Antonio.
> >
> > If you don't like this way what do you suggest?
> >
> 
> I suggest that we instead change the minimum allocation unit as we
> always have on a meeting to meeting basis and avoid creating a
> specific policy with automatic triggers.

Explain how changing the minimum allocations unit does anything?  Are you 
suggesting we raise the minimum allocation unit to /10 so only the big guys 
can get addresses?

Specificall what are you suggesting?

> So, in order to [attempt to] avoid another five hundred post thread,
> let me summarize:
> 
> 1. Not in favor

OK fine

> 2. Unfair to change mid-game

What happened to the /13 maximum allocation that ARIN originally had 
then?  Why wasn't that an unfair change mid-game?  Change is not unfair it 
is what policy does.

> 3. Creates an unfair condition where some get satisfied and others
> don't. 

This policy doesn't do that, running out of IPv4 addresses does, this policy is 
just trying to find a way to deal with the facts-of-life.

> 4. Could create an unfair advantage for competitors[3]

The current policy will (no could) create a unfair advantage for competitors.  
This policy is just trying make sure there are no big winers out of the run-out, 
it is trying to spread the pain around a bit.

> 5. Invites BoT emergency power action since it has automatic triggers
> that could fail on [unknown] existing conditions at any time.
> 
> I'd rather see the BoT invoke their emergency powers for something
> that we "missed", not created.


No your suggesting the we do nothing even though we see a big problem 
coming at us.
 
> Best,
> 
> Martin
> 
> 1. Not all requests are from service providers. There are big
> enterprises and infrastructure players who have large amounts of space
> as well and are likely to have continued needs.

Yes, they are included in this too, the policy covers allocations and 
assignements

> 2. I'm still baffled as to why the lawyers agreed with me when I
> stated the same thing re unfair and lopsided fulfillment with this
> policy, but disagreed with me on another, similarly functioning
> regional policy
> 
> 3. IANAL, but seems to at least offer a whiff of anti-trust i.e.
> restraint of free trade.



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From michael.dillon at bt.com  Fri Jun 19 03:24:54 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 19 Jun 2009 08:24:54 +0100
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out
	byPrefix Size - Revised
In-Reply-To: <4607e1d50906181713l55a2525cx8a1d72759388e5a6@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C49745801BDF587@E03MVZ2-UKDY.domain1.systemhost.net>

> 1. Not in favor

No comment.

> 2. Unfair to change mid-game

It's the end-game, not mid-game.

> 3. Creates an unfair condition where some get satisfied and 
> others don't.

The unfair condition has already been created by the circumstance
of IPv4 runout.

--Michael Dillon


From michael.dillon at bt.com  Fri Jun 19 03:27:56 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 19 Jun 2009 08:27:56 +0100
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out
	by	Prefix Size - Revised
In-Reply-To: <4A3ADFE5.9070005@chl.com>
Message-ID: <28E139F46D45AF49A31950F88C49745801BDF592@E03MVZ2-UKDY.domain1.systemhost.net>



> At a bare minimum, new entrants must be safeguarded.

Not in the end-game. In any case, there is plenty of IPv6 for
new entrants so ARIN is safeguarding them. 

Remember that IPv4 runout causes a certain amount of chaos
and only the most foolish investors would fund a new entrant
into a dying game during a period of chaos, when there is
a new game already running with future prospects and no
chaos.

--Michael Dillon


From tvest at pch.net  Fri Jun 19 08:51:35 2009
From: tvest at pch.net (Tom Vest)
Date: Fri, 19 Jun 2009 08:51:35 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out
	by	Prefix Size - Revised
In-Reply-To: <28E139F46D45AF49A31950F88C49745801BDF592@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745801BDF592@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <AAECA927-97ED-4948-BDA8-1FC2F975BD7E@pch.net>


On Jun 19, 2009, at 3:27 AM, <michael.dillon at bt.com> <michael.dillon at bt.com 
 > wrote:

>
>
>> At a bare minimum, new entrants must be safeguarded.
>
> Not in the end-game.

How do you justify this assertion?
Do you think that accepting industry closure to new entry is a good  
idea in general?
Do you think that the current balance of internal (i.e., current  
member) and external stakeholder interests, which favors the existing  
industry coordination arrangements, will survive that development?

> In any case, there is plenty of IPv6 for new entrants so ARIN is  
> safeguarding them.

I'm glad that IANA didn't think that way thirty years ago: "256 /8  
recipients could easily support plenty of future customers, so the  
system is safeguarding them."

I'm glad that the internal stakeholders didn't think that way fifteen  
years ago: "there's no shortage of private addressing options for new  
entrants, so the system is safeguarding them."

The fiction that IPv6 is substitutable for IPv4 *today* will not hold;  
it will never hold until it ceases to be fiction. The timing of that  
development will be wholly determined by incumbent IPv4 holders.

> Remember that IPv4 runout causes a certain amount of chaos
> and only the most foolish investors would fund a new entrant
> into a dying game during a period of chaos, when there is
> a new game already running with future prospects and no
> chaos.

How many investors were still funding real estate speculation in Q4  
2007?
Why didn't the wise, farsighted investors who knew better save the  
system by shorting all of the crazy ideas and deflating the bubble  
before it was too late?
We will not be saved by the farsightedness and deep wisdom of outside  
observers/investors.

The chaos and "dying game" that you're describing will be internal to  
current IPv4-based operators, who need to decide out what to do next.  
The most visible/prominent manifestation that the runout will have in  
the broader context will be the stories of what happens to the next  
generation of aspiring operators who find out what our version of  
"safeguarding them" really means.

I'm glad that other industries aren't guided by this kind of  
reasoning; there would be a lot more engineered chaos, and a lot fewer  
competitive markets in the world.

TV


From michael.dillon at bt.com  Fri Jun 19 11:13:28 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 19 Jun 2009 16:13:28 +0100
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out
	by	Prefix Size - Revised
In-Reply-To: <AAECA927-97ED-4948-BDA8-1FC2F975BD7E@pch.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801BE0087@E03MVZ2-UKDY.domain1.systemhost.net>


> >> At a bare minimum, new entrants must be safeguarded.
> >
> > Not in the end-game.
> 
> How do you justify this assertion?
> Do you think that accepting industry closure to new entry is 
> a good idea in general?

The end-game is created by circumstance and it is the circumstance
that closes the industry to new entrants. Just like oil production
in Pennsylvania.

There will eventually be a new IPv4 game once the Internet game has
shifted onto IPv6, and at that time, new entrants will once again
be able to build IPv4 networks, again because of circumstances.
Just like repurposing a steel mill from processing ore to processing
scrap metal.

> Do you think that the current balance of internal (i.e., current
> member) and external stakeholder interests, which favors the 
> existing industry coordination arrangements, will survive 
> that development?

Huh?
This is the PUBLIC policy mailing list. Please write in English.

> > In any case, there is plenty of IPv6 for new entrants so ARIN is 
> > safeguarding them.
> 
> I'm glad that IANA didn't think that way thirty years ago: 
> "256 /8 recipients could easily support plenty of future 
> customers, so the system is safeguarding them."

But IANA did think that way more or less. But when circumstances
changed, the thinking changed as well. 

> The fiction that IPv6 is substitutable for IPv4 *today* will 
> not hold; it will never hold until it ceases to be fiction. 
> The timing of that development will be wholly determined by 
> incumbent IPv4 holders.

The fact is that the global IPv4 network will not be able to grow
in a few years and after two years, growth will be harder and more
costly. But IPv6 can grow today, two years from now and twenty years
from now. This is fact, not fiction. The only reason that IPv6 and
IPv4 are not easily substitutable today is because the networking
industry (equipment vendors and operators) are dragging their feet.
The OS industry has been ready for years now and people who turn on
IPv6 find that it just works, until they bang their heads against
network operators who in turn are banging their heads against
various vendors. Even Cisco and Juniper, who are the best of the
lot concerning IPv6, still have some rough spots.

> How many investors were still funding real estate speculation 
> in Q4 2007?

You convinced me. ARIN should help new entrants to throw away
their money on new IPv4 networks right up until the last day.
Let the bankruptcy courts resolve the issue.

> The chaos and "dying game" that you're describing will be 
> internal to current IPv4-based operators, who need to decide 
> out what to do next.  

No, it will affect anyone running an IPv4 network that needs
to grow. That includes end users and new entrants who are not
currently running IPv4 networks.

> The most visible/prominent manifestation that the runout will 
> have in the broader context will be the stories of what 
> happens to the next generation of aspiring operators who find 
> out what our version of "safeguarding them" really means.

Nah, the press likes an underdog. They will be writing about the
farsighting new entrants whose IPv6 network is running rings around
the incumbents who are struggling to get IPv6 product out of the lab.

--Michael Dillon

P.S. that bit about helping new entrants throw away money was
sarcasm, in case anyone thought I was serious.



From tvest at pch.net  Fri Jun 19 14:12:24 2009
From: tvest at pch.net (Tom Vest)
Date: Fri, 19 Jun 2009 14:12:24 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out
	by	Prefix Size - Revised
In-Reply-To: <28E139F46D45AF49A31950F88C49745801BE0087@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745801BE0087@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <3F150ADF-3787-439F-8797-4FD79622E225@pch.net>


On Jun 19, 2009, at 11:13 AM, <michael.dillon at bt.com> wrote:

>
>>>> At a bare minimum, new entrants must be safeguarded.
>>>
>>> Not in the end-game.
>>
>> How do you justify this assertion?
>> Do you think that accepting industry closure to new entry is
>> a good idea in general?
>
> The end-game is created by circumstance and it is the circumstance
> that closes the industry to new entrants. Just like oil production
> in Pennsylvania.

That would be a good analogy IF Pennsylvania oil producers controlled  
the only oil on Earth, AND Pennsylvania oil producers could continue  
to service their own customers indefinitely regardless of the size of  
the oil reserves, AND they also unilaterally controlled the  
feasibility/cost of shifting to a different energy source for every  
other current or future energy user.

In other words, it's not a very good analogy.

> There will eventually be a new IPv4 game once the Internet game has
> shifted onto IPv6, and at that time, new entrants will once again
> be able to build IPv4 networks, again because of circumstances.
> Just like repurposing a steel mill from processing ore to processing
> scrap metal.

No one really cares about about building "IPv4 networks" -- not today,  
nor in all likelihood anytime in the future.
They care about building IP networks that work, which includes the  
feature "can interoperate independently with more than 0.1% of the  
rest of the Internet."
Today that happens to limit the options to IPv4-based networks.
If the environment eventually changes enough to make IPv6 functional  
enough to stand in for IPv4, then the ambition will still be the same;  
only the implementation options will change.

The goal is to preserve industry openness as long as it takes for that  
environmental shift to occur.

>> Do you think that the current balance of internal (i.e., current
>> member) and external stakeholder interests, which favors the
>> existing industry coordination arrangements, will survive
>> that development?
>
> Huh?
> This is the PUBLIC policy mailing list. Please write in English.

Every governance arrangement that endures for any length of time does  
so because of a combination of internal and external support.
One of the best ways to preserve that support, on both sides, is to  
keep the barrier between internal and external stakeholders low, so  
it's easy to transition back and forth as circumstances dictate. One  
of the fastest ways to erode that support is to let the barrier  
ossify, creating a permanent caste of privileged insiders vs. everyone  
else.

Hopefully that's clear enough.

>>> In any case, there is plenty of IPv6 for new entrants so ARIN is
>>> safeguarding them.
>>
>> I'm glad that IANA didn't think that way thirty years ago:
>> "256 /8 recipients could easily support plenty of future
>> customers, so the system is safeguarding them."
>
> But IANA did think that way more or less.

The "less" part of that thinking is why there are now around 15-20k  
independent players in the routing services industry, instead of just  
256.
I personally don't think that that's a trivial difference.

> But when circumstances changed, the thinking changed as well.

Agreed, but in the previous two episodes, the thinking changed *in  
anticipation* of the changing circumstances, and the pro-competitive  
adjustments in industry practices that resulted *averted* the worst of  
the anticipated consequences. I wish that model of industry adaptation  
were more widely appreciated today.

>> The fiction that IPv6 is substitutable for IPv4 *today* will
>> not hold; it will never hold until it ceases to be fiction.
>> The timing of that development will be wholly determined by
>> incumbent IPv4 holders.
>
> The fact is that the global IPv4 network will not be able to grow
> in a few years and after two years, growth will be harder and more
> costly. But IPv6 can grow today, two years from now and twenty years
> from now.

Does that mean that you're willing to start returning all of your IPv4  
to the registry today, in return for IPv6?

> This is fact, not fiction. The only reason that IPv6 and
> IPv4 are not easily substitutable today is because the networking
> industry (equipment vendors and operators) are dragging their feet.

But Michael, when we say "the industry," we're talking about us.
There is no "they" in "dragging their feet" that is not us.
It's a description of the fact, not an explanation -- much less an  
explanation that instills confidence that the problem will simply  
disappear by itself anytime soon.

> The OS industry has been ready for years now and people who turn on
> IPv6 find that it just works, until they bang their heads against
> network operators who in turn are banging their heads against
> various vendors. Even Cisco and Juniper, who are the best of the
> lot concerning IPv6, still have some rough spots.
>
>> How many investors were still funding real estate speculation
>> in Q4 2007?
>
> You convinced me. ARIN should help new entrants to throw away
> their money on new IPv4 networks right up until the last day.
> Let the bankruptcy courts resolve the issue.

The only thing that ARIN and/or industry members can do, at any/every  
point in time, is take steps to make sure that some kind of  
*functional* IP addresses remain available to aspiring and eligible  
new entrants on a non-adversarial, non-discriminatory basis -- kind of  
like they way they are today. Availability of non-functional IP  
addresses, or availability of functional addresses but only under  
crippling conditions are not real alternatives; they're not going to  
fool anybody for long.

If there's nothing that ARIN and/or industry members can do to  
preserve that condition, then the future is predetermined, and I guess  
we can all just relax.

>> The chaos and "dying game" that you're describing will be
>> internal to current IPv4-based operators, who need to decide
>> out what to do next.
>
> No, it will affect anyone running an IPv4 network that needs
> to grow. That includes end users and new entrants who are not
> currently running IPv4 networks.

An incumbent IPv4 holder who needs to grow in a post-IPv4 environment  
has three choices:

1. Beg/borrow/buy IPv4 from another incumbent
2. RFC 1918 + reshuffle
3. IPv6

A new entrant will have, at best, (1) -- but they'll be competing with  
all of the incumbents who will still be preferring that over the  
alternatives.
The winning public argument for transfer markets depended heavily on  
the assertion that there would be substantial continuing demand for  
IPv4 *among incumbents.*
Without that element, the transfer proposals would have taken on an  
entirely different character.

>> The most visible/prominent manifestation that the runout will
>> have in the broader context will be the stories of what
>> happens to the next generation of aspiring operators who find
>> out what our version of "safeguarding them" really means.
>
> Nah, the press likes an underdog. They will be writing about the
> farsighting new entrants whose IPv6 network is running rings around
> the incumbents who are struggling to get IPv6 product out of the lab.

Or perhaps they'll be writing about the clever operators using IPv10,  
which will be just as useful to new entrants in an IPv4-mandatory  
market.

But I think that neither is likely.

When read the papers and magazines "of record" these days, I don't see  
a lot of articles about scrappy new banks running rings around their  
stodgy, misguided predecessors.
I do see lots of articles about banks -- but most of them have a  
decidedly different story line.

nuff said,

TV


> --Michael Dillon
>
> P.S. that bit about helping new entrants throw away money was
> sarcasm, in case anyone thought I was serious.

I got that ;-)
For anyone who didn't, please note that I was being similarly glib  
with the "IPv10" reference...



From michael.dillon at bt.com  Sat Jun 20 05:27:54 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sat, 20 Jun 2009 10:27:54 +0100
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out
	by	Prefix Size - Revised
In-Reply-To: <3F150ADF-3787-439F-8797-4FD79622E225@pch.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801C74F16@E03MVZ2-UKDY.domain1.systemhost.net>


>could continue to service their own customers 
> indefinitely regardless of the size of the 

ISPs cannot continue to service their customers indefinitely
with IPv4 because their main service is not IPv4 connectivity
but access to the Internet. The Internet is constantly growing
and in a couple of years that growth will shift to IPv6. Any
ISP that only supports IPv4 access will be at a disadvantage.
In that climate it would be as crazy to start up an IPv4 ISP 
as to start drilling for oil in Pennsylvania. That dog don't 
hunt no more.

> The goal is to preserve industry openness as long as it takes 
> for that environmental shift to occur.

Unfortunately, IPv4 runout is an absolute limit to growth, and unless
some companies shift early and give up their IPv4 addresses, we will
runout and be unable to serve new entrants.

> > This is fact, not fiction. The only reason that IPv6 and
> > IPv4 are not easily substitutable today is because the networking 
> > industry (equipment vendors and operators) are dragging their feet.
> 
> But Michael, when we say "the industry," we're talking about us.
> There is no "they" in "dragging their feet" that is not us.

Unfortunately, you are wrong. The people on PPML are such a small
subset of the industry, that it is wrong to think that they are 
us. In addition, most of the people on PPML are not decision
makers on any kind of scale. There may be CEOs here, but they
run small network businesses. The big organizations, if they are
represented here at all, are not represented by key decision
makers.

In addition, consolidation of the ISP industry and telecom 
industry, has meant that most of the Internet is now controlled
by large companies, and we all know that decision making in
large companies is complex and diffuse.

I think that the people on this list are more likely to be 
pioneers of IPv6, pushing their companies, their employers,
their vendors, to get IPv6 ready for full commercial deployment.

> An incumbent IPv4 holder who needs to grow in a post-IPv4 
> environment has three choices:
> 
> 1. Beg/borrow/buy IPv4 from another incumbent 2. RFC 1918 + 
> reshuffle 3. IPv6
> 
> A new entrant will have, at best, (1) -- but they'll be 
> competing with all of the incumbents who will still be 
> preferring that over the alternatives.

And that is the elephant in room number 1. New entrants
will not be able to beg, borrow or buy any IPv4 addresses
until IPv6 is widely deployed.

> The winning public argument for transfer markets depended 
> heavily on the assertion that there would be substantial 
> continuing demand for
> IPv4 *among incumbents.*
> Without that element, the transfer proposals would have taken 
> on an entirely different character.

It doesn't really matter. With virtually zero supply available
there won't be any transfers except for a few speculators who
have been sitting on unused addresses.

--Michael Dillon


From tvest at pch.net  Sat Jun 20 15:04:28 2009
From: tvest at pch.net (Tom Vest)
Date: Sat, 20 Jun 2009 15:04:28 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out
	by	Prefix Size - Revised
In-Reply-To: <28E139F46D45AF49A31950F88C49745801C74F16@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745801C74F16@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <574914CA-6A7C-4E37-A3B9-301342ADB222@pch.net>


On Jun 20, 2009, at 5:27 AM, <michael.dillon at bt.com> wrote:

>> The goal is to preserve industry openness as long as it takes
>> for that environmental shift to occur.
>
> Unfortunately, IPv4 runout is an absolute limit to growth, and unless
> some companies shift early and give up their IPv4 addresses, we will
> runout and be unable to serve new entrants.

That would be an unfortunate, and truly surprising/disappointing  
development, given the precedent established by previous addressing  
format transitions.
But since you decided to delete the relevant sections of this thread,  
I guess you don't want to talk about that anymore (?).

If you're right, then I guess we can just wait and see how fortunate  
or unfortunate it really is.

>>> This is fact, not fiction. The only reason that IPv6 and
>>> IPv4 are not easily substitutable today is because the networking
>>> industry (equipment vendors and operators) are dragging their feet.
>>
>> But Michael, when we say "the industry," we're talking about us.
>> There is no "they" in "dragging their feet" that is not us.
>
> Unfortunately, you are wrong. The people on PPML are such a small
> subset of the industry, that it is wrong to think that they are
> us. In addition, most of the people on PPML are not decision
> makers on any kind of scale. There may be CEOs here, but they
> run small network businesses. The big organizations, if they are
> represented here at all, are not represented by key decision
> makers.
>
> In addition, consolidation of the ISP industry and telecom
> industry, has meant that most of the Internet is now controlled
> by large companies, and we all know that decision making in
> large companies is complex and diffuse.

I agree of course. It was that larger "we" that I was referring to,  
and that larger "we" that, I suspect, increases the uncertainty and  
risk surrounding this particular moment of truth.

> I think that the people on this list are more likely to be
> pioneers of IPv6, pushing their companies, their employers,
> their vendors, to get IPv6 ready for full commercial deployment.

I agree here again, and I am only too aware how unwelcome some of my  
concerns have been to some of "us." But Michael, consider the  
implications of what you're claiming. I've been using this forum,  
pretty much exclusively, to describe what I think are credible  
concerns about the looming challenges and how policy might or might  
not affect them. I've been using this forum because I've been assuming  
that it's the right way to address those decision makers -- directly  
or indirectly -- who will determine whether we'll get through these  
changes with *important* and *unique* and *historically unprecedented*  
features of the Internet sector intact, if not strengthened -- or  
alternately if those features will get lost in the transition. I've  
been using this forum, pretty much exclusively, because I truly  
believe what I wrote before about governance structures -- another  
passage you decided to edit out of this exchange. In this case I'll  
restore it:

> Every governance arrangement that endures for any length of time  
> does so because of a combination of internal and external support.
> One of the best ways to preserve that support, on both sides, is to  
> keep the barrier between internal and external stakeholders low, so  
> it's easy to transition back and forth as circumstances dictate. One  
> of the fastest ways to erode that support is to let the barrier  
> ossify, creating a permanent caste of privileged insiders vs.  
> everyone else.


You're now suggesting that, regardless of my concerns, there's no  
point in sharing them in this internal forum because "we" have no real  
influence over how things turn out, including the disposition of  
policies that might exacerbate or meliorate the looming transition  
challenges. By my actions I am demonstrating that I disagree, so I can  
only hope that you're wrong about this.


>> An incumbent IPv4 holder who needs to grow in a post-IPv4
>> environment has three choices:
>>
>> 1. Beg/borrow/buy IPv4 from another incumbent 2. RFC 1918 +
>> reshuffle 3. IPv6
>>
>> A new entrant will have, at best, (1) -- but they'll be
>> competing with all of the incumbents who will still be
>> preferring that over the alternatives.
>
> And that is the elephant in room number 1. New entrants
> will not be able to beg, borrow or buy any IPv4 addresses
> until IPv6 is widely deployed.


Again, for the sake of all of "us" -- and everyone else -- I hope  
you're mistaken.


>> The winning public argument for transfer markets depended
>> heavily on the assertion that there would be substantial
>> continuing demand for
>> IPv4 *among incumbents.*
>> Without that element, the transfer proposals would have taken
>> on an entirely different character.
>
> It doesn't really matter. With virtually zero supply available
> there won't be any transfers except for a few speculators who
> have been sitting on unused addresses.
>
> --Michael Dillon

Well, on this count we agree once again. But speculators (or "market  
makers" as they're often called in other sectors) are a permanent,  
ubiquitous feature of markets, wherever there is a market. (BTW, have  
you noticed what's been happening to oil prices over the last week?)

And -- once again referring back to exchanges that you chose to delete  
from this thread -- the opportunity that "market makers" will be  
targeting will not be IPv4 per se, but rather portable IP addresses  
that are capable of supporting additional/new independent routing  
services, i.e., the kind that are mandatory for new entrants to exist.  
Anyone who's been paying attention to what happened in the broader  
economy over the last couple of years will probably agree that  
professional speculators may be guilty of ethical deficits, and also  
of an unhealthy capacity for self-deception, but they're rarely  
stupid, or ignorant of the conditions that permit them to exist and  
thrive. They just tend to work very hard to sustain those conditions  
until the absolute last possible minute, which the rest of us  
sometimes belatedly discover was actually about 2-3 years in the past.  
Once transfers have been institutionalized, the market will be a  
permanent reality for us -- regardless of whether there are a million  
transactions or zero transactions, i.e., regardless of whether it  
"promotes liquidity" (its intended effect) or it has the opposite  
effect (which you and I seem to agree is more likely).

... which is (just one of several reasons) why I have advocated  
mechanisms other than transfers/privatization to help us get past this  
unavoidable challenge.

TV

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090620/f4ee843d/attachment.htm>

From michael.dillon at bt.com  Sat Jun 20 16:18:39 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sat, 20 Jun 2009 21:18:39 +0100
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out
	by	Prefix Size - Revised
In-Reply-To: <574914CA-6A7C-4E37-A3B9-301342ADB222@pch.net>
Message-ID: <28E139F46D45AF49A31950F88C49745801C74F49@E03MVZ2-UKDY.domain1.systemhost.net>


> One of the fastest ways to erode 
> that support is to let the barrier ossify, creating a 
> permanent caste of privileged insiders vs. everyone else.

I think that this has already happened and a couple of symptoms are
the fact that PPML does not have much representation from decision
makers, and the changed policy development process that gives
the Advisory Council an enlarged role. The AC doesn't see a lot
of truly new blood, probably because the set of ISPs who are 
engaged in ARIN membership activity or PPML discussion, doesn't
change a whole lot. The ones that are ignoring us today, have
been ignoring us for a long time.

> You're now suggesting that, regardless of my concerns, 
> there's no point in sharing them in this internal forum 
> because "we" have no real influence over how things turn out, 
> including the disposition of policies that might exacerbate 
> or meliorate the looming transition challenges. By my actions 
> I am demonstrating that I disagree, so I can only hope that 
> you're wrong about this. 

Sometimes by raising an issue like this, people take various
actions, and the situation changes. Often it doesn't, but for
the level of effort involved, it is worth a try. And if you
really care about this, I think you need to try and get your
message out by other means than PPML to cover all your bases.

> 	And that is the elephant in room number 1. New entrants
> 	will not be able to beg, borrow or buy any IPv4 addresses
> 	until IPv6 is widely deployed.
> 
> Again, for the sake of all of "us" -- and everyone else -- I 
> hope you're mistaken.

Runout means there ain't any more of the stuff. It's all gone,
either in use or on someone's storeroom shelf waiting to be
used. Even if ARIN policy mandates JIT and demands that
everyone clear their storeroom shelves, ARIN can't enforce
such a policy, and nobody is going to jump to comply.

The only way to free up the supply is for some people to get
enough IPv6 in commercial production that they feel the risk
to themselves of giving up IPv4 addresses, is very very low.
I think that in most cases that will involve a service transition
whereby customers getting IPv4 service are upgraded en-masse
to IPv6. The ones who object will not be able to go elsewhere
and get IPv4 access. And a percentage of the IPv4 addresses 
recovered will be kept for some high-margin services that still
need growing IPv4 networks (probably private network services).
In that scenarion, a network operator could see a very low risk
to returning IPv4 blocks to ARIN or the market.

> Once 
> transfers have been institutionalized, the market will be a 
> permanent reality for us -- regardless of whether there are a 
> million transactions or zero transactions, i.e., regardless 
> of whether it "promotes liquidity" (its intended effect) or 
> it has the opposite effect (which you and I seem to agree is 
> more likely). 

I disagree that a market can exist without liquidity which
requires a steady stream of transactions and reasonably 
stable prices.

--Michael Dillon


From mueller at syr.edu  Mon Jun 22 12:37:00 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 22 Jun 2009 12:37:00 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out b
 Prefix Size - Revised
Message-ID: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>

>The only thing that ARIN and/or industry members can do, at any/every
>point in time, is take steps to make sure that some kind of
>*functional* IP addresses remain available to aspiring and eligible
>new entrants on a non-adversarial, non-discriminatory basis 

I've never understood this aspect of your argument, Tom. Please tell me how in an environment of exhaustion of the IPv4 space, ARIN makes IPv4 resources freely available to "aspiring" new entrants on a non-adversarial basis. Scarcity is coterminous with competition for possession. Scarcity means one person's occupation of addresses is mutually exclusive with another's. You posture as the holy man saving the open character of the Internet, but I have not yet heard a single feasible policy proposal from you that makes IPv4 addresses any less scarce. 

I totally share your concern with maintaining open entry, and allowing newcomers. Totally. I just think you've psychologically projected that concern into the wrong place. You did it with the debate over transfer markets, and you just keep doing it. 

Chopping up the last large blocks and handing them out in small chunks rather than large chunks does not make IP addresses more available to "aspiring and eligible new entrants." There is no guarantee in the policy that the small blocks will go to new entrants rather than, e.g., small incumbents or small chunks to big incumbents, or organizations in the education or financial industry. If your business plan depends on standing first in line for the last remaining scraps of v4 space, then you're entry into the Internet market may be doomed anyway, perhaps that's what Dillon is trying to tell you. 

As a rationing device, the finer-slice/maximum limit idea has some merit on purely equitable distribution grounds. But I do wish you'd quit distorting this debate with your posturing about new entrants. You want to do something about new entrants, start taking a look at levels of venture capital, bandwidth costs, spectrum availability, FCC regulations, etc. Any examples of specific firms who've left the market because of inability to access v4 addresses? That would be useful data. anmy data on how many such "aspiring" firms are standing in line waiting for some v4 crumbs? and who business plan depends on it? 

--MM

From jmaimon at chl.com  Mon Jun 22 13:22:01 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Mon, 22 Jun 2009 13:22:01 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out b
 Prefix Size - Revised
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>
References: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4A3FBDB9.2040300@chl.com>



Milton L Mueller wrote:

> Chopping up the last large blocks and handing them out in small chunks rather than large chunks does not make IP addresses more available to "aspiring and eligible new entrants." There is no guarantee in the policy that the small blocks will go to new entrants rather than, e.g., small incumbents or small chunks to big incumbents, or organizations in the education or financial industry. 


2009-2 which was abandoned for lack of consensus dealt with new entrants 
and small entities much better than this proposal.

This proposal is better than nothing and might win some consensus this 
time around.

 > If your business plan depends on standing first in line for the last 
remaining scraps of v4 space, then you're entry into the Internet market 
may be doomed anyway, perhaps that's what Dillon is trying to tell you.

Any business plan for entering the ISP market is going to depend on an 
ability to offer some minimum of ipv4 services, likely for many years 
following free pool depletion. That is the point of departure where not 
all of us share Dillon's rosy outlook on how the transition to ipv6 will 
occur.






From martin.hannigan at batelnet.bs  Mon Jun 22 13:56:46 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Mon, 22 Jun 2009 13:56:46 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out b
	Prefix Size - Revised
In-Reply-To: <4A3FBDB9.2040300@chl.com>
References: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>
	<4A3FBDB9.2040300@chl.com>
Message-ID: <4607e1d50906221056s7d03fa6xb946e47342ea15e6@mail.gmail.com>

On Mon, Jun 22, 2009 at 1:22 PM, Joe Maimon<jmaimon at chl.com> wrote:
>
>
> Milton L Mueller wrote:
>
>> Chopping up the last large blocks and handing them out in small chunks
>> rather than large chunks does not make IP addresses more available to
>> "aspiring and eligible new entrants." There is no guarantee in the policy
>> that the small blocks will go to new entrants rather than, e.g., small
>> incumbents or small chunks to big incumbents, or organizations in the
>> education or financial industry.
>
>
> 2009-2 which was abandoned for lack of consensus dealt with new entrants and
> small entities much better than this proposal.
>
> This proposal is better than nothing and might win some consensus this time
> around.

I think that's unlikely myself.

>> If your business plan depends on standing first in line for the last
>> remaining scraps of v4 space, then you're entry into the Internet market may
>> be doomed anyway, perhaps that's what Dillon is trying to tell you.
>
> Any business plan for entering the ISP market is going to depend on an
> ability to offer some minimum of ipv4 services, likely for many years
> following free pool depletion.


We could instead simply raise the minimum allocation unit and raise
the bar of entry _for PI_, eliminate end user allocations altogether,
and start pushing people towards PA.

Wouldn't that equalize the market for new entrants? They should be
able to operate an ISP as long as they can get numbers. Period.

Best,

Martin


From jmaimon at chl.com  Mon Jun 22 15:24:49 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Mon, 22 Jun 2009 15:24:49 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out b
 Prefix Size - Revised
In-Reply-To: <4607e1d50906221056s7d03fa6xb946e47342ea15e6@mail.gmail.com>
References: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>	
	<4A3FBDB9.2040300@chl.com>
	<4607e1d50906221056s7d03fa6xb946e47342ea15e6@mail.gmail.com>
Message-ID: <4A3FDA81.8090503@chl.com>


Martin Hannigan wrote:
>>
>> This proposal is better than nothing and might win some consensus this time
>> around.
>>     
>
> I think that's unlikely myself.
>   
Rather sad commentary, since the only thing shining through is the 
attitude "if I cant have it no one can".
> We could instead simply raise the minimum allocation unit and raise
> the bar of entry _for PI_, eliminate end user allocations altogether,
> and start pushing people towards PA.
>
> Wouldn't that equalize the market for new entrants? 

No, since there isnt any more space available after 5 to 10 of the 80 
large organizations per year get their requests fulfilled.

Making it easier (or harder) to get requests approved when there is no 
space to fulfill them is silly and pointless.

> They should be
> able to operate an ISP as long as they can get numbers. Period.
>   
Exactly, and we should ensure that they can continue to do so.
> Best,
>
> Martin
>   
Regards,

Joe


From martin.hannigan at batelnet.bs  Mon Jun 22 16:54:59 2009
From: martin.hannigan at batelnet.bs (Martin Hannigan)
Date: Mon, 22 Jun 2009 16:54:59 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out b
	Prefix Size - Revised
In-Reply-To: <4A3FDA81.8090503@chl.com>
References: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>
	<4A3FBDB9.2040300@chl.com>
	<4607e1d50906221056s7d03fa6xb946e47342ea15e6@mail.gmail.com>
	<4A3FDA81.8090503@chl.com>
Message-ID: <4607e1d50906221354x4437fbf5q60099b46264e827e@mail.gmail.com>

On Mon, Jun 22, 2009 at 3:24 PM, Joe Maimon<jmaimon at chl.com> wrote:
>
> Martin Hannigan wrote:
>>>
>>> This proposal is better than nothing and might win some consensus this
>>> time
>>> around.
>>>
>>
>> I think that's unlikely myself.
>>
>
> Rather sad commentary, since the only thing shining through is the attitude
> "if I cant have it no one can".


Quite the opposite. My comments and suggested alternatives are
generally considerate of a) the region b) continuing to find some
method of providing v4 space to everyone in this region  until final
exhaustion and c) the rest of the regions. After regional exhaustion,
markets will undoubtedly take over entirely with regards to v4. This
is likely to occur in all RIR regions.

>>
>> We could instead simply raise the minimum allocation unit and raise
>> the bar of entry _for PI_, eliminate end user allocations altogether,
>> and start pushing people towards PA.
>>
>> Wouldn't that equalize the market for new entrants?
>
> No, since there isnt any more space available after 5 to 10 of the 80 large
> organizations per year get their requests fulfilled.

Their requests would include the needs of their customers.

>
> Making it easier (or harder) to get requests approved when there is no space
> to fulfill them is silly and pointless.
>
>> They should be
>> able to operate an ISP as long as they can get numbers. Period.
>>
>
> Exactly, and we should ensure that they can continue to do so.


Getting space from their upstream does not accomplish this?

-M<


From bmanning at vacation.karoshi.com  Mon Jun 22 17:08:27 2009
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 22 Jun 2009 21:08:27 +0000
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out b
	Prefix Size - Revised
In-Reply-To: <4607e1d50906221354x4437fbf5q60099b46264e827e@mail.gmail.com>
References: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>
	<4A3FBDB9.2040300@chl.com>
	<4607e1d50906221056s7d03fa6xb946e47342ea15e6@mail.gmail.com>
	<4A3FDA81.8090503@chl.com>
	<4607e1d50906221354x4437fbf5q60099b46264e827e@mail.gmail.com>
Message-ID: <20090622210827.GB12065@vacation.karoshi.com.>



 crwaling out from under the rock and onto the soapbax.

 Martin.  there is no exaustion here... there is full utilization.
	the trick here is to recast your thinking ... utilization is
	not when a block of size foo is released by ARIN (RIR) to an
	actor.  this has been the historical metric (IANA will exaust
	when the last /8 is handed over ot the RIR) and is a false measure.
	the RIRs are using HD ratios to measure utilization, which is 
	a somewhat better metric, but even that might be too ambgious
	going forward.

	once all the v4 space (as measured by /8) is fully utilized, its
	wise to change ones thinking. and we sort of have... by moving the
	utilization metric to a /22 or /24 (depending).
	using that technique, we still have some (perhaps a lot) of v4 space
	left.  but soon we will be in the postion where 
	all the v4 space (as measured by /24) is fully utilized.  but I'd make
	you the wager that there is still a whole lot of unused /28 and longer
	space that is fallow.  

	then the question is, how to squeeze better utilization out of the free space
	to aid in transtion?

	are /31 blocks of v4 space useful/usable going forward?  I'd say yes, but
	thats not a currently popular POV.

	so..  we are not exausting, we are (or should be) shooting for higher
	utilization of the space.

--bill



On Mon, Jun 22, 2009 at 04:54:59PM -0400, Martin Hannigan wrote:
> On Mon, Jun 22, 2009 at 3:24 PM, Joe Maimon<jmaimon at chl.com> wrote:
> >
> > Martin Hannigan wrote:
> >>>
> >>> This proposal is better than nothing and might win some consensus this
> >>> time
> >>> around.
> >>>
> >>
> >> I think that's unlikely myself.
> >>
> >
> > Rather sad commentary, since the only thing shining through is the attitude
> > "if I cant have it no one can".
> 
> 
> Quite the opposite. My comments and suggested alternatives are
> generally considerate of a) the region b) continuing to find some
> method of providing v4 space to everyone in this region  until final
> exhaustion and c) the rest of the regions. After regional exhaustion,
> markets will undoubtedly take over entirely with regards to v4. This
> is likely to occur in all RIR regions.
> 
> >>
> >> We could instead simply raise the minimum allocation unit and raise
> >> the bar of entry _for PI_, eliminate end user allocations altogether,
> >> and start pushing people towards PA.
> >>
> >> Wouldn't that equalize the market for new entrants?
> >
> > No, since there isnt any more space available after 5 to 10 of the 80 large
> > organizations per year get their requests fulfilled.
> 
> Their requests would include the needs of their customers.
> 
> >
> > Making it easier (or harder) to get requests approved when there is no space
> > to fulfill them is silly and pointless.
> >
> >> They should be
> >> able to operate an ISP as long as they can get numbers. Period.
> >>
> >
> > Exactly, and we should ensure that they can continue to do so.
> 
> 
> Getting space from their upstream does not accomplish this?
> 
> -M<
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From jmaimon at chl.com  Mon Jun 22 17:43:09 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Mon, 22 Jun 2009 17:43:09 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out b
 Prefix Size - Revised
In-Reply-To: <4607e1d50906221354x4437fbf5q60099b46264e827e@mail.gmail.com>
References: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>	
	<4A3FBDB9.2040300@chl.com>	
	<4607e1d50906221056s7d03fa6xb946e47342ea15e6@mail.gmail.com>	
	<4A3FDA81.8090503@chl.com>
	<4607e1d50906221354x4437fbf5q60099b46264e827e@mail.gmail.com>
Message-ID: <4A3FFAED.9040609@chl.com>

Bill Manning wrote regarding utilization:

The transfer system is intended to wring inefficiencies out of previous 
utilization measures. It will probably succeed to the extent that our 
routing system can accommodate it.

However, I believe complete reliance on a transfer market driven 
situation is not advantageous or necessarily equitable to all players. 
We need to hedge our bets.


Martin Hannigan wrote:
> On Mon, Jun 22, 2009 at 3:24 PM, Joe Maimon<jmaimon at chl.com> wrote:
>   
>> Martin Hannigan wrote:
>>     
>>>> This proposal is better than nothing and might win some consensus this
>>>> time
>>>> around.
>>>>
>>>>         
>>> I think that's unlikely myself.
>>>
>>>       
>> Rather sad commentary, since the only thing shining through is the attitude
>> "if I cant have it no one can".
>>     
>
>
> Quite the opposite. My comments and suggested alternatives are
> generally considerate of a) the region b) continuing to find some
> method of providing v4 space to everyone in this region  until final
> exhaustion and c) the rest of the regions. After regional exhaustion,
> markets will undoubtedly take over entirely with regards to v4. This
> is likely to occur in all RIR regions.
>   

I dont think complete reliance on a transfer system that could as easily 
lock out small players as it could larger players is a defensible 
position in light of ARIN's goals.

>>> We could instead simply raise the minimum allocation unit and raise
>>> the bar of entry _for PI_, eliminate end user allocations altogether,
>>> and start pushing people towards PA.
>>>
>>> Wouldn't that equalize the market for new entrants?
>>>       
>> No, since there isnt any more space available after 5 to 10 of the 80 large
>> organizations per year get their requests fulfilled.
>>     
>
> Their requests would include the needs of their customers.
>   

Only by revocation of PI availability. This sounds like pouring salt 
into the wounds of the small organizations.Which is all moot at the rate 
it is going anyways.

>   
>> Making it easier (or harder) to get requests approved when there is no space
>> to fulfill them is silly and pointless.
>>
>>     
>>> They should be
>>> able to operate an ISP as long as they can get numbers. Period.
>>>
>>>       
>> Exactly, and we should ensure that they can continue to do so.
>>     
>
>
> Getting space from their upstream does not accomplish this?
>   

No, there is a reason PI exists.

> -M<
>
>   
Joe


From tvest at pch.net  Mon Jun 22 18:19:23 2009
From: tvest at pch.net (Tom Vest)
Date: Mon, 22 Jun 2009 18:19:23 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out b
	Prefix Size - Revised
In-Reply-To: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>
References: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <2367B756-B4FD-46BA-B981-8175B2DF8BEA@pch.net>


On Jun 22, 2009, at 12:37 PM, Milton L Mueller wrote:

>> The only thing that ARIN and/or industry members can do, at any/every
>> point in time, is take steps to make sure that some kind of
>> *functional* IP addresses remain available to aspiring and eligible
>> new entrants on a non-adversarial, non-discriminatory basis
>
> I've never understood this aspect of your argument, Tom. Please tell  
> me how in an environment of exhaustion of the IPv4 space, ARIN makes  
> IPv4 resources freely available to "aspiring" new entrants on a non- 
> adversarial basis. Scarcity is coterminous with competition for  
> possession. Scarcity means one person's occupation of addresses is  
> mutually exclusive with another's. You posture as the holy man  
> saving the open character of the Internet, but I have not yet heard  
> a single feasible policy proposal from you that makes IPv4 addresses  
> any less scarce.

Hi Milton,

Wow, I don't think anyone has ever accused me of "posturing," much  
less as a holy man.
I'm not quite sure whether to take that as an unintentional compliment  
or an ad hominem attack -- but no matter ;-)

In the world you seem to advocate in all of your research to-date,  
scarcity is a perennial, all-pervasive fact. Privatization and markets  
are the eternal, all-pervasive solution.
Clearly it's always possible to move up or down in abstraction/ 
specificity or to reframe matters in some way so that every  
conceivable issue becomes a problem of scarcity. That can be a handy  
trick, since if one can pull it off one can effortlessly capitalize on  
the (until so recently) near-universal reflexive faith in private  
markets (the more private and unconstrained, the better) as the  
universal panacea that can never go wrong. Come to think of it, for  
some years now haven't you also advocated the "devolution" of IP  
number resource distribution to competing institutions (like the ITU),  
to help overcome the scarcity of policy choices / arbitrage options  
created by the RIR allocation regime "monopoly"?

For the record, I too like markets and private property -- I just  
don't think that I see inescapable scarcity in as many places as you  
do, nor as the "master problem" in all of the places where it actually  
exists.

The reason I ask now is because I think that your sudden interest in  
IP address policy is rather opportunistic. I don't think that your  
policy preferences in this domain were, or would have been any  
different 10 years ago, or even 20-30 years ago. The scarcity that  
seems to animate all of your reasoning is the "scarcity of choice"  
that exists at all times in all matters for those who embrace the  
subjective theory of value -- i.e., those for whom IP addresses would  
be equally scarce regardless of whether there are two or two hundred  
or two million /8s in reserve, and for whom the RIRs (and every other  
non-market distribution mechanism) are considered to be equally  
illegitimate at all times. That's not exactly a mainstream view for a  
(public, community, et. al) policy advocate, however -- not even in  
the Internet community, I think. Wouldn't be surprising for moments  
like the present one -- when the idea of "scarcity" naturally  
resonates more widely -- to feel like a terrific opportunity for  
pushing the Doctrine of Pure Perpetual Scarcity without ever having to  
admit that the current conditions that everyone else is worried about  
aren't really all that relevant... without ever being obliged to  
defend or even acknowledge the Doctrine itself.

Everyone has a right to their own philosophy, of course. Even if the  
above is a perfect description of you -- which I am not claiming, any  
more than you are accusing me of being a sham holy roller -- your  
right to advocate your views on address policy matters remains  
absolutely unabridged.

I share the above mainly because I think it helps to clarify why we  
are so radically at odds over this matter (thanks again btw for  
helping to crystallize my thinking on this).
I've been arguing for the exact opposite of your approach to handling  
the looming challenges -- i.e., a "transition of necessity" to your  
"scarcity of choice."
I've resisted engaging in your preferred *scarcity of IPv4* rhetoric  
because I believe that, on balance, people don't care (and also  
shouldn't care) nearly as much about the particulars of addressing  
formats as they do about the *availability of IP addresses that work*  
-- i.e., a preference of function over form. IPv6 could become  
functionally equivalent to IPv4, but only if (after) the market has  
becomes confident enough that IPv4 will never become a permanent  
competitive bottleneck to fully embrace IPv6 (or technically, anything  
else that would eliminate the bottleneck). Obviously that would take  
quite a while to happen under the best of circumstances if the pace of  
IPv6 deployment/activation were the only indicator. Or it could never  
happen at all if the transition is complicated by widespread perceived  
risks of speculation and competitive exploitation of IPv4 bottlenecks  
-- which I suspect are already causing / will continue to cause many  
people to (quite sensibly) put off any irreversible commitments to any  
specific future access technology, perhaps indefinitely.

I don't really think that a delay of centuries is likely. However,  
that's not due to my faith in the infallibility of markets, but rather  
to the glum expectation of external "help" If we're unable to manage a  
prompt, orderly transition on our own. I believe that external help  
would likely create and institutionalize many of the same problems  
that privatization would create, which is why I've argued ad nauseam  
in favor of *community adoption* of modest, scale-sensitive policies  
that would effectively put a ceiling on (not eliminate) speculation,  
and eliminate the kind of opacity/uncertainty and potentially  
existential risks that would likely deter many prudent decision makers  
from gambling their futures, possibly until it's too late.


> I totally share your concern with maintaining open entry, and  
> allowing newcomers. Totally. I just think you've psychologically  
> projected that concern into the wrong place. You did it with the  
> debate over transfer markets, and you just keep doing it.


Thank you for acknowledging the consistency of my position.


> Chopping up the last large blocks and handing them out in small  
> chunks rather than large chunks does not make IP addresses more  
> available to "aspiring and eligible new entrants." There is no  
> guarantee in the policy that the small blocks will go to new  
> entrants rather than, e.g., small incumbents or small chunks to big  
> incumbents, or organizations in the education or financial industry.

A routing service provider that provides routing services to  
themselves is still a "new entrant" in my book, and in the routing  
table; the salient distinction is "initial allocation" vs. "subsequent  
allocation." Have described necessary/appropriate policy distinctions  
between PA & PI in an earlier message; not going to repeat them here.  
Your other sub-points reduce to absolute skepticism about the RIR  
system in general/at all times, along the lines outlined above, so  
I'll ignore them for the moment.


> If your business plan depends on standing first in line for the last  
> remaining scraps of v4 space, then you're entry into the Internet  
> market may be doomed anyway, perhaps that's what Dillon is trying to  
> tell you.

Hopefully the above clarifies this misperception.

> As a rationing device, the finer-slice/maximum limit idea has some  
> merit on purely equitable distribution grounds. But I do wish you'd  
> quit distorting this debate with your posturing about new entrants.  
> You want to do something about new entrants, start taking a look at  
> levels of venture capital, bandwidth costs, spectrum availability,  
> FCC regulations, etc. Any examples of specific firms who've left the  
> market because of inability to access v4 addresses? That would be  
> useful data. anmy data on how many such "aspiring" firms are  
> standing in line waiting for some v4 crumbs? and who business plan  
> depends on it?

A more sensible approach would be to provide a few examples of what  
we'd all be missing today had the community embraced your preferred  
adaptation model back in 1983, or 1993, or even in 2000.

256 "provider independent" institutions, instead of today's 15k-20k. I  
wonder how many readers of this list that are not legacy /8 holders  
would agree that they would be better today off as address-dependent  
customers of GE, or Halliburton, or anyone? I'd be grateful if anyone  
who does feel that way would share a brief note to that effect to ppml.

As late as the mid-late 1990s Japan was the most expensive  
communications services market in the world (IIRC). In 2001 a total  
outsider new entrant pioneered cheap, high capacity flat-rate DSL  
access. In 2000 they had zero, or close to zero, IP addresses. Today  
Japan is the close to being the cheapest and most well provisioned  
access market, thanks to that latecomer -- which is now Japan's  
largest Internet access provider, and also one of the top IP address  
holders in Japan (perhaps #1, will have to refresh my memory).

Google's distributed production network; love'em or hate'em, how much  
do you think Google would have had to pay for IPv4 in a c. 2003 IPv4  
trading market? I think I'd settle for a 10% share of all revenue, but  
people have told me that I'm a pushover...

Note well,

TV, personal opinions only





From mueller at syr.edu  Mon Jun 22 18:28:57 2009
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 22 Jun 2009 18:28:57 -0400
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out b
 Prefix Size - Revised
In-Reply-To: <2367B756-B4FD-46BA-B981-8175B2DF8BEA@pch.net>
References: <75822E125BCB994F8446858C4B19F0D77B233EA9@SUEX07-MBX-04.ad.syr.edu>
	<2367B756-B4FD-46BA-B981-8175B2DF8BEA@pch.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D77B1A82CD@SUEX07-MBX-04.ad.syr.edu>

Sorry I asked. Silly me; thought you might actually try to answer it

> -----Original Message-----
> > I've never understood this aspect of your argument, Tom. Please tell
> > me how in an environment of exhaustion of the IPv4 space, ARIN makes
> > IPv4 resources freely available to "aspiring" new entrants on a non-
> > adversarial basis. 

<10,000 tons of verbiage snipped.>


From michael.dillon at bt.com  Tue Jun 23 03:31:38 2009
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 23 Jun 2009 08:31:38 +0100
Subject: [arin-ppml] Policy Proposal 93: Predicable IPv4 Run Out bPrefix
	Size - Revised
In-Reply-To: <20090622210827.GB12065@vacation.karoshi.com.>
Message-ID: <28E139F46D45AF49A31950F88C49745801D16610@E03MVZ2-UKDY.domain1.systemhost.net>

> 	so..  we are not exausting, we are (or should be) 
> shooting for higher
> 	utilization of the space.

Simple. Just use the last /31s to run NAT-PT or web proxies
or NAT64 or some other kind of middleboxes. If you count
all the IPv6 hosts served by such a service, the utilisation
will be higher than most other IPv4 blocks.

--Michael Dillon


From info at arin.net  Tue Jun 23 15:07:15 2009
From: info at arin.net (Member Services)
Date: Tue, 23 Jun 2009 15:07:15 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - June 2009
Message-ID: <4A4127E3.5000308@arin.net>

On 18 June 2009 the ARIN Advisory Council (AC) met and made decisions
about several policy proposals. Policy proposals are the earliest stage
of the ARIN Policy Development Process; they are ideas about policy
changes. The AC decides how to use policy proposals.

The AC accepted the following proposals on to the AC's docket for
development and evaluation. From these proposals the AC intends to
create and publish draft policies in time for the October Public Policy
Meeting:

   Policy Proposal 89 (Global): Internet Assigned Numbers Authority
(IANA)Policy for Allocation of ASN Blocks (ASNs) to Regional Internet
Registries
   Policy Proposal 90: Open Access To IPv6
   Policy Proposal 93: Predicable IPv4 Run Out by Prefix Size
   Policy Proposal 94. Predictable IPv4 Run Out by Allocation Window

The AC accepted the following proposal on the AC's docket, however the
AC will delay working on it until after the October Public Policy Meeting:

   Policy Proposal 95: Customer Confidentiality

The AC abandoned the following policy proposals:

   Policy Proposal 88: IPv4 Example Shortages
   Policy Proposal 91: Sunset Clause for Liberalized Transfer Policy
   Policy Proposal 92: A Modest Proposal for an Alternate IPv6 Allocation
Process

Regarding Policy Proposal 92: A Modest Proposal for an Alternate IPv6
Allocation Process, the AC stated, "The AC believes that Policy Proposal
#92 has some merit in concept, but does not believe that the problem
addressed is immediate nor of sufficient scope currently. Furthermore,
the benefits presumed may be achieved in ways other than using the
discrete pools for address allocation. We hope that the author continues
to discuss this issue with the AC and community."

The AC abandoned proposals 88, 91, and 92, and delayed working on
proposal 95. These are actions that can be petitioned. The purpose of a
petition at this stage would be to advance a policy proposal by
promoting it to a draft policy for discussion on the Public Policy
Mailing List and at the October meeting. Per the ARIN Policy Development
Process, ?Any member of the community, including a proposal originator,
may initiate a Discussion Petition if they are dissatisfied with the
action taken by the Advisory Council regarding any specific policy
proposal. If successful, this petition will change the policy proposal
to a draft policy which will be published for discussion and review by
the community on the PPML and at an upcoming public policy meeting.? The
deadline to begin a petition for these proposals is 30 June 2009.
Petitions must include the proposal and a petition statement. Once
begun, a petition lasts for 5 business days. Success is measured as
support from at least 10 different people from 10 different
organizations. Should a petition begin, ARIN staff will post additional
information to the petition thread. If there is no petition, or the
petition fails, then the abandoned proposals are closed.

Draft Policy and Policy Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)









From jmaimon at chl.com  Thu Jun 25 21:08:34 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Thu, 25 Jun 2009 21:08:34 -0400
Subject: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate IPv6
	Allocation
Message-ID: <4A441F92.6030408@chl.com>

"The AC believes that Policy Proposal
#92 has some merit in concept, but does not believe that the problem
addressed is immediate nor of sufficient scope currently. Furthermore,
the benefits presumed may be achieved in ways other than using the
discrete pools for address allocation. We hope that the author continues
to discuss this issue with the AC and community."

I believe there are timeliness issues involved, especially as it
pertains to routing policy, as well as an interest in dispelling
uncertainty with regards to ipv6 rollout which may be a factor in
delaying migration.

I would suggest a more appropriate action would be to delay working on
the proposal until it has had more time to mature in our minds,
something like what happened with policy proposal 95, customer
confidentiality.

Is it considered polite to defer to a policy proposal's author for a
discussion petition? Ia a petition under consideration?






From BillD at cait.wustl.edu  Thu Jun 25 21:23:11 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 25 Jun 2009 20:23:11 -0500
Subject: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate
	IPv6Allocation
References: <4A441F92.6030408@chl.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087914DBB@ex1.cait.wustl.edu>

Joe,

According to my reading of the PDP....

Anyone may initiate a petition to bring a proposal to discussion as long as the petition is begun within 5 days of the announced action by the AC...which was the 23rd, I believe.

Once a petition is brought forth, the petitioners have 5 days to generate 10 petition supporters from 10 different organizations to be successful.

The full PDP including the petition process is to be found at.... https://www.arin.net/policy/pdp.html

Bill Darte
ARIN Advisory Council





-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Joe Maimon
Sent: Thu 6/25/2009 8:08 PM
To: ppml at arin.net
Subject: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate IPv6Allocation
 
"The AC believes that Policy Proposal
#92 has some merit in concept, but does not believe that the problem
addressed is immediate nor of sufficient scope currently. Furthermore,
the benefits presumed may be achieved in ways other than using the
discrete pools for address allocation. We hope that the author continues
to discuss this issue with the AC and community."

I believe there are timeliness issues involved, especially as it
pertains to routing policy, as well as an interest in dispelling
uncertainty with regards to ipv6 rollout which may be a factor in
delaying migration.

I would suggest a more appropriate action would be to delay working on
the proposal until it has had more time to mature in our minds,
something like what happened with policy proposal 95, customer
confidentiality.

Is it considered polite to defer to a policy proposal's author for a
discussion petition? Ia a petition under consideration?




_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090625/76977341/attachment.htm>

From bill at herrin.us  Fri Jun 26 08:41:04 2009
From: bill at herrin.us (William Herrin)
Date: Fri, 26 Jun 2009 08:41:04 -0400
Subject: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate IPv6
	Allocation
In-Reply-To: <4A441F92.6030408@chl.com>
References: <4A441F92.6030408@chl.com>
Message-ID: <3c3e3fca0906260541u7f3735a6l7d62424c30022b76@mail.gmail.com>

On Thu, Jun 25, 2009 at 9:08 PM, Joe Maimon<jmaimon at chl.com> wrote:
> "The AC believes that Policy Proposal
> #92 has some merit in concept, but does not believe that the problem
> addressed is immediate nor of sufficient scope currently. Furthermore,
> the benefits presumed may be achieved in ways other than using the
> discrete pools for address allocation. We hope that the author continues
> to discuss this issue with the AC and community."
>
> I believe there are timeliness issues involved, especially as it
> pertains to routing policy, as well as an interest in dispelling
> uncertainty with regards to ipv6 rollout which may be a factor in
> delaying migration.
>
> I would suggest a more appropriate action would be to delay working on
> the proposal until it has had more time to mature in our minds,
> something like what happened with policy proposal 95, customer
> confidentiality.
>
> Is it considered polite to defer to a policy proposal's author for a
> discussion petition? Ia a petition under consideration?

Hi Joe,

I don't plan to petition but I won't object if you want to.

I suggest, however, that you're right: judging from the response,
folks need more time to bounce the ideas around and consider what the
most important results of IPv6 addressing policy really are. That may
be less threatening if the ideas aren't looming overhead in the form
of a policy proposal that must be ratified or rejected on schedule.

At any rate, we can dust the proposal off at any time and use it as a
reference to write a better one.

Regards,
Bill


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jmaimon at chl.com  Fri Jun 26 15:26:52 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 26 Jun 2009 15:26:52 -0400
Subject: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate IPv6
 Allocation
In-Reply-To: <3c3e3fca0906260541u7f3735a6l7d62424c30022b76@mail.gmail.com>
References: <4A441F92.6030408@chl.com>
	<3c3e3fca0906260541u7f3735a6l7d62424c30022b76@mail.gmail.com>
Message-ID: <4A4520FC.7060705@chl.com>

I cant find anything more specific to the process, so perhaps this 
thread should be considered the petition along with the original 
statement,  rephrased as follows.

I believe the policy proposal has potential timeliness issues with it 
along with the AC suggestion that it may have merit, as such to my view, 
the proper course of action assuming the community as a whole is not yet 
ready to deal head on with it is to put it on the docket for the next 
public policy meeting instead of the immediate upcoming one.

Personally, I found it well written and fairly convincing on its face value.

Am I missing some formality or proper address or is it done and should I 
just wait and see if support rolls in to turn this proposal into a draft 
discussion policy or not?


"
2.4 Discussion Petition

Any member of the community, including a proposal originator, may 
initiate a Discussion Petition if they are dissatisfied with the action 
taken by the Advisory Council regarding any specific policy proposal. If 
successful, this petition will change the policy proposal to a draft 
policy which will be published for discussion and review by the 
community on the PPML and at an upcoming public policy meeting.

The Discussion Petition must be initiated within 5 business days of 
announcement of the Advisory Council's decision regarding a specific 
policy proposal; the petition must include the proposal and a petition 
statement. The petition duration is 5 business days. The ARIN President 
determines if the petition succeeds (success is support from at least 10 
different people from 10 different organizations). In order to be 
considered at an upcoming public policy meeting, the petition must be 
successfully completed at least 35 days prior to that meeting.

A successful petition may result in competing versions of the same draft 
policy. Staff and legal reviews will be conducted and published for 
successful petitions.

All draft policies that are selected by the Advisory Council or 
successfully petitioned are published for review and discussion on the 
public policy mailing list.
"



William Herrin wrote:
> On Thu, Jun 25, 2009 at 9:08 PM, Joe Maimon<jmaimon at chl.com> wrote:
>   
>> "The AC believes that Policy Proposal
>> #92 has some merit in concept, but does not believe that the problem
>> addressed is immediate nor of sufficient scope currently. Furthermore,
>> the benefits presumed may be achieved in ways other than using the
>> discrete pools for address allocation. We hope that the author continues
>> to discuss this issue with the AC and community."
>>
>> I believe there are timeliness issues involved, especially as it
>> pertains to routing policy, as well as an interest in dispelling
>> uncertainty with regards to ipv6 rollout which may be a factor in
>> delaying migration.
>>
>> I would suggest a more appropriate action would be to delay working on
>> the proposal until it has had more time to mature in our minds,
>> something like what happened with policy proposal 95, customer
>> confidentiality.
>>
>> Is it considered polite to defer to a policy proposal's author for a
>> discussion petition? Ia a petition under consideration?
>>     
>
> Hi Joe,
>
> I don't plan to petition but I won't object if you want to.
>
> I suggest, however, that you're right: judging from the response,
> folks need more time to bounce the ideas around and consider what the
> most important results of IPv6 addressing policy really are. That may
> be less threatening if the ideas aren't looming overhead in the form
> of a policy proposal that must be ratified or rejected on schedule.
>
> At any rate, we can dust the proposal off at any time and use it as a
> reference to write a better one.
>
> Regards,
> Bill
>
>   


From john.sweeting at twcable.com  Fri Jun 26 17:05:26 2009
From: john.sweeting at twcable.com (Sweeting, John)
Date: Fri, 26 Jun 2009 17:05:26 -0400
Subject: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate IPv6
	Allocation
Message-ID: <58174FA985B92A42B9E3142C4DD2CC0405EC08CE@PRVPVSMAIL07.corp.twcable.com>

Thanks Joe,

I need to check but I believe that by petitioning this decision it means that you are taking on the responsibility of presenting it at the next PPM in order to gain community support. The AC stands ready to help but a petition does not return the proposal to the AC's docket until after it has been presented at the PPM and community support has been proven. I will ask ARIN staff to elaobrate on this.

Thanks


P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible.
 
 
----- Original Message -----
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
To: William Herrin <bill at herrin.us>
Cc: ppml at arin.net <ppml at arin.net>
Sent: Fri Jun 26 15:26:52 2009
Subject: Re: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate IPv6 Allocation

I cant find anything more specific to the process, so perhaps this 
thread should be considered the petition along with the original 
statement,  rephrased as follows.

I believe the policy proposal has potential timeliness issues with it 
along with the AC suggestion that it may have merit, as such to my view, 
the proper course of action assuming the community as a whole is not yet 
ready to deal head on with it is to put it on the docket for the next 
public policy meeting instead of the immediate upcoming one.

Personally, I found it well written and fairly convincing on its face value.

Am I missing some formality or proper address or is it done and should I 
just wait and see if support rolls in to turn this proposal into a draft 
discussion policy or not?


"
2.4 Discussion Petition

Any member of the community, including a proposal originator, may 
initiate a Discussion Petition if they are dissatisfied with the action 
taken by the Advisory Council regarding any specific policy proposal. If 
successful, this petition will change the policy proposal to a draft 
policy which will be published for discussion and review by the 
community on the PPML and at an upcoming public policy meeting.

The Discussion Petition must be initiated within 5 business days of 
announcement of the Advisory Council's decision regarding a specific 
policy proposal; the petition must include the proposal and a petition 
statement. The petition duration is 5 business days. The ARIN President 
determines if the petition succeeds (success is support from at least 10 
different people from 10 different organizations). In order to be 
considered at an upcoming public policy meeting, the petition must be 
successfully completed at least 35 days prior to that meeting.

A successful petition may result in competing versions of the same draft 
policy. Staff and legal reviews will be conducted and published for 
successful petitions.

All draft policies that are selected by the Advisory Council or 
successfully petitioned are published for review and discussion on the 
public policy mailing list.
"



William Herrin wrote:
> On Thu, Jun 25, 2009 at 9:08 PM, Joe Maimon<jmaimon at chl.com> wrote:
>   
>> "The AC believes that Policy Proposal
>> #92 has some merit in concept, but does not believe that the problem
>> addressed is immediate nor of sufficient scope currently. Furthermore,
>> the benefits presumed may be achieved in ways other than using the
>> discrete pools for address allocation. We hope that the author continues
>> to discuss this issue with the AC and community."
>>
>> I believe there are timeliness issues involved, especially as it
>> pertains to routing policy, as well as an interest in dispelling
>> uncertainty with regards to ipv6 rollout which may be a factor in
>> delaying migration.
>>
>> I would suggest a more appropriate action would be to delay working on
>> the proposal until it has had more time to mature in our minds,
>> something like what happened with policy proposal 95, customer
>> confidentiality.
>>
>> Is it considered polite to defer to a policy proposal's author for a
>> discussion petition? Ia a petition under consideration?
>>     
>
> Hi Joe,
>
> I don't plan to petition but I won't object if you want to.
>
> I suggest, however, that you're right: judging from the response,
> folks need more time to bounce the ideas around and consider what the
> most important results of IPv6 addressing policy really are. That may
> be less threatening if the ideas aren't looming overhead in the form
> of a policy proposal that must be ratified or rejected on schedule.
>
> At any rate, we can dust the proposal off at any time and use it as a
> reference to write a better one.
>
> Regards,
> Bill
>
>   
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.

From jmaimon at chl.com  Fri Jun 26 17:20:00 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 26 Jun 2009 17:20:00 -0400
Subject: [arin-ppml] Petitioning AC abandonment of Policy Proposal 92
 Alternate IPv6 Allocation
In-Reply-To: <58174FA985B92A42B9E3142C4DD2CC0405EC08CE@PRVPVSMAIL07.corp.twcable.com>
References: <58174FA985B92A42B9E3142C4DD2CC0405EC08CE@PRVPVSMAIL07.corp.twcable.com>
Message-ID: <4A453B80.70701@chl.com>



Sweeting, John wrote:
> Thanks Joe,
>
> I need to check but I believe that by petitioning this decision it means that you are taking on the responsibility of presenting it at the next PPM in order to gain community support. The AC stands ready to help but a petition does not return the proposal to the AC's docket until after it has been presented at the PPM and community support has been proven. I will ask ARIN staff to elaobrate on this.
>
>   

I dont quite understand how your petition process makes sense or is at 
all contained in the text quoted below. The dates alone should render it 
impossible to petition the AC decision at ppm. Furthermore to what 
purpose does the petition serve at this point if not to return it to the 
AC docket?

If you perhaps mean that by petitioning here on ppml, there is a 
side-effect of slapping my name up as official presenter of the draft 
policy, well that was part of my original query.

>  
>  
> ----- Original Message -----
> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
> To: William Herrin <bill at herrin.us>
> Cc: ppml at arin.net <ppml at arin.net>
> Sent: Fri Jun 26 15:26:52 2009
> Subject: Re: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate IPv6 Allocation
>
> I cant find anything more specific to the process, so perhaps this 
> thread should be considered the petition along with the original 
> statement,  rephrased as follows.
>
> I believe the policy proposal has potential timeliness issues with it 
> along with the AC suggestion that it may have merit, as such to my view, 
> the proper course of action assuming the community as a whole is not yet 
> ready to deal head on with it is to put it on the docket for the next 
> public policy meeting instead of the immediate upcoming one.
>
> Personally, I found it well written and fairly convincing on its face value.
>
> Am I missing some formality or proper address or is it done and should I 
> just wait and see if support rolls in to turn this proposal into a draft 
> discussion policy or not?
>
>
> "
> 2.4 Discussion Petition
>
> Any member of the community, including a proposal originator, may 
> initiate a Discussion Petition if they are dissatisfied with the action 
> taken by the Advisory Council regarding any specific policy proposal. If 
> successful, this petition will change the policy proposal to a draft 
> policy which will be published for discussion and review by the 
> community on the PPML and at an upcoming public policy meeting.
>
> The Discussion Petition must be initiated within 5 business days of 
> announcement of the Advisory Council's decision regarding a specific 
> policy proposal; the petition must include the proposal and a petition 
> statement. The petition duration is 5 business days. The ARIN President 
> determines if the petition succeeds (success is support from at least 10 
> different people from 10 different organizations). In order to be 
> considered at an upcoming public policy meeting, the petition must be 
> successfully completed at least 35 days prior to that meeting.
>
> A successful petition may result in competing versions of the same draft 
> policy. Staff and legal reviews will be conducted and published for 
> successful petitions.
>
> All draft policies that are selected by the Advisory Council or 
> successfully petitioned are published for review and discussion on the 
> public policy mailing list.
> "
>
>
>
> William Herrin wrote:
>   
>> On Thu, Jun 25, 2009 at 9:08 PM, Joe Maimon<jmaimon at chl.com> wrote:
>>   
>>     
>>> "The AC believes that Policy Proposal
>>> #92 has some merit in concept, but does not believe that the problem
>>> addressed is immediate nor of sufficient scope currently. Furthermore,
>>> the benefits presumed may be achieved in ways other than using the
>>> discrete pools for address allocation. We hope that the author continues
>>> to discuss this issue with the AC and community."
>>>
>>> I believe there are timeliness issues involved, especially as it
>>> pertains to routing policy, as well as an interest in dispelling
>>> uncertainty with regards to ipv6 rollout which may be a factor in
>>> delaying migration.
>>>
>>> I would suggest a more appropriate action would be to delay working on
>>> the proposal until it has had more time to mature in our minds,
>>> something like what happened with policy proposal 95, customer
>>> confidentiality.
>>>
>>> Is it considered polite to defer to a policy proposal's author for a
>>> discussion petition? Ia a petition under consideration?
>>>     
>>>       
>> Hi Joe,
>>
>> I don't plan to petition but I won't object if you want to.
>>
>> I suggest, however, that you're right: judging from the response,
>> folks need more time to bounce the ideas around and consider what the
>> most important results of IPv6 addressing policy really are. That may
>> be less threatening if the ideas aren't looming overhead in the form
>> of a policy proposal that must be ratified or rejected on schedule.
>>
>> At any rate, we can dust the proposal off at any time and use it as a
>> reference to write a better one.
>>
>> Regards,
>> Bill
>>
>>   
>>     
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> This E-mail and any of its attachments may contain Time Warner
> Cable proprietary information, which is privileged, confidential,
> or subject to copyright belonging to Time Warner Cable. This E-mail
> is intended solely for the use of the individual or entity to which
> it is addressed. If you are not the intended recipient of this
> E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents
> of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>
>
>   


From scottleibrand at gmail.com  Fri Jun 26 17:27:14 2009
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 26 Jun 2009 14:27:14 -0700
Subject: [arin-ppml] Petitioning AC abandonment of Policy Proposal 92
 Alternate IPv6 Allocation
In-Reply-To: <4A453B80.70701@chl.com>
References: <58174FA985B92A42B9E3142C4DD2CC0405EC08CE@PRVPVSMAIL07.corp.twcable.com>
	<4A453B80.70701@chl.com>
Message-ID: <4A453D32.5060504@gmail.com>

The petition process is simply a support-gathering exercise on PPML.  If 
the petition is successful, then the proposal becomes a draft policy, 
and is presented by the petitioner or a designate (not by the AC) at the 
next public policy meeting.

Another side effect is that the AC no longer controls the text of the 
policy after a successful petition.  (I'm not sure who does, but I'd 
imagine it's the author and/or petitioner who can make revisions after a 
successful petition.)

This is the first time we've used this part of the new PDP, so we're all 
trying to figure out the mechanics, too.

-Scott

Joe Maimon wrote:
>
>
> Sweeting, John wrote:
>> Thanks Joe,
>>
>> I need to check but I believe that by petitioning this decision it 
>> means that you are taking on the responsibility of presenting it at 
>> the next PPM in order to gain community support. The AC stands ready 
>> to help but a petition does not return the proposal to the AC's 
>> docket until after it has been presented at the PPM and community 
>> support has been proven. I will ask ARIN staff to elaobrate on this.
>>
>>   
>
> I dont quite understand how your petition process makes sense or is at 
> all contained in the text quoted below. The dates alone should render 
> it impossible to petition the AC decision at ppm. Furthermore to what 
> purpose does the petition serve at this point if not to return it to 
> the AC docket?
>
> If you perhaps mean that by petitioning here on ppml, there is a 
> side-effect of slapping my name up as official presenter of the draft 
> policy, well that was part of my original query.
>
>>  
>>  
>> ----- Original Message -----
>> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
>> To: William Herrin <bill at herrin.us>
>> Cc: ppml at arin.net <ppml at arin.net>
>> Sent: Fri Jun 26 15:26:52 2009
>> Subject: Re: [arin-ppml] AC abandonment of Policy Proposal 92 
>> Alternate IPv6 Allocation
>>
>> I cant find anything more specific to the process, so perhaps this 
>> thread should be considered the petition along with the original 
>> statement,  rephrased as follows.
>>
>> I believe the policy proposal has potential timeliness issues with it 
>> along with the AC suggestion that it may have merit, as such to my 
>> view, the proper course of action assuming the community as a whole 
>> is not yet ready to deal head on with it is to put it on the docket 
>> for the next public policy meeting instead of the immediate upcoming 
>> one.
>>
>> Personally, I found it well written and fairly convincing on its face 
>> value.
>>
>> Am I missing some formality or proper address or is it done and 
>> should I just wait and see if support rolls in to turn this proposal 
>> into a draft discussion policy or not?
>>
>>
>> "
>> 2.4 Discussion Petition
>>
>> Any member of the community, including a proposal originator, may 
>> initiate a Discussion Petition if they are dissatisfied with the 
>> action taken by the Advisory Council regarding any specific policy 
>> proposal. If successful, this petition will change the policy 
>> proposal to a draft policy which will be published for discussion and 
>> review by the community on the PPML and at an upcoming public policy 
>> meeting.
>>
>> The Discussion Petition must be initiated within 5 business days of 
>> announcement of the Advisory Council's decision regarding a specific 
>> policy proposal; the petition must include the proposal and a 
>> petition statement. The petition duration is 5 business days. The 
>> ARIN President determines if the petition succeeds (success is 
>> support from at least 10 different people from 10 different 
>> organizations). In order to be considered at an upcoming public 
>> policy meeting, the petition must be successfully completed at least 
>> 35 days prior to that meeting.
>>
>> A successful petition may result in competing versions of the same 
>> draft policy. Staff and legal reviews will be conducted and published 
>> for successful petitions.
>>
>> All draft policies that are selected by the Advisory Council or 
>> successfully petitioned are published for review and discussion on 
>> the public policy mailing list.
>> "
>>
>>
>>
>> William Herrin wrote:
>>  
>>> On Thu, Jun 25, 2009 at 9:08 PM, Joe Maimon<jmaimon at chl.com> wrote:
>>>      
>>>> "The AC believes that Policy Proposal
>>>> #92 has some merit in concept, but does not believe that the problem
>>>> addressed is immediate nor of sufficient scope currently. Furthermore,
>>>> the benefits presumed may be achieved in ways other than using the
>>>> discrete pools for address allocation. We hope that the author 
>>>> continues
>>>> to discuss this issue with the AC and community."
>>>>
>>>> I believe there are timeliness issues involved, especially as it
>>>> pertains to routing policy, as well as an interest in dispelling
>>>> uncertainty with regards to ipv6 rollout which may be a factor in
>>>> delaying migration.
>>>>
>>>> I would suggest a more appropriate action would be to delay working on
>>>> the proposal until it has had more time to mature in our minds,
>>>> something like what happened with policy proposal 95, customer
>>>> confidentiality.
>>>>
>>>> Is it considered polite to defer to a policy proposal's author for a
>>>> discussion petition? Ia a petition under consideration?
>>>>           
>>> Hi Joe,
>>>
>>> I don't plan to petition but I won't object if you want to.
>>>
>>> I suggest, however, that you're right: judging from the response,
>>> folks need more time to bounce the ideas around and consider what the
>>> most important results of IPv6 addressing policy really are. That may
>>> be less threatening if the ideas aren't looming overhead in the form
>>> of a policy proposal that must be ratified or rejected on schedule.
>>>
>>> At any rate, we can dust the proposal off at any time and use it as a
>>> reference to write a better one.
>>>
>>> Regards,
>>> Bill
>>>
>>>       
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>> This E-mail and any of its attachments may contain Time Warner
>> Cable proprietary information, which is privileged, confidential,
>> or subject to copyright belonging to Time Warner Cable. This E-mail
>> is intended solely for the use of the individual or entity to which
>> it is addressed. If you are not the intended recipient of this
>> E-mail, you are hereby notified that any dissemination,
>> distribution, copying, or action taken in relation to the contents
>> of and attachments to this E-mail is strictly prohibited and may be
>> unlawful. If you have received this E-mail in error, please notify
>> the sender immediately and permanently delete the original and any
>> copy of this E-mail and any printout.
>>
>>
>>   
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From jmaimon at chl.com  Fri Jun 26 17:38:25 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 26 Jun 2009 17:38:25 -0400
Subject: [arin-ppml] Petitioning AC abandonment of Policy Proposal 92
 Alternate IPv6 Allocation
In-Reply-To: <4A453D32.5060504@gmail.com>
References: <58174FA985B92A42B9E3142C4DD2CC0405EC08CE@PRVPVSMAIL07.corp.twcable.com>
	<4A453B80.70701@chl.com> <4A453D32.5060504@gmail.com>
Message-ID: <4A453FD1.1070609@chl.com>



Scott Leibrand wrote:
> The petition process is simply a support-gathering exercise on PPML.  
> If the petition is successful, then the proposal becomes a draft 
> policy, and is presented by the petitioner or a designate (not by the 
> AC) at the next public policy meeting.
>
> Another side effect is that the AC no longer controls the text of the 
> policy after a successful petition.  (I'm not sure who does, but I'd 
> imagine it's the author and/or petitioner who can make revisions after 
> a successful petition.)
Thanks for the clarification.
>
> This is the first time we've used this part of the new PDP, so we're 
> all trying to figure out the mechanics, too.

We wont get too far without some support for this petition.

>
> -Scott
>
> Joe Maimon wrote:
>>
>>
>> Sweeting, John wrote:
>>> Thanks Joe,
>>>
>>> I need to check but I believe that by petitioning this decision it 
>>> means that you are taking on the responsibility of presenting it at 
>>> the next PPM in order to gain community support. The AC stands ready 
>>> to help but a petition does not return the proposal to the AC's 
>>> docket until after it has been presented at the PPM and community 
>>> support has been proven. I will ask ARIN staff to elaobrate on this.
>>>
>>>   
>>
>> I dont quite understand how your petition process makes sense or is 
>> at all contained in the text quoted below. The dates alone should 
>> render it impossible to petition the AC decision at ppm. Furthermore 
>> to what purpose does the petition serve at this point if not to 
>> return it to the AC docket?
>>
>> If you perhaps mean that by petitioning here on ppml, there is a 
>> side-effect of slapping my name up as official presenter of the draft 
>> policy, well that was part of my original query.
>>
>>>  
>>>  
>>> ----- Original Message -----
>>> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
>>> To: William Herrin <bill at herrin.us>
>>> Cc: ppml at arin.net <ppml at arin.net>
>>> Sent: Fri Jun 26 15:26:52 2009
>>> Subject: Re: [arin-ppml] AC abandonment of Policy Proposal 92 
>>> Alternate IPv6 Allocation
>>>
>>> I cant find anything more specific to the process, so perhaps this 
>>> thread should be considered the petition along with the original 
>>> statement,  rephrased as follows.
>>>
>>> I believe the policy proposal has potential timeliness issues with 
>>> it along with the AC suggestion that it may have merit, as such to 
>>> my view, the proper course of action assuming the community as a 
>>> whole is not yet ready to deal head on with it is to put it on the 
>>> docket for the next public policy meeting instead of the immediate 
>>> upcoming one.
>>>
>>> Personally, I found it well written and fairly convincing on its 
>>> face value.
>>>
>>> Am I missing some formality or proper address or is it done and 
>>> should I just wait and see if support rolls in to turn this proposal 
>>> into a draft discussion policy or not?
>>>
>>>
>>> "
>>> 2.4 Discussion Petition
>>>
>>> Any member of the community, including a proposal originator, may 
>>> initiate a Discussion Petition if they are dissatisfied with the 
>>> action taken by the Advisory Council regarding any specific policy 
>>> proposal. If successful, this petition will change the policy 
>>> proposal to a draft policy which will be published for discussion 
>>> and review by the community on the PPML and at an upcoming public 
>>> policy meeting.
>>>
>>> The Discussion Petition must be initiated within 5 business days of 
>>> announcement of the Advisory Council's decision regarding a specific 
>>> policy proposal; the petition must include the proposal and a 
>>> petition statement. The petition duration is 5 business days. The 
>>> ARIN President determines if the petition succeeds (success is 
>>> support from at least 10 different people from 10 different 
>>> organizations). In order to be considered at an upcoming public 
>>> policy meeting, the petition must be successfully completed at least 
>>> 35 days prior to that meeting.
>>>
>>> A successful petition may result in competing versions of the same 
>>> draft policy. Staff and legal reviews will be conducted and 
>>> published for successful petitions.
>>>
>>> All draft policies that are selected by the Advisory Council or 
>>> successfully petitioned are published for review and discussion on 
>>> the public policy mailing list.
>>> "
>>>
>>>
>>>
>>> William Herrin wrote:
>>>  
>>>> On Thu, Jun 25, 2009 at 9:08 PM, Joe Maimon<jmaimon at chl.com> wrote:
>>>>     
>>>>> "The AC believes that Policy Proposal
>>>>> #92 has some merit in concept, but does not believe that the problem
>>>>> addressed is immediate nor of sufficient scope currently. 
>>>>> Furthermore,
>>>>> the benefits presumed may be achieved in ways other than using the
>>>>> discrete pools for address allocation. We hope that the author 
>>>>> continues
>>>>> to discuss this issue with the AC and community."
>>>>>
>>>>> I believe there are timeliness issues involved, especially as it
>>>>> pertains to routing policy, as well as an interest in dispelling
>>>>> uncertainty with regards to ipv6 rollout which may be a factor in
>>>>> delaying migration.
>>>>>
>>>>> I would suggest a more appropriate action would be to delay 
>>>>> working on
>>>>> the proposal until it has had more time to mature in our minds,
>>>>> something like what happened with policy proposal 95, customer
>>>>> confidentiality.
>>>>>
>>>>> Is it considered polite to defer to a policy proposal's author for a
>>>>> discussion petition? Ia a petition under consideration?
>>>>>           
>>>> Hi Joe,
>>>>
>>>> I don't plan to petition but I won't object if you want to.
>>>>
>>>> I suggest, however, that you're right: judging from the response,
>>>> folks need more time to bounce the ideas around and consider what the
>>>> most important results of IPv6 addressing policy really are. That may
>>>> be less threatening if the ideas aren't looming overhead in the form
>>>> of a policy proposal that must be ratified or rejected on schedule.
>>>>
>>>> At any rate, we can dust the proposal off at any time and use it as a
>>>> reference to write a better one.
>>>>
>>>> Regards,
>>>> Bill
>>>>
>>>>       
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>> This E-mail and any of its attachments may contain Time Warner
>>> Cable proprietary information, which is privileged, confidential,
>>> or subject to copyright belonging to Time Warner Cable. This E-mail
>>> is intended solely for the use of the individual or entity to which
>>> it is addressed. If you are not the intended recipient of this
>>> E-mail, you are hereby notified that any dissemination,
>>> distribution, copying, or action taken in relation to the contents
>>> of and attachments to this E-mail is strictly prohibited and may be
>>> unlawful. If you have received this E-mail in error, please notify
>>> the sender immediately and permanently delete the original and any
>>> copy of this E-mail and any printout.
>>>
>>>
>>>   
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>


From john.sweeting at twcable.com  Fri Jun 26 17:45:01 2009
From: john.sweeting at twcable.com (Sweeting, John)
Date: Fri, 26 Jun 2009 17:45:01 -0400
Subject: [arin-ppml] Petitioning AC abandonment of Policy Proposal 92
	Alternate IPv6 Allocation
Message-ID: <58174FA985B92A42B9E3142C4DD2CC0405EC08CF@PRVPVSMAIL07.corp.twcable.com>

Sorry I am traveling and responding from my bb. But yes as the petition process is now written a successful petition would slap your name on the proposal as author and presenter. 




P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible.
 
 
----- Original Message -----
From: Joe Maimon <jmaimon at chl.com>
To: Sweeting, John
Cc: bill at herrin.us <bill at herrin.us>; ppml at arin.net <ppml at arin.net>
Sent: Fri Jun 26 17:20:00 2009
Subject: Re: [arin-ppml] Petitioning AC abandonment of Policy Proposal 92 Alternate IPv6 Allocation



Sweeting, John wrote:
> Thanks Joe,
>
> I need to check but I believe that by petitioning this decision it means that you are taking on the responsibility of presenting it at the next PPM in order to gain community support. The AC stands ready to help but a petition does not return the proposal to the AC's docket until after it has been presented at the PPM and community support has been proven. I will ask ARIN staff to elaobrate on this.
>
>   

I dont quite understand how your petition process makes sense or is at 
all contained in the text quoted below. The dates alone should render it 
impossible to petition the AC decision at ppm. Furthermore to what 
purpose does the petition serve at this point if not to return it to the 
AC docket?

If you perhaps mean that by petitioning here on ppml, there is a 
side-effect of slapping my name up as official presenter of the draft 
policy, well that was part of my original query.

>  
>  
> ----- Original Message -----
> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
> To: William Herrin <bill at herrin.us>
> Cc: ppml at arin.net <ppml at arin.net>
> Sent: Fri Jun 26 15:26:52 2009
> Subject: Re: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate IPv6 Allocation
>
> I cant find anything more specific to the process, so perhaps this 
> thread should be considered the petition along with the original 
> statement,  rephrased as follows.
>
> I believe the policy proposal has potential timeliness issues with it 
> along with the AC suggestion that it may have merit, as such to my view, 
> the proper course of action assuming the community as a whole is not yet 
> ready to deal head on with it is to put it on the docket for the next 
> public policy meeting instead of the immediate upcoming one.
>
> Personally, I found it well written and fairly convincing on its face value.
>
> Am I missing some formality or proper address or is it done and should I 
> just wait and see if support rolls in to turn this proposal into a draft 
> discussion policy or not?
>
>
> "
> 2.4 Discussion Petition
>
> Any member of the community, including a proposal originator, may 
> initiate a Discussion Petition if they are dissatisfied with the action 
> taken by the Advisory Council regarding any specific policy proposal. If 
> successful, this petition will change the policy proposal to a draft 
> policy which will be published for discussion and review by the 
> community on the PPML and at an upcoming public policy meeting.
>
> The Discussion Petition must be initiated within 5 business days of 
> announcement of the Advisory Council's decision regarding a specific 
> policy proposal; the petition must include the proposal and a petition 
> statement. The petition duration is 5 business days. The ARIN President 
> determines if the petition succeeds (success is support from at least 10 
> different people from 10 different organizations). In order to be 
> considered at an upcoming public policy meeting, the petition must be 
> successfully completed at least 35 days prior to that meeting.
>
> A successful petition may result in competing versions of the same draft 
> policy. Staff and legal reviews will be conducted and published for 
> successful petitions.
>
> All draft policies that are selected by the Advisory Council or 
> successfully petitioned are published for review and discussion on the 
> public policy mailing list.
> "
>
>
>
> William Herrin wrote:
>   
>> On Thu, Jun 25, 2009 at 9:08 PM, Joe Maimon<jmaimon at chl.com> wrote:
>>   
>>     
>>> "The AC believes that Policy Proposal
>>> #92 has some merit in concept, but does not believe that the problem
>>> addressed is immediate nor of sufficient scope currently. Furthermore,
>>> the benefits presumed may be achieved in ways other than using the
>>> discrete pools for address allocation. We hope that the author continues
>>> to discuss this issue with the AC and community."
>>>
>>> I believe there are timeliness issues involved, especially as it
>>> pertains to routing policy, as well as an interest in dispelling
>>> uncertainty with regards to ipv6 rollout which may be a factor in
>>> delaying migration.
>>>
>>> I would suggest a more appropriate action would be to delay working on
>>> the proposal until it has had more time to mature in our minds,
>>> something like what happened with policy proposal 95, customer
>>> confidentiality.
>>>
>>> Is it considered polite to defer to a policy proposal's author for a
>>> discussion petition? Ia a petition under consideration?
>>>     
>>>       
>> Hi Joe,
>>
>> I don't plan to petition but I won't object if you want to.
>>
>> I suggest, however, that you're right: judging from the response,
>> folks need more time to bounce the ideas around and consider what the
>> most important results of IPv6 addressing policy really are. That may
>> be less threatening if the ideas aren't looming overhead in the form
>> of a policy proposal that must be ratified or rejected on schedule.
>>
>> At any rate, we can dust the proposal off at any time and use it as a
>> reference to write a better one.
>>
>> Regards,
>> Bill
>>
>>   
>>     
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> This E-mail and any of its attachments may contain Time Warner
> Cable proprietary information, which is privileged, confidential,
> or subject to copyright belonging to Time Warner Cable. This E-mail
> is intended solely for the use of the individual or entity to which
> it is addressed. If you are not the intended recipient of this
> E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents
> of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>
>
>   
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.

From BillD at cait.wustl.edu  Fri Jun 26 18:22:39 2009
From: BillD at cait.wustl.edu (Bill Darte)
Date: Fri, 26 Jun 2009 17:22:39 -0500
Subject: [arin-ppml] Petitioning AC abandonment of Policy Proposal
	92Alternate IPv6 Allocation
References: <58174FA985B92A42B9E3142C4DD2CC0405EC08CF@PRVPVSMAIL07.corp.twcable.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087914DBF@ex1.cait.wustl.edu>

Joe,

I believe that if you are indeed choosing to petition that the Policy Proposal #92 be presented at the next ARIN PPM, you should make a rather formal statement of that starting a new thread.  In it you should at a minimum restate the proposal text and ask for support.  Stating that you need 10 supporters from independent companies within 5 days might make it clearer to those on the fence that some urgency exists.

Under the most lenient assessment by ARIN's President, I believe you would have to formalize that petitions statement by next Tuesday as the announcement was made on Tuesday the 23rd.  I suppose, the announcement day could be counted, but that would seem inappropriate to me as the announcement was made 'during' the day and thus that day would not be a 'full' day for accounting purposes.

If anyone at ARIN or on the Board would like to clarify the exact rules, that would be useful at this time.

Bill Darte
ARIN Advisory Council


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Sweeting, John
Sent: Fri 6/26/2009 4:45 PM
To: jmaimon at chl.com
Cc: ppml at arin.net
Subject: Re: [arin-ppml] Petitioning AC abandonment of Policy Proposal 92Alternate IPv6 Allocation
 
Sorry I am traveling and responding from my bb. But yes as the petition process is now written a successful petition would slap your name on the proposal as author and presenter. 




P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible.
 
 
----- Original Message -----
From: Joe Maimon <jmaimon at chl.com>
To: Sweeting, John
Cc: bill at herrin.us <bill at herrin.us>; ppml at arin.net <ppml at arin.net>
Sent: Fri Jun 26 17:20:00 2009
Subject: Re: [arin-ppml] Petitioning AC abandonment of Policy Proposal 92 Alternate IPv6 Allocation



Sweeting, John wrote:
> Thanks Joe,
>
> I need to check but I believe that by petitioning this decision it means that you are taking on the responsibility of presenting it at the next PPM in order to gain community support. The AC stands ready to help but a petition does not return the proposal to the AC's docket until after it has been presented at the PPM and community support has been proven. I will ask ARIN staff to elaobrate on this.
>
>   

I dont quite understand how your petition process makes sense or is at 
all contained in the text quoted below. The dates alone should render it 
impossible to petition the AC decision at ppm. Furthermore to what 
purpose does the petition serve at this point if not to return it to the 
AC docket?

If you perhaps mean that by petitioning here on ppml, there is a 
side-effect of slapping my name up as official presenter of the draft 
policy, well that was part of my original query.

>  
>  
> ----- Original Message -----
> From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
> To: William Herrin <bill at herrin.us>
> Cc: ppml at arin.net <ppml at arin.net>
> Sent: Fri Jun 26 15:26:52 2009
> Subject: Re: [arin-ppml] AC abandonment of Policy Proposal 92 Alternate IPv6 Allocation
>
> I cant find anything more specific to the process, so perhaps this 
> thread should be considered the petition along with the original 
> statement,  rephrased as follows.
>
> I believe the policy proposal has potential timeliness issues with it 
> along with the AC suggestion that it may have merit, as such to my view, 
> the proper course of action assuming the community as a whole is not yet 
> ready to deal head on with it is to put it on the docket for the next 
> public policy meeting instead of the immediate upcoming one.
>
> Personally, I found it well written and fairly convincing on its face value.
>
> Am I missing some formality or proper address or is it done and should I 
> just wait and see if support rolls in to turn this proposal into a draft 
> discussion policy or not?
>
>
> "
> 2.4 Discussion Petition
>
> Any member of the community, including a proposal originator, may 
> initiate a Discussion Petition if they are dissatisfied with the action 
> taken by the Advisory Council regarding any specific policy proposal. If 
> successful, this petition will change the policy proposal to a draft 
> policy which will be published for discussion and review by the 
> community on the PPML and at an upcoming public policy meeting.
>
> The Discussion Petition must be initiated within 5 business days of 
> announcement of the Advisory Council's decision regarding a specific 
> policy proposal; the petition must include the proposal and a petition 
> statement. The petition duration is 5 business days. The ARIN President 
> determines if the petition succeeds (success is support from at least 10 
> different people from 10 different organizations). In order to be 
> considered at an upcoming public policy meeting, the petition must be 
> successfully completed at least 35 days prior to that meeting.
>
> A successful petition may result in competing versions of the same draft 
> policy. Staff and legal reviews will be conducted and published for 
> successful petitions.
>
> All draft policies that are selected by the Advisory Council or 
> successfully petitioned are published for review and discussion on the 
> public policy mailing list.
> "
>
>
>
> William Herrin wrote:
>   
>> On Thu, Jun 25, 2009 at 9:08 PM, Joe Maimon<jmaimon at chl.com> wrote:
>>   
>>     
>>> "The AC believes that Policy Proposal
>>> #92 has some merit in concept, but does not believe that the problem
>>> addressed is immediate nor of sufficient scope currently. Furthermore,
>>> the benefits presumed may be achieved in ways other than using the
>>> discrete pools for address allocation. We hope that the author continues
>>> to discuss this issue with the AC and community."
>>>
>>> I believe there are timeliness issues involved, especially as it
>>> pertains to routing policy, as well as an interest in dispelling
>>> uncertainty with regards to ipv6 rollout which may be a factor in
>>> delaying migration.
>>>
>>> I would suggest a more appropriate action would be to delay working on
>>> the proposal until it has had more time to mature in our minds,
>>> something like what happened with policy proposal 95, customer
>>> confidentiality.
>>>
>>> Is it considered polite to defer to a policy proposal's author for a
>>> discussion petition? Ia a petition under consideration?
>>>     
>>>       
>> Hi Joe,
>>
>> I don't plan to petition but I won't object if you want to.
>>
>> I suggest, however, that you're right: judging from the response,
>> folks need more time to bounce the ideas around and consider what the
>> most important results of IPv6 addressing policy really are. That may
>> be less threatening if the ideas aren't looming overhead in the form
>> of a policy proposal that must be ratified or rejected on schedule.
>>
>> At any rate, we can dust the proposal off at any time and use it as a
>> reference to write a better one.
>>
>> Regards,
>> Bill
>>
>>   
>>     
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> This E-mail and any of its attachments may contain Time Warner
> Cable proprietary information, which is privileged, confidential,
> or subject to copyright belonging to Time Warner Cable. This E-mail
> is intended solely for the use of the individual or entity to which
> it is addressed. If you are not the intended recipient of this
> E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents
> of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>
>
>   
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090626/f63a2bc1/attachment.htm>

From einarb at arin.net  Fri Jun 26 20:46:05 2009
From: einarb at arin.net (Einar Bohlin)
Date: Fri, 26 Jun 2009 20:46:05 -0400
Subject: [arin-ppml] Petitioning AC abandonment of Policy Proposal 92
 Alternate IPv6 Allocation
In-Reply-To: <4A453B80.70701@chl.com>
References: <58174FA985B92A42B9E3142C4DD2CC0405EC08CE@PRVPVSMAIL07.corp.twcable.com>
	<4A453B80.70701@chl.com>
Message-ID: <FEA070315E40A3489D38398C35FE7BB23AEE7AB1D0@EDAMAME.arin.net>

Joe,

A successful petition would turn the proposal into a draft policy and you would control the text on the PPML and thru the upcoming Public Policy Meeting (you'd be the presenter). 

In order to petition, post to PPML that you wish to petition, and provide the proposal text that you wish to move forward. And as Bill Darte pointed out in a later post, go ahead and ask for support on the list. Success will require that 10 people agree with you.

The deadline to initiate a petition is 30 June as was stated in our post on 23 June. If this proposal is not successfully petitioned, then it will be closed.

The post about the AC abandoning the proposal is here:
http://lists.arin.net/pipermail/arin-ppml/2009-June/014661.html

Regards,

Einar Bohlin
Policy Analyst
Member Services, ARIN
einarb at arin.net +1 703 227-9867


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Joe Maimon
> Sent: Friday, June 26, 2009 5:20 PM
> To: Sweeting, John
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Petitioning AC abandonment of Policy Proposal
> 92 Alternate IPv6 Allocation
> 
> 
> 
> Sweeting, John wrote:
> > Thanks Joe,
> >
> > I need to check but I believe that by petitioning this decision it
> means that you are taking on the responsibility of presenting it at the
> next PPM in order to gain community support. The AC stands ready to
> help but a petition does not return the proposal to the AC's docket
> until after it has been presented at the PPM and community support has
> been proven. I will ask ARIN staff to elaobrate on this.
> >
> >
> 
> I dont quite understand how your petition process makes sense or is at
> all contained in the text quoted below. The dates alone should render
> it
> impossible to petition the AC decision at ppm. Furthermore to what
> purpose does the petition serve at this point if not to return it to
> the
> AC docket?
> 
> If you perhaps mean that by petitioning here on ppml, there is a
> side-effect of slapping my name up as official presenter of the draft
> policy, well that was part of my original query.
> 
> >
> >
> > ----- Original Message -----
> > From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
> > To: William Herrin <bill at herrin.us>
> > Cc: ppml at arin.net <ppml at arin.net>
> > Sent: Fri Jun 26 15:26:52 2009
> > Subject: Re: [arin-ppml] AC abandonment of Policy Proposal 92
> Alternate IPv6 Allocation
> >
> > I cant find anything more specific to the process, so perhaps this
> > thread should be considered the petition along with the original
> > statement,  rephrased as follows.
> >
> > I believe the policy proposal has potential timeliness issues with it
> > along with the AC suggestion that it may have merit, as such to my
> view,
> > the proper course of action assuming the community as a whole is not
> yet
> > ready to deal head on with it is to put it on the docket for the next
> > public policy meeting instead of the immediate upcoming one.
> >
> > Personally, I found it well written and fairly convincing on its face
> value.
> >
> > Am I missing some formality or proper address or is it done and
> should I
> > just wait and see if support rolls in to turn this proposal into a
> draft
> > discussion policy or not?
> >
> >
> > "
> > 2.4 Discussion Petition
> >
> > Any member of the community, including a proposal originator, may
> > initiate a Discussion Petition if they are dissatisfied with the
> action
> > taken by the Advisory Council regarding any specific policy proposal.
> If
> > successful, this petition will change the policy proposal to a draft
> > policy which will be published for discussion and review by the
> > community on the PPML and at an upcoming public policy meeting.
> >
> > The Discussion Petition must be initiated within 5 business days of
> > announcement of the Advisory Council's decision regarding a specific
> > policy proposal; the petition must include the proposal and a
> petition
> > statement. The petition duration is 5 business days. The ARIN
> President
> > determines if the petition succeeds (success is support from at least
> 10
> > different people from 10 different organizations). In order to be
> > considered at an upcoming public policy meeting, the petition must be
> > successfully completed at least 35 days prior to that meeting.
> >
> > A successful petition may result in competing versions of the same
> draft
> > policy. Staff and legal reviews will be conducted and published for
> > successful petitions.
> >
> > All draft policies that are selected by the Advisory Council or
> > successfully petitioned are published for review and discussion on
> the
> > public policy mailing list.
> > "
> >
> >
> >
> > William Herrin wrote:
> >
> >> On Thu, Jun 25, 2009 at 9:08 PM, Joe Maimon<jmaimon at chl.com> wrote:
> >>
> >>
> >>> "The AC believes that Policy Proposal
> >>> #92 has some merit in concept, but does not believe that the
> problem
> >>> addressed is immediate nor of sufficient scope currently.
> Furthermore,
> >>> the benefits presumed may be achieved in ways other than using the
> >>> discrete pools for address allocation. We hope that the author
> continues
> >>> to discuss this issue with the AC and community."
> >>>
> >>> I believe there are timeliness issues involved, especially as it
> >>> pertains to routing policy, as well as an interest in dispelling
> >>> uncertainty with regards to ipv6 rollout which may be a factor in
> >>> delaying migration.
> >>>
> >>> I would suggest a more appropriate action would be to delay working
> on
> >>> the proposal until it has had more time to mature in our minds,
> >>> something like what happened with policy proposal 95, customer
> >>> confidentiality.
> >>>
> >>> Is it considered polite to defer to a policy proposal's author for
> a
> >>> discussion petition? Ia a petition under consideration?
> >>>
> >>>
> >> Hi Joe,
> >>
> >> I don't plan to petition but I won't object if you want to.
> >>
> >> I suggest, however, that you're right: judging from the response,
> >> folks need more time to bounce the ideas around and consider what
> the
> >> most important results of IPv6 addressing policy really are. That
> may
> >> be less threatening if the ideas aren't looming overhead in the form
> >> of a policy proposal that must be ratified or rejected on schedule.
> >>
> >> At any rate, we can dust the proposal off at any time and use it as
> a
> >> reference to write a better one.
> >>
> >> Regards,
> >> Bill
> >>
> >>
> >>
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> > This E-mail and any of its attachments may contain Time Warner
> > Cable proprietary information, which is privileged, confidential,
> > or subject to copyright belonging to Time Warner Cable. This E-mail
> > is intended solely for the use of the individual or entity to which
> > it is addressed. If you are not the intended recipient of this
> > E-mail, you are hereby notified that any dissemination,
> > distribution, copying, or action taken in relation to the contents
> > of and attachments to this E-mail is strictly prohibited and may be
> > unlawful. If you have received this E-mail in error, please notify
> > the sender immediately and permanently delete the original and any
> > copy of this E-mail and any printout.
> >
> >
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From jmaimon at chl.com  Mon Jun 29 11:39:28 2009
From: jmaimon at chl.com (Joe Maimon)
Date: Mon, 29 Jun 2009 11:39:28 -0400
Subject: [arin-ppml] Petitioning AC abandonment of Policy Proposal 92
 Alternate IPv6 Allocation
In-Reply-To: <FEA070315E40A3489D38398C35FE7BB23AEE7AB1D0@EDAMAME.arin.net>
References: <58174FA985B92A42B9E3142C4DD2CC0405EC08CE@PRVPVSMAIL07.corp.twcable.com>
	<4A453B80.70701@chl.com>
	<FEA070315E40A3489D38398C35FE7BB23AEE7AB1D0@EDAMAME.arin.net>
Message-ID: <4A48E030.40602@chl.com>

Einar Bohlin wrote:
> Joe,
>
> A successful petition would turn the proposal into a draft policy and you would control the text on the PPML and thru the upcoming Public Policy Meeting (you'd be the presenter). 
>
> In order to petition, post to PPML that you wish to petition, and provide the proposal text that you wish to move forward. And as Bill Darte pointed out in a later post, go ahead and ask for support on the list. Success will require that 10 people agree with you.
>
> The deadline to initiate a petition is 30 June as was stated in our post on 23 June. If this proposal is not successfully petitioned, then it will be closed.
>
> The post about the AC abandoning the proposal is here:
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014661.html
>
> Regards,
>
> Einar Bohlin
> Policy Analyst
> Member Services, ARIN
> einarb at arin.net +1 703 227-9867
>
>
>
>   
Einar,

I appreciate yours and all others added clarity on the petition process 
and its results that I did not find in the PDP text. Perhaps some work 
is needed on that.

Judging  from the current text and extensive effort that Bill has put 
into this proposal, I doubt I am the principal advocate it deserves at 
this time.

My primary interest was to have meaningful discussion on the proposals 
merits and demerits all the way through draft policy, as I believe it 
confronts issues that have come up time and again. Apparently now may 
not be quite the right time for that.

As the archives show, most of the discussion to date has been regarding 
router architecture.

As such, I am going to defer to its original author and will not proceed 
with my own petition. I would support a petition made by anyone else who 
wishes to take on the task.

Thanks,

Joe



From bill at herrin.us  Mon Jun 29 13:24:50 2009
From: bill at herrin.us (William Herrin)
Date: Mon, 29 Jun 2009 13:24:50 -0400
Subject: [arin-ppml] Minimum allocations list?
Message-ID: <3c3e3fca0906291024yc9706fbk70797f7e26a479fa@mail.gmail.com>

Hi,

What happened to the list of minimum ARIN IPv4 allocations that used
to be at http://www.arin.net/statistics/index.html#cidr ? The one
similar to http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations
?

Thanks,
Bill


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From farmer at umn.edu  Mon Jun 29 13:39:23 2009
From: farmer at umn.edu (David Farmer)
Date: Mon, 29 Jun 2009 12:39:23 -0500
Subject: [arin-ppml] Minimum allocations list?
In-Reply-To: <3c3e3fca0906291024yc9706fbk70797f7e26a479fa@mail.gmail.com>
References: <3c3e3fca0906291024yc9706fbk70797f7e26a479fa@mail.gmail.com>
Message-ID: <4A48B5FB.14442.E746EAB@farmer.umn.edu>

Is this what you are referring to?

https://www.arin.net/knowledge/ip_blocks.html

On 29 Jun 2009 William Herrin wrote:

> Hi,
> 
> What happened to the list of minimum ARIN IPv4 allocations that used
> to be at http://www.arin.net/statistics/index.html#cidr ? The one
> similar to http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations
> ?
> 
> Thanks,
> Bill
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



===============================================
David Farmer                                      Email:farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota		       Phone: 612-626-0815
2218 University Ave SE		       Cell: 612-812-9952
Minneapolis, MN 55414-3029	       FAX: 612-626-1818
===============================================



From info at arin.net  Tue Jun 30 10:28:29 2009
From: info at arin.net (Member Services)
Date: Tue, 30 Jun 2009 10:28:29 -0400
Subject: [arin-ppml] Policy Development Process - Submit policy proposals at
	any time
Message-ID: <4A4A210D.3090809@arin.net>

The ARIN Policy Development Process (PDP) allows for policy proposals to
be submitted at any time.

However, while there is no deadline, the PDP does contain several time
requirements:
? Policy originators need time to think about and write policy proposals,
? ARIN staff needs time to conduct the Clarity and Understanding review,
? The AC needs time to make a decision and create draft policy,
? ARIN staff and legal counsel must be given time to perform staff
assessments,
? And, draft policies must be posted to PPML at least 35 days prior to
an ARIN meeting to be considered for that meeting?s agenda.

Therefore, if you are considering submitting a policy proposal for
consideration for the October ARIN Public Policy Meeting, the sooner you
turn it in the better. Note that there are 15 proposals today in various
states of development, and, even though proposals received may not be
considered for the October meeting, they will be considered for the
April meeting.

The Policy Development Process and Policy Proposal Template are
available at:
https://www.arin.net/policy/pdp.html

Policy proposals and draft policies under discussion are available at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)