From bill at herrin.us  Mon Feb  1 00:16:54 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 1 Feb 2010 00:16:54 -0500
Subject: [arin-ppml] Draft Policy 2010-2: /24 End User Minimum
	Assignment Unit - Correct Title
In-Reply-To: <EB28C701-7CEE-43C1-9C4B-B2D9F805CFE0@delong.com>
References: <4B58C4A5.2000406@arin.net>
	<9BD4795A-4AC5-43A3-AA9D-215C622BA71C@delong.com> 
	<CCD4153D830F584982521DFC986BFF31534F8FE13E@tgainf06.TGASolutions.local>
	<3c3e3fca1001290818r77d06748o9d86cc67465a09ff@mail.gmail.com> 
	<CCD4153D830F584982521DFC986BFF31534F8FE1B7@tgainf06.TGASolutions.local>
	<62CFC76A-D302-426F-92B2-26BCC51C4BFE@delong.com>
	<3c3e3fca1001291157s1c4b9c68rf4f78578ac0aa4d1@mail.gmail.com> 
	<CCD4153D830F584982521DFC986BFF31534F8FE24F@tgainf06.TGASolutions.local>
	<3c3e3fca1001291721j637e073bwb7c0865aad9282c9@mail.gmail.com> 
	<EB28C701-7CEE-43C1-9C4B-B2D9F805CFE0@delong.com>
Message-ID: <3c3e3fca1001312116h724abab0tfe47132534f2b921@mail.gmail.com>

On Sun, Jan 31, 2010 at 11:59 PM, Owen DeLong <owen at delong.com> wrote:
> On Jan 29, 2010, at 5:21 PM, William Herrin wrote:
>> That's one reason why letting the ISP decide whether or not to give
>> you a /24 suppresses abuse.
>>
> I suppose that depends on how you define abuse. ?If you ask the ISP
> and they refuse, but, you have a legitimate reason for wanting to
> multihome, isn't that another form of abuse?

Hi Owen,

Not if your multihoming is two phone lines and a pair of $10 dialups,
no. Introducing a route into the DFZ isn't a God-given right
sanctified in the 42nd amendment. It's a privilege you pay hard cash
for and not everyone who can vend it chooses to.

I'd bet that the number of above-board providers who are willing to
provide you with BGP service but are unwilling to assign a /24 is
vanishingly small. That could well change after free pool depletion
but if this proposal achieves consensus then we'll have headed off
that worry before it can become a problem.

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  Mon Feb  1 00:27:09 2010
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Mon, 1 Feb 2010 00:27:09 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:Customer	Confidentiality - Time Sensitive
In-Reply-To: <FE7D4327AABC0448A6281C0AC4445C7C82CC667CF2@Exchange2007.HostedMail.local>
References: <02c701caa054$b71df010$2559d030$@net>
	<4B62098C.60606@arin.net><D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net><4B636B12.6090603@ipinc.net>
	<4B638058.7010500@umn.edu><4B63865F.7070608@ipinc.net><D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com><3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com><4B65DB30.6080200@umn.edu><3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com>
	<FE7D4327AABC0448A6281C0AC4445C7C82CC667CF2@Exchange2007.HostedMail.local>
Message-ID: <997BC128AE961E4A8B880CD7442D9480126F3EFA@NJCHLEXCMB01.cable.comcast.com>

Bill H,

I usually try to avoid posting as I'm more interested in hearing the
opinions of the community, and having that feedback evolve my own
thoughts as to how the AC should be advising the Board. Your frustration
is noted, however and I will try and sum up a few thoughts without being
too redundant to the conversation. When it comes to swips and whois, I
think we keep trying to revise the how without ever coming to terms with
the what or why. Not that this is a bad thing. Sometimes one leads to
the other.

Who are we trying to contact with this directory and why? The primary
reason for a swip record is for a contact in the event of an issue. My
opinion is it should not need to be a contact of who's host is using the
IP. The contact should be one that can respond in a timely manner if
there is an issue with the host. That could be the end user or the
upstream ISP who made the assignment and is responsible for the
allocation it was given. The focus should be on who has the ability to
respond instead of the who it was assigned to.

I question the opinion that if you are using IP resources your
information should be listed. This leads to an inconsistency in the
approach as most of the end users are not listed. (DHCP, /30's,
residential, etc) Are we trying to use swips for abuse contacts, or are
we trying to mimic a phone directory? I don't think the latter is a
practical approach. 

Some have voiced the opinion of using swips as a means of reporting
utilization to ARIN. I think this use of swips had its day, but has
become outdated and unreliable. Each member organization is under RSA
with ARIN and there are any number of means to understand an allocations
utilization other than swips. The trick is what options an organization
would have available and how that would remain transparent to the
community. 

My opinion is that we should do away with prefix size requirements, the
focus on which end users should be listed, and with what data. I think
the focus of swips should be on who is able to effectively respond to an
issue. When it comes to reporting utilization, or responding to law
enforcement, these issues should be approached from completely new and
different means, and we should not try and force these solutions into a
system that was never designed to accommodate them.

My two cents.
Dan Alexander
ARIN AC


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Bill Sandiford
Sent: Sunday, January 31, 2010 8:40 PM
To: 'William Herrin'; David Farmer
Cc: John Curran; arin-ppml at arin.net
Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95:Customer
Confidentiality - Time Sensitive

William Herrin wrote:
> <snip>
>
> Marla Azinger. Last PPML post September 2009
> Stacy Hughes. Last PPML post September 2009
> Heather Schiller. Last PPML post: July 2009
> Dan Alexander. Last PPML post: June 2009
> Bill Sandiford. Posted a message on the PPML exactly once.
> Marc Crandall. Has he *ever* participated on the PPML?
> Tom Zeller. No participation identified in the last decade of PPML
> archives.
> 

Hi Bill:

I can't speak for any of the others, but I have only sat on the AC for a
grand total of 31 days now.  After being elected, I decided that I was
going observe for a little while before getting vocal.  I felt it was
prudent to do so.  I also found that while observing, Scott, Owen, and
David usually ask a lot of the questions that I would ask anyways.  I'm
not about to repeat those questions ad nauseum just to increase my "post
count". 

The fact that I have not been *posting* does not mean that I (or the
others for that matter) haven't spent a considerable amount of time
*reading* the emails of others that are sent to PPML.  By my count there
have been ~350 emails since January 31st alone, the reading of which
takes a considerable amount of time.  I also appreciate that there are
people like yourself that have spent the same amount of time reading and
participating as well.

To summarize, just because I'm not posting, does not mean I'm not doing
my job as an AC member.  I'm reading, gauging community
opinion/consensus, and taking that feedback into consideration when the
AC meets in order to create/advance good policy.

I look forward to meeting you and others of the community at the
upcoming PPM in Toronto (my home town).

Regards,
Bill Sandiford



_______________________________________________
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 Feb  1 00:32:10 2010
From: farmer at umn.edu (David Farmer)
Date: Sun, 31 Jan 2010 23:32:10 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
 Confidentiality - Time Sensitive
In-Reply-To: <DBD6A9B35C8E714692C63182AC49382C34A480@MAVS1.kendall.corp.akamai.com>
References: <DBD6A9B35C8E714692C63182AC49382C34A480@MAVS1.kendall.corp.akamai.com>
Message-ID: <4B66675A.6080206@umn.edu>

Hannigan, Martin wrote:
> 
> David, 
> 
> Have you actually read the "new" PDP? 
> 
> Best, 
> 
> Martin 

Yes, several times and I have listened to several other people's 
interpretations of it, there are some issues that are not as clear cut 
as some might think.

The question at hand here is, there is no specific deadline or time 
frame in the PDP for the AC to move a proposal from an Policy Proposal 
accepted on to the AC docket to a Draft Policy.  In theory by the letter 
of the PDP, the AC could accept a proposal on to its docket and not ever 
move it to Draft policy.  Then is the lack of moving a Policy Proposal 
to Draft Policy an action taken by the AC that would be petitionable, 
and if so when?

If I remember correctly, the AC came to the conclusion that when the AC 
decides that we were not going to move a policy forward to draft policy 
in time for a PPM that we would announce that as an action taken by the 
AC with the intent that it would be petitionable, this seems to follow 
the spirit of the PDP.

I don't think it is reasonable for the lack of action by the AC to be 
petitionable at any time, the AC does need a chance to do its job and to 
manage its workflow.  But, at the same time the AC shouldn't be allowed 
to sit on a proposal forever either.  At some point the lack of action 
is an action, it seems reasonable for that point to be when a proposal 
is not going to make it to a PPM as a Draft Policy for adoption 
discussion.  However, this is not explicitly covered in the PDP.

> ----- Original Message -----
> From: David Farmer <farmer at umn.edu>
> To: William Herrin <bill at herrin.us>
> Cc: John Curran <jcurran at arin.net>; arin-ppml at arin.net <arin-ppml at arin.net>
> Sent: Sun Jan 31 19:50:31 2010
> Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95: Customer Confidentiality - Time Sensitive
> 
> William Herrin wrote:
>> On Sun, Jan 31, 2010 at 2:34 PM, David Farmer <farmer at umn.edu> wrote:
>>> I would like to point out that PP#95 was originally put forward in June
>>> 2009, the AC decided it wouldn't be part of the Dearborn PPM, I supported
>>> this as I thought we had more important thins to work on.  It became clear
>>> that we the AC wasn't not going to have something ready for the Toronto PPM.
>>>  I therefore supported abandoning the proposal, at this time because it
>>> didn't make sense to me for us to keep it on our docket and not actually
>>> make any progress on it.
>> How is that delay possible anyway? Section 2.2 in the PDP reads in part:
>>
>> "Council must make a decision regarding any policy proposal at their
>> next regularly scheduled meeting that occurs after the Advisory
>> Council receives the Clarity and Understanding Report from staff. 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, but the period shall not be extended beyond 45
>> days."
>>
>> I haven't examined the schedule in detail but it seems to me that more
>> time than that has elapsed since June 2009.

Bill, I just realized I didn't actually answer your question, or at 
least as directly as I could have.

The AC accepted the proposal on to its docket per the terms of the 
section you quoted.  But we said we would not have a Draft Policy ready 
for Dearborn, and this was noted as a petitionable action in the notice 
I pointed out below.  I don't know how I missed it the first time, but 
it was there like I said it should be.

Earlier in 2.2 it says;

"The Advisory Council develops a draft policy. During this effort they 
may take any action such as rewrite, abandon, merge various proposals, 
or use a proposal as an idea to generate a draft policy."

Which is consistent with the action we took at our last meeting that 
initiated this petition.  In theory the AC could have said we still want 
to work on it but won't have a Draft Policy for Toronto, delaying again. 
  But, I think abandoning it was more honest to the community.  However, 
delaying again may have been a politically wiser move, it is at least 
possible if the AC sent the message that we still want to work on it, 
that a petition may not have been initiated or would have failed to gain 
sufficient support.

> It was publicly announced, see:
> 
> http://lists.arin.net/pipermail/arin-ppml/2009-June/014661.html
> 
> I thought it was announced at some point that this was petitionable, but 
> I can't seem to find it.  If it wasn't that was probably a mistake on 
> our part, but I don't believe there was any intent to deceive anyone. 
> The PDP is just a year old and we haven't figured it all out yet.



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


From owen at delong.com  Mon Feb  1 00:32:26 2010
From: owen at delong.com (Owen DeLong)
Date: Sun, 31 Jan 2010 21:32:26 -0800
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
	Confidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net>
	<D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>
	<4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu>
	<4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
Message-ID: <E35CCC98-234B-479F-835F-D7AD97CA2316@delong.com>


On Jan 31, 2010, at 8:35 AM, William Herrin wrote:

> On Sun, Jan 31, 2010 at 2:15 AM, Owen DeLong <owen at delong.com> wrote:
>> On Jan 29, 2010, at 5:07 PM, Ted Mittelstaedt wrote:
>>> Of course it did.  The success of the petition means one thing - that
>>> the AC made a bad decision.
>> 
>> I disagree.  I think the AC made the absolutely correct decision and that
>> the petition means that 10 or more members of the community disagree
>> with the AC's decision sufficiently strongly that they successfully
>> petitioned it. That's how the process is supposed to work.  There's
>> nothing wrong with it.
> 
> Hi Owen,
> 
> That depends whether this one incident becomes a pattern. One incident
> standing alone means the process is working as intended. A pattern of
> incidents, should one develop, would mean that the AC is  suppressing
> public participation.
> 
> Something to consider the next time you vote to abandon a policy
> simply because you think it's "bad." That isn't what you were elected
> to do.
> 
Bill,
	The AC was elected to help develop good, technically sound
policy.

	We do have an obligation to focus our efforts on the things
we think have the greatest potential for becoming that.  As such,
it is absolutely appropriate for the AC to abandon policies which
we feel do not meet the tests of:

	+	Good policy
	+	Technically Sound
	+	Supported by the Community

	I will not vote to abandon a policy merely because I disagree
with the policy.  (If that were the case, I would have been trying
to abandon many more policies.)  I will vote to abandon a policy
if I believe the policy to be:

	+	Detrimental to the ARIN community
	+	Technically infeasible
	+	Malformed to the point of being incomprehensible
		or non-implementable.
	+	Overwhelmingly opposed by the community

	Otherwise, even if I don't like the policy, I will vote to bring
it to the floor.

Owen



From marty at akamai.com  Mon Feb  1 00:41:21 2010
From: marty at akamai.com (Martin Hannigan)
Date: Mon, 1 Feb 2010 00:41:21 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
	Confidentiality - Time Sensitive
In-Reply-To: <4B66675A.6080206@umn.edu>
References: <DBD6A9B35C8E714692C63182AC49382C34A480@MAVS1.kendall.corp.akamai.com>
	<4B66675A.6080206@umn.edu>
Message-ID: <E2B65DC7-CB31-4396-9DB5-26B6CF6F093A@akamai.com>


On Feb 1, 2010, at 12:32 AM, David Farmer wrote:

> Hannigan, Martin wrote:
> >
> > David,
> >
> > Have you actually read the "new" PDP?
> >
> > Best,
> >
> > Martin
>
> Yes, several times and I have listened to several other people's
> interpretations of it, there are some issues that are not as clear cut
> as some might think.
>

This has been the case with many PDP's over the years.

>
> The question at hand here is, there is no specific deadline or time
> frame in the PDP for the AC to move a proposal from an Policy Proposal
> accepted on to the AC docket to a Draft Policy.  In theory by the  
> letter
> of the PDP, the AC could accept a proposal on to its docket and not  
> ever
> move it to Draft policy.  Then is the lack of moving a Policy Proposal
> to Draft Policy an action taken by the AC that would be petitionable,
> and if so when?
>
>

Perhaps that was intentional?


> If I remember correctly, the AC came to the conclusion that when the  
> AC
> decides that we were not going to move a policy forward to draft  
> policy
> in time for a PPM that we would announce that as an action taken by  
> the
> AC with the intent that it would be petitionable, this seems to follow
> the spirit of the PDP.
>
> I don't think it is reasonable for the lack of action by the AC to be
> petitionable at any time, the AC does need a chance to do its job  
> and to
> manage its workflow.
>

Perhaps that's a feature of the PDP and not a bug?

The reason I mentioned this was because I was surprised. You spend a  
LOT of time posting, but then when the tough questions arose you  
pointed at the PDP and claimed deficiencies.  I found that interesting.

Best,

Martin




From bill at herrin.us  Mon Feb  1 01:03:31 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 1 Feb 2010 01:03:31 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
	Confidentiality - Time Sensitive
In-Reply-To: <E35CCC98-234B-479F-835F-D7AD97CA2316@delong.com>
References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net> 
	<D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>
	<4B636B12.6090603@ipinc.net> 
	<4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com> 
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> 
	<E35CCC98-234B-479F-835F-D7AD97CA2316@delong.com>
Message-ID: <3c3e3fca1001312203i2c5141depf3d4e6d13213c1d6@mail.gmail.com>

On Mon, Feb 1, 2010 at 12:32 AM, Owen DeLong <owen at delong.com> wrote:
> ? ? ? ?The AC was elected to help develop good, technically sound
> policy.

Owen,

The AC was elected first and foremost to be shepherds of the bottom-up
public-originated policy development process. Advising whether a
particular proposal is "good, technically sound policy" is supposed to
be the very last step, not the first. Moving it to the front violates,
disrupts and eventually destroys the bottom-up character of the
process.

Welcome to corruption 101. It starts with a conflict of interest and a
sense of entitlement born of expertise and honest, earnest work. From
there it's one short slide after another down the long and slippery
slope.


> I will vote to abandon a policy if I believe the policy to be:
> ? ? ? ?+ ? ? ? Technically infeasible
> ? ? ? ?+ ? ? ? Malformed to the point of being incomprehensible
> ? ? ? ? ? ? ? ?or non-implementable.
> ? ? ? ?+ ? ? ? Overwhelmingly opposed by the community

Reasonable.

>        +       Detrimental to the ARIN community

Out of order. This does not belong in your evaluation prior to the
board-recommendation phase. You're supposed to help proposal authors
produce the best proposal possible that's consistent with their
intentions and then encourage community comment. Instead you cut them
off at the knees.

The "advise" in "advisory council" isn't an artifact and the board
isn't the group that needs your advice.

You won't see it. You never do. But in your unsubtle way you have, I
hope, exhibited the error for others. Because it isn't your error
alone.

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 mysidia at gmail.com  Mon Feb  1 01:06:30 2010
From: mysidia at gmail.com (James Hess)
Date: Mon, 1 Feb 2010 00:06:30 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:Customer
	Confidentiality - Time Sensitive
In-Reply-To: <997BC128AE961E4A8B880CD7442D9480126F3EFA@NJCHLEXCMB01.cable.comcast.com>
References: <02c701caa054$b71df010$2559d030$@net> <4B636B12.6090603@ipinc.net>
	<4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
	<4B65DB30.6080200@umn.edu>
	<3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com>
	<FE7D4327AABC0448A6281C0AC4445C7C82CC667CF2@Exchange2007.HostedMail.local>
	<997BC128AE961E4A8B880CD7442D9480126F3EFA@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <6eb799ab1001312206t6a1ee92fm71cd24334f2dd8fa@mail.gmail.com>

On Sun, Jan 31, 2010 at 11:27 PM, Alexander, Daniel
<Daniel_Alexander at cable.comcast.com> wrote: [snip]
..
Information doesn't have to be provided with SWIP.    The  ARIN  NRPM
provides that a provider can offer  re-assignment information via a
RWHOIS. server    The  NRPM  doesn't actually specify  what type of
contact information the RWHOIS server has to provide.

If a providers'  RWHOIS server only provided a 'name'  for the
contact,  the  'usefulness'  of the RWHOIS server would be limited.
However, the NRPM doesn't list   "attributes that have to be
populated"  for each record.

Perhaps someone could point to the current clause in the NRPM that
would be violated  by a  RWHOIS server   that  did not  provide
e-mail  or  phone number for a contact?

..
> Who are we trying to contact with this directory and why? The primary
> reason for a swip record is for a contact in the event of an issue. My
> opinion is it should not need to be a contact of who's host is using the
> IP. The contact should be one that can respond in a timely manner if

No,  there are multiple kinds of contacts in the directory. "An issue"
is probably the most common reason that information is to be looked up
and actually used, but that doesn't mean it is the primary reason the
record is there.

Another reason is to provide public accountability for IP re-assignment.
Just an  'organization name' is not sufficient for that:  names can be
made up or fictional, ARIN looking up public records requires more
details than a name.
If they have to  "ask"  for the information,  that  implies   ARIN
doesn't  even have information required to audit re-assignments  --
going through the trouble to "ask" for basic contact information
increases costs for ARIN, and for ISPs.


Re-assignment information allows an organization to easily "prove"
they are a legitimate user of those ip addresses.    Other internet
users can more easily investigate allegations  that someone has
"hijacked a range of IP addresses",  or decide which user is
legitimate,  or a secondary ISP of  end users' network may require
their contact appears in WHOIS, before they will initially allow the
end-user network to announce that prefix to the ISP for multi-homing.




One of the contact addresses provided with the WHOIS directory should
reach the network manager for the network involved,  a  person   with
the ability and authority  to disconnect a host in the block in
question from the network,   without the collateral damage of
disconnecting other  important parts of the network.



--
-J


From bill at herrin.us  Mon Feb  1 01:06:22 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 1 Feb 2010 01:06:22 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:Customer
	Confidentiality - Time Sensitive
In-Reply-To: <997BC128AE961E4A8B880CD7442D9480126F3EFA@NJCHLEXCMB01.cable.comcast.com>
References: <02c701caa054$b71df010$2559d030$@net> <4B636B12.6090603@ipinc.net>
	<4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com> 
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> 
	<4B65DB30.6080200@umn.edu>
	<3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com> 
	<FE7D4327AABC0448A6281C0AC4445C7C82CC667CF2@Exchange2007.HostedMail.local>
	<997BC128AE961E4A8B880CD7442D9480126F3EFA@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <3c3e3fca1001312206h4471ae86k3122373318742cb5@mail.gmail.com>

On Mon, Feb 1, 2010 at 12:27 AM, Alexander, Daniel
<Daniel_Alexander at cable.comcast.com> wrote:
> Who are we trying to contact with this directory and why? The primary
> reason for a swip record is for a contact in the event of an issue. My
> opinion is it should not need to be a contact of who's host is using the
> IP. The contact should be one that can respond in a timely manner if
> there is an issue with the host. That could be the end user or the
> upstream ISP who made the assignment and is responsible for the
> allocation it was given. The focus should be on who has the ability to
> respond instead of the who it was assigned to.

Hi Dan,

Good to see you again.

Respectfully, the primary reason for SWIP is and has always been
public accountability. Emergency contact is a valuable benefit but
it's no more SWIP's purpose than hunting is the purpose of the second
amendment.

Find me a process of *public* accountability that beats SWIP and I'll
jump on the ditch-SWIP bandwagon.

Good luck.

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  Mon Feb  1 01:30:53 2010
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Mon, 1 Feb 2010 01:30:53 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:Customer
	Confidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001312206h4471ae86k3122373318742cb5@mail.gmail.com>
References: <02c701caa054$b71df010$2559d030$@net> <4B636B12.6090603@ipinc.net>
	<4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
	<4B65DB30.6080200@umn.edu>
	<3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com>
	<FE7D4327AABC0448A6281C0AC4445C7C82CC667CF2@Exchange2007.HostedMail.local>
	<997BC128AE961E4A8B880CD7442D9480126F3EFA@NJCHLEXCMB01.cable.comcast.com>
	<3c3e3fca1001312206h4471ae86k3122373318742cb5@mail.gmail.com>
Message-ID: <997BC128AE961E4A8B880CD7442D9480126F3F03@NJCHLEXCMB01.cable.comcast.com>

Hey Bill,

This is my last post tonight. I'm on EST time and it's late. I have a
question on your last post. If it is all about public accountability,
then why do you think we draw the lines where we do? Why is a commercial
network behind a /30 less accountable than one with a /29? Why are
residential hosts less accountable then commercial hosts? I know they
are loaded questions, but it concerns me when we draw these lines in
policy. This also touches on Leo's posts about IPv6, in that I question
if swips are a viable means of accountability. 

Have a good night.
Dan

-----Original Message-----
From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William
Herrin
Sent: Monday, February 01, 2010 1:06 AM
To: Alexander, Daniel
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95:Customer
Confidentiality - Time Sensitive

On Mon, Feb 1, 2010 at 12:27 AM, Alexander, Daniel
<Daniel_Alexander at cable.comcast.com> wrote:
> Who are we trying to contact with this directory and why? The primary
> reason for a swip record is for a contact in the event of an issue. My
> opinion is it should not need to be a contact of who's host is using
the
> IP. The contact should be one that can respond in a timely manner if
> there is an issue with the host. That could be the end user or the
> upstream ISP who made the assignment and is responsible for the
> allocation it was given. The focus should be on who has the ability to
> respond instead of the who it was assigned to.

Hi Dan,

Good to see you again.

Respectfully, the primary reason for SWIP is and has always been
public accountability. Emergency contact is a valuable benefit but
it's no more SWIP's purpose than hunting is the purpose of the second
amendment.

Find me a process of *public* accountability that beats SWIP and I'll
jump on the ditch-SWIP bandwagon.

Good luck.

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 farmer at umn.edu  Mon Feb  1 01:45:03 2010
From: farmer at umn.edu (David Farmer)
Date: Mon, 01 Feb 2010 00:45:03 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
 Confidentiality - Time Sensitive
In-Reply-To: <E2B65DC7-CB31-4396-9DB5-26B6CF6F093A@akamai.com>
References: <DBD6A9B35C8E714692C63182AC49382C34A480@MAVS1.kendall.corp.akamai.com>
	<4B66675A.6080206@umn.edu>
	<E2B65DC7-CB31-4396-9DB5-26B6CF6F093A@akamai.com>
Message-ID: <4B66786F.1060902@umn.edu>

Martin Hannigan wrote:
> 
> On Feb 1, 2010, at 12:32 AM, David Farmer wrote:
> 
>> Hannigan, Martin wrote:
>> >
>> > David,
>> >
>> > Have you actually read the "new" PDP?
>> >
>> > Best,
>> >
>> > Martin
>>
>> Yes, several times and I have listened to several other people's
>> interpretations of it, there are some issues that are not as clear cut
>> as some might think.
>>
> 
> This has been the case with many PDP's over the years.

It is the case with most policy and processes, they almost always leave 
a lot to interpretation.

>> The question at hand here is, there is no specific deadline or time
>> frame in the PDP for the AC to move a proposal from an Policy Proposal
>> accepted on to the AC docket to a Draft Policy.  In theory by the letter
>> of the PDP, the AC could accept a proposal on to its docket and not ever
>> move it to Draft policy.  Then is the lack of moving a Policy Proposal
>> to Draft Policy an action taken by the AC that would be petitionable,
>> and if so when?
>>
>>
> 
> Perhaps that was intentional?

Could be.

>> If I remember correctly, the AC came to the conclusion that when the AC
>> decides that we were not going to move a policy forward to draft policy
>> in time for a PPM that we would announce that as an action taken by the
>> AC with the intent that it would be petitionable, this seems to follow
>> the spirit of the PDP.
>>
>> I don't think it is reasonable for the lack of action by the AC to be
>> petitionable at any time, the AC does need a chance to do its job and to
>> manage its workflow.
>>
> 
> Perhaps that's a feature of the PDP and not a bug?

I believe it is a feature and it is not a bug, but it is not well 
understood by most people.

> The reason I mentioned this was because I was surprised. You spend a LOT 
> of time posting, but then when the tough questions arose you pointed at 
> the PDP and claimed deficiencies.  I found that interesting.

I assume you mean this comment "The PDP is just a year old and we 
haven't figured it all out yet."  If not, please help me understand what 
comment I made that made you think I claimed the PDP had deficiencies.

My intent, wasn't that there was anything wrong with the PDP.  It was 
since much of what it really means is left to interpretation, we haven't 
explored all or even very many of the corner cases, and set precedent 
for dealing with them.  That is what I meant by, "The PDP is just a year 
old and we haven't figured it all out yet."

As for the tough questions, I supported abandoning the proposal because 
the AC was not making progress on it that we said we would.  I 
therefore, believed the best course of action was to abandon it allowing 
for the community to petition and have it succeed or fail.  If the 
petition had failed, I had no doubt that a new proposal would have come 
along and maybe it would have been a better one.

As has been mentioned on PPML by others, customer privacy should be 
driven by the customer's interest not the ISP's interest.  This proposal 
seems to protect the ISP's interest and not necessarily the customer's. 
  When I voted to accept the proposal on the the docket originally, it 
was in the intent that we the AC would work on this, looking at the 
issue from an IPv6 perspective.  That hasn't happened, and I'm not sure 
it is going to happen in the short term, so when it was recommended that 
we abandon this proposal by the AC shepherd, I supported that idea.


> Best,
> 
> Martin
> 
> 


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


From bill at herrin.us  Mon Feb  1 01:59:12 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 1 Feb 2010 01:59:12 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:Customer
	Confidentiality - Time Sensitive
In-Reply-To: <997BC128AE961E4A8B880CD7442D9480126F3F03@NJCHLEXCMB01.cable.comcast.com>
References: <02c701caa054$b71df010$2559d030$@net> <4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> 
	<4B65DB30.6080200@umn.edu>
	<3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com> 
	<FE7D4327AABC0448A6281C0AC4445C7C82CC667CF2@Exchange2007.HostedMail.local>
	<997BC128AE961E4A8B880CD7442D9480126F3EFA@NJCHLEXCMB01.cable.comcast.com>
	<3c3e3fca1001312206h4471ae86k3122373318742cb5@mail.gmail.com> 
	<997BC128AE961E4A8B880CD7442D9480126F3F03@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <3c3e3fca1001312259g6c074dbvaaf4561761e078e4@mail.gmail.com>

On Mon, Feb 1, 2010 at 1:30 AM, Alexander, Daniel
<Daniel_Alexander at cable.comcast.com> wrote:
> This is my last post tonight. I'm on EST time and it's late. I have a
> question on your last post. If it is all about public accountability,
> then why do you think we draw the lines where we do? Why is a commercial
> network behind a /30 less accountable than one with a /29? Why are
> residential hosts less accountable then commercial hosts? I know they
> are loaded questions, but it concerns me when we draw these lines in
> policy. This also touches on Leo's posts about IPv6, in that I question
> if swips are a viable means of accountability.

Hi Dan,

Surely you don't mean to suggest that SWIP is arbitrary and capricious?

So it is. SWIP is to accountability what democracy is to governance:
the worst possible form except for everything else we've considered.

SWIP isn't perfect. It isn't even particularly good. But as long as
we're doing needs-based allocation, SWIP more or less gets the
accountability job done.

Show me an alternative whose structure has a history of success in
other applications. I've no love for SWIP. It was a pain in the rump
back when I was responsible for the operations of an ISP. You might
recall that my proposal 103 would have eliminated it in IPv6. But to
accomplish that I had to change the address allocation criteria to
something invulnerable to fraud.

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 mysidia at gmail.com  Mon Feb  1 02:34:15 2010
From: mysidia at gmail.com (James Hess)
Date: Mon, 1 Feb 2010 01:34:15 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:Customer
	Confidentiality - Time Sensitive
In-Reply-To: <997BC128AE961E4A8B880CD7442D9480126F3F03@NJCHLEXCMB01.cable.comcast.com>
References: <02c701caa054$b71df010$2559d030$@net> <4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
	<4B65DB30.6080200@umn.edu>
	<3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com>
	<FE7D4327AABC0448A6281C0AC4445C7C82CC667CF2@Exchange2007.HostedMail.local>
	<997BC128AE961E4A8B880CD7442D9480126F3EFA@NJCHLEXCMB01.cable.comcast.com>
	<3c3e3fca1001312206h4471ae86k3122373318742cb5@mail.gmail.com>
	<997BC128AE961E4A8B880CD7442D9480126F3F03@NJCHLEXCMB01.cable.comcast.com>
Message-ID: <6eb799ab1001312334r1100307er970801c5432d2bc7@mail.gmail.com>

<Daniel_Alexander at cable.comcast.com> wrote:
> This is my last post tonight. I'm on EST time and it's late. I have a
> question on your last post. If it is all about public accountability,
> then why do you think we draw the lines where we do? Why is a commercial
> network behind a /30 less accountable than one with a /29? Why are
> residential hosts less accountable then commercial hosts? I know they
> are loaded questions, but it concerns me when we draw these lines in

"Hosts"  aren't accountable.    It  is  administrators of networks
that are accountable.
Information is supposed to still be kept using SWIP or the form  4.2.3.7.5.

The utilization criterion required to properly justify a  /30  is so
trivial,  that the public basically need not be concerned with the
individual user's  information, providing the ISP is not systemically
cooperating in allocating one individual many /30s.

ISPs often do not assign residential users permanent IP space, instead
they get  dynamic allocated an IP.   The paperwork  required to update
POCs would be unreasonable.

Also there are privacy concerns that lead a good ISP to avoid SWIP'ing
residential users if possible -- a residential user often does not
have such a thing as suitable business contact information.

There is an expectation that businesses can always be contacted, a
duty can reasonably be imposed on them to hire or make an existing
contact available, but residential user information might be otherwise
unavailable,  and  can be used to invade personal privacy of real
people.

It is unreasonable to require a residential end user to  'hire out'
someone to serve as a POC for their one host.


There are lines drawn, but   /29 or larger appears to the reasonable place.
It essentially allows  max of 4 user IPs,  or  1 point-to-point link
for a user, without requiring SWIP.

--
-J


From gbonser at seven.com  Mon Feb  1 02:49:55 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 31 Jan 2010 23:49:55 -0800
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001312259g6c074dbvaaf4561761e078e4@mail.gmail.com>
References: <02c701caa054$b71df010$2559d030$@net>
	<4B63865F.7070608@ipinc.net><D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com><3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
	<4B65DB30.6080200@umn.edu><3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com>
	<FE7D4327AABC0448A6281C0AC4445C7C82CC667CF2@Exchange2007.HostedMail.local><997BC128AE961E4A8B880CD7442D9480126F3EFA@NJCHLEXCMB01.cable.comcast.com><3c3e3fca1001312206h4471ae86k3122373318742cb5@mail.gmail.com>
	<997BC128AE961E4A8B880CD7442D9480126F3F03@NJCHLEXCMB01.cable.comcast.com>
	<3c3e3fca1001312259g6c074dbvaaf4561761e078e4@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F74FB@RWC-EX1.corp.seven.com>

> 
> Show me an alternative whose structure has a history of success in
> other applications. I've no love for SWIP. It was a pain in the rump
> back when I was responsible for the operations of an ISP. You might
> recall that my proposal 103 would have eliminated it in IPv6. But to
> accomplish that I had to change the address allocation criteria to
> something invulnerable to fraud.
> 
> Regards,
> Bill Herrin

An alternative is a layer of abstraction where the information you are
given depends on who you are and what you are looking for.  ARIN would
have all of the detailed information but there is no reason that one
should be able to easily trawl whois for a providers block and collect
all their SWIPs.  I just haven't figured out how such a thing would be
implemented yet.

SWIP information is VERY useful to me on a regular basis.  When I am
white listing a partner's space, I can easily find their network
assignments or at least know how big a block they have surrounding the
specific IPs they have given me.  I don't allocate space but discovering
a partner's allocated space is useful to me.  By "partner" I mean
someone who we are providing services for ... a customer.

What I need to do is enter that organization's handle and get back their
network assignments.  I don't need to work through their upstream's
address space to figure out who all their SWIPS are.

I also often need to know who the contact is for a specific IP.  We
might have a problem with someone's POP3 or IMAP server.  That is a
common issue where by default they allow only some small number of
concurrent connections.  But maybe our connections on behalf of their
users exceed that so I need to contact them to increase the number of
connections we are allowed.  Stuff like that happens fairly frequently
and getting their transit provider's contact info is going to make my
life more difficult because there isn't a darned thing the transit
provider is going to be able to do for me except give me the information
I should have already had.

So as a normal day to day requirement, I use the SWIP information to
gauge customer network assignments for traffic policy (at least as a
starting point) and for contact information to get problems fixed.

This proposal would make that more difficult.

What needs to be figured out is a way to give specific information to
specific requests but to deny casual perusal of the database yet in a
way that lends itself to automation and does not cause undue additional
work on the part of ARIN.




From farmer at umn.edu  Mon Feb  1 04:03:33 2010
From: farmer at umn.edu (David Farmer)
Date: Mon, 01 Feb 2010 03:03:33 -0600
Subject: [arin-ppml] Policy Proposal 107: Rework of IPv6 assignment
 criteria - Updated text
In-Reply-To: <4B5AA539.7000404@umn.edu>
References: <4B4FA35F.9070804@arin.net> <4B5AA539.7000404@umn.edu>
Message-ID: <4B6698E5.3060004@umn.edu>

As a result of the staff clarity review the text these has been a number 
for minor changes and the following major changes. Text that were 
basically operational suggestions were moved to a Note at the end of the 
appropriate section.  Additionally, examples of reasonable 
justifications have been added to sections 6.5.8.2.c and 6.5.8.3.b.

Finally, this proposal eliminates the customer count as part of the 
criteria for a community network that was originally in 2008-3.

Feed back please.

----

Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0
1. Policy Proposal Name: Rework of IPv6 assignment criteria
2. Proposal Originator
    a. name: David Farmer
    b. email: farmer at umn.edu
    c. telephone: 612-812-9952
    d. organization: University of Minnesota
3. Proposal Version: 3.0
4. Date: 2/1/2010
5. Proposal type: modify
new, modify, or delete.
6. Policy term: Permanent
temporary, permanent, or renewable.
7. Policy statement:

6.5.8. Initial assignments

6.5.8.1. Initial assignment size

Organizations that meet at least one of the following criteria are 
eligible to receive a minimum assignment of /48.  Requests for larger 
initial assignments, reasonably justified with supporting documentation, 
will be evaluated based on the number of sites and the number of subnets 
needed to support a site.

Organizations may request up to a /48 for each site in their network, 
with the overall allocation rounded up to the next whole prefix only as 
necessary.  A subnet plan demonstrating a utilization of 33,689 or more 
subnets within a site is necessary to justify an additional /48 for any 
individual site, beyond this the 0.94 HD-Ratio metric of the number of 
subnets is used.

All assignments shall be made from distinctly identified prefixes, with 
each assignment receiving a reservation for growth of at least a /44. 
Such reservations are not guaranteed and ARIN, at its discretion, may 
assign them to other organizations at any time.

Note: Organizations with multiple sites are encouraged to consider the 
use /56s for smaller satellite sites.

6.5.8.2. Criteria for initial assignment to Internet connected end-users

Organizations may justify an initial assignment for connecting their own 
network to the IPv6 Internet, with an intent to provide global 
reachability for the assignment within 12 months, and for addressing 
devices directly attached to their network infrastructure, by meeting 
one of the following additional criteria:

a. Having a previously justified IPv4 end-user assignment from ARIN or 
one of its predecessor registries, or;

b. Currently being IPv6 Multihomed or immediately becoming IPv6 
Multihomed and using an assigned valid global AS number, or;

c. By providing a reasonable technical justification indicating why 
other IPv6 addresses from an ISP or other LIR are unsuitable and a plan 
detailing the utilization of sites and subnets for one, two and five 
year periods.

Examples of justifications for why addresses from an ISP or other LIR 
may be unsuitable include, but are not limited to:

? An organization that operates infrastructure critical to life safety 
or the functioning of society, has justification based on the fact that 
renumbering would have a broader than expected impact than simply the 
number of hosts involved.  These would include; hospitals, fire 
fighting, police, emergency response, power or energy distribution, 
water or waste treatment, traffic management and control, etc?
? Regardless of the number of hosts involved, an organization has 
justification if renumbering would affect 1000 or more individuals 
either internal or external to the organization.

6.5.8.3 Criteria for initial assignment to non-connected networks

Organizations may justify an initial assignment for operating their own 
non-connected IPv6 network and for addressing devices directly attached 
to their network infrastructure, by meeting one of the following 
additional criteria:

a. Having a previously justified IPv4 end-users assignment from ARIN or 
one of its predecessor registries, or;

b. By providing a reasonable technical justification indicating why an 
assignment for a non-connected networks is necessary, including the 
intended purpose for the assignment, and describing the network 
infrastructure the assignment will be used to support.  Justification 
must include why Unique Local IPv6 Unicast Addresses (ULA) is unsuitable 
and a plan detailing the utilization of sites and subnets for one, two 
and five year periods.

Examples of justifications for why ULA may be unsuitable include, but 
are not limited to:

? The need for authoritative delegation of reverse DNS, including 
documentation way this is necessary.
? The need for documented uniqueness, beyond the statistical uniqueness 
provided by ULA, including documentation way this is necessary.
? A documented need to connect with other networks connected to or not 
connected to the Internet

NOTE: Organizations are encouraged to consider the use of ULA, for 
non-connected networks, see RFC 4193 for details.

6.5.8.4 Criteria for initial assignment to Community Networks

Organizations may justify an initial assignment for operating a 
Community Network by documenting that they meet the criteria specified 
in section 2.11.  A Community Network is considered a single site and a 
larger initial assignment may only be justified based on the number of 
subnets necessary to serve the community in question.

6.5.9. Subsequent assignments

Subsequent assignments may be made when the need for additional sites or 
subnets are justified with reasonable supporting documentation.  When 
possible, subsequent assignments will be made from an adjacent address 
block.

Organizations may request up to a /48 for each site in their network, 
with the overall allocation rounded up to the next whole prefix only as 
necessary.  A subnet plan demonstrating a utilization of 33,689 or more 
subnets within a site is necessary to justify an additional /48 for any 
individual site, beyond this the 0.94 HD-Ratio metric of the number of 
subnets is used.

Note: Organizations with multiple sites are encouraged to consider the 
use /56s for smaller satellite sites.

Delete current 6.5.9 Community Network Assignments as it is incorporated 
in 6.5.8.4.

8. Rationale:

This proposal provides a complete rework of the IPv6 end-user assignment 
criteria, removing the dependency on IPv4 policy, while maintaining many 
of the basic concepts contained in the current policies.  The order of 
the subsections of 6.5.8 was rearranged moving the initial assignment 
size to 6.5.8.1 and subsequent assignments to 6.5.9.  This will 
facilitate adding future criteria without additional renumbering of 
current policies.

The initial assignment criteria include the following general concepts:

? When Internet connectivity is use to justify resources it is implied 
the resources should be advertised to the Internet, within some 
reasonable time frame after they are received.
? IPv4 resources may be use to justify the need for IPv6 resources.
? Internet multihoming is sufficient justification for an end-user 
assignment in and of itself.
? Other Internet connected end-users must justify why an ISP or LIR 
assignment is not sufficient for their needs.
? Non-connected networks must describe the purpose and network 
infrastructure the assignment will be supporting, including why ULA is 
not sufficient for their needs.
? Organizations with multiple sites are allowed to request a /48 for 
each site, with a suggestion to use /56s for smaller sites.
? While HD-Ratio is not completely eliminated it really only applies to 
situations that an individual site of an organization needs more that a /48.
? Community networks are assumed to justify an assignment in and of 
themselves, but they should be considered a single site, otherwise they 
should get an ISP allocation.


9. Timetable for implementation:  Immediate

END OF TEMPLATE


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


From bicknell at ufp.org  Mon Feb  1 09:15:22 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 1 Feb 2010 06:15:22 -0800
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
	Confidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001312032raec9c5ek7478e2444c584c25@mail.gmail.com>
References: <D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>
	<4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu>
	<4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
	<4B65DB30.6080200@umn.edu>
	<3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com>
	<4B662557.5000202@umn.edu>
	<3c3e3fca1001312032raec9c5ek7478e2444c584c25@mail.gmail.com>
Message-ID: <20100201141522.GA91915@ussenterprise.ufp.org>

In a message written on Sun, Jan 31, 2010 at 11:32:10PM -0500, William Herrin wrote:
> I'm not trying to single out anyone, but frankly I'm frustrated by the
> AC's collective behavior this past year and I doubt I'm the only one.
> I'd be far more sympathetic if all the quiet work outside the public
> eye resulted more and better advice for proposal authors from among
> the general public, and less suppression of proposals not written by
> members of the AC itself.

I won't comment on the merits of your argument, but I will comment
on one small aspect, "the quiet work outside the public eye."

I would favor having AC meetings "open to the public".  To be clear,
the public would be in listen only mode, they could not participate
in any way, shape, or form.

This would allow interesting parties (including proposal authors)
to know the exact discussion around their proposal in real time
rather than getting edited minutes a month or more later.  This should
foster much faster turn around of policy proposals.  Additionally,
it would give the public more insight into what the AC members are
doing, which might help them choose who to elect.

Sunshine can fix either of the problems here; if the AC is run amock
the public will see it, and if in fact they are doing a good job,
the public will also see that.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100201/b5563779/attachment.sig>

From michael.dillon at bt.com  Mon Feb  1 09:47:45 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Feb 2010 14:47:45 -0000
Subject: [arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4
	Requests
In-Reply-To: <6B297B2D-4DB6-4D38-A5A6-AD75596DC7BF@delong.com>
Message-ID: <28E139F46D45AF49A31950F88C49745804FF8903@E03MVZ2-UKDY.domain1.systemhost.net>

 
> > I suggest that it is not ARIN's business to decide what 
> better serves 
> > the community, since ARIN is not lord and master of the 
> community, but 
> > its servant. ARIN should only try to be reasonably fair, not make 
> > heroic efforts whose outcome could be worse, and whose outcome is 
> > certainly unknowable.
> > 
> ARIN is the community's steward over the address space and it 
> is absolutely ARIN's role to balance the needs of the various 
> stakeholders in the community and develop policies that meet 
> the communities consensus of what best meets the community's 
> need with the application of sound judgment by those elected 
> by the community to that consensus.

That is a very paternalistic attitude. ARIN is not the boss of
us. It is only a forum in which the stakeholders themselves can
balance their needs. If the stakeholders fail to come to agreement
then ARIN should not act independently to impose a solution. ARIN
is fundamentally a bottom-up creature of self-regulation among the
stakeholders.

> The idea of fair depends a great deal on perspective in the 
> case in question. If you are the guy asking for a /14, then, 
> fair is to give you all the pieces necessary for you to have 
> address space equivalent to the /14. If your the guy who put 
> in the request for a /24 30 seconds after the guy who asked 
> for the /14, your idea of fair might be a bit different.

ARIN simply does not have the information to know which outcome
is more fair. It is not ARIN's job to be judge and jury over the
last few crumbs. There is a bigger picture that does not involve
the aberrations of squabbles over the last few crumbs of IPv4 adress
space.

> > Far better for them to get down to the rag market and 
> haggle over the 
> > price of an old silk dress that could be reworked into a silk purse.
> > 
> Who are you to decide which is better for them? Why should 
> ARIN decide on their behalf?

ARIN is deciding on ARIN's behalf that it does not want to sit in
the middle and arbitrate squabbles over the last few crumbs. ARIN's
main job is not to hand out address blocks but to evaluate applications
and decide how many IP addresses are justified. Then, if there are some
on the shelf, ARIN hands out an appropriately sized block. When the
shelf
becomes bare, ARIN should resist expanding it's activities, and stick to
evaluating applications, and recording records.

> That's one strategy option. Not necessarily the only strategy.
> Clearly it's the one you think is best, but, like LDAP, it is 
> not necessarily the best answer for everyone in every case.

No, I do not think hunting for transfer blocks is best since I don't
believe that many people will e successful. The best strategy is to
deploy IPv6 and completely avoid the runout mess.

> Thought exercise: Under your proposed method, where does one 
> draw the line between DoS and legitimate efforts to have your 
> request hit the lottery? How many lottery tickets should 
> someone be allowed to request per what unit of time?

One.
The fact is that ARIN should not play this game. Today, you
only should apply for IP addresses once per year, or more.
There is no good reason for that basic model to change. Yes,
we may shorten time periods so that everyone has to apply once
per 3 months, but once your application is approved, we should
not create reasons to encourage more applications. If you didn't
get your full justified allocation, then the mechanisms for
handing over addresses need to be handled in an orderly fashion
so that people are not encouraged to bombard ARIN's systems in
the hopes of winning a lottery.

--Michael Dillon



From michael.dillon at bt.com  Mon Feb  1 10:14:17 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Feb 2010 15:14:17 -0000
Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F74D3@RWC-EX1.corp.seven.com>
Message-ID: <28E139F46D45AF49A31950F88C49745804FF89AC@E03MVZ2-UKDY.domain1.systemhost.net>

 
> Exactly.  Unless the provider is doing 100% managed services 
> for all hosts in that net block, calling the provider is 
> usually a waste of time.  What if that block of IP addresses 
> is actually in use in someone else's colo or back at the 
> customer's office?  What is the provider going to do except 
> (hopefully) give you the information you should have already 
> been able to get.  And what if it is midnight local on a 
> weekend?  Is the person on duty going to know that they are 
> even allowed to give out the customer contact info?
> 
> There are so many problems with this at so many levels for no 
> other reason than to protect someone's customer list and 
> absolutely no benefit to any other segment of the community.

Fact is that to solve the kind of issues that are under discussion
all you need is a phone number. You don't need to know the customer's
name or their physical location.

--Michael Dillon



From michael.dillon at bt.com  Mon Feb  1 10:41:05 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Feb 2010 15:41:05 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	CustomerConfidentiality - Time Sensitive
In-Reply-To: <66FAFE30-CC74-48CC-A4F2-4B62CD57B65C@delong.com>
Message-ID: <28E139F46D45AF49A31950F88C49745804FF8A35@E03MVZ2-UKDY.domain1.systemhost.net>

 
> So you run their antivirus software and clean their machines 
> if they get infected? If it's that level of managed service, 
> then, arguably their machines are part of your infrastructure 
> from an administrative perspective. If you are the end-user, 
> you don't need to swip the space as a customer assignment.
> If someone else administers the machines, then, that someone 
> else should be on the SWIP.

And what happens when that "someone else"'s 10th grade English
class is interrupted by your phone call about a possible botnet
infection on his uncle's server?

Let's be realistic here. This is not the Internet of 1990 where
everything was in a big building owned by a big organization that
was paying big bucks for the underlying IT infrastructure that
was connected to the Internet.

--Michael Dillon


From michael.dillon at bt.com  Mon Feb  1 10:43:59 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Feb 2010 15:43:59 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	CustomerConfidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C49745804FF8A3F@E03MVZ2-UKDY.domain1.systemhost.net>

> I'm not so concerned about you but what about the the half of 
> the AC who can't even find time to participate on PPML?

It's their job to do the AC stuff, not spend time posting
on PPML trying to influence the AC stuff. Most of the stakeholders
in ARIN have no presence at all on PPML, but they still have
representation on the AC.

--Michael Dillon


From michael.dillon at bt.com  Mon Feb  1 11:01:30 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Feb 2010 16:01:30 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	CustomerConfidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001312203i2c5141depf3d4e6d13213c1d6@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C49745804FF8A9B@E03MVZ2-UKDY.domain1.systemhost.net>

> The AC was elected first and foremost to be shepherds of the 
> bottom-up public-originated policy development process. 

Uhhh... the bylaws say this:

Function. The Advisory Council shall act in an advisory capacity to the
Board of Trustees on matters as the Board of Trustees may, from time to
time, request involving Internet numbering resource policies and related
matters. The President of ARIN shall be the primary point of contact
between the Advisory Council and the Board of Trustees. 

> Welcome to corruption 101. It starts with a conflict of 
> interest and a sense of entitlement born of expertise and 
> honest, earnest work. From there it's one short slide after 
> another down the long and slippery slope.

Uhh... Wikipedia has this to say about this classical informal fallacy:
<http://en.wikipedia.org/wiki/Slippery_slope>

--Michael Dillon

P.S. ARIN is what it is, not what you or anyone else imagine it to be.


From marty at akamai.com  Mon Feb  1 11:03:11 2010
From: marty at akamai.com (Martin Hannigan)
Date: Mon, 1 Feb 2010 11:03:11 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
	Confidentiality - Time Sensitive
In-Reply-To: <20100201141522.GA91915@ussenterprise.ufp.org>
References: <D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>
	<4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu>
	<4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
	<4B65DB30.6080200@umn.edu>
	<3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com>
	<4B662557.5000202@umn.edu>
	<3c3e3fca1001312032raec9c5ek7478e2444c584c25@mail.gmail.com>
	<20100201141522.GA91915@ussenterprise.ufp.org>
Message-ID: <95A6D1C0-FB8F-43D9-B24C-58ACF9C50225@akamai.com>


On Feb 1, 2010, at 9:15 AM, Leo Bicknell wrote:

> In a message written on Sun, Jan 31, 2010 at 11:32:10PM -0500,  
> William Herrin wrote:
>> I'm not trying to single out anyone, but frankly I'm frustrated by  
>> the
>> AC's collective behavior this past year and I doubt I'm the only one.
>> I'd be far more sympathetic if all the quiet work outside the public
>> eye resulted more and better advice for proposal authors from among
>> the general public, and less suppression of proposals not written by
>> members of the AC itself.

[ clip ]


>
> I won't comment on the merits of your argument, but I will comment
> on one small aspect, "the quiet work outside the public eye."
>
> I would favor having AC meetings "open to the public".  To be clear,
> the public would be in listen only mode, they could not participate
> in any way, shape, or form.

+1




From michael.dillon at bt.com  Mon Feb  1 11:06:32 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Feb 2010 16:06:32 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001312206h4471ae86k3122373318742cb5@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C49745804FF8AB3@E03MVZ2-UKDY.domain1.systemhost.net>

> Respectfully, the primary reason for SWIP is and has always 
> been public accountability.

I dispute that the primary reason for SWIP has always been
public accountability. I will agree that this was the original
reason for SWIP back when the ARPANET was spending public monies
which had to be accounted for. But since that time, the ARPANET
has become the Internet, and the Internet has become
commercialised to the extent that "accounting for public monies"
is not a concern for us any more. That would still be a 
concern for the various organizations on the Internet who spend
public monies, of course, but the core infrastructure is 
thoroughly privatised at this point.

We really need to make a clean break with the past and ask ourselves
what achievable public benefits can be served by a whois directory
and stop moaning and wishing about how it could have been if only
we had not evolved to the point where we find ourselves today.

--Michael Dillon





From michael.dillon at bt.com  Mon Feb  1 11:16:10 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Feb 2010 16:16:10 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001312259g6c074dbvaaf4561761e078e4@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C49745804FF8AE1@E03MVZ2-UKDY.domain1.systemhost.net>

 
> SWIP isn't perfect. It isn't even particularly good. But as 
> long as we're doing needs-based allocation, SWIP more or less 
> gets the accountability job done.
> 
> Show me an alternative whose structure has a history of 
> success in other applications.

CSV files work fine here. Just dump all the assignment info right
down to the last /32 into a CSV file and attach it to an email to
the ARIN hostmaster. We've used this to justify several /15 or /16
allocations. The point is that ARIN evaluates your usage, not the
entries in its SWIP database, which may be less than accurate 
due to the /29 rule among other things. A dump from the operational
database tends to be the most accurate.

SWIP has nothing to do with justifying a needs based allocation.
The public whois directory has nothing to do with any internal
ARIN activities.

--Michael Dillon





From michael.dillon at bt.com  Mon Feb  1 11:22:24 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Feb 2010 16:22:24 -0000
Subject: [arin-ppml] Petition Underway - Policy
	Proposal95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F74FB@RWC-EX1.corp.seven.com>
Message-ID: <28E139F46D45AF49A31950F88C49745804FF8B03@E03MVZ2-UKDY.domain1.systemhost.net>

> I just haven't figured out how such a thing 
> would be implemented yet.

ARIN has. It's called a separate data store. The hostmasters
currently have access, under NDA, to lots of confidential
information that even their own supervisors have no right
to access. This is the way that it should be.

> SWIP information is VERY useful to me on a regular basis.  
> When I am white listing a partner's space, I can easily find 
> their network assignments or at least know how big a block 
> they have surrounding the specific IPs they have given me.  I 
> don't allocate space but discovering a partner's allocated 
> space is useful to me.  By "partner" I mean someone who we 
> are providing services for ... a customer.

You could also phone them and ask for this.

> I also often need to know who the contact is for a specific 
> IP.  We might have a problem with someone's POP3 or IMAP 
> server. 

Now you have justified publishing some phone numbers and email
addresses in WHOIS. Not names, addresses or anything else.


> What needs to be figured out is a way to give specific 
> information to specific requests but to deny casual perusal 
> of the database yet in a way that lends itself to automation 
> and does not cause undue additional work on the part of ARIN.

Don't record anything that will not be published in the whois
directory, and most especially, do not record any information
that does not have a defined and agreed upon public use.

--Michael Dillon


From kkargel at polartel.com  Mon Feb  1 12:29:38 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 1 Feb 2010 11:29:38 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	Customer	Confidentiality - Time Sensitive
In-Reply-To: <065001caa14b$9a626800$cf273800$@net>
References: <02c701caa054$b71df010$2559d030$@net>	<4B62098C.60606@arin.net>
	<D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>	<4B636B12.6090603@ipinc.net>
	<05a901caa13b$4cd154d0$e673fe70$@net>	<4B637523.1070708@ipinc.net>
	<05da01caa140$e111f5f0$a335e1d0$@net>	<4B6384A4.4040304@ipinc.net>
	<065001caa14b$9a626800$cf273800$@net>
Message-ID: <8695009A81378E48879980039EEDAD28876D3F96@MAIL1.polartel.local>

> Not all of them.  I have a customer, {redacted}.  It's a photography
> studio run by two people.  They colo a server with me and have a /29. I
> have
> to SWIP their information even though they are the last people that should
> be called if there's an issue and would just end up calling me anyway.
> 

In this case whoever takes care of their networks is their agent and should be listed directly as their tech and abuse PoC's.  Or am I wrong?




From gbonser at seven.com  Mon Feb  1 13:26:12 2010
From: gbonser at seven.com (George Bonser)
Date: Mon, 1 Feb 2010 10:26:12 -0800
Subject: [arin-ppml] Petition Underway -
	PolicyProposal95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <28E139F46D45AF49A31950F88C49745804FF8B03@E03MVZ2-UKDY.domain1.systemhost.net>
References: <5A6D953473350C4B9995546AFE9939EE081F74FB@RWC-EX1.corp.seven.com>
	<28E139F46D45AF49A31950F88C49745804FF8B03@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F750E@RWC-EX1.corp.seven.com>

> 
> You could also phone them and ask for this.
> 
> > I also often need to know who the contact is for a specific
> > IP.  We might have a problem with someone's POP3 or IMAP
> > server.
> 
> Now you have justified publishing some phone numbers and email
> addresses in WHOIS. Not names, addresses or anything else.

Provided I can use that phone number to get a list of all their SWIPs so
I can check to see if I have also been having trouble with connections
to servers that might be in other subnets, or if I have been blocking
connection attempts from their other subnets, then fine.

In other words, I need to know:

Who owns an IP address that I am having trouble with.
What other network assignments do they have so I can "fix" problems that
might be happening with the same operator in other network segments.

Just having a phone number is going to be a pain in the rear end.  Who
am I going to be talking to?  Is it someone with barely a clue who has
simply leased a handful of servers from some rental outfit in a colo?
Or is it a well established telecom?  With just a phone number, that is
going to be hard to tell.  My first question is going to be "who are
you"? Followed by "what other network assignments do you have so we can
fix this problem in a more global sense?".

WHOIS currently gives me this information.

What I do NOT need is the ability to "walk" through an upstream transit
provider's SWIPS to find them all out. But I DO need as much information
as I can get for a specific end user to include who they are, who their
contact is, and what other networks they have assigned to them.




From kkargel at polartel.com  Mon Feb  1 13:34:23 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 1 Feb 2010 12:34:23 -0600
Subject: [arin-ppml] Petition Underway
	-	PolicyProposal95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F750E@RWC-EX1.corp.seven.com>
References: <5A6D953473350C4B9995546AFE9939EE081F74FB@RWC-EX1.corp.seven.com>
	<28E139F46D45AF49A31950F88C49745804FF8B03@E03MVZ2-UKDY.domain1.systemhost.net>
	<5A6D953473350C4B9995546AFE9939EE081F750E@RWC-EX1.corp.seven.com>
Message-ID: <8695009A81378E48879980039EEDAD28876D3F9D@MAIL1.polartel.local>

> 
> What I do NOT need is the ability to "walk" through an upstream transit
> provider's SWIPS to find them all out. But I DO need as much information
> as I can get for a specific end user to include who they are, who their
> contact is, and what other networks they have assigned to them.
> 
> 

So are you suggesting that we limit the '>' operator in the whois search when the customer is an ISP or greater?

I am not saying whether that would be good or bad, just asking for clarification.


From gbonser at seven.com  Mon Feb  1 13:43:19 2010
From: gbonser at seven.com (George Bonser)
Date: Mon, 1 Feb 2010 10:43:19 -0800
Subject: [arin-ppml] Petition Underway
	-PolicyProposal95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <8695009A81378E48879980039EEDAD28876D3F9D@MAIL1.polartel.local>
References: <5A6D953473350C4B9995546AFE9939EE081F74FB@RWC-EX1.corp.seven.com><28E139F46D45AF49A31950F88C49745804FF8B03@E03MVZ2-UKDY.domain1.systemhost.net>
	<5A6D953473350C4B9995546AFE9939EE081F750E@RWC-EX1.corp.seven.com>
	<8695009A81378E48879980039EEDAD28876D3F9D@MAIL1.polartel.local>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7512@RWC-EX1.corp.seven.com>

> So are you suggesting that we limit the '>' operator in the whois
> search when the customer is an ISP or greater?
> 
> I am not saying whether that would be good or bad, just asking for
> clarification.

That might be a very reasonable answer.  I have no need to know who all
of a provider's netblocks downstream assignments belong to.  Knowing at
the very highest level what a provider's aggregate block assignment is
might be helpful in some cases when I am troubleshooting routing issues
(hmm, I seem to be having a routing loop whenever I am trying to
communicate with a user in zippy-super-clueful-isp's address space.) or
some such.

But yeah, removing that option would probably not impact my operations.
I can't recall when I have ever needed to use it for normal operations
for a provider net block.



From michael.dillon at bt.com  Mon Feb  1 14:46:20 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 1 Feb 2010 19:46:20 -0000
Subject: [arin-ppml] Petition Underway -
	PolicyProposal95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F750E@RWC-EX1.corp.seven.com>
Message-ID: <28E139F46D45AF49A31950F88C49745804FF8C6D@E03MVZ2-UKDY.domain1.systemhost.net>

 
> What I do NOT need is the ability to "walk" through an 
> upstream transit provider's SWIPS to find them all out. But I 
> DO need as much information as I can get for a specific end 
> user to include who they are, who their contact is, and what 
> other networks they have assigned to them.

So, what I am hearing from you is that you do not want a 
whois directory, you want an application where you can
put in an IP address and the app will give you a page with
all the information that ARIN has related to the owners
of that address including other blocks that they use, 
their upstream's contact info, the upstream of their upstream's
contact info and so on.

The ARIN suggestion box is over that way:
<https://www.arin.net/app/suggestion/>

I don't like to use a sledge hammer to solve a problem that
requires a screwdriver.

--Michael Dillon


From gbonser at seven.com  Mon Feb  1 15:51:19 2010
From: gbonser at seven.com (George Bonser)
Date: Mon, 1 Feb 2010 12:51:19 -0800
Subject: [arin-ppml] Petition Underway
	-PolicyProposal95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <28E139F46D45AF49A31950F88C49745804FF8C6D@E03MVZ2-UKDY.domain1.systemhost.net>
References: <5A6D953473350C4B9995546AFE9939EE081F750E@RWC-EX1.corp.seven.com>
	<28E139F46D45AF49A31950F88C49745804FF8C6D@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7522@RWC-EX1.corp.seven.com>


> So, what I am hearing from you is that you do not want a
> whois directory, you want an application where you can
> put in an IP address and the app will give you a page with
> all the information that ARIN has related to the owners
> of that address including other blocks that they use,
> their upstream's contact info, the upstream of their upstream's
> contact info and so on.

No. What you are hearing me say is that things work just fine the way
they are right now with whois.  I can get all the information I
currently need from whois and Proposal 95 would break that.

The only benefit Proposal 95 offers is protection of customer lists. 

I could support a proposal that protects the customer lists while also
protects my being able to do what I need to do.

Blocking of the > operator for that one type of query would not impact
my ability to get my work done and would make it harder for sales drones
to walk provider address space.




From mueller at syr.edu  Mon Feb  1 16:56:05 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 1 Feb 2010 16:56:05 -0500
Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality
In-Reply-To: <3c3e3fca1001290836l1775d9c5ta0fbfba5d1231228@mail.gmail.com>
References: <02c701caa054$b71df010$2559d030$@net>
	<8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local>
	<4B621114.3050808@ipinc.net> <4B6212D0.4000404@gmail.com>
	<38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com>
	<ED2FBBE5-A7C6-4095-8080-31F1B58E9F2A@delong.com>
	<38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com>
	<3c3e3fca1001290836l1775d9c5ta0fbfba5d1231228@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB37F5@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin
> Sent: Friday, January 29, 2010 11:36 AM
> 
> It's a fact that transparency requires reporting sufficient for
> members of the general public to audit process should they desire to
> do so.

This is not a fact but a very complex (possibly justified) intepretation, the validity of which rests almost entirely on how you define "reporting," and "sufficient." 

> It's a fact that ISP address allocations are strictly dependent on
> downstream assignments.
> 
> It's a fact that an audit can't positively confirm the accuracy of an
> end-user assignment without checking with the end-user.

But this fact does not necessarily imply a generalized capability of any member of the public to check with the end user. There are other mechanisms of doing audits. 

> It's thus a conclusion resting solely on fact that transparency in the
> allocation process requires members of the general public to be able
> to contact the end-users to whom portions of the finite resource are
> assigned.

Here you've equated the ability to "audit process" with the ability of any member of the general public, for any reason, at any time, to directly contact an end user. Not a logically valid equation, as far as I can tell. 

By the way, the finitness of the resource is completely irrelevant to this discussion. Printer ink is scarce, too, but that doesn't give you the right to demand that OfficeMax give you the information needed to ring me up whenever I replace the cartridge on my HP 1012.

> The only way you get rid of this, as a matter of fact, is by unifying
> the allocation and assignment policies and moving to an assignment
> criteria that's not based on downstream assignment count for
> justification.

That's an interesting thought. Please keep moving in that direction. 

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  Mon Feb  1 17:05:16 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 1 Feb 2010 17:05:16 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	Customer	Confidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001312203i2c5141depf3d4e6d13213c1d6@mail.gmail.com>
References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net>
	<D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>
	<4B636B12.6090603@ipinc.net> 	<4B638058.7010500@umn.edu>
	<4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
	<E35CCC98-234B-479F-835F-D7AD97CA2316@delong.com>
	<3c3e3fca1001312203i2c5141depf3d4e6d13213c1d6@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB37F6@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 William Herrin
> 
> >        +       Detrimental to the ARIN community
> 
> Out of order. This does not belong in your evaluation prior to the
> board-recommendation phase. 

+1



From mueller at syr.edu  Mon Feb  1 17:07:17 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 1 Feb 2010 17:07:17 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	Customer	Confidentiality - Time Sensitive
In-Reply-To: <20100201141522.GA91915@ussenterprise.ufp.org>
References: <D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>
	<4B636B12.6090603@ipinc.net> <4B638058.7010500@umn.edu>
	<4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
	<4B65DB30.6080200@umn.edu>
	<3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com>
	<4B662557.5000202@umn.edu>
	<3c3e3fca1001312032raec9c5ek7478e2444c584c25@mail.gmail.com>
	<20100201141522.GA91915@ussenterprise.ufp.org>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB37F7@SUEX07-MBX-04.ad.syr.edu>

Great proposal, Leo! 

> -----Original Message-----
> I would favor having AC meetings "open to the public".  To be clear,
> the public would be in listen only mode, they could not participate
> in any way, shape, or form.
> 
> This would allow interesting parties (including proposal authors)
> to know the exact discussion around their proposal in real time
> rather than getting edited minutes a month or more later.  This should
> foster much faster turn around of policy proposals.  Additionally,
> it would give the public more insight into what the AC members are
> doing, which might help them choose who to elect.
> 
> Sunshine can fix either of the problems here; if the AC is run amock
> the public will see it, and if in fact they are doing a good job,
> the public will also see that.


From mueller at syr.edu  Mon Feb  1 16:33:01 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 1 Feb 2010 16:33:01 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
 Confidentiality - Time Sensitive
In-Reply-To: <05a901caa13b$4cd154d0$e673fe70$@net>
References: <02c701caa054$b71df010$2559d030$@net>	<4B62098C.60606@arin.net>
	<D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>	<4B636B12.6090603@ipinc.net>
	<05a901caa13b$4cd154d0$e673fe70$@net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB37F4@SUEX07-MBX-04.ad.syr.edu>

I support the petition to give Policy Proposal 95 due consideration. 

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

> 
> 
> John Curran wrote:
> > ARIN Community - 
> > 
> > I am reposting this Petition Announcement under a distinct subject 
> > line as otherwise not all mailing list participants may recognize 
> > that this process is underway.  This is neither a statement for or 
> > against the petition, and all statements of support posted under 
> > the original thread or this one will be counted in the total.
> > 
> > /John
> > 
> > John Curran
> > President and CEO
> > ARIN
> > 
> > On Jan 28, 2010, at 5:02 PM, Member Services wrote:
> > 
> >> With the message below a petition has started regarding the ARIN
> >> Advisory Council's decision to abandon Proposal 95: Customer
> >> Confidentiality. ARIN staff posted on 21 January 2010 to 
> PPML that the
> >> ARIN Advisory Council (AC) had decided to abandon the proposal.
> >>
> >> If successful, this petition will change Proposal 95 into 
> a Draft Policy
> >> which will be published for discussion and review by the 
> community on
> >> the PPML and at the Public Policy Meeting in April. If the petition
> >> fails, the proposal will be closed.
> >>
> >> For this petition to be successful, it will need 
> statements of support
> >> from at least 10 different people from 10 different 
> organizations. If
> >> you wish to support this petition, post a statement of 
> support to PPML
> >> on this thread. Point of contact information is required, 
> either to the
> >> entire PPML or with a follow up post to petition at arin.net 
> with full POC
> >> information (name, organization, street address, email, phone).
> >>
> >> The duration of the petition is five business days; it 
> will end on 4
> >> February 2010. ARIN staff will post the result of the 
> petition to PPML.
> >>
> >> For more information on starting and participating in 
> petitions, see PDP
> >> Petitions at: https://www.arin.net/policy/pdp_petitions.html
> >>
> >> The proposal text is below and 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)
> >>
> >> #####
> >>
> >> Aaron Wendel wrote:
> >>> I do not feel the AC should abandon Policy Proposal 95: Customer
> >>> Confidentiality. I formally petition to move the 
> following text forward
> for
> >>> discussion on the list and at the next Public Policy 
> Meeting. I would
> >>> appreciate it if anyone this policy applies to would 
> support moving this
> >>> proposal forward by posting statements in support of the 
> petition to
> this
> >>> list.
> >>>
> >>> 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
> >>>
> >>> Aaron Wendel Wholesale Internet, Inc. 324 E. 11th St.  Suite 1000
> >>> Kansas City, MO 64106
> >>> 816-256-3031
> >>>
> >>> _______________________________________________
> >>> 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.
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.733 / Virus Database: 271.1.1/2648 - Release 
> Date: 01/29/10
> 03:08:00
> 
> _______________________________________________
> 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 steve at ibctech.ca  Mon Feb  1 20:29:59 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Mon, 01 Feb 2010 20:29:59 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal
 95:	CustomerConfidentiality - Time Sensitive
In-Reply-To: <28E139F46D45AF49A31950F88C49745804FF8A35@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C49745804FF8A35@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4B678017.7060300@ibctech.ca>

michael.dillon at bt.com wrote:
>  
>> So you run their antivirus software and clean their machines 
>> if they get infected? If it's that level of managed service, 
>> then, arguably their machines are part of your infrastructure 
>> from an administrative perspective. If you are the end-user, 
>> you don't need to swip the space as a customer assignment.
>> If someone else administers the machines, then, that someone 
>> else should be on the SWIP.
> 
> And what happens when that "someone else"'s 10th grade English
> class is interrupted by your phone call about a possible botnet
> infection on his uncle's server?

...then the IP was SWIP'ed to a school, and the uncle shouldn't have a
server within the school network IP allocation.

If he does, then the school PoC is responsible, unless the school
assigned a /29 to the uncle.

> Let's be realistic here. This is not the Internet of 1990 where
> everything was in a big building owned by a big organization that
> was paying big bucks for the underlying IT infrastructure that
> was connected to the Internet.

...I want to know how to get a hold of the person/people who are
managing the machines that are addressed.

If you house machines within someone else's ARIN space that requires a
/29 or larger, your info should be on it. If 'uncle's' information is on
the SWIP, then he should be responsible, disruption to his English class
is irrelevant.

Steve


From steve at ibctech.ca  Mon Feb  1 20:34:20 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Mon, 01 Feb 2010 20:34:20 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
 Confidentiality - Time Sensitive
In-Reply-To: <4B636B12.6090603@ipinc.net>
References: <02c701caa054$b71df010$2559d030$@net>
	<4B62098C.60606@arin.net>	<D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>
	<4B636B12.6090603@ipinc.net>
Message-ID: <4B67811C.1040208@ibctech.ca>

Ted Mittelstaedt wrote:
> 
>   So far I count 12 solid supporters of the petition.
> 
> They are:
> 
> jay at handynetworks.com   // Handy Networks LLC
> joe at joesdatacenter.com  //  Joe's Datacenter, LLC
> network at dimenoc.com  //DimeNoc  AS33182
> bicknell at ufp.org   - bicknell at ufp.org - CCIE 3440
> spamfree at wansecurity.com  Robert Smith, CISSP  WANSecurity, Inc.
> dsd at carpathiahost.com   Carpathia Hosting, Inc
> thorsten.ziegler at 1and1.com  1&1 Internet, AS8560
> lar at mwtcorp.net  ARIN ORG: CBS-129
> bill at herrin.us  AS 11875
> stephen.r.middleton at verizon.com  Verizon Services Operations
> raul at datavo.com  Datavo / AS26773
> tony at lava.net  LavaNet
> 
> 
> The following people stated they supported the policy but they
> didn't state that they supported the petition
> 
> todd at kcix.net
> 
> The following people supported the petition but didn't identify
> who they represent:
> 
> rudi.daniel at gmail.com
> marty at akamai.com
> rob at lagniappeinternet.com
> 
> Naturally the AC will need to make the "official" determination
> but it looks like we will be discussing this.

fwiw, I officially support the petition, and the process. We'll deal
with the potential policy once it is re-introduced.

Steve Bertrand, AS14270, eagle.ca Internet Services, SBE96-ARIN.

Steve


From steve at ibctech.ca  Mon Feb  1 20:44:56 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Mon, 01 Feb 2010 20:44:56 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
 Confidentiality - Time Sensitive
In-Reply-To: <D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
References: <02c701caa054$b71df010$2559d030$@net>	<4B62098C.60606@arin.net>	<D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>	<4B636B12.6090603@ipinc.net>
	<4B638058.7010500@umn.edu>	<4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
Message-ID: <4B678398.3050106@ibctech.ca>

Owen DeLong wrote:
> 
> On Jan 29, 2010, at 5:07 PM, Ted Mittelstaedt wrote:

>> Of course it did.  The success of the petition means one thing - that
>> the AC made a bad decision.
>>
> I disagree.  I think the AC made the absolutely correct decision and that
> the petition means that 10 or more members of the community disagree
> with the AC's decision sufficiently strongly that they successfully
> petitioned
> it. That's how the process is supposed to work.  There's nothing wrong
> with it.
> 
> I think in the end, it is likely that the community as a whole will uphold
> the AC's decision, but, in this case, there's enough dissent that it merits
> consideration of the full community and that's what is happening.
>>
>> My only observation on this is that I think if the AC had been
>> more specific (and long) on the explanation of why it was dropped
>> that people might not have supported the petition.
>>
> Perhaps. I guess there's a question of resource allocation there in terms
> of how much AC time should be spent justifying a decision to abandon
> vs. focusing on things still on the docket. I'm not saying we did the
> absolutely correct thing in this case, merely that there is a tradeoff to
> be considered that isn't part of your previous paragraph.

Out of curiosity, is the AC able to focus on the other items on the
docket with all of this going on?

I mean... this is the first real test. What kind of impact and/or
disruption has this caused, if any? It may be worth documenting.

>From early experience, how is this conundrum affecting the normal policy
process from progressing normally? Is it having an effect?

Steve


From steve at ibctech.ca  Mon Feb  1 23:19:37 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Mon, 01 Feb 2010 23:19:37 -0500
Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality
In-Reply-To: <064a01caa14a$9a8f12c0$cfad3840$@net>
References: <02c701caa054$b71df010$2559d030$@net><8695009A81378E48879980039EEDAD28876D3F77@MAIL1.polartel.local><4B621114.3050808@ipinc.net>	<4B6212D0.4000404@gmail.com><38dd4e411001281504r2b805200w10ed8534cd615670@mail.gmail.com><ED2FBBE5-A7C6-4095-8080-31F1B58E9F2A@delong.com><38dd4e411001290001i3ddf5004u6e9a4ee0c25bfecf@mail.gmail.com>	<6eb799ab1001291617v486e484jfe3fb2dcbdbd2151@mail.gmail.com>	<5A6D953473350C4B9995546AFE9939EE081F74D3@RWC-EX1.corp.seven.com>	<060b01caa144$66614820$3323d860$@net>	<5A6D953473350C4B9995546AFE9939EE081F74E2@RWC-EX1.corp.seven.com>
	<064a01caa14a$9a8f12c0$cfad3840$@net>
Message-ID: <4B67A7D9.6090105@ibctech.ca>

Aaron Wendel wrote:
> Ok.  How would you change the wording to reflect that?

...if you are delegated a /29 or larger, your info is in the SWIP. If
the 'operator' of the systems that are assigned the addresses within
that /29 are that of the assigning ISP, then the ISP's contact
information will be placed *along side* that of the current address holder.

If someone requires information on the aggregate address holder, they
will use WHOIS to find that information.

Steve


From michael.dillon at bt.com  Tue Feb  2 06:26:05 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 2 Feb 2010 11:26:05 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:	CustomerConfidentiality - Time Sensitive
In-Reply-To: <4B678017.7060300@ibctech.ca>
Message-ID: <28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>

> > And what happens when that "someone else"'s 10th grade 
> English class 
> > is interrupted by your phone call about a possible botnet 
> infection on 
> > his uncle's server?
> 
> ...then the IP was SWIP'ed to a school, and the uncle 
> shouldn't have a server within the school network IP allocation.

A 10th grade kid's extracurricular activities have nothing
whatsoever to do with the school's network. We've already
been told that this is a small photography business that
has a server colocated with their local ISP. Since the 
business owners are experts in photography, it is reasonable
to assume that the server and networking expertise comes
from outside the photography business. Since it is a very
small business, it is reasonable to assume that they hire
tech support as and when needed, not on retainer and not
on-call 24x7. It is also reasonable to assume that they
would shop around for the best price for said tech support
and a 10th-grade nephew is highly likely to fit the profile
of cheap tech support. However, said 10th grade nephew has
other obligations such as attending school, and keeping their
mobile phone turned off while on the school premises.

Why on earth do you want to polute the whois directory with
thousands of phone numbers for 10th grader's mobile phones?
And the number of such tech support people is growing at the
same time that their age is dropping. I would not be surprised
to learn that their are 8th graders now looking after colocated
servers, or VPS root servers.

> > Let's be realistic here. This is not the Internet of 1990 where 
> > everything was in a big building owned by a big 
> organization that was 
> > paying big bucks for the underlying IT infrastructure that was 
> > connected to the Internet.
> 
> ...I want to know how to get a hold of the person/people who 
> are managing the machines that are addressed.

Then the whois directory needs a system for recording stuff like:
"Technical contact is attending school between the hours of
8:30 to 4:30 EST, Mondays thru Fridays. Saturdays from 10:00 to
12:00 he is playing baseball. Contactable at (604)555-1234
other times except when he is on a hot date which is most
likely Thursday thru Saturday evenings EST."

If you have a look through the RIPE database you will see that
they do have long complicated notes about who and how to contact
various support departments, although I've never seen one quite
like the above example.

I really do not understand why people do not support the basic
and fundamental principle of only recording contact information
in the whois directory for people who are READY, WILLING and ABLE
to TAKE ACTION when contacted. What good is it to have mobile
numbers that ring through to voicemail or contact people who,
although they set up the server themselves 3 months ago, have
more or less forgotten all the technical details that they barely
grasped in the first place. It really should be up to ISPs to
manage their customers, and the rest of us should contact the
ISPs who have 24x7 support people who are READY, WILLING and ABLE
to TAKE ACTION when contacted. If this were the standard way
to do things, then ISP contracts would have standard clauses
that allow them to unplug servers until the owner can be contacted
and arrangements made to clean up the problems.

As for servers that are not accepting incoming email or similar 
things, that is not your problem and it is not ARIN's problem.
We can't boil the sea.

--Michael Dillon


From vaughn at swiftsystems.com  Tue Feb  2 07:52:05 2010
From: vaughn at swiftsystems.com (Vaughn Thurman - Swift Systems)
Date: Tue, 2 Feb 2010 07:52:05 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:	CustomerConfidentiality - Time Sensitive
In-Reply-To: <28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <A902215B-E182-4404-9123-E7214E202C2C@swiftsystems.com>

As a regional ISP with a mix of colo customers ranging from real big- 
co's to ma-pa-co's all the way down to the "someday we are going to  
be..." futon-co's, I wholly agree that IP sub allocation contact data  
should be discretionary to the ISP.  Some would say "you just don't  
want your competitors looking up the phone numbers for your client's  
tech contacts if you ever have an outage" and I would honestly answer,  
well yeah, that too!  But honestly, other than that there would  
actually be no use to reaching out to many of my customers "tech"  
contacts, so why do this?  They are not all here (in colo) just  
because our air conditioning and power are well conditioned, and  
facilities secure.  They are here so that if they get into trouble of  
various kinds we can help them because we are reachable.  Calling them  
only delays this process by the extra steps of reaching them first.   
What if they change thier number and forget to let us know?  Believe  
me, for the orgs large enough to handle these issues there is a mutual  
and natural incentive to put thier contact data into the swip.  Leave  
the discretion where it belongs IMHO in the hands of the people who  
have always made this community work, the ISPs.

Best regards,
Vaughn

Sent from my iPhone

On Feb 2, 2010, at 6:26 AM, <michael.dillon at bt.com> wrote:

>>> And what happens when that "someone else"'s 10th grade
>> English class
>>> is interrupted by your phone call about a possible botnet
>> infection on
>>> his uncle's server?
>>
>> ...then the IP was SWIP'ed to a school, and the uncle
>> shouldn't have a server within the school network IP allocation.
>
> A 10th grade kid's extracurricular activities have nothing
> whatsoever to do with the school's network. We've already
> been told that this is a small photography business that
> has a server colocated with their local ISP. Since the
> business owners are experts in photography, it is reasonable
> to assume that the server and networking expertise comes
> from outside the photography business. Since it is a very
> small business, it is reasonable to assume that they hire
> tech support as and when needed, not on retainer and not
> on-call 24x7. It is also reasonable to assume that they
> would shop around for the best price for said tech support
> and a 10th-grade nephew is highly likely to fit the profile
> of cheap tech support. However, said 10th grade nephew has
> other obligations such as attending school, and keeping their
> mobile phone turned off while on the school premises.
>
> Why on earth do you want to polute the whois directory with
> thousands of phone numbers for 10th grader's mobile phones?
> And the number of such tech support people is growing at the
> same time that their age is dropping. I would not be surprised
> to learn that their are 8th graders now looking after colocated
> servers, or VPS root servers.
>
>>> Let's be realistic here. This is not the Internet of 1990 where
>>> everything was in a big building owned by a big
>> organization that was
>>> paying big bucks for the underlying IT infrastructure that was
>>> connected to the Internet.
>>
>> ...I want to know how to get a hold of the person/people who
>> are managing the machines that are addressed.
>
> Then the whois directory needs a system for recording stuff like:
> "Technical contact is attending school between the hours of
> 8:30 to 4:30 EST, Mondays thru Fridays. Saturdays from 10:00 to
> 12:00 he is playing baseball. Contactable at (604)555-1234
> other times except when he is on a hot date which is most
> likely Thursday thru Saturday evenings EST."
>
> If you have a look through the RIPE database you will see that
> they do have long complicated notes about who and how to contact
> various support departments, although I've never seen one quite
> like the above example.
>
> I really do not understand why people do not support the basic
> and fundamental principle of only recording contact information
> in the whois directory for people who are READY, WILLING and ABLE
> to TAKE ACTION when contacted. What good is it to have mobile
> numbers that ring through to voicemail or contact people who,
> although they set up the server themselves 3 months ago, have
> more or less forgotten all the technical details that they barely
> grasped in the first place. It really should be up to ISPs to
> manage their customers, and the rest of us should contact the
> ISPs who have 24x7 support people who are READY, WILLING and ABLE
> to TAKE ACTION when contacted. If this were the standard way
> to do things, then ISP contracts would have standard clauses
> that allow them to unplug servers until the owner can be contacted
> and arrangements made to clean up the problems.
>
> As for servers that are not accepting incoming email or similar
> things, that is not your problem and it is not ARIN's problem.
> We can't boil the sea.
>
> --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 john.sweeting at twcable.com  Tue Feb  2 08:13:47 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 2 Feb 2010 08:13:47 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
 Confidentiality - Time Sensitive
In-Reply-To: <4B678398.3050106@ibctech.ca>
Message-ID: <C78D8F3B.ED40%john.sweeting@twcable.com>

Steve,

In answer to your question, yes the AC has continued to stay focused on the business at hand. The petition itself has not been a distraction and although some of the posts not dealing directly with the petition may seem to be a distraction we, the AC, have actually used them to discuss how to make the PDP better moving forward. Over the last 5 days the AC has edited and submitted 3 proposals to ARIN for legal and staff review and there has been 1 additional proposal submitted that should be posted later today. We are on a tight schedule for the Toronto meeting and really cannot afford to be distracted. To be perfectly honest the Petition Process is a very important part of the new PDP and the use of it is fully supported. Thanks for giving me the opportunity to address this issue.

-john


++++++


On 2/1/10 8:44 PM, "Steve Bertrand" <steve at ibctech.ca> wrote:

Owen DeLong wrote:
>
> On Jan 29, 2010, at 5:07 PM, Ted Mittelstaedt wrote:

>> Of course it did.  The success of the petition means one thing - that
>> the AC made a bad decision.
>>
> I disagree.  I think the AC made the absolutely correct decision and that
> the petition means that 10 or more members of the community disagree
> with the AC's decision sufficiently strongly that they successfully
> petitioned
> it. That's how the process is supposed to work.  There's nothing wrong
> with it.
>
> I think in the end, it is likely that the community as a whole will uphold
> the AC's decision, but, in this case, there's enough dissent that it merits
> consideration of the full community and that's what is happening.
>>
>> My only observation on this is that I think if the AC had been
>> more specific (and long) on the explanation of why it was dropped
>> that people might not have supported the petition.
>>
> Perhaps. I guess there's a question of resource allocation there in terms
> of how much AC time should be spent justifying a decision to abandon
> vs. focusing on things still on the docket. I'm not saying we did the
> absolutely correct thing in this case, merely that there is a tradeoff to
> be considered that isn't part of your previous paragraph.

Out of curiosity, is the AC able to focus on the other items on the
docket with all of this going on?

I mean... this is the first real test. What kind of impact and/or
disruption has this caused, if any? It may be worth documenting.

>From early experience, how is this conundrum affecting the normal policy
process from progressing normally? Is it having an effect?

Steve
_______________________________________________
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 info at arin.net  Tue Feb  2 09:46:05 2010
From: info at arin.net (Member Services)
Date: Tue, 02 Feb 2010 09:46:05 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in the
	NRPM
Message-ID: <4B683AAD.4020502@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.

Draft Policies and Proposals under discussion can be found 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

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 108: Eliminate the term license in the NRPM

Proposal Originator: David Farmer

Proposal Version: 1.0

Date: 2 February 2010

Proposal type: modify

Policy term: Permanent

Policy statement:

Delete section 6.4.1 and replace with a new section;

1.1 Number resources are not property

To serve the interests of the Internet community as a whole, number
resources are not property (real, personal, or intellectual). The
allocation and assignment of IP addresses, ASNs, and other number
resources are subject to the terms of the ARIN Registration Services
Agreement, the policies in this document, and any amendments as may be
made to either one.

Modify section 11.4 by removing ?on a lease/license basis?, leaving the
following;

11.4 Resource Allocation Term and Renewal

The Numbering Resources are allocated for a period of one year. The
allocation can be renewed on application to ARIN providing information
as per Detail One. The identity and details of the applicant and the
allocated Numbering Resources will be published under the conditions of
ARIN's normal publication policy. At the end of the experiment,
resources allocated under this policy will be returned to the available
pool.

Rationale:

As part of the discussion of Policy Proposal #106 the issue of the use
of the term ?license? in section 6.4.1 and that it is not likely in
harmony with the ARIN Registration Services Agreement was recognized.
The AC feels that this issue is important enough to make it a separate
Draft Policy that stands on its own.

This section could not be fixed by simple editorial changes and it
requires a complete rewrite in order to fix the issues. It was further
recognized that the concept that ?Number resources are not property? is
not exclusively an IPv6 issue and should be moved out of section 6, so
that it is clear that it applies to all number resources.

Finally, the rest of the NRPM was searched for any additional uses of
the term ?license?. One additional use was found in section 11.4, in
this case deleting it and a few other words surrounding it, fixes the
issue without significantly changing the meaning of the section.

Timetable for implementation: Immediate




From cengel at sponsordirect.com  Tue Feb  2 11:07:44 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Tue, 2 Feb 2010 11:07:44 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <mailman.709.1265110021.30980.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>

Michael Dillon wrote:

"I really do not understand why people do not support the basic and fundamental principle of only recording contact information in the whois directory for people who are READY, WILLING and ABLE to TAKE ACTION when contacted. "


Michael is absolutely correct in this. The idea that the business/end user contact listed will be some-one who is ready/willing/able to take action on an issue 24/7/365 is simply a pipe dream.... it's not going to happen. Even for REAL Enterprises (i.e. not your mom & pop shops) only the very large ones are going to have a PUBLICALY listed  contact number that is manned round the clock. Very few have NOC coverage that is 24/7/365.

With my company....which is definately a real enterprise... you'll see our business contact info listed. If you hit those, you are NOT going to get a response outside of normal business hours. I'm not going to put my cell-phone/home-phone number on ANY of those public listings...nor would I ask any Tech that works for me to do the same.

Now, my Service Providers do have 24/7/365 NOC's and they DO have a contact list with our home/cell phone numbers. They even have an escalation list so they know who to try first, and who next if they can't get a response. They are the ones that are perfectly suited to act as Gatekeepers to determine whether a situation really warrants an emergency phone call or whether contact can wait for normal business hours.  So if it's 2:00 AM on Sunday morning and some-one is getting hit by a DoS attack from our Network...by jingo, they'll get ahold of one of us....but if it's an offer for Cheap Web Hosting in India (and yes we have gotten those that we KNOW, due to the address used, came in through WHOIS listings)...well that doesn't really need some-one to be woken out of bed to answer.

For most companies, it actualy makes alot more sense to be listing thier service providers contact info then thier own (if the service provider allows it).



Christopher Engel



From kkargel at polartel.com  Tue Feb  2 11:17:35 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 2 Feb 2010 10:17:35 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>
References: <mailman.709.1265110021.30980.arin-ppml@arin.net>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>
Message-ID: <8695009A81378E48879980039EEDAD28876D3FBE@MAIL1.polartel.local>


> 
> For most companies, it actualy makes alot more sense to be listing thier
> service providers contact info then thier own (if the service provider
> allows it).
> 
I completely agree with this, allowing the proviso that it is the customers decision, not the ISP's decision.  I as an ISP will certainly advise my customers on the best way to go, and that advise will be different for the barber shop than it is for the manufacturing plant with a tech staff.

In the end though, when I SWIP IP's to a customer they are now the proprietor of those IP's and I need to follow their instructions on how those IP's are registered.  If my customer requests that I be the tech or abuse contact and they are paying me money then I will happily do so.  If they want to be the contact then that is how it will be.

We can certainly steer our customers toward a path, but it is not ethical to assume we are smarter than they are and know what they want.  The matter of PoC contacts is a simple fill-in-the-blank question (with an option to insert ISP?) on whatever form or conversation you use when you arrange a >/29 assignment to your customer.  This does not have to be an onerous task.


From bill at herrin.us  Tue Feb  2 11:27:35 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 2 Feb 2010 11:27:35 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
	Confidentiality - Time Sensitive
In-Reply-To: <20100201141522.GA91915@ussenterprise.ufp.org>
References: <D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net> 
	<4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com> 
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com> 
	<4B65DB30.6080200@umn.edu>
	<3c3e3fca1001311327n634300far14067c7e5a2657e@mail.gmail.com> 
	<4B662557.5000202@umn.edu>
	<3c3e3fca1001312032raec9c5ek7478e2444c584c25@mail.gmail.com> 
	<20100201141522.GA91915@ussenterprise.ufp.org>
Message-ID: <3c3e3fca1002020827o14dd2f13w7166d9e491bf6272@mail.gmail.com>

On Mon, Feb 1, 2010 at 9:15 AM, Leo Bicknell <bicknell at ufp.org> wrote:
> I would favor having AC meetings "open to the public". ?To be clear,
> the public would be in listen only mode, they could not participate
> in any way, shape, or form.
>
> Sunshine can fix either of the problems here; if the AC is run amock
> the public will see it, and if in fact they are doing a good job,
> the public will also see that.

At the cost of a new problem: restricting the free discussion between
AC members. I would hope we can find a way to hold the members of the
AC more accountable for their choices without having to hold every
word they utter up for scrutiny.

Better yet, I'd like to see the board adjust the AC's process so that
they focus on their roles as *advisers* leaving fewer decisions for
which significant scrutiny is required. The AC should be advising, not
deciding. Deciding is what we have the BoT for.

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 cengel at sponsordirect.com  Tue Feb  2 11:53:56 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Tue, 2 Feb 2010 11:53:56 -0500
Subject: [arin-ppml] Policy Proposal 95: Customer Confidentiality
In-Reply-To: <mailman.695.1265061926.30980.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58F@Skyhawk>


Milton L Mueller wrote:

"> It's a fact that an audit can't positively confirm the accuracy of an
> end-user assignment without checking with the end-user.

But this fact does not necessarily imply a generalized capability of any member of the public to check with the end user. There are other mechanisms of doing audits."


Milton is absolutely correct here as well. So through a public lookup you know that ACME, inc has been assigned X number of IP addresses. As a member of the general public, how does that actualy help you determine whether that assignment is justified or not? A member of the general public may never have heard of ACME, Inc before and wonder why they should possibly get so many IP's....but they may have just signed a private contract to host all web services for Microsoft. You can't really expect that ACME has to divulge all the details of it's private contracts to anyone that calls them on the phone. ARIN's staff needs that info, because it's THIER job to justify the IP assignment...not John Smith's....and it's ARIN's staff that gets access to that INFO...under proper confidentialty rules.

So I'm not really sure of the utility of "public accountability" under such a scenerio. ARIN's accountable to the public for good management of a public resource. The people who request address space from ARIN are accountable to ARIN for utilizing that space in accordance with the justifications they provided for getting it. It's ARIN staff, not the public who actualy have the mechanisms to determine that. The public isn't really going to have the ability to determine whether ACME, inc is a legitimate business under private contracts to provide a huge number of services....or just a shell corporation being run out of some guys basement that's hoarding IP's to try to lease them out later.





Christopher Engel



From bill at herrin.us  Tue Feb  2 11:52:32 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 2 Feb 2010 11:52:32 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>
References: <mailman.709.1265110021.30980.arin-ppml@arin.net> 
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>
Message-ID: <3c3e3fca1002020852q22a3626ct8ae1fa8790bcb961@mail.gmail.com>

On Tue, Feb 2, 2010 at 11:07 AM, Chris Engel <cengel at sponsordirect.com> wrote:
> Michael Dillon wrote:
>
>> "I really do not understand why people do not support
>> the basic and fundamental principle of only recording
>> contact information in the whois directory for people
>> who are READY, WILLING and ABLE to TAKE ACTION
>> when contacted. "
>
> Michael is absolutely correct in this. The idea that the
>business/end user contact listed will be some-one who
>is ready/willing/able to take action on an issue 24/7/365
>is simply a pipe dream.... it's not going to happen.

Chris,

Whatever happened to the concept of administrative and technical
contacts where the administrative contact was capable of dealing with
administrative issues associated with the entity and the technical
contact was capable of dealing with technical issues associated with
the entity's network?

I have issues with Joe of the bot-infestation that his ISP is probably
better geared to chase down but I also have issues with Joe the
/14-holding florist that I want to discuss with Joe directly.

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 jcurran at arin.net  Tue Feb  2 12:35:18 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 2 Feb 2010 12:35:18 -0500
Subject: [arin-ppml] Petition Successful - Policy Proposal 95: Customer
	Confidentiality
Message-ID: <807A78B5-10A0-4CEC-B7D8-8FA829879BC8@arin.net>

The petition received the required number of statements of support and 
is therefore successful. The proposal will be posted as Draft Policy for 
discussion and review by the community on the Public Policy Mailing List 
and at the Public Policy Meeting in April.

Thank you,
/John

John Curran
President and CEO
ARIN


From cengel at sponsordirect.com  Tue Feb  2 12:52:58 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Tue, 2 Feb 2010 12:52:58 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <3c3e3fca1002020852q22a3626ct8ae1fa8790bcb961@mail.gmail.com>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA590@Skyhawk>

Bill Herrin wrote:

"Chris,

Whatever happened to the concept of administrative and technical contacts where the administrative contact was capable of dealing with administrative issues associated with the entity and the technical contact was capable of dealing with technical issues associated with the entity's network?

I have issues with Joe of the bot-infestation that his ISP is probably better geared to chase down but I also have issues with Joe the /14-holding florist that I want to discuss with Joe directly."


Bill,

That's great...but I'm not sure how exactly having Joe's contact info really helps you determine whether his /14 is justified?

As a member of the general public... you can't FORCE Joe to speak with you, right?

As a member of the general public... you can't FORCE Joe to answer questions about how he is using that address space...or even reasonably expect him to answer if his use involves confidential business practices... after-all how does Joe know your not helping a competitor fish for information on his business plans? He may even be under a confidentiality agreement himself which governs who/under what purposes he can reveal information about his services.

As a member of the general public.... if Joe is a private corporation, you don't even know how large his business is or how many computer/network assets he actually has or even what he utilizes them for.

As a member of the general public.... if Joe decides to feed you a fish story...your means of vetting  it are really quite limited...unless he's totally inept at scamming.

As a member of the general public.... You can't actually take any IP's Joe has away from him, can you? That would be ARIN's job.


As a matter of practicality, about the only real use I can see you for having Joe's contact info in THAT regards is if Joe's ISP assigned him a vastly larger network space then was justified..... and Joe really didn't know anything about it. Even then, it's not like the ISP can actually do anything with that space as long as it's assigned to Joe....and it would mean that Arin's staff was pretty darn asleep at the wheel.... if you as a member of the general public can catch something like that with only cursorary investigative abilities. Furthermore, even the rationale for an ISP wanting to hoard IP's pretty much goes away under IPv6 doesn't it?

In other words, I can see a legitimate case usage for wanting the info under such a scenario...but in terms of practicality it strikes me as even far more limited then the counter-case of mapping a competitors customer list or other privacy concerns.

I'm not adverse to having customer contact info published under the Administrative section but I DO think it aught to be the customers prerogative to determine if they are listed there or not.... at least as long as it's a public DB that allows anonymous look-ups. If you have to give up your own info to get info on somebody else...I could maybe see the case being otherwise. I could also see maybe exceptions for really large assignments... but practically what use is it to have a listing for every single /28 or /29 that's out there. Are you really going to check out each one as a member of the general public?

Honestly, I don't see the listing or not listing as that critical of an issue....but in the absence of a compelling use case for information needing to be public..... I prefer erring on the side of privacy. Just my preferences as a member of the general internet using community. I don't think the world will end or anything like that if the info is public...but if I'm given a preference...privacy is where my priority would fall.


Christopher Engel



From kkargel at polartel.com  Tue Feb  2 12:59:31 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 2 Feb 2010 11:59:31 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA590@Skyhawk>
References: <3c3e3fca1002020852q22a3626ct8ae1fa8790bcb961@mail.gmail.com>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA590@Skyhawk>
Message-ID: <8695009A81378E48879980039EEDAD28876D3FCA@MAIL1.polartel.local>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Chris Engel
> Sent: Tuesday, February 02, 2010 11:53 AM
> To: 'William Herrin'
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95
> 
> Bill Herrin wrote:
> 
> "Chris,
> 
> Whatever happened to the concept of administrative and technical contacts
> where the administrative contact was capable of dealing with
> administrative issues associated with the entity and the technical contact
> was capable of dealing with technical issues associated with the entity's
> network?
> 
> I have issues with Joe of the bot-infestation that his ISP is probably
> better geared to chase down but I also have issues with Joe the /14-
> holding florist that I want to discuss with Joe directly."
> 
> 
> Bill,
> 
> That's great...but I'm not sure how exactly having Joe's contact info
> really helps you determine whether his /14 is justified?
> 
There are other administrative reasons for speaking to a domain holder.  It could be that based on traffic you see on your network you want to set up a peering or other cooperative relationship more appropriate for an admin contact than a tech contact.

You may have legal reasons to talk to the company that have nothing to do with netops.




From info at arin.net  Tue Feb  2 13:09:34 2010
From: info at arin.net (Member Services)
Date: Tue, 02 Feb 2010 13:09:34 -0500
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
Message-ID: <4B686A5E.9090503@arin.net>

Draft Policy 2010-3
Customer Confidentiality

Draft Policy 2010-3 comes from the successful petition of "Policy
Proposal 95: Customer Confidentiality." The draft policy is being posted
for adoption discussion on the PPML and at the Public Policy Meeting in
Toronto in April. The text of this draft policy is under the control of
the petitioner, Aaron Wendel, until the conclusion of the Public Policy
Meeting.

Draft Policy 2010-3 is below and can be found at:
https://www.arin.net/policy/proposals/2010_3.html

You are encouraged to discuss Draft Policy 2010-3 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-3
Customer Confidentiality

Version/Date: 2 February 2010

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.

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.

Timetable for implementation: immediate









From bill at herrin.us  Tue Feb  2 13:18:34 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 2 Feb 2010 13:18:34 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA590@Skyhawk>
References: <3c3e3fca1002020852q22a3626ct8ae1fa8790bcb961@mail.gmail.com> 
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA590@Skyhawk>
Message-ID: <3c3e3fca1002021018t358ce58dy49b8044d9de355ad@mail.gmail.com>

On Tue, Feb 2, 2010 at 12:52 PM, Chris Engel <cengel at sponsordirect.com> wrote:
> Bill Herrin wrote:
>> I have issues with Joe of the bot-infestation that
>>his ISP is probably better geared to chase down
>>but I also have issues with Joe the /14-holding
>>florist that I want to discuss with Joe directly."
>
> That's great...but I'm not sure how exactly having
>Joe's contact info really helps you determine
>whether his /14 is justified?

Chris,

If Joe, allegedly assigned a /14 from his ISP, is a neighborhood
florist and he responds "What's the Internet?" then my audit is
basically done and it's time to report the ISP's fraud to ARIN.

If his reasons for the /14 are moderately plausible and I get the same
result with the other half-dozen suspicious looking assignments then
I'm basically done as well, though for the opposite reason.


The problem is: Joe's /14 assignment can't look suspicious or look any
other way if it's public listing is permissibly redacted to "ISP
Customer."


There are, of course, other values to an administrative contact. You
are, for example, not a common carrier. If your customer is hiding
behind your identity as an ISP, you could end up responsible for
accepting legal notice on his behalf. Is your legal department staffed
adequately to avoid missteps in that process that will get you sued by
the complainant, your customer or both?

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 kkargel at polartel.com  Tue Feb  2 13:26:27 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 2 Feb 2010 12:26:27 -0600
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
Message-ID: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>

Now that the petition has moved forward I do have some further comments on this proposal.

I do not think that ARIN is in the business of defending the secrecy of customer lists.  Keeping your customers should be a matter of competitive pricing and quality of service, not sequestering your customers in a closet or keeping them in a walled garden.  Free enterprise is part and parcel of doing business on the internet.

Hiding community members from contact by prospective service offerings is not included anywhere in the ARIN mission statement that I could see.





From jcurran at arin.net  Tue Feb  2 13:49:06 2010
From: jcurran at arin.net (John Curran)
Date: Tue, 2 Feb 2010 13:49:06 -0500
Subject: [arin-ppml] Notes on the current ARIN Policy Development Process
In-Reply-To: <3c3e3fca1001312203i2c5141depf3d4e6d13213c1d6@mail.gmail.com>
References: <02c701caa054$b71df010$2559d030$@net> <4B62098C.60606@arin.net>
	<D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>
	<4B636B12.6090603@ipinc.net>
	<4B638058.7010500@umn.edu> <4B63865F.7070608@ipinc.net>
	<D119BEC9-3CDE-4BF2-9F6D-203199D6E276@delong.com>
	<3c3e3fca1001310835n4fc264edjeb1bcb9441151f29@mail.gmail.com>
	<E35CCC98-234B-479F-835F-D7AD97CA2316@delong.com>
	<3c3e3fca1001312203i2c5141depf3d4e6d13213c1d6@mail.gmail.com>
Message-ID: <DAE65501-DA5D-4005-AA85-A5EEFB1BFC97@arin.net>

On Feb 1, 2010, at 4:03 PM, William Herrin wrote:
> 
> On Mon, Feb 1, 2010 at 12:32 AM, Owen DeLong <owen at delong.com> wrote:
>>        The AC was elected to help develop good, technically sound
>> policy.
> 
> Owen,
> 
> The AC was elected first and foremost to be shepherds of the bottom-up
> public-originated policy development process. Advising whether a
> particular proposal is "good, technically sound policy" is supposed to
> be the very last step, not the first. Moving it to the front violates,
> disrupts and eventually destroys the bottom-up character of the
> process.

At the end of 2008, the ARIN Board of Trustees adopted an updated 
Policy Development Process (PDP) which gave ARIN Advisory Council 
more freedom in handling policy proposals. The revision to the PDP 
was made after presentation of the proposed changes in the Denver 
Public Policy Meeting in April 2008, and then after a public call 
for comments. You can view the full explanation of the changes here:
<http://lists.arin.net/pipermail/arin-announce/2008-April/000715.html>

The revised PDP places policy proposals and draft policies under the 
purview of the AC as opposed to the proposal submitter, and made clear 
that the AC has the authority edit/merge/abandon policy proposals as 
needed to come up with draft policies which fair and technically sound. 
The result of the AC's work then goes to the PPML and the Public Policy 
Meeting for consideration by the community (full process is available
here: <https://www.arin.net/policy/pdp.html>)

This change was made to insure that draft policies are technically
sound, not duplicative, and consistent with the policy framework.  
It is hoped that the AC output will be Draft Policies which are 
strong candidates for adoption and will gain community support as 
a result during the PPML and Public Policy Meeting discussion.

It was recognized that this revision to the PDP places significant
control in the hands of the ARIN AC, and hence the petition process
was made prominent in the revised PDP to allow any AC action to be
petitioned via only 10 members of the community.  This is a very
low threshold intentionally, so that community could readily bring 
a matter to the PPML and next Public Policy Meeting.  It does not
indicate that the AC failed in any manner, but only that an action
taken by the AC may warrant further consideration.  As this is the
first time we're exercising this process, we also taking notes as
to the process itself in addition to the results.

The Policy Development process is not static, and there's already
some thought that we should look at another update based on the
experiences and lessons learned with the new PDP to date.  If 
there are specific suggestions that people have which they have
not already posted, you may send them to me directly at any time.
Of course, there will also be a similar community presentation
of any revised PDP and that will also offer another opportunity
to provide feedback in a public manner.

I post this message to PPML in order to make sure that everyone
is aware of these changes, and encourage folks to continue with 
the important discussions of the policy proposals and drafts 
which are before us.

Thanks!
/John

John Curran
President and CEO
ARIN







From kkargel at polartel.com  Tue Feb  2 13:53:13 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 2 Feb 2010 12:53:13 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <3c3e3fca1002021018t358ce58dy49b8044d9de355ad@mail.gmail.com>
References: <3c3e3fca1002020852q22a3626ct8ae1fa8790bcb961@mail.gmail.com>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA590@Skyhawk>
	<3c3e3fca1002021018t358ce58dy49b8044d9de355ad@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD28876D3FCC@MAIL1.polartel.local>

> There are, of course, other values to an administrative contact. You
> are, for example, not a common carrier. If your customer is hiding
> behind your identity as an ISP, you could end up responsible for
> accepting legal notice on his behalf. Is your legal department staffed
> adequately to avoid missteps in that process that will get you sued by
> the complainant, your customer or both?
> 
> Regards,
> Bill Herrin


One current and active example of this is the flurry of Digital Millenium Copyright Act (DMCA) activity.  While there are protections for ISP's under Title II (OCILLA) of that act it *could* be interpreted by the provisions in this act that (as Bill inferred) if you are sequestering your customer then you are assuming the responsibility and/or liability under DMCA.  At the very least by that act you are assuming the responsibility to proxy actionable notices to your customer, and if you fail in that responsibility you may assume liabilities. 

This is for better legal minds than mine to determine, but it makes me wonder.  

IANAL  (I AM NOT A LAWYER)




From craig.finseth at state.mn.us  Tue Feb  2 13:45:17 2010
From: craig.finseth at state.mn.us (Craig Finseth)
Date: Tue, 2 Feb 2010 12:45:17 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <8695009A81378E48879980039EEDAD28876D3FBE@MAIL1.polartel.local>
	(message from Kevin Kargel on Tue, 2 Feb 2010 10:17:35 -0600)
References: <mailman.709.1265110021.30980.arin-ppml@arin.net>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>
	<8695009A81378E48879980039EEDAD28876D3FBE@MAIL1.polartel.local>
Message-ID: <201002021845.o12IjH5k025052@inana.itg.state.mn.us>

Kevin Kargel <kkargel at polartel.com> write:

   > For most companies, it actualy makes alot more sense to be listing thier
   > service providers contact info then thier own (if the service provider
   > allows it).
   > 

   I completely agree with this, allowing the proviso that it is the
   customers decision, not the ISP's decision.  I as an ISP will
   certainly advise my customers on the best way to go, and that
   advise will be different for the barber shop than it is for the
   manufacturing plant with a tech staff.

   In the end though, when I SWIP IP's to a customer they are now the
   proprietor of those IP's and I need to follow their instructions on
   how those IP's are registered.  If my customer requests that I be
   the tech or abuse contact and they are paying me money then I will
   happily do so.  If they want to be the contact then that is how it
   will be.

   We can certainly steer our customers toward a path, but it is not
   ethical to assume we are smarter than they are and know what they
   want.  The matter of PoC contacts is a simple fill-in-the-blank
   question (with an option to insert ISP?) on whatever form or
   conversation you use when you arrange a >/29 assignment to your
   customer.  This does not have to be an onerous task.

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

I think Kevin's words bear repeating: his summary of the situation is
succint and clear and I agree with it 100%.

Craig



From cengel at sponsordirect.com  Tue Feb  2 14:24:50 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Tue, 2 Feb 2010 14:24:50 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <3c3e3fca1002021018t358ce58dy49b8044d9de355ad@mail.gmail.com>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA591@Skyhawk>

Bill Herrin wrote:

"There are, of course, other values to an administrative contact. You are, for example, not a common carrier. If your customer is hiding behind your identity as an ISP, you could end up responsible for accepting legal notice on his behalf. Is your legal department staffed adequately to avoid missteps in that process that will get you sued by the complainant, your customer or both?"


Bill,

That is a great arguement for an ISP WANTING to tell a customer "You must make your admin contact available for public listing as part of the Terms of our service agreement".  However why is it ARIN's mission to mandate via policy that decision for BOTH the ISP and the Client. Shouldn't the decision be left in the hands of the parties actualy affected by that decision. I mean if the ISP WANTs to accept responsability for things like relaying Take Down Notices and the client WANT's them to do it...who is ARIN to dictate to them that they can't have that arrangement?

By that same token, if I'm something like an ASP (we actually happen to fall into that category) and as part of our application, we provide our customers the ability to send out e-mail from the application.... and some-one finds something ACTIONABLE in one of our clients use of that function (sending e-mail). Then, if the plaintiff has no other way of tracing the origin of that e-mail other then IP...we, as the ASP WILL be getting the initial Legal Notice related to that use anyway...and be responsible for the legal issues in handling/responding/forwarding that NOTICE. Does that mean that ARIN's policy should REQUIRE that we publish in a public database for anonymous lookup every single customer who uses our application and presumably also publish in that same DB the info to track each use of the application to them? If NOT, then why should it insist that an ISP must essentialy do the same thing?

As I see it, only 2 things really fall under ARIN's mandate.... 1) Making sure that the use of public address space is fair and equitable.  2) Making sure that every public IP address can be tracked to some ENTITY responsible for answering for it's use. In the case you brought up it would be.... The ISP is the answerable party.... it may be acting as an Agent for the actual end user...but how is that any different from an ASP....or even one of those companies that rents office space/services acting as an Agent for an actual end user of it's services?

Again, if both the Service Provider and the Client are willing to have the Service Provider act as an agent for the client.... why should policy dictate that they can't?

Heck, if some-one wants to list in WHOIS the admin contact info for thier lawyers office....and thier lawyer is willing to do it...why should ARIN dictate that they can't?




Christopher Engel



From cengel at sponsordirect.com  Tue Feb  2 14:39:57 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Tue, 2 Feb 2010 14:39:57 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <mailman.714.1265136816.30980.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA592@Skyhawk>


Kevin Kargel wrote:

"Now that the petition has moved forward I do have some further comments on this proposal.

I do not think that ARIN is in the business of defending the secrecy of customer lists.  Keeping your customers should be a matter of competitive pricing and quality of service, not sequestering your customers in a closet or keeping them in a walled garden.  Free enterprise is part and parcel of doing business on the internet.

Hiding community members from contact by prospective service offerings is not included anywhere in the ARIN mission statement that I could see."


Kevin,

Could you point to the portion of ARIN's mission statement that covers regulating who a community member may be permited to have act as an agent for them?



Christopher Engel




From gbonser at seven.com  Tue Feb  2 14:40:14 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 2 Feb 2010 11:40:14 -0800
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Kevin Kargel
> Sent: Tuesday, February 02, 2010 10:26 AM
> Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
> 
> Hiding community members from contact by prospective service offerings
> is not included anywhere in the ARIN mission statement that I could
> see.

My feeling as well.  But in addition, I would want to make sure that
there is a technical POC listed for whoever is the one that actually has
"enable"/"root"/"administrator" access to the gear I am communicating
with.  I don't care if it is the ISP or the end user's IT staff, but I
want to make sure that there is a technical contact listed that can
actually do something about a problem.

I don't want to call an ISP who has no access to the mail/DNS server or
router or whatever on that user's network. That is a waste of time for
both of us.  We run a very lean shop and I don't have a couple of hours
to open tickets and wait for a response just to get a contact that I
should have been able to obtain from whois.  I believe that is the
purpose of it to begin with.  If you are not going to put the end user's
info in whois, there is no sense having whois at all.  Incorrect
information or information that points to someone who can't help me is
worse than useless.  I would rather have nothing than have a pointer to
a time sink.

People should be talking to me when there is a problem and not talking
to our finance department or CTO because an SMPP bind with someone's
SMSC is failing, for example.  I certainly don't want them calling the
upstream who SWIPed us the subnet because there is nothing they are
going to be able to do about it. 

They should be able to notice there is a problem, look up the IP
address, see the technical POC, send an email or call, and get some kind
of a response from someone who is likely to be able to solve or at least
troubleshoot the problem.  And I want to be able to do the same in the
other direction.

Whois, for the most part, does that today and saves me time.

I am not interested in protecting someone's customer list as a higher
priority than getting meaningful work done but don't mind some mechanism
of protecting them provided it doesn't make life more difficult for
everyone else.  Not allowing the ">" operator on certain whois queries
might be a way to start.



From kkargel at polartel.com  Tue Feb  2 14:40:25 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 2 Feb 2010 13:40:25 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA591@Skyhawk>
References: <3c3e3fca1002021018t358ce58dy49b8044d9de355ad@mail.gmail.com>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA591@Skyhawk>
Message-ID: <8695009A81378E48879980039EEDAD28876D3FD2@MAIL1.polartel.local>

> 
> Again, if both the Service Provider and the Client are willing to have the
> Service Provider act as an agent for the client.... why should policy
> dictate that they can't?
> 
> Heck, if some-one wants to list in WHOIS the admin contact info for thier
> lawyers office....and thier lawyer is willing to do it...why should ARIN
> dictate that they can't?
> 
> 

I agree with this, though it is the customer's decision.  I can see the point that today the customer may make that decision by deciding whether to use an ISP that SWIPs or one that doesn't..  

Personally I would like to see wording to the effect that:
The contact information for the customer MUST be entered UNLESS directed by the customer to enter the information for a designated agent as *PoC

The intent is to make entering something functional mandatory, to have the actual customer information preferred, but to allow a customer designated agent.

The customer designated agent could certainly be the ISP *if* the customer directs it to be so, it could also be their netops contracter, their help desk or their attorney.  Let's avoid SHOULD or MAY in the actual wording.  SHOULD and MAY are no-ops.


From rudi.daniel at gmail.com  Tue Feb  2 14:36:10 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Tue, 2 Feb 2010 15:36:10 -0400
Subject: [arin-ppml] Draft policy 2010-3
Message-ID: <8aeeaff61002021136o4b83ca7t2b82f8be997bbd7a@mail.gmail.com>

 "The customer's actual information must be provided to ARIN on request and
will be held in the strictest confidence."

The wording of 2010-3:  I think that the "on request" should be a mandatory
requirement. ARIN should not have to request it.

RD




>
> Draft Policy 2010-3
> Customer Confidentiality
>
> Draft Policy 2010-3 comes from the successful petition of "Policy
> Proposal 95: Customer Confidentiality." The draft policy is being posted
> for adoption discussion on the PPML and at the Public Policy Meeting in
> Toronto in April. The text of this draft policy is under the control of
> the petitioner, Aaron Wendel, until the conclusion of the Public Policy
> Meeting.
>
> Draft Policy 2010-3 is below and can be found at:
> https://www.arin.net/policy/proposals/2010_3.html
>
> You are encouraged to discuss Draft Policy 2010-3 on the PPML prior to
> the April Public Policy Meeting. Both the discussion on the list and
> at the meeting will be used by the ARIN Advisory Council to determine
> the community consensus for adopting this as policy.
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy 2010-3
> Customer Confidentiality
>
> Version/Date: 2 February 2010
>
> 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.
>
> 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.
>
> Timetable for implementation: immediate
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 2 Feb 2010 13:18:34 -0500
> From: William Herrin <bill at herrin.us>
> To: Chris Engel <cengel at sponsordirect.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95
> Message-ID:
>        <3c3e3fca1002021018t358ce58dy49b8044d9de355ad at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Feb 2, 2010 at 12:52 PM, Chris Engel <cengel at sponsordirect.com>
> wrote:
> > Bill Herrin wrote:
> >> I have issues with Joe of the bot-infestation that
> >>his ISP is probably better geared to chase down
> >>but I also have issues with Joe the /14-holding
> >>florist that I want to discuss with Joe directly."
> >
> > That's great...but I'm not sure how exactly having
> >Joe's contact info really helps you determine
> >whether his /14 is justified?
>
> Chris,
>
> If Joe, allegedly assigned a /14 from his ISP, is a neighborhood
> florist and he responds "What's the Internet?" then my audit is
> basically done and it's time to report the ISP's fraud to ARIN.
>
> If his reasons for the /14 are moderately plausible and I get the same
> result with the other half-dozen suspicious looking assignments then
> I'm basically done as well, though for the opposite reason.
>
>
> The problem is: Joe's /14 assignment can't look suspicious or look any
> other way if it's public listing is permissibly redacted to "ISP
> Customer."
>
>
> There are, of course, other values to an administrative contact. You
> are, for example, not a common carrier. If your customer is hiding
> behind your identity as an ISP, you could end up responsible for
> accepting legal notice on his behalf. Is your legal department staffed
> adequately to avoid missteps in that process that will get you sued by
> the complainant, your customer or both?
>
> 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
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 2 Feb 2010 12:26:27 -0600
> From: Kevin Kargel <kkargel at polartel.com>
> To: "'ppml at arin.net'" <ppml at arin.net>
> Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
> Message-ID:
>        <8695009A81378E48879980039EEDAD28876D3FCB at MAIL1.polartel.local>
> Content-Type: text/plain; charset="us-ascii"
>
> Now that the petition has moved forward I do have some further comments on
> this proposal.
>
> I do not think that ARIN is in the business of defending the secrecy of
> customer lists.  Keeping your customers should be a matter of competitive
> pricing and quality of service, not sequestering your customers in a closet
> or keeping them in a walled garden.  Free enterprise is part and parcel of
> doing business on the internet.
>
> Hiding community members from contact by prospective service offerings is
> not included anywhere in the ARIN mission statement that I could see.
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 2 Feb 2010 13:49:06 -0500
> From: John Curran <jcurran at arin.net>
> To: William Herrin <bill at herrin.us>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: [arin-ppml] Notes on the current ARIN Policy Development
>        Process
> Message-ID: <DAE65501-DA5D-4005-AA85-A5EEFB1BFC97 at arin.net>
> Content-Type: text/plain; charset="us-ascii"
>
> On Feb 1, 2010, at 4:03 PM, William Herrin wrote:
> >
> > On Mon, Feb 1, 2010 at 12:32 AM, Owen DeLong <owen at delong.com> wrote:
> >>        The AC was elected to help develop good, technically sound
> >> policy.
> >
> > Owen,
> >
> > The AC was elected first and foremost to be shepherds of the bottom-up
> > public-originated policy development process. Advising whether a
> > particular proposal is "good, technically sound policy" is supposed to
> > be the very last step, not the first. Moving it to the front violates,
> > disrupts and eventually destroys the bottom-up character of the
> > process.
>
> At the end of 2008, the ARIN Board of Trustees adopted an updated
> Policy Development Process (PDP) which gave ARIN Advisory Council
> more freedom in handling policy proposals. The revision to the PDP
> was made after presentation of the proposed changes in the Denver
> Public Policy Meeting in April 2008, and then after a public call
> for comments. You can view the full explanation of the changes here:
> <http://lists.arin.net/pipermail/arin-announce/2008-April/000715.html>
>
> The revised PDP places policy proposals and draft policies under the
> purview of the AC as opposed to the proposal submitter, and made clear
> that the AC has the authority edit/merge/abandon policy proposals as
> needed to come up with draft policies which fair and technically sound.
> The result of the AC's work then goes to the PPML and the Public Policy
> Meeting for consideration by the community (full process is available
> here: <https://www.arin.net/policy/pdp.html>)
>
> This change was made to insure that draft policies are technically
> sound, not duplicative, and consistent with the policy framework.
> It is hoped that the AC output will be Draft Policies which are
> strong candidates for adoption and will gain community support as
> a result during the PPML and Public Policy Meeting discussion.
>
> It was recognized that this revision to the PDP places significant
> control in the hands of the ARIN AC, and hence the petition process
> was made prominent in the revised PDP to allow any AC action to be
> petitioned via only 10 members of the community.  This is a very
> low threshold intentionally, so that community could readily bring
> a matter to the PPML and next Public Policy Meeting.  It does not
> indicate that the AC failed in any manner, but only that an action
> taken by the AC may warrant further consideration.  As this is the
> first time we're exercising this process, we also taking notes as
> to the process itself in addition to the results.
>
> The Policy Development process is not static, and there's already
> some thought that we should look at another update based on the
> experiences and lessons learned with the new PDP to date.  If
> there are specific suggestions that people have which they have
> not already posted, you may send them to me directly at any time.
> Of course, there will also be a similar community presentation
> of any revised PDP and that will also offer another opportunity
> to provide feedback in a public manner.
>
> I post this message to PPML in order to make sure that everyone
> is aware of these changes, and encourage folks to continue with
> the important discussions of the policy proposals and drafts
> which are before us.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 2 Feb 2010 12:53:13 -0600
> From: Kevin Kargel <kkargel at polartel.com>
> To: 'William Herrin' <bill at herrin.us>, 'Chris Engel'
>        <cengel at sponsordirect.com>
> Cc: "'arin-ppml at arin.net'" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95
> Message-ID:
>        <8695009A81378E48879980039EEDAD28876D3FCC at MAIL1.polartel.local>
> Content-Type: text/plain; charset="us-ascii"
>
> > There are, of course, other values to an administrative contact. You
> > are, for example, not a common carrier. If your customer is hiding
> > behind your identity as an ISP, you could end up responsible for
> > accepting legal notice on his behalf. Is your legal department staffed
> > adequately to avoid missteps in that process that will get you sued by
> > the complainant, your customer or both?
> >
> > Regards,
> > Bill Herrin
>
>
> One current and active example of this is the flurry of Digital Millenium
> Copyright Act (DMCA) activity.  While there are protections for ISP's under
> Title II (OCILLA) of that act it *could* be interpreted by the provisions in
> this act that (as Bill inferred) if you are sequestering your customer then
> you are assuming the responsibility and/or liability under DMCA.  At the
> very least by that act you are assuming the responsibility to proxy
> actionable notices to your customer, and if you fail in that responsibility
> you may assume liabilities.
>
> This is for better legal minds than mine to determine, but it makes me
> wonder.
>
> IANAL  (I AM NOT A LAWYER)
>
>
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 56, Issue 10
> *****************************************
>



-- 
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
?The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.? - Bertrand
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100202/88d09d29/attachment.htm>

From kkargel at polartel.com  Tue Feb  2 14:46:29 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 2 Feb 2010 13:46:29 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA592@Skyhawk>
References: <mailman.714.1265136816.30980.arin-ppml@arin.net>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA592@Skyhawk>
Message-ID: <8695009A81378E48879980039EEDAD28876D3FD3@MAIL1.polartel.local>

> 
> Kevin,
> 
> Could you point to the portion of ARIN's mission statement that covers
> regulating who a community member may be permited to have act as an agent
> for them?
> 
> 
> 
> Christopher Engel
> 

No.



From bill at herrin.us  Tue Feb  2 14:47:41 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 2 Feb 2010 14:47:41 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA592@Skyhawk>
References: <mailman.714.1265136816.30980.arin-ppml@arin.net> 
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA592@Skyhawk>
Message-ID: <3c3e3fca1002021147x510b431dge9297ab458e85a01@mail.gmail.com>

On Tue, Feb 2, 2010 at 2:39 PM, Chris Engel <cengel at sponsordirect.com> wrote:
> Could you point to the portion of ARIN's mission
> statement that covers regulating who a community
> member may be permited to have act as an agent for them?

Chris,

I would have no problem with allowing small consumers of IP addresses
to instruct the ISP to serve as his SWIP POC so long as the -default-
action was open publication. I don't see any compelling cause to deny
individuals consuming less than a /24 the right to retain their
privacy when they strongly desire to do so.

I wouldn't want to see it made a routine either-or decision, though.
Perhaps pair it with a dollar annual fee so that a customer who
doesn't care one way or the other participates in the SWIP system
instead of avoiding 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 marty at akamai.com  Tue Feb  2 14:52:43 2010
From: marty at akamai.com (Martin Hannigan)
Date: Tue, 2 Feb 2010 14:52:43 -0500
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <4B686A5E.9090503@arin.net>
References: <4B686A5E.9090503@arin.net>
Message-ID: <B9EEE48E-6DA6-42FD-A37B-639801C7625C@akamai.com>


On Feb 2, 2010, at 1:09 PM, Member Services wrote:


[ clip ]


>
> Draft Policy 2010-3
> Customer Confidentiality
>
> Version/Date: 2 February 2010
>
> 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.

If city, state, and zip (equivalents for non US) were added to this  
that I might support it. We can already nail them down to their  
neighborhoods with geo-location. Omitting the pinpoint address seems  
reasonable. I think maintaining a minimum level of neutrality is  
healthy in this case. While some of our participants would like to use  
us to control their competition I don't think that we should take the  
bait. I think that we should instead be reasonable and make some  
simple modifications that will raise the difficulty level to that off  
other existing methods for engaging in competitive conduct.


>  The customer's actual
> information must be provided to ARIN on request and will be held in  
> the
> strictest confidence.


This is not workable from my perspective. I see no reason to insert  
ARIN in the loop and this will only introduce confusion. Some will  
think that they can now refuse to service subpoenas for subscriber  
information and deflect them to ARIN. I would also think  (only  
because I have significant experience in this area, IANAL) that this  
may not be CALEA compliant if implemented with this activity. Even  
though our job is not to minimize liability for people that don't do  
it themselves, I think that rejecting this proposal based on this  
section alone is prudent for the good of all.

Finally if implemented as is, this will raise ARIN's costs and  
ultimately be unfairly distributed to the rest of us through our  
annual fees.

I would support this proposal if:

    1. Add city, state and zip (equivalents for non US locations)
    2. Removed ARIN, Inc. requirements related to address (with)holding
    3. Was sound from a regulatory perspective including items 1 and 2


Best,

Martin




From cgrundemann at gmail.com  Tue Feb  2 15:05:50 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 2 Feb 2010 13:05:50 -0700
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
Message-ID: <443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>

On Tue, Feb 2, 2010 at 12:40, George Bonser <gbonser at seven.com> wrote:
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
>> Behalf Of Kevin Kargel
>> Sent: Tuesday, February 02, 2010 10:26 AM
>> Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
>>
>> Hiding community members from contact by prospective service offerings
>> is not included anywhere in the ARIN mission statement that I could
>> see.
>
> My feeling as well. ?But in addition, I would want to make sure that
> there is a technical POC listed for whoever is the one that actually has
> "enable"/"root"/"administrator" access to the gear I am communicating
> with. ?I don't care if it is the ISP or the end user's IT staff, but I
> want to make sure that there is a technical contact listed that can
> actually do something about a problem.
>
> I don't want to call an ISP who has no access to the mail/DNS server or
> router or whatever on that user's network. That is a waste of time for
> both of us. ?We run a very lean shop and I don't have a couple of hours
> to open tickets and wait for a response just to get a contact that I
> should have been able to obtain from whois. ?I believe that is the
> purpose of it to begin with. ?If you are not going to put the end user's
> info in whois, there is no sense having whois at all. ?Incorrect
> information or information that points to someone who can't help me is
> worse than useless. ?I would rather have nothing than have a pointer to
> a time sink.
>
> People should be talking to me when there is a problem and not talking
> to our finance department or CTO because an SMPP bind with someone's
> SMSC is failing, for example. ?I certainly don't want them calling the
> upstream who SWIPed us the subnet because there is nothing they are
> going to be able to do about it.
>
> They should be able to notice there is a problem, look up the IP
> address, see the technical POC, send an email or call, and get some kind
> of a response from someone who is likely to be able to solve or at least
> troubleshoot the problem. ?And I want to be able to do the same in the
> other direction.

+1

whois must contain valid contact information for the person/entity
directly responsible for the host(s) using a given IP. I oppose this
and any other policy which undermines this fundamental requirement.

~Chris

>
> Whois, for the most part, does that today and saves me time.
>
> I am not interested in protecting someone's customer list as a higher
> priority than getting meaningful work done but don't mind some mechanism
> of protecting them provided it doesn't make life more difficult for
> everyone else. ?Not allowing the ">" operator on certain whois queries
> might be a way to start.
>
> _______________________________________________
> 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From gbonser at seven.com  Tue Feb  2 15:12:40 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 2 Feb 2010 12:12:40 -0800
Subject: [arin-ppml] Draft policy 2010-3
In-Reply-To: <8aeeaff61002021136o4b83ca7t2b82f8be997bbd7a@mail.gmail.com>
References: <8aeeaff61002021136o4b83ca7t2b82f8be997bbd7a@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7563@RWC-EX1.corp.seven.com>

And does "strictest confidence" mean nobody can access it?  If so, does
ARIN want to troubleshoot problems concerning those "strictly
confidential" networks out there? Or at least place itself in the middle
of such troubleshooting or injecting itself in the middle of disputes
concerning nefarious network activity?

 

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Rudolph Daniel
Sent: Tuesday, February 02, 2010 11:36 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] Draft policy 2010-3

 

 "The customer's actual information must be provided to ARIN on request
and will be held in the strictest confidence."

 

The wording of 2010-3:  I think that the "on request" should be a
mandatory requirement. ARIN should not have to request it.

 

RD

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

From rudi.daniel at gmail.com  Tue Feb  2 15:22:17 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Tue, 2 Feb 2010 16:22:17 -0400
Subject: [arin-ppml] Draft policy 2010-3
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7563@RWC-EX1.corp.seven.com>
References: <8aeeaff61002021136o4b83ca7t2b82f8be997bbd7a@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F7563@RWC-EX1.corp.seven.com>
Message-ID: <8aeeaff61002021222i372b9371pa1a1d51086d72b5f@mail.gmail.com>

Does the strictly confidence mean, no arbitrary free public access? if so
then there would have to be some procedure for access to the information.
Correct me if I am mistaken but I dont think ARIN is in the network trouble
shooting business. But it should have as much information as possible on its
assignments.
RD

On Tue, Feb 2, 2010 at 4:12 PM, George Bonser <gbonser at seven.com> wrote:

>  And does ?strictest confidence? mean nobody can access it?  If so, does
> ARIN want to troubleshoot problems concerning those ?strictly confidential?
> networks out there? Or at least place itself in the middle of such
> troubleshooting or injecting itself in the middle of disputes concerning
> nefarious network activity?
>
>
>
>
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *Rudolph Daniel
> *Sent:* Tuesday, February 02, 2010 11:36 AM
> *To:* arin-ppml at arin.net
> *Subject:* [arin-ppml] Draft policy 2010-3
>
>
>
>  "The customer's actual information must be provided to ARIN on requestand will be held in the strictest confidence."
>
>
>
> The wording of 2010-3:  I think that the "on request" should be a mandatory
> requirement. ARIN should not have to request it.
>
>
>
> RD
>



-- 
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
?The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.? - Bertrand
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100202/a17782fd/attachment.htm>

From gbonser at seven.com  Tue Feb  2 15:29:11 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 2 Feb 2010 12:29:11 -0800
Subject: [arin-ppml] Draft policy 2010-3
In-Reply-To: <8aeeaff61002021222i372b9371pa1a1d51086d72b5f@mail.gmail.com>
References: <8aeeaff61002021136o4b83ca7t2b82f8be997bbd7a@mail.gmail.com><5A6D953473350C4B9995546AFE9939EE081F7563@RWC-EX1.corp.seven.com>
	<8aeeaff61002021222i372b9371pa1a1d51086d72b5f@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7569@RWC-EX1.corp.seven.com>

The notion of "strictly confidential" end users somehow seems to go
against the entire fundamental idea that the Internet is a community
resource.  It does not belong to the ISP or to the end user.

 

The best analogy for this that I can think if is some apartment building
owner demanding that all of his residents have his name and phone number
listed in directory assistance because some other apartment building
owner keeps calling them offering them better deals on rent.

 

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Rudolph Daniel
Sent: Tuesday, February 02, 2010 12:22 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft policy 2010-3

 

Does the strictly confidence mean, no arbitrary free public access? if
so then there would have to be some procedure for access to the
information. Correct me if I am mistaken but I dont think ARIN is in the
network trouble shooting business. But it should have as much
information as possible on its assignments.

RD

 

On Tue, Feb 2, 2010 at 4:12 PM, George Bonser <gbonser at seven.com> wrote:

And does "strictest confidence" mean nobody can access it?  If so, does
ARIN want to troubleshoot problems concerning those "strictly
confidential" networks out there? Or at least place itself in the middle
of such troubleshooting or injecting itself in the middle of disputes
concerning nefarious network activity?

 

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Rudolph Daniel
Sent: Tuesday, February 02, 2010 11:36 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] Draft policy 2010-3

 

 "The customer's actual information must be provided to ARIN on request
and will be held in the strictest confidence."

 

The wording of 2010-3:  I think that the "on request" should be a
mandatory requirement. ARIN should not have to request it.

 

RD




-- 
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
"The whole problem with the world is that fools and fanatics are always
so certain of themselves, but wiser people so full of doubts." -
Bertrand Russell

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

From cengel at sponsordirect.com  Tue Feb  2 15:34:24 2010
From: cengel at sponsordirect.com (Chris Engel)
Date: Tue, 2 Feb 2010 15:34:24 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <mailman.717.1265139713.30980.arin-ppml@arin.net>
Message-ID: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA593@Skyhawk>

Kevin Kargel wrote:

"Personally I would like to see wording to the effect that:
The contact information for the customer MUST be entered UNLESS directed by the customer to enter the information for a designated agent as *PoC"

The wording I would like to see would probably be something along the lines of -

In cases of an assignment of less then /24 (or IPv6 Equivalent), contact information for a CONSENTING agent MAY be substituted for the assignee if mutually agreed upon by both service provider and assignee. Party responsible for entering SWIP/WHOIS data must confirm said agents consent to be listed and that contact information is accurate at time of submission. Listed party is responsible for notifying service provider of any changes in consent or contact information. In the event that no mutually agreement can be reached or consent or contact information cannot be verified or the assignment is of /24 or greater contact information of the assignee MUST be used.


That should cover Bills public interest usage case of an ISP trying to park a significant assignment on some small end user. It should also insure that who-ever is designated as agent knows and agrees that they are an agent..... and it should give the ISP the option to say "No we really don't want to deal with all this hassle, if you want to use us...we are going to list you." In which case, a client who doesn't like it can say "Fine, we're going with an ISP who offers that service". It also spells out who's responsible for what if everything goes to pot. In other words, it gets ARIN out of the business of mandating decisions for people where parties can work something else out between themselves.... but still insures that there is SOME-ONE willing to take responsbility for being assocaited with the address.


Christopher Engel


From rudi.daniel at gmail.com  Tue Feb  2 15:34:35 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Tue, 2 Feb 2010 16:34:35 -0400
Subject: [arin-ppml] Draft policy 2010-3
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7569@RWC-EX1.corp.seven.com>
References: <8aeeaff61002021136o4b83ca7t2b82f8be997bbd7a@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F7563@RWC-EX1.corp.seven.com>
	<8aeeaff61002021222i372b9371pa1a1d51086d72b5f@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F7569@RWC-EX1.corp.seven.com>
Message-ID: <8aeeaff61002021234wd5e222r8a7da1ad4edfa30@mail.gmail.com>

I dont have an unalterable position on 2010-3, I think it deserves
discussion. I prefer to have an open discussion than to stay with the status
quo. And I would agree that we should view this as pertaining to ipv6. Lets
us see what comes out of it.
RD

On Tue, Feb 2, 2010 at 4:29 PM, George Bonser <gbonser at seven.com> wrote:

>  The notion of ?strictly confidential? end users somehow seems to go
> against the entire fundamental idea that the Internet is a community
> resource.  It does not belong to the ISP or to the end user.
>
>
>
> The best analogy for this that I can think if is some apartment building
> owner demanding that all of his residents have his name and phone number
> listed in directory assistance because some other apartment building owner
> keeps calling them offering them better deals on rent.
>
>
>
>
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *Rudolph Daniel
> *Sent:* Tuesday, February 02, 2010 12:22 PM
>
> *To:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] Draft policy 2010-3
>
>
>
> Does the strictly confidence mean, no arbitrary free public access? if so
> then there would have to be some procedure for access to the information.
> Correct me if I am mistaken but I dont think ARIN is in the network trouble
> shooting business. But it should have as much information as possible on its
> assignments.
>
> RD
>
>
>
> On Tue, Feb 2, 2010 at 4:12 PM, George Bonser <gbonser at seven.com> wrote:
>
> And does ?strictest confidence? mean nobody can access it?  If so, does
> ARIN want to troubleshoot problems concerning those ?strictly confidential?
> networks out there? Or at least place itself in the middle of such
> troubleshooting or injecting itself in the middle of disputes concerning
> nefarious network activity?
>
>
>
>
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *Rudolph Daniel
> *Sent:* Tuesday, February 02, 2010 11:36 AM
> *To:* arin-ppml at arin.net
> *Subject:* [arin-ppml] Draft policy 2010-3
>
>
>
>  "The customer's actual information must be provided to ARIN on requestand will be held in the strictest confidence."
>
>
>
> The wording of 2010-3:  I think that the "on request" should be a mandatory
> requirement. ARIN should not have to request it.
>
>
>
> RD
>
>
>
>
> --
> Rudi Daniel
> e Business Consultant
> http://www.svgpso.org
> http://oecstimes.wordpress.com
> ?The whole problem with the world is that fools and fanatics are always so
> certain of themselves, but wiser people so full of doubts.? - Bertrand
> Russell
>



-- 
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
?The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.? - Bertrand
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100202/ebf5eb04/attachment.htm>

From bicknell at ufp.org  Tue Feb  2 15:36:22 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 2 Feb 2010 12:36:22 -0800
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
Message-ID: <20100202203622.GA66264@ussenterprise.ufp.org>

In a message written on Tue, Feb 02, 2010 at 01:05:50PM -0700, Chris Grundemann wrote:
> whois must contain valid contact information for the person/entity
> directly responsible for the host(s) using a given IP. I oppose this
> and any other policy which undermines this fundamental requirement.
[snip]
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org

% dig +short weblog.chrisgrundemann.com
173.14.10.9
% whois -h whois.arin.net "GTS-Castle Rock-CO-2013227"

CustName:   GTS-Castle Rock-CO-2013227
Address:    Private
City:       Private
StateProv:  CO
PostalCode: 99999
Country:    US
RegDate:    2009-07-08
Updated:    2009-07-08

NetRange:   173.14.10.8 - 173.14.10.15
CIDR:       173.14.10.8/29
NetName:    GTS-CASTLE-ROCK-CO-2013227
NetHandle:  NET-173-14-10-8-1
Parent:     NET-173-14-0-0-1
NetType:    Reassigned
Comment:
RegDate:    2009-07-08
Updated:    2009-07-08

RAbuseHandle: NAPO-ARIN
RAbuseName:   Network Abuse and Policy Observance
RAbusePhone:  +1-856-317-7272
RAbuseEmail:  abuse at comcast.net

OrgAbuseHandle: NAPO-ARIN
OrgAbuseName:   Network Abuse and Policy Observance
OrgAbusePhone:  +1-856-317-7272
OrgAbuseEmail:  abuse at comcast.net

OrgTechHandle: IC161-ARIN
OrgTechName:   Comcast Cable Communications Inc
OrgTechPhone:  +1-856-317-7200
OrgTechEmail:  CNIPEO-Ip-registration at cable.comcast.com

Your host is in a /29 in the database, and you say the person
directly responsible is a fundamental requirement; yet you are not
listed.

Indeed, I downloaded bulk whois and did this check several years
ago.  I point you to
https://www.arin.net/participate/meetings/reports/ARIN_XVIII/PDF/thursday/WHOIS_Bicknell.pdf.

Did you know there were 104,511 netblocks at the same street address!
Whee!  Turns out it was the street address of PacBell's HQ.

So if you want to assert that having contact information is a
fundamental requirement then I'm afraid to say by 2006 (when I did
that presentation) a good percentage of the SWIP's arlready were
missing such information.  I believe since then the growth has
continued in that direction.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100202/087305eb/attachment.sig>

From Ed.Wrona at aeroflex.com  Tue Feb  2 15:50:20 2010
From: Ed.Wrona at aeroflex.com (Wrona, Ed)
Date: Tue, 2 Feb 2010 15:50:20 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>
Message-ID: <29CA5C46-5E45-4498-BB9F-673B65CE2792@aeroflex.com>

Chris

      Your comments below echo my situation exactly and I am sitting  
here now thinking about

       I am wondering, however, is it by design that you have left the  
business contact info in whois, even though as you say, there will be  
response during off-hours ?


-Ed Wrona

On Feb 2, 2010, at 11:08 AM, "Chris Engel" <cengel at sponsordirect.com>  
wrote:

> Michael Dillon wrote:
>
> "I really do not understand why people do not support the basic and  
> fundamental principle of only recording contact information in the  
> whois directory for people who are READY, WILLING and ABLE to TAKE  
> ACTION when contacted. "
>
>
> Michael is absolutely correct in this. The idea that the business/ 
> end user contact listed will be some-one who is ready/willing/able  
> to take action on an issue 24/7/365 is simply a pipe dream.... it's  
> not going to happen. Even for REAL Enterprises (i.e. not your mom &  
> pop shops) only the very large ones are going to have a PUBLICALY  
> listed  contact number that is manned round the clock. Very few have  
> NOC coverage that is 24/7/365.
>
> With my company....which is definately a real enterprise... you'll  
> see our business contact info listed. If you hit those, you are NOT  
> going to get a response outside of normal business hours. I'm not  
> going to put my cell-phone/home-phone number on ANY of those public  
> listings...nor would I ask any Tech that works for me to do the same.
>
> Now, my Service Providers do have 24/7/365 NOC's and they DO have a  
> contact list with our home/cell phone numbers. They even have an  
> escalation list so they know who to try first, and who next if they  
> can't get a response. They are the ones that are perfectly suited to  
> act as Gatekeepers to determine whether a situation really warrants  
> an emergency phone call or whether contact can wait for normal  
> business hours.  So if it's 2:00 AM on Sunday morning and some-one  
> is getting hit by a DoS attack from our Network...by jingo, they'll  
> get ahold of one of us....but if it's an offer for Cheap Web Hosting  
> in India (and yes we have gotten those that we KNOW, due to the  
> address used, came in through WHOIS listings)...well that doesn't  
> really need some-one to be woken out of bed to answer.
>
> For most companies, it actualy makes alot more sense to be listing  
> thier service providers contact info then thier own (if the service  
> provider allows it).
>
>
>
> Christopher Engel
>
> _______________________________________________
> 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.
>

Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged, company confidential and/or exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.  If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail or collect telephone call and del
 ete or destroy all copies of this e-mail message, any physical copies made of this e-mail message and/or any file attachment(s).




From Ed.Wrona at aeroflex.com  Tue Feb  2 15:52:03 2010
From: Ed.Wrona at aeroflex.com (Wrona, Ed)
Date: Tue, 2 Feb 2010 15:52:03 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <29CA5C46-5E45-4498-BB9F-673B65CE2792@aeroflex.com>
References: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>
	<29CA5C46-5E45-4498-BB9F-673B65CE2792@aeroflex.com>
Message-ID: <B9A68617-63E0-4A99-8E16-180BD52FCD23@aeroflex.com>

> Sorry bout that.
Chris :
>     Your comments below echo my situation exactly and I am sitting  
> here now thinking about changing our info.
>
>      I am wondering, however, is it by design that you have left the  
> business contact info in whois, even though as you say, there will  
> be NO response during off-hours ?

-Ed Wrona

On Feb 2, 2010, at 3:50 PM, "Wrona, Ed" <Ed.Wrona at aeroflex.com> wrote:

> Chris
>
>
>
> -Ed Wrona
>
> On Feb 2, 2010, at 11:08 AM, "Chris Engel"  
> <cengel at sponsordirect.com> wrote:
>
>> Michael Dillon wrote:
>>
>> "I really do not understand why people do not support the basic and  
>> fundamental principle of only recording contact information in the  
>> whois directory for people who are READY, WILLING and ABLE to TAKE  
>> ACTION when contacted. "
>>
>>
>> Michael is absolutely correct in this. The idea that the business/ 
>> end user contact listed will be some-one who is ready/willing/able  
>> to take action on an issue 24/7/365 is simply a pipe dream.... it's  
>> not going to happen. Even for REAL Enterprises (i.e. not your mom &  
>> pop shops) only the very large ones are going to have a PUBLICALY  
>> listed  contact number that is manned round the clock. Very few  
>> have NOC coverage that is 24/7/365.
>>
>> With my company....which is definately a real enterprise... you'll  
>> see our business contact info listed. If you hit those, you are NOT  
>> going to get a response outside of normal business hours. I'm not  
>> going to put my cell-phone/home-phone number on ANY of those public  
>> listings...nor would I ask any Tech that works for me to do the same.
>>
>> Now, my Service Providers do have 24/7/365 NOC's and they DO have a  
>> contact list with our home/cell phone numbers. They even have an  
>> escalation list so they know who to try first, and who next if they  
>> can't get a response. They are the ones that are perfectly suited  
>> to act as Gatekeepers to determine whether a situation really  
>> warrants an emergency phone call or whether contact can wait for  
>> normal business hours.  So if it's 2:00 AM on Sunday morning and  
>> some-one is getting hit by a DoS attack from our Network...by  
>> jingo, they'll get ahold of one of us....but if it's an offer for  
>> Cheap Web Hosting in India (and yes we have gotten those that we  
>> KNOW, due to the address used, came in through WHOIS  
>> listings)...well that doesn't really need some-one to be woken out  
>> of bed to answer.
>>
>> For most companies, it actualy makes alot more sense to be listing  
>> thier service providers contact info then thier own (if the service  
>> provider allows it).
>>
>>
>>
>> Christopher Engel
>>
>> _______________________________________________
>> 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.
>>

Notice: This e-mail is intended solely for use of the individual or entity to which it is addressed and may contain information that is proprietary, privileged, company confidential and/or exempt from disclosure under applicable law. If the reader is not the intended recipient or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.  If this communication has been transmitted from a U.S. location it may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you have received this communication in error, please notify the sender by reply e-mail or collect telephone call and del
 ete or destroy all copies of this e-mail message, any physical copies made of this e-mail message and/or any file attachment(s).




From cgrundemann at gmail.com  Tue Feb  2 15:52:04 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 2 Feb 2010 13:52:04 -0700
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <20100202203622.GA66264@ussenterprise.ufp.org>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org>
Message-ID: <443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>

On Tue, Feb 2, 2010 at 13:36, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Tue, Feb 02, 2010 at 01:05:50PM -0700, Chris Grundemann wrote:
>> whois must contain valid contact information for the person/entity
>> directly responsible for the host(s) using a given IP. I oppose this
>> and any other policy which undermines this fundamental requirement.
> [snip]
>> @ChrisGrundemann
>> weblog.chrisgrundemann.com
>> www.burningwiththebush.com
>> www.coisoc.org
>
> % dig +short weblog.chrisgrundemann.com
> 173.14.10.9
> % whois -h whois.arin.net "GTS-Castle Rock-CO-2013227"
>
> CustName: ? GTS-Castle Rock-CO-2013227
> Address: ? ?Private
> City: ? ? ? Private
> StateProv: ?CO
> PostalCode: 99999
> Country: ? ?US
> RegDate: ? ?2009-07-08
> Updated: ? ?2009-07-08
>
> NetRange: ? 173.14.10.8 - 173.14.10.15
> CIDR: ? ? ? 173.14.10.8/29
> NetName: ? ?GTS-CASTLE-ROCK-CO-2013227
> NetHandle: ?NET-173-14-10-8-1
> Parent: ? ? NET-173-14-0-0-1
> NetType: ? ?Reassigned
> Comment:
> RegDate: ? ?2009-07-08
> Updated: ? ?2009-07-08
>
> RAbuseHandle: NAPO-ARIN
> RAbuseName: ? Network Abuse and Policy Observance
> RAbusePhone: ?+1-856-317-7272
> RAbuseEmail: ?abuse at comcast.net
>
> OrgAbuseHandle: NAPO-ARIN
> OrgAbuseName: ? Network Abuse and Policy Observance
> OrgAbusePhone: ?+1-856-317-7272
> OrgAbuseEmail: ?abuse at comcast.net
>
> OrgTechHandle: IC161-ARIN
> OrgTechName: ? Comcast Cable Communications Inc
> OrgTechPhone: ?+1-856-317-7200
> OrgTechEmail: ?CNIPEO-Ip-registration at cable.comcast.com
>
> Your host is in a /29 in the database, and you say the person
> directly responsible is a fundamental requirement; yet you are not
> listed.

I agree - I think that Comcast should require an abuse and technical
contact and published that info, they did not.

>
> Indeed, I downloaded bulk whois and did this check several years
> ago. ?I point you to
> https://www.arin.net/participate/meetings/reports/ARIN_XVIII/PDF/thursday/WHOIS_Bicknell.pdf.
>
> Did you know there were 104,511 netblocks at the same street address!
> Whee! ?Turns out it was the street address of PacBell's HQ.
>
> So if you want to assert that having contact information is a
> fundamental requirement then I'm afraid to say by 2006 (when I did
> that presentation) a good percentage of the SWIP's arlready were
> missing such information. ?I believe since then the growth has
> continued in that direction.

Agreed again - I think whois is in pretty sorry shape at the moment
(for more than one reason); but should we respond by throwing our
hands up and codifying bad behavior - or by addressing the problem?
~Chris

>
> --
> ? ? ? 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From bicknell at ufp.org  Tue Feb  2 16:29:03 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 2 Feb 2010 13:29:03 -0800
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org>
	<443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
Message-ID: <20100202212903.GA70818@ussenterprise.ufp.org>

In a message written on Tue, Feb 02, 2010 at 01:52:04PM -0700, Chris Grundemann wrote:
> Agreed again - I think whois is in pretty sorry shape at the moment
> (for more than one reason); but should we respond by throwing our
> hands up and codifying bad behavior - or by addressing the problem?

While we clearly disagree on the desired outcome, it appears we
both agree that the current situation is absurd.

I have consistenly supported proposals to remove this information
from whois, and I have also written and spent several years propmoting
my own policy in this space (2005-2) which was subsequently abandoned.

I have yet to see anyone on the other side of this issue propose
any method of "addressing the problem" from the other side, that
is tightening requirements such that someone is required to be
listed.

Please understand this is why I find such positions hypocritical.
While I would disgree with tightening requirements, I would respect
those making the argument that such requirments were "fundamental"
if they were pushing policy initatives to make that actually be the
case.  Using such forceful language to oppose policy when it is
known not to represent the status quo and also when not working to
change the status quo leaves the impression that the convictions
on that point are weak, or nonexistant.

I think ARIN just has the whois thing plain wrong.  Allocations and
assignments made from ARIN should have regularized information
published on them by ARIN.  Everything below that should be optional,
as decided by the ISP and the customer.  More to the point, it
should be more open than the current system, a-la what RIPE does.
If the customer and the ISP want to put a 20 page missive in whois
listing every employee with phone, e-mail, cell, facebook page, and
favorite color, great!  If they want to not be listed, and have
their ISP take calls, great!

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100202/8da2f3b0/attachment.sig>

From john.sweeting at twcable.com  Tue Feb  2 16:52:12 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 2 Feb 2010 16:52:12 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
 Confidentiality - Time Sensitive
In-Reply-To: <3c3e3fca1001312032raec9c5ek7478e2444c584c25@mail.gmail.com>
Message-ID: <C78E08BC.EE2A%john.sweeting@twcable.com>

Hi Bill,

First and foremost on behalf of the AC I would like to thank you for
your commitment and dedication to the Internet community. You have
been one of the biggest contributors to the policy process and many of
your ideas are reflected in the current proposals and draft policies
that the AC is working on. PP 106 is a direct result of your efforts
on PP 103 and hopefully we are capturing some of the spirit and intent
of your proposal.

The new PDP is very different from the old IRPEP and it has taken time
for everyone to adapt to the differences. We are continuously looking to
improve and welcome all feedback on the job we are doing. I can tell
you that every single member of the AC spends many hours each month
working to improve policy as well as recommend new policies that will
be of benefit to the community.

Members of the AC have different approaches to participation - my
personal preference is to *not* post very often and then only to help
guide discussion as I would like my opinion to be formed by what I
read as well as by my past experience and current knowledge.  I assure
you that as the Chair I read every post to PPML and that the
expectation is that the AC members that shepherd proposals read every
post pertinent to their assigned proposals.  Most AC members read
every post.  In short, it's not fair to evaluate AC members'
participation on the basis of the number of posts they make to PPML.

In addressing your research on the proposals that have been abandoned
over the last 18 months I would say that this was in no way intended
to be a personal slight and that the AC will attempt to be sensitive
to this concern in the future.

Please continue to contribute and please feel free to contact me
anytime that you see fit.

Best Regards,
John


+++++++++
On 1/31/10 11:32 PM, "William Herrin" <bill at herrin.us> wrote:

On Sun, Jan 31, 2010 at 7:50 PM, David Farmer <farmer at umn.edu> wrote:
> William Herrin wrote:
>> Do you realize that only five of the fifteen of you have participated
>> in the PUBLIC policy mailing list this month?
>
> I'll just point out not everyone participates in the same way, and this is a
> good thing, there are other roles to play than opinionated guy who shoots
> his mouth off a lot, that I some time play.  We do need quite contemplative
> thinkers too.  I believe the AC is a well rounded group and there are many
> different roles to be played on the AC.  I don't think it would serve the
> community well if we all thought and acted the same.  I can tell you that
> all of the people on your list above have contributed in their own ways,
> even if it wasn't to post to PPML.

David,

I'm not trying to single out anyone, but frankly I'm frustrated by the
AC's collective behavior this past year and I doubt I'm the only one.
I'd be far more sympathetic if all the quiet work outside the public
eye resulted more and better advice for proposal authors from among
the general public, and less suppression of proposals not written by
members of the AC itself.

Take an instructive look at the proposals abandoned prior to formal
discussion over the past 18 months:

First, the ones authored by the members of the AC:

96. Abandoned because it was process rather than policy. Referred to
the ARIN President for further action.
91. Abandoned without comment, presumably because it was principally a
challenge to a Board of Trustees action. I note that it was abandoned
despite significant support for the proposal among the community.
87. Abandoned after ARIN staff procedures were altered to accomplish
the same result.
85: Abandoned in favor of proposal 91 by the same AC member.

Now look at the difference with the ones authored by the general public:

104, 103: Abandoned because "the AC could not support this proposal in
its current form"
100: Abandoned without comment as the AC advanced a similar proposal
written by one of its members.
98: Abandoned because "the proposal is overly complicated."
95: Abandoned because it resembles a proposal defeated half a decade ago.
92: Abandoned because "The AC [...] does not believe that the problem
addressed is immediate nor of sufficient scope"
88: Abandoned without comment.
86: Abandoned on the grounds that modifications to the policy
development process can not be made through the policy development
process.
83: Abandoned "seeing little support and a large amount of opposition on PPML."


Have I painted a clear enough picture or do I need to spell it out?
The insiders' right to advance a proposal is almost undisputed while
the evaluation of bottom-up policy has progressed from "seeing little
[public] support" to "the AC could not support."

The BoT has thrown you a nasty conflict of interest by having you sit
in judgment on your own proposals as well as those from the general
public . Quite frankly you are, as a group, handling it poorly.

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.

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 cgrundemann at gmail.com  Tue Feb  2 17:15:21 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 2 Feb 2010 15:15:21 -0700
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <20100202212903.GA70818@ussenterprise.ufp.org>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org>
	<443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
	<20100202212903.GA70818@ussenterprise.ufp.org>
Message-ID: <443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>

On Tue, Feb 2, 2010 at 14:29, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Tue, Feb 02, 2010 at 01:52:04PM -0700, Chris Grundemann wrote:
>> Agreed again - I think whois is in pretty sorry shape at the moment
>> (for more than one reason); but should we respond by throwing our
>> hands up and codifying bad behavior - or by addressing the problem?
>
> While we clearly disagree on the desired outcome, it appears we
> both agree that the current situation is absurd.
>
> I have consistenly supported proposals to remove this information
> from whois, and I have also written and spent several years propmoting
> my own policy in this space (2005-2) which was subsequently abandoned.
>
> I have yet to see anyone on the other side of this issue propose
> any method of "addressing the problem" from the other side, that
> is tightening requirements such that someone is required to be
> listed.
>
> Please understand this is why I find such positions hypocritical.
> While I would disgree with tightening requirements, I would respect
> those making the argument that such requirments were "fundamental"
> if they were pushing policy initatives to make that actually be the
> case. ?Using such forceful language to oppose policy when it is
> known not to represent the status quo and also when not working to
> change the status quo leaves the impression that the convictions
> on that point are weak, or nonexistant.

See policy 2008-7 (and the surrounding discussions), my first step in
addressing the problems, as I see them, with our current use of whois.
 Although I am not prepared to lay out a plan for addressing the whole
system in this message - you can be assured that my convictions are
real.

The status quo does not necessarily (and often does not at all)
represent the ideal or the intended. The original intent of whois was
to register everyone who was able to pass traffic across the
Internet[1]. The required information was name, physical address,
phone number and network mailbox. Obviously we can not (and do not
want) to register every cell-phone user or PC owner. We do still want
to be able to contact network administrators who actually have the
ability to make changes on the network in question though. In some
cases, this is an ISP but in most cases involving an end-user who is a
business, it is the end-user.

~Chris

[1] See "WHO SHOULD BE IN THE DATA BASE" in RFC 812 and RFC 954


> I think ARIN just has the whois thing plain wrong. ?Allocations and
> assignments made from ARIN should have regularized information
> published on them by ARIN. ?Everything below that should be optional,
> as decided by the ISP and the customer. ?More to the point, it
> should be more open than the current system, a-la what RIPE does.
> If the customer and the ISP want to put a 20 page missive in whois
> listing every employee with phone, e-mail, cell, facebook page, and
> favorite color, great! ?If they want to not be listed, and have
> their ISP take calls, great!
>
> --
> ? ? ? 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.
>


-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From tony at lava.net  Tue Feb  2 17:34:33 2010
From: tony at lava.net (Antonio Querubin)
Date: Tue, 2 Feb 2010 12:34:33 -1000 (HST)
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org>
	<443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
	<20100202212903.GA70818@ussenterprise.ufp.org>
	<443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
Message-ID: <alpine.OSX.2.00.1002021220390.575@cust11794.lava.net>

On Tue, 2 Feb 2010, Chris Grundemann wrote:

> want) to register every cell-phone user or PC owner. We do still want
> to be able to contact network administrators who actually have the
> ability to make changes on the network in question though. In some
> cases, this is an ISP but in most cases involving an end-user who is a
> business, it is the end-user.

Those who can make the best informed decision about that are really the 
ISP and end-user.  The current two sizes fits all policy still leaves the 
ISP in a quandary when the end-user is an at-home business.


Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  tony at lava.net


From bicknell at ufp.org  Tue Feb  2 17:49:25 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 2 Feb 2010 14:49:25 -0800
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org>
	<443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
	<20100202212903.GA70818@ussenterprise.ufp.org>
	<443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
Message-ID: <20100202224925.GA76402@ussenterprise.ufp.org>

In a message written on Tue, Feb 02, 2010 at 03:15:21PM -0700, Chris Grundemann wrote:
> See policy 2008-7 (and the surrounding discussions), my first step in
> addressing the problems, as I see them, with our current use of whois.
>  Although I am not prepared to lay out a plan for addressing the whole
> system in this message - you can be assured that my convictions are
> real.

2008-7 is a bit messy due to the merged proposals, but it seems to
me the general concepts at work there are orthogonal to the ones
we are discussing at this instance.

The recent petition and related discussion is about who should or
should not be listed in the database.  2008-7 addresses making sure
the info in the database stays up to date post that decision, and
what action we take if we find it out of date.

> The status quo does not necessarily (and often does not at all)
> represent the ideal or the intended. The original intent of whois was
> to register everyone who was able to pass traffic across the
> Internet[1]. The required information was name, physical address,

Let me quote the passage from RFC 954 for others they don't have
to go look it up:

    WHO SHOULD BE IN THE DATABASE 

    DCA requests that each individual with a directory on an ARPANET
    or MILNET host, who is capable of passing traffic across the DoD
    Internet, be registered in the NIC WHOIS Database. MILNET TAC users
    must be registered in the database.

I want to point out, at that time substantially all of the network
was directly paid for by government contract, so the government was
asking for full documentation of who was benefiting from the use
of public funds.  Indeed, I believe to some degree this is required
by Government purchasing rules (that they disclose who receives the
funding).

As a result I'm dubious this historical artifact has anything to
do with the privately run, privately paid for network run by RIR's,
and not the DoD that we have today.

> ability to make changes on the network in question though. In some
> cases, this is an ISP but in most cases involving an end-user who is a
> business, it is the end-user.

Actually, in many cases it is both.  When Grandma's PC is infected
with a virus and made part of a botnet there are multiple solutions.
Calling Grandma and explaining the situation and having her fix her
machine might work.  Calling her ISP, and having them disconnect
her box, or put it in a quaranteen VLAN and then working with her
might work as well.

What I advocate is that the RIR's allow the users and ISP's to
choose.  If Grandma buys from Joes Bait and Internet on the $1.99
a month budget plan, he may list her and not even pick up the phone.
If she buys PlatinumCo's $499 a month hyperpeed premium Internet
they may send her the PC, manage it remotely for her, and guarantee
it to be virus free.  They may want to list themselves as the right
contact.

I don't understand how Stewardship requires us to pick one business
model over the over.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100202/41c244ce/attachment.sig>

From gbonser at seven.com  Tue Feb  2 17:51:23 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 2 Feb 2010 14:51:23 -0800
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <alpine.OSX.2.00.1002021220390.575@cust11794.lava.net>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local><5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com><443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com><20100202203622.GA66264@ussenterprise.ufp.org><443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com><20100202212903.GA70818@ussenterprise.ufp.org><443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
	<alpine.OSX.2.00.1002021220390.575@cust11794.lava.net>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7585@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Antonio Querubin
> Sent: Tuesday, February 02, 2010 2:35 PM
> To: Chris Grundemann
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
> 
> On Tue, 2 Feb 2010, Chris Grundemann wrote:
> 
> > want) to register every cell-phone user or PC owner. We do still
want
> > to be able to contact network administrators who actually have the
> > ability to make changes on the network in question though. In some
> > cases, this is an ISP but in most cases involving an end-user who is
> a
> > business, it is the end-user.

I don't believe there is a need to get beyond the realm of common sense.
I would not expect private users of internet services to be listed.  I
would, however, expect users who provide Internet services for the
general public and manage those services to be listed. 

My cell phone is not delivering Internet services and neither is my home
network so neither should require listing.




From cgrundemann at gmail.com  Tue Feb  2 17:54:56 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 2 Feb 2010 15:54:56 -0700
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7585@RWC-EX1.corp.seven.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org>
	<443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
	<20100202212903.GA70818@ussenterprise.ufp.org>
	<443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
	<alpine.OSX.2.00.1002021220390.575@cust11794.lava.net>
	<5A6D953473350C4B9995546AFE9939EE081F7585@RWC-EX1.corp.seven.com>
Message-ID: <443de7ad1002021454r22bd6c17l628daaebbbe65d1b@mail.gmail.com>

On Tue, Feb 2, 2010 at 15:51, George Bonser <gbonser at seven.com> wrote:
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
>> Behalf Of Antonio Querubin
>> Sent: Tuesday, February 02, 2010 2:35 PM
>> To: Chris Grundemann
>> Cc: ppml at arin.net
>> Subject: Re: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
>>
>> On Tue, 2 Feb 2010, Chris Grundemann wrote:
>>
>> > want) to register every cell-phone user or PC owner. We do still
> want
>> > to be able to contact network administrators who actually have the
>> > ability to make changes on the network in question though. In some
>> > cases, this is an ISP but in most cases involving an end-user who is
>> a
>> > business, it is the end-user.
>
> I don't believe there is a need to get beyond the realm of common sense.
> I would not expect private users of internet services to be listed. ?I
> would, however, expect users who provide Internet services for the
> general public and manage those services to be listed.
>
> My cell phone is not delivering Internet services and neither is my home
> network so neither should require listing.
>

That was my point as well - we no longer need ALL users of the
Internet listed but we do need those who are directly responsible for
managing networks to be listed.

>
>


From rwsiv at ETRN.com  Tue Feb  2 18:07:26 2010
From: rwsiv at ETRN.com (Robert Sanderson)
Date: Tue, 02 Feb 2010 17:07:26 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95: Customer
 Confidentiality - Time Sensitive
In-Reply-To: <4B67811C.1040208@ibctech.ca>
References: <02c701caa054$b71df010$2559d030$@net>	<4B62098C.60606@arin.net>	<D214550E-D7E4-4008-A46A-6F809E6265E3@arin.net>	<4B636B12.6090603@ipinc.net>
	<4B67811C.1040208@ibctech.ca>
Message-ID: <4B68B02E.2070005@ETRN.com>


Ted Mittelstaedt wrote:

>   So far I count 12 solid supporters of the petition.
>
> They are:
>
> jay at handynetworks.com   // Handy Networks LLC
> joe at joesdatacenter.com  //  Joe's Datacenter, LLC
> network at dimenoc.com  //DimeNoc  AS33182
> bicknell at ufp.org   - bicknell at ufp.org - CCIE 3440
> spamfree at wansecurity.com  Robert Smith, CISSP  WANSecurity, Inc.
> dsd at carpathiahost.com   Carpathia Hosting, Inc
> thorsten.ziegler at 1and1.com  1&1 Internet, AS8560
> lar at mwtcorp.net  ARIN ORG: CBS-129
> bill at herrin.us  AS 11875
> stephen.r.middleton at verizon.com  Verizon Services Operations
> raul at datavo.com  Datavo / AS26773
> tony at lava.net  LavaNet
>
>
> The following people stated they supported the policy but they
> didn't state that they supported the petition
>
> todd at kcix.net
>
> The following people supported the petition but didn't identify
> who they represent:
>
> rudi.daniel at gmail.com
> marty at akamai.com
> rob at lagniappeinternet.com
>
> Naturally the AC will need to make the "official" determination
> but it looks like we will be discussing this.
>   

I officially support the petition, and the process.

Robert Sanderson, AS15041, ARIN ORG: ETRNC, RWS40-ARIN

-Bob



From cgrundemann at gmail.com  Tue Feb  2 18:55:49 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 2 Feb 2010 16:55:49 -0700
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <20100202224925.GA76402@ussenterprise.ufp.org>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org>
	<443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
	<20100202212903.GA70818@ussenterprise.ufp.org>
	<443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
	<20100202224925.GA76402@ussenterprise.ufp.org>
Message-ID: <443de7ad1002021555m431ded34hf8f1bb8e07740f0a@mail.gmail.com>

On Tue, Feb 2, 2010 at 15:49, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Tue, Feb 02, 2010 at 03:15:21PM -0700, Chris Grundemann wrote:
>> See policy 2008-7 (and the surrounding discussions), my first step in
>> addressing the problems, as I see them, with our current use of whois.
>>  Although I am not prepared to lay out a plan for addressing the whole
>> system in this message - you can be assured that my convictions are
>> real.
>
> 2008-7 is a bit messy due to the merged proposals, but it seems to
> me the general concepts at work there are orthogonal to the ones
> we are discussing at this instance.
>
> The recent petition and related discussion is about who should or
> should not be listed in the database.  2008-7 addresses making sure
> the info in the database stays up to date post that decision, and
> what action we take if we find it out of date.

Correct, I believe that whois data should be both complete and
accurate; 2008-7 addresses the latter, here we discuss the former.

>
>> The status quo does not necessarily (and often does not at all)
>> represent the ideal or the intended. The original intent of whois was
>> to register everyone who was able to pass traffic across the
>> Internet[1]. The required information was name, physical address,
>
> Let me quote the passage from RFC 954 for others they don't have
> to go look it up:
>
>    WHO SHOULD BE IN THE DATABASE
>
>    DCA requests that each individual with a directory on an ARPANET
>    or MILNET host, who is capable of passing traffic across the DoD
>    Internet, be registered in the NIC WHOIS Database. MILNET TAC users
>    must be registered in the database.
>
> I want to point out, at that time substantially all of the network
> was directly paid for by government contract, so the government was
> asking for full documentation of who was benefiting from the use
> of public funds.  Indeed, I believe to some degree this is required
> by Government purchasing rules (that they disclose who receives the
> funding).
>
> As a result I'm dubious this historical artifact has anything to
> do with the privately run, privately paid for network run by RIR's,
> and not the DoD that we have today.

Ok lets get more recent, this is from RFC 2050 "Internet Registry IP
Allocation Guidelines:"

2.2  Submission of Reassignment Information

   It is imperative that reassignment information be submitted in a
   prompt and efficient manner to facilitate database maintenance and
   ensure database integrity.  Therefore, assignment information must be
   submitted to the regional registry immediately upon making the
   assignment.  The following reasons necessitate transmission of the
   reassignment information:

       a)  to provide operational staff with information on who is using
           the network number and to provide a contact in case of
           operational/security problems,

       b)  to ensure that a provider has exhausted a majority of its
           current CIDR allocation, thereby justifying an additional
           allocation,

       c)  to assist in IP allocation studies.

   Procedures for submitting the reassignment information will be
   determined by each regional registry based on its unique
   requirements.

   All sub-registries (ISPs, Local registries, etc.) must register with
   their respective regional registry to receive information regarding
   reassignment guidelines.  No additional CIDR blocks will be allocated
   by the regional registry or upstream providers until approximately
   80% of all reassignment information has been submitted.

>
>> ability to make changes on the network in question though. In some
>> cases, this is an ISP but in most cases involving an end-user who is a
>> business, it is the end-user.
>
> Actually, in many cases it is both.  When Grandma's PC is infected
> with a virus and made part of a botnet there are multiple solutions.
> Calling Grandma and explaining the situation and having her fix her
> machine might work.  Calling her ISP, and having them disconnect
> her box, or put it in a quaranteen VLAN and then working with her
> might work as well.
>
> What I advocate is that the RIR's allow the users and ISP's to
> choose.  If Grandma buys from Joes Bait and Internet on the $1.99
> a month budget plan, he may list her and not even pick up the phone.
> If she buys PlatinumCo's $499 a month hyperpeed premium Internet
> they may send her the PC, manage it remotely for her, and guarantee
> it to be virus free.  They may want to list themselves as the right
> contact.

A very nice corner-case. I will assume that Grandma has a /29 (or
larger) and cede that there must be a SWIP and that the proper
technical/abuse contact is in fact PlatinumCo. A similar scenario
might be if Grandma buys from Joes B&E and then hires ManageCo to
install and maintain her PC/Network - in this case ManageCO is very
likely the proper technical/abuse contact and I agree that Grandma
should be free to designate them as such. I also don't think that
current policy precludes this - maybe I missed the part that says
every POC must be Grandma (or even in her direct employ; contractors,
etc are often made POCs I assume).

There is of course more than one reason to list end-users in whois, my
primary concern (and the one that I have raised so far) is with valid
technical and abuse contacts. The other two raised in RFC 2050 above
are; justification of efficient use and research data. The second and
third apply more directly in your scenario.

Justification of efficient use can be handled by DP 2010-3's inclusion
of the line: "The customer's actual information must be provided to
ARIN on request..." For now we will ignore the increased burden this
likely puts on ARIN staff when evaluating new requests.

Access to information for IP allocation (and other similar) studies is
not well served by private data however. It is in the best interest of
the Internet for it to be studied and I think that we should
facilitate that whenever possible.

>
> I don't understand how Stewardship requires us to pick one business
> model over the over.

We should not pick one business model over another, we should write
clear policy that avoids impinging upon any responsible model.

Asking for a valid POC at the entity controlling a network does
nothing to establish or impede anyone's business model, with the
possible exception of those bad actors who have cause to remain
unknown (namely so they can jump from block to block causing
mischief).

Recording general customer data in whois does not stop either of the
models you suggested above from operating either.

I am far from convinced that having this data in whois has any
negative impact, other than maybe a bit of extra spam - which is an
except-able price for the rewards of a proper whois database, IMHO.

~Chris

>
> --
>       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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From lar at mwtcorp.net  Tue Feb  2 18:56:53 2010
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Tue, 02 Feb 2010 16:56:53 -0700
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
Message-ID: <web-17195031@be2.mail.trib.com>


> 
> I do not think that ARIN is in the business of defending the secrecy of 
>customer lists.  Keeping your customers should be a matter of competitive 
>pricing and quality of service, not sequestering your customers in a closet 
>or keeping them in a walled garden.  Free enterprise is part and parcel of 
>doing business on the internet.

ARIN should not be in the business of telling every ISP how to run the 
day-to-day
operations of their business. Each has their own strategies and it's none of
any of our business what they are. Free enterprise means that everyone may
enter the marketplace and attempt to gather customers to them. Existing 
organizations
can use any lawful means to keep existing customers. You or I may not like
some of those practices but free means free.

There needs to be some overriding issue that outweighs all normal 
considerations
before a group like ARIN should impact the internal operations of the 
associated
enterprises.
The scarcity of IPV4 was and is such a issue. That justifies ARIN requiring 
ISP's to
disclose enough information to determine that each is utilizing the scarce 
resource
in a responsible manner. That does not in my opinion justify requiring 
making that
information public.As an ISP I am exposed to the public and must be 
accountable,
that goes with the teritory, but if I assign  ip addresses for lawful use to 
a
law enforcement agency, or a battered women's home, or runaway children's 
home
(the list goes on and on) each has valid reasons why they don't want even 
their
names associated with the IP's they are using. Even an ongoing DOS attack
(which is highly unlikely) does not justify the risks associated with the 
wrong
people figuring out where that IP is at.

99.9% of the time it's no big deal but any policy that cannot easily deal
with the 0.1% exception is bad policy and should not exist. That
is my opinion of the current policy.

This proposal, while not going far enough, is at least a step in the right 
direction.


> Hiding community members from contact by prospective service offerings is 
>not included anywhere in the ARIN mission statement that I could see.
> 

I don't seem to remember congress acting on the ARIN mission statement. It's
a private mission statement and not law. It should not be tortured into
having an opinion on each proposed policy.


The longer I am on this list the more I am beginning to feel that ARIN
is a growing bureaucracy that will become the enemy of ISP's and the
internet community as a whole.


Sometimes I think I'm watching an episode of "pinky and the brain" via 
email.

> 
> 
> _______________________________________________
> 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 kkargel at polartel.com  Tue Feb  2 19:13:18 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 2 Feb 2010 18:13:18 -0600
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <web-17195031@be2.mail.trib.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<web-17195031@be2.mail.trib.com>
Message-ID: <8695009A81378E48879980039EEDAD28876D3FDB@MAIL1.polartel.local>

> >
> > I do not think that ARIN is in the business of defending the secrecy of
> >customer lists.  Keeping your customers should be a matter of competitive
> >pricing and quality of service, not sequestering your customers in a
> closet
> >or keeping them in a walled garden.  Free enterprise is part and parcel
> of
> >doing business on the internet.
> 
> ARIN should not be in the business of telling every ISP how to run the
> day-to-day
> operations of their business. Each has their own strategies and it's none
> of
> any of our business what they are. Free enterprise means that everyone may
> enter the marketplace and attempt to gather customers to them. Existing
> organizations
> can use any lawful means to keep existing customers. You or I may not like
> some of those practices but free means free.

Umm, I think ARIN is precisely in the business of managing and shepherding IP addresses.  If you don't want to follow the rules for that then you are just going to have to find a way to run your ISP without IP addresses.  

> 
> There needs to be some overriding issue that outweighs all normal
> considerations
> before a group like ARIN should impact the internal operations of the
> associated
> enterprises.
> The scarcity of IPV4 was and is such a issue. That justifies ARIN
> requiring
> ISP's to
> disclose enough information to determine that each is utilizing the scarce
> resource
> in a responsible manner. That does not in my opinion justify requiring
> making that
> information public.As an ISP I am exposed to the public and must be
> accountable,
> that goes with the teritory, but if I assign  ip addresses for lawful use
> to
> a
> law enforcement agency, or a battered women's home, or runaway children's
> home
> (the list goes on and on) each has valid reasons why they don't want even
> their
> names associated with the IP's they are using. Even an ongoing DOS attack
> (which is highly unlikely) does not justify the risks associated with the
> wrong
> people figuring out where that IP is at.

In associations that I have had with covert law enforcement and with organizations like abuse shelters (women's or otherwise) they have always had DBA names for registration of things like phone numbers, mailing addresses, email, etc..  I don't see why this would be any different..   

> 
> 99.9% of the time it's no big deal but any policy that cannot easily deal
> with the 0.1% exception is bad policy and should not exist. That
> is my opinion of the current policy.

Can you point me to a single policy in any organization that deals completely with 100% of any possible situation and does it fairly and optimally?


> 
> This proposal, while not going far enough, is at least a step in the right
> direction.
> 
> 
> > Hiding community members from contact by prospective service offerings
> is
> >not included anywhere in the ARIN mission statement that I could see.
> >
> 
> I don't seem to remember congress acting on the ARIN mission statement.
> It's
> a private mission statement and not law. It should not be tortured into
> having an opinion on each proposed policy.

I don't see where anyone referred to any of this as a law.  Do I understand you correctly as saying that ARIN should not have an opinion on each proposed policy?  

ARIN covers more territory than the USA..  Or are you saying that Canada and the Caribbean fall under US law?

> 
> 
> The longer I am on this list the more I am beginning to feel that ARIN
> is a growing bureaucracy that will become the enemy of ISP's and the
> internet community as a whole.
> 
> 
> Sometimes I think I'm watching an episode of "pinky and the brain" via
> email.
> 
> >
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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 tony at lava.net  Tue Feb  2 19:45:32 2010
From: tony at lava.net (Antonio Querubin)
Date: Tue, 2 Feb 2010 14:45:32 -1000 (HST)
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <8695009A81378E48879980039EEDAD28876D3FDB@MAIL1.polartel.local>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<web-17195031@be2.mail.trib.com>
	<8695009A81378E48879980039EEDAD28876D3FDB@MAIL1.polartel.local>
Message-ID: <alpine.OSX.2.00.1002021441220.826@cust11794.lava.net>

On Tue, 2 Feb 2010, Kevin Kargel wrote:

> shepherding IP addresses.  If you don't want to follow the rules for 
> that then you are just going to have to find a way to run your ISP 
> without IP addresses.

I would hope this discussion is about finding ways to CHANGE the rules to 
be more relevant, fair, and inclusive.

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  tony at lava.net


From bicknell at ufp.org  Tue Feb  2 20:53:51 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 2 Feb 2010 17:53:51 -0800
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <443de7ad1002021555m431ded34hf8f1bb8e07740f0a@mail.gmail.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org>
	<443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
	<20100202212903.GA70818@ussenterprise.ufp.org>
	<443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
	<20100202224925.GA76402@ussenterprise.ufp.org>
	<443de7ad1002021555m431ded34hf8f1bb8e07740f0a@mail.gmail.com>
Message-ID: <20100203015351.GA86626@ussenterprise.ufp.org>

In a message written on Tue, Feb 02, 2010 at 04:55:49PM -0700, Chris Grundemann wrote:
> Correct, I believe that whois data should be both complete and
> accurate; 2008-7 addresses the latter, here we discuss the former.

For the record, I agree that whatever information the rules say should
be in whois needs to be accurate and up to date.  I support efforts to
make it so.

I will also note, one of the issues raised by staff is that with the
current level of information there are man-years of work to verify it
all.  Turning that around, if we have less information in the database
it's likely it can be verified more often, with less staff.  I suppose
that is a bit of a linkage, the more info in the database the harder it
is to keep it all accurate.

> Ok lets get more recent, this is from RFC 2050 "Internet Registry IP
> Allocation Guidelines:"
> 
> 2.2  Submission of Reassignment Information

2.2 covers that the ISP's must provide everything you quote to ARIN.
There is no requirement expressed or implied that ARIN in turn
provide all of that information to the public.

But let's break these down step by step:

>        a)  to provide operational staff with information on who is using
>            the network number and to provide a contact in case of
>            operational/security problems,

This becomes the core of the argument.  It is quite vague.

I could argue that a record of the form "Cable Modem Customers in
Detroit", "abuse at cableco.com" on a /20 satisifies this requirement.
I could also argue that even in the case of DHCP /32 assignments
in a cable network they need to be in whois so your operation staff
knows "who is using the network number".

I don't think the text really provides any strong guidence on the
standard by which this point is met.  A number of people have proposed
standards over time, and the only one that makes any sense to me is to
list the entity that is "ready, willing, and able" to handle operational
issues.

Unfortunately even on that standard I could make arguments for and
against various folks.

So, to our discussion above.  I'd rather ISP's and End Users decide
together who is, or is not listed.  I'd then like ARIN to agressively
test and verify that someone answer the phone, reply to the e-mail, etc.
That is, the useful response indicates that the person listed is right,
rather than any arbitrary standard.

>        b)  to ensure that a provider has exhausted a majority of its
>            current CIDR allocation, thereby justifying an additional
>            allocation,

Let's look at what is required of registries when making this
determination, also from 2050:

] 3.2 Network Engineering Plans
] 
] Before a registry makes an assignment, it must examine each address
] space request in terms of the requesting organization's networking
] plans. These plans should be documented, and the following information
] should be included: 
] 
]   1. subnetting plans, including subnet masks and number of hosts on 
]      each subnet for at least one year 
]   2. a description of the network topology 
]   3. a description of the network routing plans, including the routing 
]      protocols to be used as well as any limitations.
[And more]

So from an "audit" perspective, if you wanted to independantly
reconstruct that the ISP was justified in assinging a netblown
downstream you would need this documentation.  AFAIK, there has
never been any such documentation in WHOIS, and thus there has never
been any way to perform an independant audit.

Having tried to make sense of SWIP's in whois, I don't see how a third
party, armed only with whois data, could verify justification in any
way.

>        c)  to assist in IP allocation studies.

The vaguest of vague statements.  Assist how much?  Similar to point b,
without the data you can't do full independant studies, so we're already
in the weeds with respect to IP allocation studies.  Providing an entry
that a /24 is full of cable modem customers is "assisting".  Providing
/32 information is assisting.  With no objective standard, there's no
way to know what is "required".

I honestly have no idea what to make of this requirement.

> Justification of efficient use can be handled by DP 2010-3's inclusion
> of the line: "The customer's actual information must be provided to
> ARIN on request..." For now we will ignore the increased burden this
> likely puts on ARIN staff when evaluating new requests.

ARIN already collects information under NDA from those applying for
addresses.  All the diagrams and routing plans and such referenced
in 2050 are supplied under NDA and never listed in WHOIS.

I see no reason to change that.  If ARIN wants to ask for the
customer name and address under NDA, that's fine with me.  It may
be appropriate in many cases.

> I am far from convinced that having this data in whois has any
> negative impact, other than maybe a bit of extra spam - which is an
> except-able price for the rewards of a proper whois database, IMHO.

I suggest it has a chilling effect for a number of groups of people.
It may prevent various classes of people from obtaining various
classes of services.

For instance, one of the things behind residential privacy was that
a battered woman who's moved away from her spouse should be able
to get Internet access without being listed in a public database.
Another example is that America has a long history of protecting
anonymous polticial speach, but if you have to be in a public
database to host your web site then how can you have that?

But all those aside, I think the real negative impact is on the
quality of the data.  ARIN staff provided an esimtate on simply
e-mailing every contact in the database to see if the e-mail addresses
worked, and IIRC it was 3 years!  By putting so much data into whois
we've created a gigantic mountain for a proposal like 2008-7.  Rather
than verifing all the records once a year at a reasonable cost,
staff is predicting years of work and having to hire multiple FTE's
to keep the data accurate.  We're all going to pay for that in the
form of increased fees.

The devel will be in the details, but here's the compromise I am
willing to support.  If we can remove residential users from the
database completely, and provide a formal framework for ISP's to
indicate they are the abuse/noc contact for a downstream so it's
clear in the public facing database then I can support expending
much more staff effort on verifing that e-mail addresses and phone
numbers work on a regular basis.

So yes, there will be less data in the database, but it will be orders
of magnitude more likely to be correct and verified on a regular basis.
Is there some middle ground there?

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100202/ca870743/attachment.sig>

From mysidia at gmail.com  Tue Feb  2 21:30:43 2010
From: mysidia at gmail.com (James Hess)
Date: Tue, 2 Feb 2010 20:30:43 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	CustomerConfidentiality - Time Sensitive
In-Reply-To: <28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
References: <4B678017.7060300@ibctech.ca>
	<28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>

On Tue, Feb 2, 2010 at 5:26 AM,  <michael.dillon at bt.com> wrote:
> A 10th grade kid's extracurricular activities have nothing
> whatsoever to do with the school's network. We've already
> been told that this is a small photography business that
> has a server colocated with their local ISP. Since the

_A server colocated with their local ISP_   stop. One server does not
justify a /29,  it doesn't have to be SWIP'ed or listed in WHOIS.

> business owners are experts in photography, it is reasonable
> to assume that the server and networking expertise comes
> from outside the photography business. [...]
Yes.   And part of that  "networking expertise"  includes providing
someone to contact about abuse and other abuses.

> tech support as and when needed, not on retainer and not
> on-call 24x7. It is also reasonable to assume that they
If they are not on-call 24x7,  then the contact information provided
should be contact information that goes to a  "Voicemail service"
when the contact is not on call.

It is not an issue with the registry if someone chose to provide a
phone number capable of disrupting an  off-call admin.   Generally,
the phone numbers used should be ones that belong to the organization,
 that only work when an admin is available.

Important networks should have someone on call 24x7.

> Why on earth do you want to polute the whois directory with
> thousands of phone numbers for 10th grader's mobile phones?

This is a classic example of a straw man argument.
In no way, shape or form, does current policy imply polluting the
directory with 10th graders'   mobile phone numbers.

Nothing says mobile phones must be in the directory.    No ARIN policy
says that contacts must be reachable  24x7,  or that mobile phone
numbers must be provided.

It is advisable that someone be available to answer the phone 24x7 for
the contact number,  for important networks,  it is not required.

The contact doesn't have to be one person,  and  hiring or otherwise
providing contacts  is part of the cost you bear in connecting to the
internet.

Even if your network is too small for a SWIP or WHOIS listing to be
required,  legitimate ISPs/collocation providers  always require a
phone number.

And the collocated server adminned by the 10th grader  might get
turned off, if the number provided to the ISP  does not get answered,
even without SWIP listings of contacts.

> Then the whois directory needs a system for recording stuff like:
> "Technical contact is attending school between the hours of
> 8:30 to 4:30 EST, Mondays thru Fridays. Saturdays from 10:00 to
> 12:00 he is playing baseball. Contactable at (604)555-1234
> other times except when he is on a hot date which is most
> likely Thursday thru Saturday evenings EST."

That's called unpredictable availability of the technical contact. It
is not suitable for important networks,  but there is no ARIN rule
against it.

The  dedicated 'phone number'  provided to ARIN for WHOIS can simply
contain a voicemail message explaining it,  when called while the
contact is out.

I  believe there is a  "Comment:"  attribute provided by WHOIS.
It could be populated via SWIP,  or  the ISP could populate its whois
server with that.


--
-J


From bicknell at ufp.org  Tue Feb  2 21:46:19 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Tue, 2 Feb 2010 18:46:19 -0800
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	CustomerConfidentiality - Time Sensitive
In-Reply-To: <6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>
References: <4B678017.7060300@ibctech.ca>
	<28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
	<6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>
Message-ID: <20100203024619.GA91971@ussenterprise.ufp.org>

In a message written on Tue, Feb 02, 2010 at 08:30:43PM -0600, James Hess wrote:
> _A server colocated with their local ISP_   stop. One server does not
> justify a /29,  it doesn't have to be SWIP'ed or listed in WHOIS.

Actually....

I have seen some colo ISP's that put every customer in a separate
VLAN.  Typically they feed these two two routers, running VRRP or
HSRP.  So a single server needs a subnet with space for 4 devices,
router1, router2, virtual gateway, and server IP address.  The
smallest subnet that can do that is a /29.

So, it is possible for a single colocated server to consume a /29.
Not everyone does it that way, of course.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100202/6d98191a/attachment.sig>

From mysidia at gmail.com  Tue Feb  2 21:58:20 2010
From: mysidia at gmail.com (James Hess)
Date: Tue, 2 Feb 2010 20:58:20 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA590@Skyhawk>
References: <3c3e3fca1002020852q22a3626ct8ae1fa8790bcb961@mail.gmail.com>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA590@Skyhawk>
Message-ID: <6eb799ab1002021858w52c817adlfc660f66e429e49e@mail.gmail.com>

On Tue, Feb 2, 2010 at 11:52 AM, Chris Engel
<cengel at sponsordirect.com> wrote: > Bill Herrin wrote:
> "Chris,
> That's great...but I'm not sure how exactly having Joe's contact info really helps you determine whether his /14 is justified?
> As a member of the general public... you can't FORCE Joe to speak with you, right?

You can't FORCE him to physically.    But  when  Joe wants to peer
with your network or get transit from you,  your contact can ask his
contact a few questions  before you agree to let him link up with you
and announce that /24.

Networks are not islands.    Joe's network is not a self-contained
entity like a private  castle.    Members of the public have to be
willing to interact with Joe's network,   e.g. other networks have to
let Joe's traffic pass through,  for Joe to have connectivity using
that IP space.

If many members of the public decide that Joe is not legitimate, and
they will block his use of those addresses, and refuse to peer with
him and receive that /24 prefix,  then  Joe  will have limited or no
connectivity.



You can use WHOIS contacts to assist in investigating Joe's claim that
his organization  has been assigned this /24.

WHOIS may also be used by DNSBLs investigating reports that usages of
certain IP ranges are 'hijacked'.

Joe  can't simply enter  demonstrably  false  info into the WHOIS
database and expect there to never ever be any negative consequences
as a result of that.

The fact the data is public could serve as a deterrant to entering
obviously false info.

--
-J


From gbonser at seven.com  Tue Feb  2 22:00:22 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 2 Feb 2010 19:00:22 -0800
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <20100203024619.GA91971@ussenterprise.ufp.org>
References: <4B678017.7060300@ibctech.ca><28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net><6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>
	<20100203024619.GA91971@ussenterprise.ufp.org>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F759D@RWC-EX1.corp.seven.com>

> 
> So, it is possible for a single colocated server to consume a /29.
> Not everyone does it that way, of course.
> 
> --
>        Leo Bicknell - bicknell at ufp.org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/

It is possible for a PROVIDER to consume a /29 in providing a single
server.  The end user isn't issued a /29 for addressing their machines.
The end user in this case is issued a single IP address.

I am sure we can all make up wacky corner cases or twist things around
but that isn't what is at issue here, nobody expects perfection under
all cases.




From joe at joesdatacenter.com  Tue Feb  2 22:11:40 2010
From: joe at joesdatacenter.com (Joe Morgan)
Date: Tue, 2 Feb 2010 21:11:40 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	CustomerConfidentiality - Time Sensitive
In-Reply-To: <20100203024619.GA91971@ussenterprise.ufp.org>
References: <4B678017.7060300@ibctech.ca>
	<28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
	<6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>
	<20100203024619.GA91971@ussenterprise.ufp.org>
Message-ID: <38dd4e411002021911r777165ecxe2361d0a86e6b3c3@mail.gmail.com>

The colo industry or dedicated server industry almost always gives at
least a /29. Most customers will need multiple ips for things like
name servers, ssl certs, ect. I believe I can safely say that it is
almost a industry standard.  I can tell you from my experience the
customer is not going to be nearly as responsive as I am to security
or abuse complaints. I would much rather be able to put my contact
information for abuse than the customers for multiple reasons. My
company watches the abuse system 24/7 365 and needs to know about all
security or abuse complaints. If the customer is directly contacted
then how am I going to know that there is somebody on my network
violating my AUP? If you cannot get the abuse contact to answer your
complaints your just going to end up sending the complaint to me
anyway. I really cannot see how the address of phone number helps in
verifying accurate data, that can be just as accurate or inaccurate as
a company name. If you try and contact a customer and are unsatisfied
or cannot verify the data your just going to end up contacting me
about it. If I put my contact information down at least I know that I
am doing my part and providing accurate contact information so abuse
and security complaints can be handled quickly. At the end of the day
I am ultimately responsible for what happens on my network and I have
the best idea of what or how abuse should be handled so why shouldn't
I be in charge of deciding what that contact information is.
I think part of the problem is that people just want to get there
noses in other peoples business and for some reason feel that it is
there right to know my customers information. I really don't see why
anyone needs to know my customer list besides me.


On Tue, Feb 2, 2010 at 8:46 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Tue, Feb 02, 2010 at 08:30:43PM -0600, James Hess wrote:
>> _A server colocated with their local ISP_ ? stop. One server does not
>> justify a /29, ?it doesn't have to be SWIP'ed or listed in WHOIS.
>
> Actually....
>
> I have seen some colo ISP's that put every customer in a separate
> VLAN. ?Typically they feed these two two routers, running VRRP or
> HSRP. ?So a single server needs a subnet with space for 4 devices,
> router1, router2, virtual gateway, and server IP address. ?The
> smallest subnet that can do that is a /29.
>
> So, it is possible for a single colocated server to consume a /29.
> Not everyone does it that way, of course.
>
> --
> ? ? ? 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.
>



-- 
Thank You,
Joe Morgan
Joe's Datacenter, LLC
http://joesdatacenter.com


From gbonser at seven.com  Tue Feb  2 22:21:01 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 2 Feb 2010 19:21:01 -0800
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <38dd4e411002021911r777165ecxe2361d0a86e6b3c3@mail.gmail.com>
References: <4B678017.7060300@ibctech.ca><28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net><6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com><20100203024619.GA91971@ussenterprise.ufp.org>
	<38dd4e411002021911r777165ecxe2361d0a86e6b3c3@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F759F@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Joe Morgan
> Sent: Tuesday, February 02, 2010 7:12 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Petition Underway - Policy Proposal
> 95:CustomerConfidentiality - Time Sensitive
> 
> I can tell you from my experience the
> customer is not going to be nearly as responsive as I am to security
> or abuse complaints. 

Being responsive is a good thing.  But can you actually DO anything
about it? Again, I am mainly talking about someone who was SWIPed a /24
or better but doesn't even announce it to you anymore.  They might have
some colo space with you and maintain a relationship, but that specific
network is possibly in a different facility and the traffic possibly
doesn't even go through you.  You might answer your phone, but can you
actually do anything?  And the extent to which the user is responsive or
not might have different consequence depending on the reason I am trying
to contact them.  If they are losing traffic, it is their loss if they
aren't responsive.  If they are engaged in nefarious activity and aren't
responsive, I want to know what other blocks they have so I can monitor
those as well.  And I want to know who they are so when they move out of
your net into someone else's, I can follow where they go.

> I would much rather be able to put my contact
> information for abuse than the customers for multiple reasons. 

I have no problem with you putting your contact in for the abuse
contact.  That might be a great idea.  But when it comes to the
technical contact, I want the person with "enable" and "root" on their
stuff.  If that is you, then by all means put your name in the tech
contact, too.  



From mysidia at gmail.com  Tue Feb  2 22:21:27 2010
From: mysidia at gmail.com (James Hess)
Date: Tue, 2 Feb 2010 21:21:27 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	CustomerConfidentiality - Time Sensitive
In-Reply-To: <38dd4e411002021911r777165ecxe2361d0a86e6b3c3@mail.gmail.com>
References: <4B678017.7060300@ibctech.ca>
	<28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
	<6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>
	<20100203024619.GA91971@ussenterprise.ufp.org>
	<38dd4e411002021911r777165ecxe2361d0a86e6b3c3@mail.gmail.com>
Message-ID: <6eb799ab1002021921u4c910e11mbd84e8fee2b1078e@mail.gmail.com>

On Tue, Feb 2, 2010 at 9:11 PM, Joe Morgan <joe at joesdatacenter.com> wrote:
> The colo industry or dedicated server industry almost always gives at
> least a /29. Most customers will need multiple ips for things like

I'm under the impression the colo industry usually  re-assigns a /29
to itself, and sub-delegates  several IP addresses from that /29  to
the customer. Unless there is a customer router involved,  the entire
block has not been subdelegated.

> almost a industry standard. ?I can tell you from my experience the
> customer is not going to be nearly as responsive as I am to security
> or abuse complaints. I would much rather be able to put my contact

Most abuse complaints will get addressed to the upstream too.  I've
seen e-mail abuse complaints before,  and senders are usually very
liberal in whom they CC.

The upstream providers, and sometimes even ARIN itself are almost always Cc'd.

> information for abuse than the customers for multiple reasons. My
> company watches the abuse system 24/7 365 and needs to know about all
> security or abuse complaints. If the customer is directly contacted
> then how am I going to know that there is somebody on my network

By listing yourself as  the official abuse contact when SWIP'ing.
Or on your  RWHOIS server,  where you have more direct control of what
gets listed.

Include the item as one of the terms of the collocation agreement,
that you will provide the 24x7  abuse contact for the IP space,   and
that the customer must provide you as one as well.

If an ISP wishes to do this,  the current text of the NRPM  does not
stop or prevent the ISP from including themselves as an additional
contact  on the SWIP record.

-- 
-Mysid


From joe at joesdatacenter.com  Tue Feb  2 22:21:54 2010
From: joe at joesdatacenter.com (Joe Morgan)
Date: Tue, 2 Feb 2010 21:21:54 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <6eb799ab1002021858w52c817adlfc660f66e429e49e@mail.gmail.com>
References: <3c3e3fca1002020852q22a3626ct8ae1fa8790bcb961@mail.gmail.com>
	<F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA590@Skyhawk>
	<6eb799ab1002021858w52c817adlfc660f66e429e49e@mail.gmail.com>
Message-ID: <38dd4e411002021921l24aa32f8tc94f1c2f073a4bd7@mail.gmail.com>

> WHOIS may also be used by DNSBLs investigating reports that usages of
> certain IP ranges are 'hijacked'.
>
> Joe  can't simply enter  demonstrably  false  info into the WHOIS
> database and expect there to never ever be any negative consequences
> as a result of that.
>
> The fact the data is public could serve as a deterrant to entering
> obviously false info.

Just my 2 cents
I have had DNSBLS been mistaken by trying to piece together
information by scanning swips or rdns and not directly contacting me.
I have seen them claim to know that a customer is a spammer or is
using a false name without knowing any information about when the
customer went online or if I have already removed a old customer that
violated my AUP. Just because DNSBLS use this information does not
mean its there right or that they even do a accurate job. I could also
argue that because the information is public it makes it more likely
that people would try and hide or falsify it.


On Tue, Feb 2, 2010 at 8:58 PM, James Hess <mysidia at gmail.com> wrote:
> On Tue, Feb 2, 2010 at 11:52 AM, Chris Engel
> <cengel at sponsordirect.com> wrote: > Bill Herrin wrote:
>> "Chris,
>> That's great...but I'm not sure how exactly having Joe's contact info really helps you determine whether his /14 is justified?
>> As a member of the general public... you can't FORCE Joe to speak with you, right?
>
> You can't FORCE him to physically. ? ?But ?when ?Joe wants to peer
> with your network or get transit from you, ?your contact can ask his
> contact a few questions ?before you agree to let him link up with you
> and announce that /24.
>
> Networks are not islands. ? ?Joe's network is not a self-contained
> entity like a private ?castle. ? ?Members of the public have to be
> willing to interact with Joe's network, ? e.g. other networks have to
> let Joe's traffic pass through, ?for Joe to have connectivity using
> that IP space.
>
> If many members of the public decide that Joe is not legitimate, and
> they will block his use of those addresses, and refuse to peer with
> him and receive that /24 prefix, ?then ?Joe ?will have limited or no
> connectivity.
>
>
>
> You can use WHOIS contacts to assist in investigating Joe's claim that
> his organization ?has been assigned this /24.
>
> WHOIS may also be used by DNSBLs investigating reports that usages of
> certain IP ranges are 'hijacked'.
>
> Joe ?can't simply enter ?demonstrably ?false ?info into the WHOIS
> database and expect there to never ever be any negative consequences
> as a result of that.
>
> The fact the data is public could serve as a deterrant to entering
> obviously false info.
>
> --
> -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.
>



-- 
Thank You,
Joe Morgan
Joe's Datacenter, LLC
http://joesdatacenter.com


From scottleibrand at gmail.com  Tue Feb  2 22:28:00 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 02 Feb 2010 19:28:00 -0800
Subject: [arin-ppml] Petition Underway - Policy Proposal
 95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F759D@RWC-EX1.corp.seven.com>
References: <4B678017.7060300@ibctech.ca><28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net><6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>	<20100203024619.GA91971@ussenterprise.ufp.org>
	<5A6D953473350C4B9995546AFE9939EE081F759D@RWC-EX1.corp.seven.com>
Message-ID: <4B68ED40.9080409@gmail.com>

On 2/2/2010 7:00 PM, George Bonser wrote:
>> So, it is possible for a single colocated server to consume a /29.
>> Not everyone does it that way, of course.
>>
>>         Leo Bicknell - bicknell at ufp.org - CCIE 3440
>>
>>      
> It is possible for a PROVIDER to consume a /29 in providing a single
> server.  The end user isn't issued a /29 for addressing their machines.
> The end user in this case is issued a single IP address.
>    

The end user may not use more than a single address in that case, but 
they will be assigned the entire /29, and it should be SWIP'd to them 
(or entered in rwhois).  If they add a second server in the same VLAN, 
it will be added to that /29, but the assignment will not change.

If I, as a colo provider, didn't SWIP customers like this their entire 
/29, I may not be able to meet 80% utilization thresholds.  For purposes 
of calculating utilization, however, the /29 is considered 100% utilized 
as long as it was properly justified, could not be met with a smaller 
subnet, and is properly SWIP'd (or rwhois'd).

-Scott



From gbonser at seven.com  Tue Feb  2 23:07:28 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 2 Feb 2010 20:07:28 -0800
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <4B68ED40.9080409@gmail.com>
References: <4B678017.7060300@ibctech.ca><28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net><6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>	<20100203024619.GA91971@ussenterprise.ufp.org><5A6D953473350C4B9995546AFE9939EE081F759D@RWC-EX1.corp.seven.com>
	<4B68ED40.9080409@gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F75A2@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Scott Leibrand
> Sent: Tuesday, February 02, 2010 7:28 PM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Petition Underway - Policy Proposal
> 95:CustomerConfidentiality - Time Sensitive
> 
> On 2/2/2010 7:00 PM, George Bonser wrote:
> >> So, it is possible for a single colocated server to consume a /29.
> >> Not everyone does it that way, of course.
> >>
> >>         Leo Bicknell - bicknell at ufp.org - CCIE 3440
> >>
> >>
> > It is possible for a PROVIDER to consume a /29 in providing a single
> > server.  The end user isn't issued a /29 for addressing their
> machines.
> > The end user in this case is issued a single IP address.
> >
> 
> The end user may not use more than a single address in that case, but
> they will be assigned the entire /29, and it should be SWIP'd to them
> (or entered in rwhois).  If they add a second server in the same VLAN,
> it will be added to that /29, but the assignment will not change.

If all they have is a single IP address, then I am probably not going to
be trying to contact them anyway.  But if you don't have root on that
server, listing you as the technical POC is a waste of your time and
mine.  But that is what I consider a corner case because most of the IP
addresses are on your routers in that one special case, not their gear
so it is a gray area and, in my opinion, an interesting but distracting
case in the overall scope of this discussion.



From bill at herrin.us  Tue Feb  2 23:40:59 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 2 Feb 2010 23:40:59 -0500
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <20100203015351.GA86626@ussenterprise.ufp.org>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local> 
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com> 
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com> 
	<20100202203622.GA66264@ussenterprise.ufp.org>
	<443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com> 
	<20100202212903.GA70818@ussenterprise.ufp.org>
	<443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com> 
	<20100202224925.GA76402@ussenterprise.ufp.org>
	<443de7ad1002021555m431ded34hf8f1bb8e07740f0a@mail.gmail.com> 
	<20100203015351.GA86626@ussenterprise.ufp.org>
Message-ID: <3c3e3fca1002022040ma34e9afvf883d5c82fb25883@mail.gmail.com>

On Tue, Feb 2, 2010 at 8:53 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Tue, Feb 02, 2010 at 04:55:49PM -0700, Chris Grundemann wrote:
>> Correct, I believe that whois data should be both complete and
>> accurate; 2008-7 addresses the latter, here we discuss the former.
>
> For the record, I agree that whatever information the rules say should
> be in whois needs to be accurate and up to date. ?I support efforts to
> make it so.
>
> I will also note, one of the issues raised by staff is that with the
> current level of information there are man-years of work to verify it
> all.

I don't particularly want to pay ARIN to audit me and require me to
spend more money proving the legitimacy of my IP address consumption.
I'm just cheap that way.

Our system is far more cost-effective and a lot less of a hassle if
ARIN instead presumes truthfulness on the part of its registrants and
reacts to complaints from the self-appointed community watchdogs who
invariably manage to notice and bust the folks doing wrong. Thing is,
community watchdogs can't catch bad guys from a void: they have to
have data that can be verified or refuted.

Perhaps a *fair* solution is that ISPs who would rather suffer
penetrating annual audits purchased by ARIN at the ISP's expense can
forgo publishing customer information via SWIP while those who place
their information in the public's hands remain relieved of that
burden.

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 dogwallah at gmail.com  Wed Feb  3 00:06:33 2010
From: dogwallah at gmail.com (McTim)
Date: Wed, 3 Feb 2010 08:06:33 +0300
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
Message-ID: <f65fb55e1002022106x7ef97a7dk32cce362b3a98af7@mail.gmail.com>

On Tue, Feb 2, 2010 at 11:05 PM, Chris Grundemann <cgrundemann at gmail.com> wrote:
<snip>
>
> +1
>
> whois must contain valid contact information for the person/entity
> directly responsible for the host(s) using a given IP. I oppose this
> and any other policy which undermines this fundamental requirement.

+1

-- 
Cheers,

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


From gbonser at seven.com  Wed Feb  3 02:16:41 2010
From: gbonser at seven.com (George Bonser)
Date: Tue, 2 Feb 2010 23:16:41 -0800
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <3c3e3fca1002022040ma34e9afvf883d5c82fb25883@mail.gmail.com>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org><443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
	<20100202212903.GA70818@ussenterprise.ufp.org><443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
	<20100202224925.GA76402@ussenterprise.ufp.org><443de7ad1002021555m431ded34hf8f1bb8e07740f0a@mail.gmail.com>
	<20100203015351.GA86626@ussenterprise.ufp.org>
	<3c3e3fca1002022040ma34e9afvf883d5c82fb25883@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F75AA@RWC-EX1.corp.seven.com>

> Perhaps a *fair* solution is that ISPs who would rather suffer
> penetrating annual audits purchased by ARIN at the ISP's expense can
> forgo publishing customer information via SWIP while those who place
> their information in the public's hands remain relieved of that
> burden.
> 
> Regards,
> Bill Herrin

For me the judgment call seems fairly simple.

>From the standpoint of someone who isn't a commercial ISP

what benefit does this proposal offer me?
What is the value of that benefit?

What is the benefit to the community at large of the proposal?
What is the value of that benefit?

What is the cost to the community of the proposal?

What is the cost to me of the proposal?


And then the question of whether to support it or not is weighed.  I
keep coming up with little/no benefit, high cost.




From mysidia at gmail.com  Wed Feb  3 02:54:03 2010
From: mysidia at gmail.com (James Hess)
Date: Wed, 3 Feb 2010 01:54:03 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:CustomerConfidentiality - Time Sensitive
In-Reply-To: <4B68ED40.9080409@gmail.com>
References: <4B678017.7060300@ibctech.ca>
	<28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
	<6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>
	<20100203024619.GA91971@ussenterprise.ufp.org>
	<5A6D953473350C4B9995546AFE9939EE081F759D@RWC-EX1.corp.seven.com>
	<4B68ED40.9080409@gmail.com>
Message-ID: <6eb799ab1002022354q29e029i6d89302cb15022b@mail.gmail.com>

On Tue, Feb 2, 2010 at 9:28 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On 2/2/2010 7:00 PM, George Bonser wrote:
> If I, as a colo provider, didn't SWIP customers like this their entire /29,
> I may not be able to meet 80% utilization thresholds. ?For purposes of
> calculating utilization, however, the /29 is considered 100% utilized as

It's possible to  keep record of utilization using  the form in sec.
4.2.3.7.5  of the NRPM  without SWIPing    -- where a full /29 block
is not re-assigned.

SWIPs  submitted to ARIN are not  (or should not)  be your only
records or way of keeping proper information about re-assignments  for
justifying additional allocation requests,  since most  ISPs and
end-users will have some allocations or assignments of blocks smaller
than /29.
e,g  it might look like

City 	Which IP Addresses Assigned 	No. of Internal Machines 	Purpose:
(CITY)            *192.0.0.0                          1
                            Collocated
                        192.0.0.1
                                  (Customer
                        192.0.0.2
                                    Name) -
                        192.0.0.3
                              4 customer IPs
                        192.0.0.4
                              4 provider
                        192.0.0.5
                                 IPs
                        192.0.0.6
                       *192.0.0.7

So, you have   4  IPs    that are part of the service provider's
network  192.0.0.0 and  192.0.0.7 broadcast addresses required for
your router,    plus  your 2  router IPs  for their  servers to use as
gateway.  Then 4 customer IPs, for their server.

It may be more convenient to just SWIP the entire /29,  provider IPs and all..
but then again,  this will  show the customer as  'responsible' for
some collocation provider router IPs then,  which might be
undesirable.


In this case... you have 100% utilized the /29.
You assigned 4 IPs to your equipment, and you delegated an address
block equivalent in allocation size of a /30 to the user  (probably
192.0.0.3 to 6).

The end-user's network block is  smaller than a  /29,  so  no SWIP
would be required under NRPM 4.2.3.7.2.

Your router on your premises...   and your inefficiency.
Now  if you peered with a customer router over a /30, and forwarded a
/29,  that would  indicate  reassignment of a full /29.


--
-J


From michael.dillon at bt.com  Wed Feb  3 07:57:13 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 3 Feb 2010 12:57:13 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <F55FF9C4FDB76643AE0CEC06D0F5CEB3048D8EA58E@Skyhawk>
Message-ID: <28E139F46D45AF49A31950F88C4974580507AE81@E03MVZ2-UKDY.domain1.systemhost.net>


> With my company....which is definately a real enterprise... 
> you'll see our business contact info listed. If you hit 
> those, you are NOT going to get a response outside of normal 
> business hours. 

This implies that everything is fine DURING business hours.
But that is not so. If the business is in Quebec, then during
business hours it will likely be answered in French, and if
you don't speak French, there will be a failure to communicate.
Even in the USA, there are businesses where people speak only 
Spanish or some other language. Even a manned phone number is
not a magic bullet now that the Internet has grown to embrace
all aspects of human society. I wouldn't be surprised to find
that Innuit-owned businesses in Nunavut are online with their
own colocated server down south. Anyone you know who speaks
Inuinnaqtun?

--Michael Dillon


From michael.dillon at bt.com  Wed Feb  3 08:07:58 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 3 Feb 2010 13:07:58 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <201002021845.o12IjH5k025052@inana.itg.state.mn.us>
Message-ID: <28E139F46D45AF49A31950F88C4974580507AEB4@E03MVZ2-UKDY.domain1.systemhost.net>



>    In the end though, when I SWIP IP's to a customer they are now the
>    proprietor of those IP's and I need to follow their instructions on
>    how those IP's are registered.  If my customer requests that I be
>    the tech or abuse contact and they are paying me money then I will
>    happily do so.  If they want to be the contact then that is how it
>    will be.

This describes a customer who is READY and WILLING to act upon 
communications about network issues. It does not include ABLE, but
in any case, I would not want to see the ISP making the determination
whether their customer is ABLE or not. That should be done by ARIN,
perhaps simply by testing the contact info every 6 months. If they
respond, then assume that they are ABLE to act.

--Michael Dillon


From michael.dillon at bt.com  Wed Feb  3 08:14:58 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 3 Feb 2010 13:14:58 -0000
Subject: [arin-ppml] Draft policy 2010-3
In-Reply-To: <8aeeaff61002021136o4b83ca7t2b82f8be997bbd7a@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C4974580507AEC9@E03MVZ2-UKDY.domain1.systemhost.net>

>  "The customer's actual information must be provided to ARIN 
> on request and will be held in the strictest confidence."
> 
> 
> The wording of 2010-3:  I think that the "on request" should 
> be a mandatory requirement. ARIN should not have to request it.

ARIN policy should not dictate staff processes. The process in 
question is for the hostmaster to send an email saying that the
application was received but they would like to see a full list
of all assignments down to the last /32. A short time later, the
applicant sends a CSV file and the total man-hours spent on this
"on request" business is about 5 minutes.

I know this because I have received several such requests.
It's not a problem and it is unrelated to policy.

--Michael Dillon


From jmaimon at chl.com  Wed Feb  3 08:55:50 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Wed, 03 Feb 2010 08:55:50 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the	NRPM
In-Reply-To: <4B683AAD.4020502@arin.net>
References: <4B683AAD.4020502@arin.net>
Message-ID: <4B698066.6010604@chl.com>

I support this policy proposal, as it conforms to my viewpoint that 
numbers cannot confer rights of property in any way, allocations are 
only an entry in a database operated and owned by a registrar and any 
impact registrars have on the configuration of routers and hosts and the 
operating of networks is due to consensus and not force of law.

While my viewpoint would favor stronger language on the subject than is 
contained in the proposal, it is a significant step in the right direction.

Thanks David.

Joe



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.
>
> Draft Policies and Proposals under discussion can be found 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
>
> 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 108: Eliminate the term license in the NRPM
>
> Proposal Originator: David Farmer
>
> Proposal Version: 1.0
>
> Date: 2 February 2010
>
> Proposal type: modify
>
> Policy term: Permanent
>
> Policy statement:
>
> Delete section 6.4.1 and replace with a new section;
>
> 1.1 Number resources are not property
>
> To serve the interests of the Internet community as a whole, number
> resources are not property (real, personal, or intellectual). The
> allocation and assignment of IP addresses, ASNs, and other number
> resources are subject to the terms of the ARIN Registration Services
> Agreement, the policies in this document, and any amendments as may be
> made to either one.
>
> Modify section 11.4 by removing ?on a lease/license basis?, leaving the
> following;
>
> 11.4 Resource Allocation Term and Renewal
>
> The Numbering Resources are allocated for a period of one year. The
> allocation can be renewed on application to ARIN providing information
> as per Detail One. The identity and details of the applicant and the
> allocated Numbering Resources will be published under the conditions of
> ARIN's normal publication policy. At the end of the experiment,
> resources allocated under this policy will be returned to the available
> pool.
>
> Rationale:
>
> As part of the discussion of Policy Proposal #106 the issue of the use
> of the term ?license? in section 6.4.1 and that it is not likely in
> harmony with the ARIN Registration Services Agreement was recognized.
> The AC feels that this issue is important enough to make it a separate
> Draft Policy that stands on its own.
>
> This section could not be fixed by simple editorial changes and it
> requires a complete rewrite in order to fix the issues. It was further
> recognized that the concept that ?Number resources are not property? is
> not exclusively an IPv6 issue and should be moved out of section 6, so
> that it is clear that it applies to all number resources.
>
> Finally, the rest of the NRPM was searched for any additional uses of
> the term ?license?. One additional use was found in section 11.4, in
> this case deleting it and a few other words surrounding it, fixes the
> issue without significantly changing the meaning of the section.
>
> 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 kkargel at polartel.com  Wed Feb  3 11:29:45 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Wed, 3 Feb 2010 10:29:45 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <28E139F46D45AF49A31950F88C4974580507AEB4@E03MVZ2-UKDY.domain1.systemhost.net>
References: <201002021845.o12IjH5k025052@inana.itg.state.mn.us>
	<28E139F46D45AF49A31950F88C4974580507AEB4@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <8695009A81378E48879980039EEDAD28876D3FE6@MAIL1.polartel.local>


> -----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, February 03, 2010 7:08 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95
> 
> 
> 
> >    In the end though, when I SWIP IP's to a customer they are now the
> >    proprietor of those IP's and I need to follow their instructions on
> >    how those IP's are registered.  If my customer requests that I be
> >    the tech or abuse contact and they are paying me money then I will
> >    happily do so.  If they want to be the contact then that is how it
> >    will be.
> 
> This describes a customer who is READY and WILLING to act upon
> communications about network issues. It does not include ABLE, but
> in any case, I would not want to see the ISP making the determination
> whether their customer is ABLE or not. That should be done by ARIN,
> perhaps simply by testing the contact info every 6 months. If they
> respond, then assume that they are ABLE to act.

Wow.  Thinking how much that would cost or what sort of staff it would take..  To pull random meaningless numbers out of my {hat} if there were 12000 PoC's and it took two minutes to check each PoC that would be about 10 man weeks (400 man hours) of ARIN staff and long distance time for each pass if everything went perfectly.  

I suspect there are many more Poc's than that.  It's a nice idea but I don't see how it would be workable.

Personally I would not gripe too hard if there were a semi-annual refresh email with a 'click to verify' link that updated an entry in the PoC record.  Even that would add up to a lot of time invested by the community but not too bad individually.

Kevin



From rudi.daniel at gmail.com  Wed Feb  3 11:45:42 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Wed, 3 Feb 2010 12:45:42 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 56, Issue 18
In-Reply-To: <mailman.744.1265183646.30980.arin-ppml@arin.net>
References: <mailman.744.1265183646.30980.arin-ppml@arin.net>
Message-ID: <8aeeaff61002030845w147ec89ek4b72fac22221a71d@mail.gmail.com>

My take on this is not whether there is whois info or not. whois info is a
must have. And accurate whois information is important to ARIN.

The system we create for collecting that info is in question as is ...what
info. is available to whom. Where a reallocation has an isp (for eg) as a
contact because the isp agrees to be, my thinking is that ARIN needs to have
all the info. on the reallocation and in many cases, the information
available to the public is not as detailed as the info. which is available
to ARIN.
We also need to decide on the level of accuracy required for ARIN records
and that ultimately  determines what we put in place. I think I'm getting
the view that the current whois database is a little way off the required
standard?? And there would seem to be much use of the or maybe abuse of the
current system as suggested by the 2006 audit.
RD




> Message: 5
> Date: Wed, 3 Feb 2010 08:06:33 +0300
> From: McTim <dogwallah at gmail.com>
> To: Chris Grundemann <cgrundemann at gmail.com>
> Cc: ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
> Message-ID:
>        <f65fb55e1002022106x7ef97a7dk32cce362b3a98af7 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Feb 2, 2010 at 11:05 PM, Chris Grundemann <cgrundemann at gmail.com>
> wrote:
> <snip>
> >
> > +1
> >
> > whois must contain valid contact information for the person/entity
> > directly responsible for the host(s) using a given IP. I oppose this
> > and any other policy which undermines this fundamental requirement.
>
> +1
>
> --
> Cheers,
>
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there."  Jon Postel
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 2 Feb 2010 23:16:41 -0800
> From: "George Bonser" <gbonser at seven.com>
> To: "William Herrin" <bill at herrin.us>,  <ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
> Message-ID:
>        <5A6D953473350C4B9995546AFE9939EE081F75AA at RWC-EX1.corp.seven.com>
> Content-Type: text/plain;       charset="us-ascii"
>
> > Perhaps a *fair* solution is that ISPs who would rather suffer
> > penetrating annual audits purchased by ARIN at the ISP's expense can
> > forgo publishing customer information via SWIP while those who place
> > their information in the public's hands remain relieved of that
> > burden.
> >
> > Regards,
> > Bill Herrin
>
> For me the judgment call seems fairly simple.
>
> >From the standpoint of someone who isn't a commercial ISP
>
> what benefit does this proposal offer me?
> What is the value of that benefit?
>
> What is the benefit to the community at large of the proposal?
> What is the value of that benefit?
>
> What is the cost to the community of the proposal?
>
> What is the cost to me of the proposal?
>
>
> And then the question of whether to support it or not is weighed.  I
> keep coming up with little/no benefit, high cost.
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 3 Feb 2010 01:54:03 -0600
> From: James Hess <mysidia at gmail.com>
> To: Scott Leibrand <scottleibrand at gmail.com>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Petition Underway - Policy Proposal
>        95:CustomerConfidentiality - Time Sensitive
> Message-ID: <6eb799ab1002022354q29e029i6d89302cb15022b at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Feb 2, 2010 at 9:28 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> > On 2/2/2010 7:00 PM, George Bonser wrote:
> > If I, as a colo provider, didn't SWIP customers like this their entire
> /29,
> > I may not be able to meet 80% utilization thresholds. ?For purposes of
> > calculating utilization, however, the /29 is considered 100% utilized as
>
> It's possible to  keep record of utilization using  the form in sec.
> 4.2.3.7.5  of the NRPM  without SWIPing    -- where a full /29 block
> is not re-assigned.
>
> SWIPs  submitted to ARIN are not  (or should not)  be your only
> records or way of keeping proper information about re-assignments  for
> justifying additional allocation requests,  since most  ISPs and
> end-users will have some allocations or assignments of blocks smaller
> than /29.
> e,g  it might look like
>
> City    Which IP Addresses Assigned     No. of Internal Machines
>  Purpose:
> (CITY)            *192.0.0.0                          1
>                            Collocated
>                        192.0.0.1
>                                  (Customer
>                        192.0.0.2
>                                    Name) -
>                        192.0.0.3
>                              4 customer IPs
>                        192.0.0.4
>                              4 provider
>                        192.0.0.5
>                                 IPs
>                        192.0.0.6
>                       *192.0.0.7
>
> So, you have   4  IPs    that are part of the service provider's
> network  192.0.0.0 and  192.0.0.7 broadcast addresses required for
> your router,    plus  your 2  router IPs  for their  servers to use as
> gateway.  Then 4 customer IPs, for their server.
>
> It may be more convenient to just SWIP the entire /29,  provider IPs and
> all..
> but then again,  this will  show the customer as  'responsible' for
> some collocation provider router IPs then,  which might be
> undesirable.
>
>
> In this case... you have 100% utilized the /29.
> You assigned 4 IPs to your equipment, and you delegated an address
> block equivalent in allocation size of a /30 to the user  (probably
> 192.0.0.3 to 6).
>
> The end-user's network block is  smaller than a  /29,  so  no SWIP
> would be required under NRPM 4.2.3.7.2.
>
> Your router on your premises...   and your inefficiency.
> Now  if you peered with a customer router over a /30, and forwarded a
> /29,  that would  indicate  reassignment of a full /29.
>
>
> --
> -J
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 56, Issue 18
> *****************************************
>



-- 
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
?The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.? - Bertrand
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100203/2ec3dd01/attachment.htm>

From gbonser at seven.com  Wed Feb  3 11:52:54 2010
From: gbonser at seven.com (George Bonser)
Date: Wed, 3 Feb 2010 08:52:54 -0800
Subject: [arin-ppml] ARIN-PPML Digest, Vol 56, Issue 18
In-Reply-To: <8aeeaff61002030845w147ec89ek4b72fac22221a71d@mail.gmail.com>
References: <mailman.744.1265183646.30980.arin-ppml@arin.net>
	<8aeeaff61002030845w147ec89ek4b72fac22221a71d@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F75B2@RWC-EX1.corp.seven.com>

There is to some extent some community self-auditing that is done.  

 

If one needs to contact an operator and discovers that the contact
information is incorrect, maybe that one could be flagged somehow for
audit as opposed to doing a blanket audit of all of them.  A top to
bottom audit would take considerable human resources and most of them
would probably be correct anyway.  And most of those that are incorrect
would be people who aren't having issues.  A lot of time would be spent
locating and correcting records that aren't causing a problem.

 

The ones that are related to some sort of issue AND are incorrect would
tend to surface rather quickly and people would find them in the course
of their normal operations.  

 

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Rudolph Daniel
Sent: Wednesday, February 03, 2010 8:46 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 56, Issue 18

 

My take on this is not whether there is whois info or not. whois info is
a must have. And accurate whois information is important to ARIN.

 

The system we create for collecting that info is in question as is
...what info. is available to whom. Where a reallocation has an isp (for
eg) as a contact because the isp agrees to be, my thinking is that ARIN
needs to have all the info. on the reallocation and in many cases, the
information available to the public is not as detailed as the info.
which is available to ARIN.

We also need to decide on the level of accuracy required for ARIN
records and that ultimately  determines what we put in place. I think
I'm getting the view that the current whois database is a little way off
the required standard?? And there would seem to be much use of the or
maybe abuse of the current system as suggested by the 2006 audit.

RD

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

From rudi.daniel at gmail.com  Wed Feb  3 13:34:57 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Wed, 3 Feb 2010 14:34:57 -0400
Subject: [arin-ppml] Proposal 2010-3-ARIN-PPML Digest
Message-ID: <8aeeaff61002031034o57a244e8ufb5b55b8d60eba9d@mail.gmail.com>

In the light of the sheer size of the database, and increasing numbers of
records, I cannot disagree. I was also reminded by a friend yesterday that
the definition of Privacy is undergoing substantial change in both
Government and Private sector spheres and the use of Social networks is I
think responsible for a need to rethink what we mean by it.

ARIN then as a community resource should be the preferred trusted custodian
of all levels of privacy pertaining to number resources and determine policy
for levels of access in the interests of the community.
RD



>
> There is to some extent some community self-auditing that is done.
>
>
>
> If one needs to contact an operator and discovers that the contact
> information is incorrect, maybe that one could be flagged somehow for
> audit as opposed to doing a blanket audit of all of them.  A top to
> bottom audit would take considerable human resources and most of them
> would probably be correct anyway.  And most of those that are incorrect
> would be people who aren't having issues.  A lot of time would be spent
> locating and correcting records that aren't causing a problem.
>
>
>
> The ones that are related to some sort of issue AND are incorrect would
> tend to surface rather quickly and people would find them in the course
> of their normal operations.
>
>
>
>
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Rudolph Daniel
> Sent: Wednesday, February 03, 2010 8:46 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN-PPML Digest, Vol 56, Issue 18
>
>
>
> My take on this is not whether there is whois info or not. whois info is
> a must have. And accurate whois information is important to ARIN.
>
>
>
> The system we create for collecting that info is in question as is
> ...what info. is available to whom. Where a reallocation has an isp (for
> eg) as a contact because the isp agrees to be, my thinking is that ARIN
> needs to have all the info. on the reallocation and in many cases, the
> information available to the public is not as detailed as the info.
> which is available to ARIN.
>
> We also need to decide on the level of accuracy required for ARIN
> records and that ultimately  determines what we put in place. I think
> I'm getting the view that the current whois database is a little way off
> the required standard?? And there would seem to be much use of the or
> maybe abuse of the current system as suggested by the 2006 audit.
>
> RD
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20100203/696711f5/attachment-0001.html
> >
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 56, Issue 20
> *****************************************
>



-- 
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
?The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.? - Bertrand
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100203/f0e94133/attachment.htm>

From cgrundemann at gmail.com  Wed Feb  3 14:03:42 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 3 Feb 2010 12:03:42 -0700
Subject: [arin-ppml] Draft Policy 2010-3: Customer Confidentiality
In-Reply-To: <20100203015351.GA86626@ussenterprise.ufp.org>
References: <8695009A81378E48879980039EEDAD28876D3FCB@MAIL1.polartel.local>
	<5A6D953473350C4B9995546AFE9939EE081F7561@RWC-EX1.corp.seven.com>
	<443de7ad1002021205i1499fb5fga44d45291caba9fb@mail.gmail.com>
	<20100202203622.GA66264@ussenterprise.ufp.org>
	<443de7ad1002021252k1b7fd888w2efaf10d653f94e4@mail.gmail.com>
	<20100202212903.GA70818@ussenterprise.ufp.org>
	<443de7ad1002021415p37ad217hf7b3502dfa77bedc@mail.gmail.com>
	<20100202224925.GA76402@ussenterprise.ufp.org>
	<443de7ad1002021555m431ded34hf8f1bb8e07740f0a@mail.gmail.com>
	<20100203015351.GA86626@ussenterprise.ufp.org>
Message-ID: <443de7ad1002031103ubba3039qa386823921787f04@mail.gmail.com>

On Tue, Feb 2, 2010 at 18:53, Leo Bicknell <bicknell at ufp.org> wrote:
>
> The devel will be in the details, but here's the compromise I am
> willing to support. ?If we can remove residential users from the
> database completely, and provide a formal framework for ISP's to
> indicate they are the abuse/noc contact for a downstream so it's
> clear in the public facing database then I can support expending
> much more staff effort on verifing that e-mail addresses and phone
> numbers work on a regular basis.

I just submitted a proposal that may meet both of our requirements for
whois - keep an eye on the ppml, I will be very interested to get your
take.
~Chris

>
> --
> ? ? ? 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From charles at office.tcsn.net  Wed Feb  3 17:35:40 2010
From: charles at office.tcsn.net (Charles O'Hern)
Date: Wed, 03 Feb 2010 14:35:40 -0800
Subject: [arin-ppml] Petition Underway - Policy Proposal
 95:	CustomerConfidentiality - Time Sensitive
In-Reply-To: <6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>
References: <4B678017.7060300@ibctech.ca>	<28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
	<6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>
Message-ID: <4B69FA3C.3040903@office.tcsn.net>

In regards to Prop 95, it is my opinion that protecting the service
provider from the possibility of customer 'theft' is insufficient
grounds for obfuscating contact information for re-assigned IP networks.

However, I do believe that the current specification is both
insufficiently specific and overly restrictive in regards to the same
re-assignment information.

Not to pick on Mr. Hess, but his message brought up several good points
for comment.  Following those comments are my ideas on the issues with
Whois re-assignment information.

James Hess wrote: 
> _A server colocated with their local ISP_   stop. One server does not
> justify a /29,  it doesn't have to be SWIP'ed or listed in WHOIS.
>   
Quite to the contrary,  a single server chassis is perfectly capable of
justifying more than the one address that a /30 would provide.  A single
chassis is not necessarily a single host.

Its common practice for the co-location providers with which I have
experience to provide at least a /29 for each colo customer, isolated by
vlans and/or port isolation.  YMMV.
> Yes.   And part of that  "networking expertise"  includes providing
> someone to contact about abuse and other abuses.
>   
Agreed, but... (jump down)
>> tech support as and when needed, not on retainer and not
>> on-call 24x7. It is also reasonable to assume that they
>>     
> If they are not on-call 24x7,  then the contact information provided
> should be contact information that goes to a  "Voicemail service"
> when the contact is not on call.
>   
If the EU is not capable of handling inquiries about network abuse, and
they do not retain a consultant for the purpose (an expense that many if
not most small businesses can not justify) then the only consistently
available personnel who might be able to answer a query pertaining to
network abuse would be those of the ISP providing the address space and
the transit.  (note that I am assuming a subnet smaller than /24 which
can not be transit except through the re-assigning ISP.)
> It is not an issue with the registry if someone chose to provide a
> phone number capable of disrupting an  off-call admin.   Generally,
> the phone numbers used should be ones that belong to the organization,
>  that only work when an admin is available.
>
> Important networks should have someone on call 24x7.  <snipped all after>
>   
'Important' is subjective (as are my opinions of course).  Currently the
only qualifier we have in the NRPM is a quantity: "/29 or larger blocks"
mentioned in sections 4.2.2.1.2, 4.2.2.2.1, and 4.2.3.7.2.  Perhaps this
is the point to which a proposal to revise the Whois SWIP should be
directed. 

Basically Sections 4.2.2.1.2, 4.2.2.2.1 and 4.2.3.7.2 divide all network
re-assignment into two groups:  ">= /29" and "< /29".

What's becoming clear as I have read this thread and last years original
thread on the original prop 95 is that there is a third class of
networks smaller than a /24 that should perhaps be considered.

Point 1: As, in common usage, the smallest network that can be
advertised via BGP is a /24. Traffic originating from a re-assigned
network smaller than /24 can not be transit independent of the ISP that
re-assigned the subnet.  Therefore it is certain that for networks
smaller than /24, the ISP assigning that network has (a) contact
information for the end user consistent with the needs of both providing
such service and billing for such service, and (b) power over the
routing of all data to or from the EU network.

Point 2: Due to the proliferation of (or perceived need of) internet
connectivity and presence at all levels of both business and personal
interaction, it is my perception that in some cases the technical
competence of the end user is insufficient to meet the needs of
answering queries about their network operations.

Point 3: End Users, whether residential or business, have a vested
interest in their privacy and, within reason, should have the final say
on whether their contact information is available on a global public
listing.  'Within reason,' in this case, being directly related to the
size and routing of the subnet assigned to them.

Point 4: Accounting for utilization must still be included in any
revision of sections 4.2.2.1.2, 4.2.2.2.1, 4.2.3, and any other
pertinent sections of the NRPM.

>From this I propose that there be three categories for re-assignment
information.  The specific bit boundaries defining the sizes of networks
involved are mere suggestions. 

Large re-assignments, perhaps specified as "larger than /25":  Both
contact information _and_ statement of responsibility (and implied
liability) for the conduct of connections required of the End User by
the ISP for publication to the Whois database.  Basically by requesting
a network of such size the end user must agree to be the responsible
party for traffic originating from the network and for having competent
personnel, either on staff or on contract, to handle network operation
and abuse issues.  There may be a need here to forbid or restrict the
ability of the ISP to be named as contractual administrative proxy for
the EU.  Neither the data transport ISP nor the re-assigning ISP are
absolved of any other responsibilities in their respective roles.
i.e "You (the EU) are a big part of the internet, and are responsible
and accountable for the conduct of your network in our global community."

Small re-assignments, perhaps specified as "/25 to /29":  Contact
information and network responsibility must be provided and assumed by
the ISP providing the address space and transit _unless_ the end user
requests to be the listed entity.  ISP's are required to present the
option to be listed to the EU.  If the EU is the listed entity, the EU
must also assume responsibility for the conduct of connections from
their network and for providing competent personnel to handle network
operation and abuse issues as per the section for "Large
re-assignments".  It is permissible for the ISP to require the EU to be
the listed entity.  If the EU is the listed entity, it is permissible
for the ISP to be listed as a Technical or Abuse or other secondary
contact, as long as the EU is still the Administrative contact and
responsible party.  Listing the EU as the responsible entity does not
absolve the ISP of any other responsibilities as the data transport
provider and holder of the assignment of the larger aggregate network.
i.e. "You (the EU) are welcome to belong to the larger community if you
so choose to accept the responsibility. (While you're at it subscribe to
the PPML, we bark, but rarely bite.)  If not, the global community will
deal with your ISP, who will deal with you."

Trivial re-assignments, smaller than the bottom of the 'small' range, do
not require specific listing and are covered under the general listing
for the ISP as the point of contact and responsible party for the larger
aggregate network and implied transit provider.


I submit that the specifics are probably a bit 'half-baked', and welcome
any comments.  The flames might help the crust harden.

-- 
Charles O'Hern
Network Operations
 
TCSN - The Computer Shop Netlink
1306 Pine St. Paso Robles CA 93446
1-(805) 227-7000  1-(800) 974-DISK
http://www.tcsn.net  abuse at tcsn.net






From mysidia at gmail.com  Wed Feb  3 20:59:41 2010
From: mysidia at gmail.com (James Hess)
Date: Wed, 3 Feb 2010 19:59:41 -0600
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
	CustomerConfidentiality - Time Sensitive
In-Reply-To: <4B69FA3C.3040903@office.tcsn.net>
References: <4B678017.7060300@ibctech.ca>
	<28E139F46D45AF49A31950F88C4974580507A221@E03MVZ2-UKDY.domain1.systemhost.net>
	<6eb799ab1002021830y793024fdsa3004563864a8e45@mail.gmail.com>
	<4B69FA3C.3040903@office.tcsn.net>
Message-ID: <6eb799ab1002031759q25b99718s390ad9fabd11e8ad@mail.gmail.com>

On Wed, Feb 3, 2010 at 4:35 PM, Charles O'Hern <charles at office.tcsn.net> wrote:
> Quite to the contrary, ?a single server chassis is perfectly capable of
> justifying more than the one address that a /30 would provide. ?A single

If there is an an  Apache process and a  Sendmail process on the same
OS install, each each using a different host address from the
IP-Aliased interfaces.    Then it is two servers.   Even if there is
only one piece of metal  powering these servers.

>> Important networks should have someone on call 24x7. ?<snipped all after>
> 'Important' is subjective (as are my opinions of course). ?Currently the

The matter of importance is to be judged by the network providing the contact.

Important means:   it  would be at least as damaging or costly to the
organization to have the upstream providers simply unplug the entire
network due to a serious issue  as it costs to have a  24x7  contact
and operator able to properly address any issue  that occurs during
their off-hours.

If the network does not reach that level of importance, then there
should be no issue using an  8x5  contact.

> Point 1: As, in common usage, the smallest network that can be
> advertised via BGP is a /24. Traffic originating from a re-assigned
> network smaller than /24 can not be transit independent of the ISP that

This is not entirely the case.    A  /25  or smaller  can be
advertised, with the proper arrangements.

Often just to the immediate upstream provider  (and many their
customers may accept).  But if the end-user is multi-homed,  with all
major Tier 1s,  they can arrange to have broad connectivity
independent of their ISP, advertising only /25s.

This may become more common after IPv4  exhaustion, and larger blocks
are not easily available.


--
-J


From michael.dillon at bt.com  Thu Feb  4 04:05:10 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 4 Feb 2010 09:05:10 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <8695009A81378E48879980039EEDAD28876D3FE6@MAIL1.polartel.local>
Message-ID: <28E139F46D45AF49A31950F88C497458050D908D@E03MVZ2-UKDY.domain1.systemhost.net>

> I suspect there are many more Poc's than that.  It's a nice 
> idea but I don't see how it would be workable.

Send out automated emails every 6 months with a personalised
URL in each one. Ask them to click through to the web page,
confirm their details, and maybe add in a survey question
or two. If they don't do it within a week, send a reminder.
After a week send another reminder to the slackers. And
after yet another week, produce an exception report for staff
to follow up however they see fit, which could mean that staff
tell the automated process to tag all those slackers as
"NO RESPONSE TO CONTACT SINCE 14Mar2010" or some such.
A couple of man-hours to run the process every six months,
and a bit of development work up front.

I think that the idea is very WORKABLE and in fact, is pretty
straightforward to implement and to run with.

--Michael Dillon


From john.sweeting at twcable.com  Thu Feb  4 08:15:17 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Thu, 4 Feb 2010 08:15:17 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95:
 CustomerConfidentiality - Time Sensitive
In-Reply-To: <6eb799ab1002031759q25b99718s390ad9fabd11e8ad@mail.gmail.com>
Message-ID: <C7903295.EF73%john.sweeting@twcable.com>

Good morning All,

Please use the current thread Draft Policy 2010-3: Customer Confidentiality for future posts either supporting or opposing this draft policy. It will make it far easier to judge the review the discussion while preparing for the upcoming PPM in Toronto. Also it would be a great help if you state your stance in the post. Thanks!

-john


+++++++++


On 2/3/10 8:59 PM, "James Hess" <mysidia at gmail.com> wrote:

On Wed, Feb 3, 2010 at 4:35 PM, Charles O'Hern <charles at office.tcsn.net> wrote:
> Quite to the contrary,  a single server chassis is perfectly capable of
> justifying more than the one address that a /30 would provide.  A single

If there is an an  Apache process and a  Sendmail process on the same
OS install, each each using a different host address from the
IP-Aliased interfaces.    Then it is two servers.   Even if there is
only one piece of metal  powering these servers.

>> Important networks should have someone on call 24x7.  <snipped all after>
> 'Important' is subjective (as are my opinions of course).  Currently the

The matter of importance is to be judged by the network providing the contact.

Important means:   it  would be at least as damaging or costly to the
organization to have the upstream providers simply unplug the entire
network due to a serious issue  as it costs to have a  24x7  contact
and operator able to properly address any issue  that occurs during
their off-hours.

If the network does not reach that level of importance, then there
should be no issue using an  8x5  contact.

> Point 1: As, in common usage, the smallest network that can be
> advertised via BGP is a /24. Traffic originating from a re-assigned
> network smaller than /24 can not be transit independent of the ISP that

This is not entirely the case.    A  /25  or smaller  can be
advertised, with the proper arrangements.

Often just to the immediate upstream provider  (and many their
customers may accept).  But if the end-user is multi-homed,  with all
major Tier 1s,  they can arrange to have broad connectivity
independent of their ISP, advertising only /25s.

This may become more common after IPv4  exhaustion, and larger blocks
are not easily available.


--
-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.

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 dsd at carpathiahost.com  Thu Feb  4 08:33:13 2010
From: dsd at carpathiahost.com (David Divins)
Date: Thu, 4 Feb 2010 08:33:13 -0500
Subject: [arin-ppml] Petition Underway - Policy Proposal 95
In-Reply-To: <28E139F46D45AF49A31950F88C497458050D908D@E03MVZ2-UKDY.domain1.systemhost.net>
References: <8695009A81378E48879980039EEDAD28876D3FE6@MAIL1.polartel.local>
	<28E139F46D45AF49A31950F88C497458050D908D@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <0BA324910E97E54EBC94D0E358E63DB0197122A0@EX2K7VS02.4emm.local>

Wasn't ARIN doing something similar as an Operation issue for WHOIS POC cleanup?

-dsd

David S. Divins
Principal Engineer
Carpathia Hosting, Inc.
43480 Yukon Dr., #200
Ashburn, VA ?20147
(703) 652-5955
www.carpathiahost.com

ServerVault is now Carpathia Hosting!
www.carpathiahosting.com<www.carpathiahosting.com>?

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

-----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: Thursday, February 04, 2010 4:05 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Petition Underway - Policy Proposal 95

> I suspect there are many more Poc's than that.  It's a nice 
> idea but I don't see how it would be workable.

Send out automated emails every 6 months with a personalised
URL in each one. Ask them to click through to the web page,
confirm their details, and maybe add in a survey question
or two. If they don't do it within a week, send a reminder.
After a week send another reminder to the slackers. And
after yet another week, produce an exception report for staff
to follow up however they see fit, which could mean that staff
tell the automated process to tag all those slackers as
"NO RESPONSE TO CONTACT SINCE 14Mar2010" or some such.
A couple of man-hours to run the process every six months,
and a bit of development work up front.

I think that the idea is very WORKABLE and in fact, is pretty
straightforward to implement and to run with.

--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 michael.dillon at bt.com  Thu Feb  4 08:39:30 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 4 Feb 2010 13:39:30 -0000
Subject: [arin-ppml] Drawing a distinction
In-Reply-To: <8aeeaff61002030845w147ec89ek4b72fac22221a71d@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C497458050D9598@E03MVZ2-UKDY.domain1.systemhost.net>

>   ... my thinking is that ARIN needs to have all the 
> info. on the reallocation and in many cases, the information 
> available to the public is not as detailed as the info. which 
> is available to ARIN.

In the WHOIS policy that is under consideration, it would be
useful to add some language to the policy that draws a clear
distinction between information provided to ARIN for the 
purposes of publishing a WHOIS DIRECTORY and information
provided to ARIN HOSTMASTERS, most probably UNDER NDA, for
the purposes of ASSESSING AN APPLICATION.

I believe that there is no need at present to change anything
regarding the information used by ARIN HOSTMASTERS but because,
historically, this information was part of the published 
information, I think that the new policy should draw a clear 
disctinction in the text, and then discuss things like the
purpose of the WHOIS directory, what information MAY be
published, what information MUST be published, and so on.
In other words, this policy proposal provides an opportunity
to clear up and clarify the policy around this issue so
that any discussions regarding information used by the 
hostmasters can be deferred to another time.

We may even discover a 3rd type of information to cover in the
policy, for instance researchers. It was after a discussion with
some people who had bonafide needs for research info that I came
up with this rationale for including an "organizational type".

i) The classification system for organization types has been
intentionally
   left unspecified. Obviously, it needs to include "individual" as a
type
   but it could include NAICS sector codes, e.g. "NAICS 25" is the
   construction industry. It could also include NTEE codes for
non-profits
   e.g. "NTEE H" is Medical research. And it could include some simple
   codes like "Company", "Non-Profit", "Education", "Government" for 
   users who don't know about the various classification systems.

I could see the use of collecting this info separately, not for
open publication, but for release to bonafide academic researchers
and for inclusion in various ARIN stats reporting. It is neither
whois info nor is it needed to assess an application.

--Michael Dillon



From michael.dillon at bt.com  Thu Feb  4 08:42:39 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 4 Feb 2010 13:42:39 -0000
Subject: [arin-ppml] Proposal 2010-3-ARIN-PPML Digest
In-Reply-To: <8aeeaff61002031034o57a244e8ufb5b55b8d60eba9d@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C497458050D95A7@E03MVZ2-UKDY.domain1.systemhost.net>

> In the light of the sheer size of the database, and 
> increasing numbers of records, I cannot disagree. I was also 
> reminded by a friend yesterday that the definition of Privacy 
> is undergoing substantial change in both Government and 
> Private sector spheres and the use of Social networks is I 
> think responsible for a need to rethink what we mean by it. 

Yes, and one possible outcome is to say:

   In light of the fact that so much of this information is
   readily available elsewhere on the Internet, ARIN will
   no longer collect or publish x, y and z, but will focus
   solely on providing network technical contact info for
   those organizations for which it has a direct contractual
   relationship.

--Michael Dillon


From michael.dillon at bt.com  Thu Feb  4 08:53:12 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 4 Feb 2010 13:53:12 -0000
Subject: [arin-ppml] Petition Underway - Policy Proposal
	95:	CustomerConfidentiality - Time Sensitive
In-Reply-To: <4B69FA3C.3040903@office.tcsn.net>
Message-ID: <28E139F46D45AF49A31950F88C497458050D95DA@E03MVZ2-UKDY.domain1.systemhost.net>

> In regards to Prop 95, it is my opinion that protecting the 
> service provider from the possibility of customer 'theft' is 
> insufficient grounds for obfuscating contact information for 
> re-assigned IP networks.

I agree with you but would like to note that you are only
addressing the rationale of 2010-3, not the actual policy
text itself.

In spite of the fact that I agree with you, I still believe
that the 2010-3 is a good change and should be implemented
with a bit of wordsmithing such as removing the last sentence
since ARIN hostmasters already sign NDAs which prohibit
disclosing information. If I remember correctly, they are
also prohibited from disclosing such info to the Board of
Trustees, the Advisory Council, and all other ARIN staff
including the supervisor of Registration Services who is
their boss.

> What's becoming clear as I have read this thread and last 
> years original thread on the original prop 95 is that there 
> is a third class of networks smaller than a /24 that should 
> perhaps be considered.

And a 4th class where Joe Bloe, in his bedroom in the rooming
house (or frat house) gets a full /48 assignment, just like
the 200 acre, 27 building Ford factory across town.

> Trivial re-assignments, smaller than the bottom of the 
> 'small' range, do not require specific listing and are 
> covered under the general listing for the ISP as the point of 
> contact and responsible party for the larger aggregate 
> network and implied transit provider.

Sounds like all IPv6 assignments /48 or less, would not
go into whois, which is not much different from saying
that only organizations under contract with ARIN go into
whois.

I know people are focusing on the IPv4 policy, but it
would be really, really nice to have one policy covering
all resources, even including ASNs. I think that this
is possible and I think that if the text presented to
the meeting covers this possibility, it would open up
people's thinking enough to break the logjam on whois
policy.

--Michael Dillon


From mcr at sandelman.ca  Thu Feb  4 06:30:16 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 04 Feb 2010 06:30:16 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B563F50.1070306@umn.edu> 
References: <4B563F50.1070306@umn.edu> 
Message-ID: <9413.1265283016@marajade.sandelman.ca>

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


>>>>> "David" == David Farmer <farmer at umn.edu> writes:
    David> At the Dearborn meeting I heard a lot of people say that ARIN
    David> shouldn't dictate routing policy.  I personally would find it
    David> hard to reconcile that stance with the idea of ARIN assigning
    David> non-connected /48s from a separate block. At least without an
    David> RFC defining centrally assignable ULA addressing, then ARIN
    David> would not be defining it, the IETF would be, ARIN would only
    David> be implementing something defined by the IETF.

I don't understand your view here.

ARIN does define routing policy right now --- if you ask ARIN for
address space, you get routable address space, and ARIN defines the
policy by which you can get it.  There is presently only one question I
can ask, and one set of criteria I can satisfy.  If I satisfy the
criteria I get one thing: routable address space.

How do you see it? 

What I liked about policy 103 was that it tried to remove ARIN as the
arbitor of a single policy, and instead provide ARIN with a series of
different policies which it could execute.  The evident for which policy
was executed is expressed in which block address space is allocated
from.

This makes it clear to the ISPs which set of criteria had been satified,
leaving the ISPs able to formulate their own policies.   yes, that
likely leads to a more disconnected IPv6net than we had with IPv4net,
but that's okay to me --- most enterprises' should be using PA prefixes
to get youtube.  


It's all the other uses (some of which that we do not even know about
yet), that enterprises need the other kinds of policies for.  I suggest
that fewer enterprises will need their own blocks in IPv6net than needed
it in IPv4net.  

What I have been asking for is for a different policy that provides for
a different kind of address space (at the request of the requestor...). 

If you are saying that ARIN can not make this decision with an IETF
action, then okay --- the pushback I've gotten over the years from IETF
is that this is an allocation policy matter, and I should talk to my
RIR.  As part of that, many have pointed out that RIPE is much more
liberal with blocks than ARIN is.  (I do not live in Europe or directly
manage networks there, so I have no direct RIPE experience, only
second-hand experience, including a few unrouted RIPE /48s which were
just thrown at me to use in the past)

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS2qvxoCLcPvd0N1lAQIEAAgAwiR86cY7Eo50rmnv9F3/eW6EXyuQ6S/F
re7BmSfxOX4r/+9CHGVNDOmLy3GcwCIytndUuWVhJQwnlF7pojhzfpM4fH2BMn4q
Se5/kVn3re7wZ/JvnSAhaO972un/ENB1kg6nZhLr2IVmqzeX6PgFz/OezyGO4El9
aQMaCJ/yWtuEW49cC+yL1Ru0VI76gpxPyHWuuC6O6+Kqpsg8uLa89n99r2XoOyy2
YfqW5Fp0LqiQadqSEZKsL+Hw0HyuCSY58G8HgQ8Isvlk6tzwzW+gTtHopnjHnWK+
izpcCn+1dKqRq4CfLpm9MgfaFL+N1THVELzrVK53phsK3AcxN21HvA==
=KnwN
-----END PGP SIGNATURE-----


From info at arin.net  Thu Feb  4 11:33:18 2010
From: info at arin.net (Member Services)
Date: Thu, 04 Feb 2010 11:33:18 -0500
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements
Message-ID: <4B6AF6CE.7000709@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.

Draft Policies and Proposals under discussion can be found 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

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 109: Standardize IP Reassignment Registration Requirements

Proposal Originator: Chris Grundemann

Proposal Version: 1.0

Date: 4 FEB 2010

Proposal type: Modify

Policy term: Permanent

Policy statement:

## Definitions ##

  - Add:

2.3. Organizational Information

When required, organization Information must include at a minimum:
Legal name, city, state, zip code equivalent and at least one valid
technical or abuse POC; inclusion of street address is highly
encouraged. The POC shall be designated by the organization and must
include at least one verifiable email address, inclusion of a phone
number is highly encouraged.

## IPv4 ##

  - Rename 4.2.3.7. "Reassignment information" to "Registration"

  - Rename 4.2.3.7.1. "Customer organization information" to
"Reassignment Information" and replace text with:

When an organization holding an IPv4 address allocation makes IPv4
address assignments, it must register reassignment information via
SWIP or RWHOIS server. SWIP and RWHOIS reassignments shall include
each client's organizational information, except where specifically
exempted by this policy.

  - Replace 4.2.3.7.6. Residential Customer Privacy with:

4.2.3.7.6. Residential Subscribers

4.2.3.7.6.1. Residential Market Area

In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather
than to individual subscribers. This assignment information regarding
each market area holding an address block should be registered with
the network name used to identify each market area. Initial
allocations are based on total number of homes that could purchase the
service in a given market area. Each assignment to specific end-users
of /29 and larger blocks still requires individual registration.

4.2.3.7.6.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /29 and
larger blocks may substitute that organization's name for the
customer's name, e.g. 'Private Customer - XYZ Network', and the
customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.

  - Strike section 4.2.6. "Cable Address Space Policy"

## IPv6 ##

  - Replace Section 6.5.5. with:

6.5.5. Registration

6.5.5.1. Reassignment information

When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register reassignment information in a
database, accessible by RIRs as appropriate (information registered by
an RIR may be replaced by a distributed database for registering
address management information in future). These reassignment
registrations shall include each client's organizational information,
except where specifically exempted by this policy.

6.5.5.2. /56 registered unit

Information is registered in units of assigned /56 networks. When more
than a /56 is assigned to a client organization, the assigning
organization is responsible for ensuring that the address space is
registered in an RIR database.

6.5.5.3. Submit within 7 days

Any time an LIR receives a new block of address space, reassignment
information should be submitted within 7 days of issuance of the new
space.

6.5.5.4. Visible via WHOIS

This information must be visible via WHOIS prior to submitting a
request for a new allocation. For further information on reassigning
IP address space, please see RFC 2050.

6.5.5.6. Residential Subscribers

6.5.5.6.1. Residential Market Area

In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather
than to individual subscribers. This assignment information regarding
each market area holding an address block should be registered with
the network name used to identify each market area. Initial
allocations are based on total number of homes that could purchase the
service in a given market area. Each assignment to specific end-users
of /56 and larger blocks still requires individual registration.

6.5.5.6.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /56 and
larger blocks may substitute that organization's name for the
customer's name, e.g. 'Private Customer - XYZ Network', and the
customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.


Rationale:

This proposal intends to do several things:
1) Bring IPv4 and IPv6 policy more in line with each other to make the
NRPM easier to understand and comply with - at least as it relates to
reassignment information.
2) Specifically define what organizational information is required to
be added to whois when reassignments are made to client organizations.
3) To specifically state that a client organization may designate the
POC of their choice for any/all whois entries. This includes
designating an upstream POC as their own prefered POC.
4) Expands the priviledges previously reserved solely for cable ISPs
to all ISPs/LIRs with residential subscribers. Namely the ability to
SWIP/RWHOIS an entire residential market area as one reassignment. It
also expands this priviledge to IPv6 reasignments, instead of just
IPv4 as it is now.

Timetable for implementation: Immediate





From packetgrrl at gmail.com  Thu Feb  4 11:05:52 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 4 Feb 2010 09:05:52 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <9413.1265283016@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
Message-ID: <c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>

Michael,

Per ARIN's Number Resource Policy Manual it says this:

"4.1.1. Routability

Provider independent (portable) addresses issued directly from ARIN or other
Regional Registries are not guaranteed to be globally routable. Therefore,
ISPs should consider the following order of priority when requesting IP
address space:

   - Request IP address space from upstream provider
   - Request IP address space from provider's provider
   - Request IP address space from ARIN (not guaranteed to be globally
   routable)"


Address allocations and assignments from ARIN are not guaranteed to be
routable.

-----Cathy

On Thu, Feb 4, 2010 at 4:30 AM, Michael Richardson <mcr at sandelman.ca> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> >>>>> "David" == David Farmer <farmer at umn.edu> writes:
>    David> At the Dearborn meeting I heard a lot of people say that ARIN
>    David> shouldn't dictate routing policy.  I personally would find it
>    David> hard to reconcile that stance with the idea of ARIN assigning
>    David> non-connected /48s from a separate block. At least without an
>    David> RFC defining centrally assignable ULA addressing, then ARIN
>    David> would not be defining it, the IETF would be, ARIN would only
>    David> be implementing something defined by the IETF.
>
> I don't understand your view here.
>
> ARIN does define routing policy right now --- if you ask ARIN for
> address space, you get routable address space, and ARIN defines the
> policy by which you can get it.  There is presently only one question I
> can ask, and one set of criteria I can satisfy.  If I satisfy the
> criteria I get one thing: routable address space.
>
> How do you see it?
>
> What I liked about policy 103 was that it tried to remove ARIN as the
> arbitor of a single policy, and instead provide ARIN with a series of
> different policies which it could execute.  The evident for which policy
> was executed is expressed in which block address space is allocated
> from.
>
> This makes it clear to the ISPs which set of criteria had been satified,
> leaving the ISPs able to formulate their own policies.   yes, that
> likely leads to a more disconnected IPv6net than we had with IPv4net,
> but that's okay to me --- most enterprises' should be using PA prefixes
> to get youtube.
>
>
> It's all the other uses (some of which that we do not even know about
> yet), that enterprises need the other kinds of policies for.  I suggest
> that fewer enterprises will need their own blocks in IPv6net than needed
> it in IPv4net.
>
> What I have been asking for is for a different policy that provides for
> a different kind of address space (at the request of the requestor...).
>
> If you are saying that ARIN can not make this decision with an IETF
> action, then okay --- the pushback I've gotten over the years from IETF
> is that this is an allocation policy matter, and I should talk to my
> RIR.  As part of that, many have pointed out that RIPE is much more
> liberal with blocks than ARIN is.  (I do not live in Europe or directly
> manage networks there, so I have no direct RIPE experience, only
> second-hand experience, including a few unrouted RIPE /48s which were
> just thrown at me to use in the past)
>
> - --
> ]       He who is tired of Weird Al is tired of life!           |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>                       then sign the petition.
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBS2qvxoCLcPvd0N1lAQIEAAgAwiR86cY7Eo50rmnv9F3/eW6EXyuQ6S/F
> re7BmSfxOX4r/+9CHGVNDOmLy3GcwCIytndUuWVhJQwnlF7pojhzfpM4fH2BMn4q
> Se5/kVn3re7wZ/JvnSAhaO972un/ENB1kg6nZhLr2IVmqzeX6PgFz/OezyGO4El9
> aQMaCJ/yWtuEW49cC+yL1Ru0VI76gpxPyHWuuC6O6+Kqpsg8uLa89n99r2XoOyy2
> YfqW5Fp0LqiQadqSEZKsL+Hw0HyuCSY58G8HgQ8Isvlk6tzwzW+gTtHopnjHnWK+
> izpcCn+1dKqRq4CfLpm9MgfaFL+N1THVELzrVK53phsK3AcxN21HvA==
> =KnwN
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20100204/2eb8575c/attachment.htm>

From marla.azinger at frontiercorp.com  Thu Feb  4 11:29:21 2010
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Thu, 4 Feb 2010 11:29:21 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <9413.1265283016@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>

Just trying to clarify a couple notes here.

ARIN's charter does not included routing policy.  It only includes the management and stewardship of IP Address Space.  Also it does not guarantee that the address space you are allocated will be routable.

That said, there have been times that address policy has been passed that crosses that line, includes routing policy and tries to dictate how networks should operate, and that is a big point of contention when it does.   

Lately several proposals have been submitted that attempt to write routing policy into the IP Address Policy.  This needs to be debated heavily since its not in the Charter and it also makes the need for Network Operators to get involved on ppml to discuss the merits or lack thereof. 

Regards
Marla Azinger
Frontier Communications


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Richardson
Sent: Thursday, February 04, 2010 3:30 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] IPv6 Non-connected networks

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


>>>>> "David" == David Farmer <farmer at umn.edu> writes:
    David> At the Dearborn meeting I heard a lot of people say that ARIN
    David> shouldn't dictate routing policy.  I personally would find it
    David> hard to reconcile that stance with the idea of ARIN assigning
    David> non-connected /48s from a separate block. At least without an
    David> RFC defining centrally assignable ULA addressing, then ARIN
    David> would not be defining it, the IETF would be, ARIN would only
    David> be implementing something defined by the IETF.

I don't understand your view here.

ARIN does define routing policy right now --- if you ask ARIN for address space, you get routable address space, and ARIN defines the policy by which you can get it.  There is presently only one question I can ask, and one set of criteria I can satisfy.  If I satisfy the criteria I get one thing: routable address space.

How do you see it? 

What I liked about policy 103 was that it tried to remove ARIN as the arbitor of a single policy, and instead provide ARIN with a series of different policies which it could execute.  The evident for which policy was executed is expressed in which block address space is allocated from.

This makes it clear to the ISPs which set of criteria had been satified,
leaving the ISPs able to formulate their own policies.   yes, that
likely leads to a more disconnected IPv6net than we had with IPv4net, but that's okay to me --- most enterprises' should be using PA prefixes to get youtube.  


It's all the other uses (some of which that we do not even know about yet), that enterprises need the other kinds of policies for.  I suggest that fewer enterprises will need their own blocks in IPv6net than needed it in IPv4net.  

What I have been asking for is for a different policy that provides for a different kind of address space (at the request of the requestor...). 

If you are saying that ARIN can not make this decision with an IETF action, then okay --- the pushback I've gotten over the years from IETF is that this is an allocation policy matter, and I should talk to my RIR.  As part of that, many have pointed out that RIPE is much more liberal with blocks than ARIN is.  (I do not live in Europe or directly manage networks there, so I have no direct RIPE experience, only second-hand experience, including a few unrouted RIPE /48s which were just thrown at me to use in the past)

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS2qvxoCLcPvd0N1lAQIEAAgAwiR86cY7Eo50rmnv9F3/eW6EXyuQ6S/F
re7BmSfxOX4r/+9CHGVNDOmLy3GcwCIytndUuWVhJQwnlF7pojhzfpM4fH2BMn4q
Se5/kVn3re7wZ/JvnSAhaO972un/ENB1kg6nZhLr2IVmqzeX6PgFz/OezyGO4El9
aQMaCJ/yWtuEW49cC+yL1Ru0VI76gpxPyHWuuC6O6+Kqpsg8uLa89n99r2XoOyy2
YfqW5Fp0LqiQadqSEZKsL+Hw0HyuCSY58G8HgQ8Isvlk6tzwzW+gTtHopnjHnWK+
izpcCn+1dKqRq4CfLpm9MgfaFL+N1THVELzrVK53phsK3AcxN21HvA==
=KnwN
-----END PGP SIGNATURE-----
_______________________________________________
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 Feb  4 11:41:46 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 4 Feb 2010 08:41:46 -0800
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements
In-Reply-To: <4B6AF6CE.7000709@arin.net>
References: <4B6AF6CE.7000709@arin.net>
Message-ID: <7B585B5D-AC81-4731-B3BF-7A07B6112E4B@gmail.com>

I like it.

For IPv6, should the cutoff be "more
than a /56" or "/56 and larger blocks"? IMO more than /56 is better,  
but it needs to be made consistent.

Thanks,
Scott

On Feb 4, 2010, at 8:33 AM, 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.
>
> Draft Policies and Proposals under discussion can be found 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
>
> 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 109: Standardize IP Reassignment Registration  
> Requirements
>
> Proposal Originator: Chris Grundemann
>
> Proposal Version: 1.0
>
> Date: 4 FEB 2010
>
> Proposal type: Modify
>
> Policy term: Permanent
>
> Policy statement:
>
> ## Definitions ##
>
> - Add:
>
> 2.3. Organizational Information
>
> When required, organization Information must include at a minimum:
> Legal name, city, state, zip code equivalent and at least one valid
> technical or abuse POC; inclusion of street address is highly
> encouraged. The POC shall be designated by the organization and must
> include at least one verifiable email address, inclusion of a phone
> number is highly encouraged.
>
> ## IPv4 ##
>
> - Rename 4.2.3.7. "Reassignment information" to "Registration"
>
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
>
> When an organization holding an IPv4 address allocation makes IPv4
> address assignments, it must register reassignment information via
> SWIP or RWHOIS server. SWIP and RWHOIS reassignments shall include
> each client's organizational information, except where specifically
> exempted by this policy.
>
> - Replace 4.2.3.7.6. Residential Customer Privacy with:
>
> 4.2.3.7.6. Residential Subscribers
>
> 4.2.3.7.6.1. Residential Market Area
>
> In most cases, ISPs that have residential subscribers assign address
> space to the infrastructure to which their customers connect rather
> than to individual subscribers. This assignment information regarding
> each market area holding an address block should be registered with
> the network name used to identify each market area. Initial
> allocations are based on total number of homes that could purchase the
> service in a given market area. Each assignment to specific end-users
> of /29 and larger blocks still requires individual registration.
>
> 4.2.3.7.6.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /29 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS record for that block.
>
> - Strike section 4.2.6. "Cable Address Space Policy"
>
> ## IPv6 ##
>
> - Replace Section 6.5.5. with:
>
> 6.5.5. Registration
>
> 6.5.5.1. Reassignment information
>
> When an organization holding an IPv6 address allocation makes IPv6
> address assignments, it must register reassignment information in a
> database, accessible by RIRs as appropriate (information registered by
> an RIR may be replaced by a distributed database for registering
> address management information in future). These reassignment
> registrations shall include each client's organizational information,
> except where specifically exempted by this policy.
>
> 6.5.5.2. /56 registered unit
>
> Information is registered in units of assigned /56 networks. When more
> than a /56 is assigned to a client organization, the assigning
> organization is responsible for ensuring that the address space is
> registered in an RIR database.
>
> 6.5.5.3. Submit within 7 days
>
> Any time an LIR receives a new block of address space, reassignment
> information should be submitted within 7 days of issuance of the new
> space.
>
> 6.5.5.4. Visible via WHOIS
>
> This information must be visible via WHOIS prior to submitting a
> request for a new allocation. For further information on reassigning
> IP address space, please see RFC 2050.
>
> 6.5.5.6. Residential Subscribers
>
> 6.5.5.6.1. Residential Market Area
>
> In most cases, ISPs that have residential subscribers assign address
> space to the infrastructure to which their customers connect rather
> than to individual subscribers. This assignment information regarding
> each market area holding an address block should be registered with
> the network name used to identify each market area. Initial
> allocations are based on total number of homes that could purchase the
> service in a given market area. Each assignment to specific end-users
> of /56 and larger blocks still requires individual registration.
>
> 6.5.5.6.2. Residential Customer Privacy
>
> To maintain the privacy of their residential customers, an
> organization with downstream residential customers holding /56 and
> larger blocks may substitute that organization's name for the
> customer's name, e.g. 'Private Customer - XYZ Network', and the
> customer's street address may read 'Private Residence'. Each private
> downstream residential reassignment must have accurate upstream Abuse
> and Technical POCs visible on the WHOIS record for that block.
>
>
> Rationale:
>
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to whois when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all whois entries. This includes
> designating an upstream POC as their own prefered POC.
> 4) Expands the priviledges previously reserved solely for cable ISPs
> to all ISPs/LIRs with residential subscribers. Namely the ability to
> SWIP/RWHOIS an entire residential market area as one reassignment. It
> also expands this priviledge to IPv6 reasignments, instead of just
> IPv4 as it is now.
>
> 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 mcr at sandelman.ca  Thu Feb  4 12:23:29 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 04 Feb 2010 12:23:29 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt> 
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>
Message-ID: <3995.1265304209@marajade.sandelman.ca>


Can you give me an example of a piece of address space (IPv4 or IPv6)
that ARIN has issued that turned out to not be routable on the DFZ?

The only example I can see are some of the 69/8 and 70/8 (if I got those
prefixes right), which many people had bogon filters for, and it took a
few months for those filters to get completely removed.

(Please ignore micro-allocations for IXs, which are often intended not
to be routable, but often turn out to be easily routed)

I understand covering-your-ass legalize in the document, but really,
let's be pragmatic here.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 




From packetgrrl at gmail.com  Thu Feb  4 13:17:42 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 4 Feb 2010 11:17:42 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3995.1265304209@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>
	<3995.1265304209@marajade.sandelman.ca>
Message-ID: <c3227e9e1002041017o3b862c51u6983bd92ac62211c@mail.gmail.com>

Michael,

Sure I can give you an example.  At one point the company I worked for
received 24.0.0.0/14.  It was not globally routable.  For some time, I would
say close to a year, Sprint would only listen to advertisements for
24.0.0.0/8.  Everyone who had a block of net 24 would advertise that block
as well as 24.0.0.0/8 and depending on the day and how lucky you were if
Sprint preferred your advertisement to 24.0.0.0/8 then you could get to
Sprint customers.  The other issue regarding this block was that most of the
world didn't have their routers configured to understand a subnet of a
traditional "class A" block.  So our NOC spent probably 1/2 it's time
tracking down these sites and getting them to add the appropriate commands.


It was a ton of fun!
----Cathy

On Thu, Feb 4, 2010 at 10:23 AM, Michael Richardson <mcr at sandelman.ca>wrote:

>
> Can you give me an example of a piece of address space (IPv4 or IPv6)
> that ARIN has issued that turned out to not be routable on the DFZ?
>
> The only example I can see are some of the 69/8 and 70/8 (if I got those
> prefixes right), which many people had bogon filters for, and it took a
> few months for those filters to get completely removed.
>
> (Please ignore micro-allocations for IXs, which are often intended not
> to be routable, but often turn out to be easily routed)
>
> I understand covering-your-ass legalize in the document, but really,
> let's be pragmatic here.
>
> --
> ]       He who is tired of Weird Al is tired of life!           |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>                       then sign the petition.
>
>
> _______________________________________________
> 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/20100204/618b9cc3/attachment.htm>

From bill at herrin.us  Thu Feb  4 14:42:15 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 4 Feb 2010 14:42:15 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B563F50.1070306@umn.edu>
References: <4B563F50.1070306@umn.edu>
Message-ID: <3c3e3fca1002041142w232dc952q8173dd1ccfed17db@mail.gmail.com>

On Tue, Jan 19, 2010 at 6:25 PM, David Farmer <farmer at umn.edu> wrote:
> At the Dearborn meeting I heard a lot of people say that ARIN shouldn't
> dictate routing policy. ?I personally would find it hard to reconcile that
> stance with the idea of ARIN assigning non-connected /48s from a separate
> block. At least without an RFC defining centrally assignable ULA addressing,
> then ARIN would not be defining it, the IETF would be, ARIN would only be
> implementing something defined by the IETF.

Hi David,

When ARIN assigns two different classes of use interspersed within the
same address block, functionally they dictate that however service
providers treat the one use, they will treat the other the same. If
one use must be carried on the Internet by reasonable ISPs then ARIN
has dictated that the other use will be carried too. In practical
effect, ARIN has set the routing policy for that second class of use.

Two obvious examples of this would be:

Assigning /22's adjacent to /16's. ARIN's practice dictates that the
/16's will be disaggregable by the assignee to /22 for TE purposes as
well.

Assigning multihomed and non-multihomed prefixes adjacent to each
other. ARIN's practice dictates that the ISPs will not distinguish
between routes announced by multihomed and single-homed entities.



When folks say "ARIN shouldn't dictate routing policy," what they mean
is, "ARIN should allocate address in a manner which makes it
technically practical for ISPs to hang their own routing policies off
the specific, major classes of use."


Some vectors which create the major classes of use include:

Aggregable (traffic engineering, single-homed downstream entities) /
non-aggregable (distinct multihomed entitiy)
Big / Small
Residential / commercial / government
My legal jurisdiction (aka country) / other jurisdiction
Internet-connected / not internet connected
Pay me / don't pay me

Perhaps others can suggest some additional IP address use vectors
which draw an important distinction with respect to desirable routing
policy.



> So what is the direction the community wants to go for IPv6 non-connected
> networks?

Published unique pool so that ISPs can assure that the non-connected
networks stay non-connected, even if Jim's Bait and Network Services
gets bribed to introduce a route.

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 mcr at sandelman.ca  Thu Feb  4 14:42:44 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 04 Feb 2010 14:42:44 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <c3227e9e1002041017o3b862c51u6983bd92ac62211c@mail.gmail.com> 
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>
	<3995.1265304209@marajade.sandelman.ca>
	<c3227e9e1002041017o3b862c51u6983bd92ac62211c@mail.gmail.com> 
Message-ID: <16258.1265312564@marajade.sandelman.ca>


>>>>> "packetgrrl" == packetgrrl  <cja at daydream.com> writes:
    packetgrrl> Sure I can give you an example.  At one point the
    packetgrrl> company I worked for received 24.0.0.0/14.  It was not
    packetgrrl> globally routable.  For some time, I would say close to
    packetgrrl> a year, Sprint would only listen to advertisements for

So, ARIN gave you a CIDR block when CIDR was still not yet "out there".

It seems to me like this was a policy mistake --- a policy was rolled out
before it the network was ready for it.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 


From packetgrrl at gmail.com  Thu Feb  4 14:45:54 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 4 Feb 2010 12:45:54 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <16258.1265312564@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>
	<3995.1265304209@marajade.sandelman.ca>
	<c3227e9e1002041017o3b862c51u6983bd92ac62211c@mail.gmail.com>
	<16258.1265312564@marajade.sandelman.ca>
Message-ID: <c3227e9e1002041145x78286f35tf99081aadb320747@mail.gmail.com>

Actually it wasn't a policy mistake.  There had been a trial with subnets of
"class A"s.  They seemed to work but our network reached out to lots and
lots more destinations by the sheer volume of our customers.  So we had to
pretty much fix the problem at thousands of little end sites.  Also we had
no control over (and neither does ARIN) the filtering policies of large
ISPs.

On Thu, Feb 4, 2010 at 12:42 PM, Michael Richardson <mcr at sandelman.ca>wrote:

>
> >>>>> "packetgrrl" == packetgrrl  <cja at daydream.com> writes:
>    packetgrrl> Sure I can give you an example.  At one point the
>    packetgrrl> company I worked for received 24.0.0.0/14.  It was not
>    packetgrrl> globally routable.  For some time, I would say close to
>    packetgrrl> a year, Sprint would only listen to advertisements for
>
> So, ARIN gave you a CIDR block when CIDR was still not yet "out there".
>
> It seems to me like this was a policy mistake --- a policy was rolled out
> before it the network was ready for it.
>
> --
> ]       He who is tired of Weird Al is tired of life!           |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>                       then sign the petition.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100204/470358db/attachment.htm>

From bicknell at ufp.org  Thu Feb  4 14:54:58 2010
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 4 Feb 2010 11:54:58 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <c3227e9e1002041145x78286f35tf99081aadb320747@mail.gmail.com>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>
	<3995.1265304209@marajade.sandelman.ca>
	<c3227e9e1002041017o3b862c51u6983bd92ac62211c@mail.gmail.com>
	<16258.1265312564@marajade.sandelman.ca>
	<c3227e9e1002041145x78286f35tf99081aadb320747@mail.gmail.com>
Message-ID: <20100204195458.GA8137@ussenterprise.ufp.org>

In a message written on Thu, Feb 04, 2010 at 12:45:54PM -0700, cja at daydream.com wrote:
>    little end sites.  Also we had no control over (and neither does ARIN)
>    the filtering policies of large ISPs.

There is a nuance in here that most people seem to ignore when
making their point.

ARIN does not control routing at any ISP.

ARIN has an extremely large influence on ISP's routing policies.

These two statements can be completely true at the same time.  Sure,
ARIN was not able to reach out to an ISP for you and wap them over
the head with a stick to say "Route Cathy's network", so you're
statement is 100% valid.  However, there is also ample evidence
that over time ISP's filtering policies tend to mirror ARIN's
allocation guidelines.  Indeed, the problem you describe has gone
away as ISP's have mirrored ARIN's policies.

Because of this situation, I argue it is extremely important for
those making policy to consider the effects on routeability.  Not
because ARIN can take a stick to someone, but because it is highly
likely to become the rule of the land over time by default.  I also
think there is a note of caution involved as well; the current
system works well in part because over time ISP's policies mirror
ARIN's.  While that is not required, I believe it's relatively
trival to show that if this were not the case costs for everyone
would go up.  ARIN would see more blocks returned and fraud in
requests looking for routable blocks, ISP's and businesses would
have to deal with those who received unroutable networks through
ignorace or accident.

Routablilty is one of many concerns when drafting policy.  It should no
more be ignored than it should be assumed to be the end-all be-all.

-- 
       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: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100204/4f0bb6ea/attachment.sig>

From bill at herrin.us  Thu Feb  4 15:43:04 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 4 Feb 2010 15:43:04 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
Message-ID: <3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>

On Thu, Feb 4, 2010 at 11:05 AM, cja at daydream.com <packetgrrl at gmail.com> wrote:
> Per ARIN's Number Resource Policy Manual it says this:
> "4.1.1. Routability
> Address allocations and assignments from ARIN are not guaranteed to be
> routable.

Hi Cathy,

I think what's starting to happen is that as a community we're
recognizing that statement as a major and expensive cop-out. Sure,
sure, ARIN's not legally liable if my addresses aren't routeable. But
we all know, wink and nod, that we get addresses from ARIN *because*
we can use them on the public Internet.

So, why not fess up to the reality and either:

1. Make ARIN officially the routing policy arbiter for North America
with appropriate care given to checks and balances, or
2. Adjust ARIN's process so that ISPs actually do control their own
routing policies.


On Thu, Feb 4, 2010 at 2:54 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> There is a nuance in here that most people seem to ignore when
> making their point.
>
> ARIN does not control routing at any ISP.
>
> ARIN has an extremely large influence on ISP's routing policies.

Hi Leo,

The dozen major airlines exert somewhat more than an "extremely large
influence" over the route I take from DC to Hawaii, and they don't
have ARIN's geographic monopoly.

He who controls the IP addresses controls the scope and shape of the
choices that others can make with the IP addresses. That control can
be used to create a rich wealth of reasonable choices or it can be
used to narrow them to just a few.

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 barbara.roseman at icann.org  Thu Feb  4 16:14:57 2010
From: barbara.roseman at icann.org (Barbara Roseman)
Date: Thu, 4 Feb 2010 13:14:57 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
Message-ID: <08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>

Bill and others,

I think there's a subtle but important distinction that's being lost, and that Cathy and Marla tried to clarify.

ARIN guarantees unique address allocations/assignments, much as IANA guarantees unique address allocations to the RIRs. Unique assignment does not mean that someone else hasn't already decided to use those addresses or to block those addresses through un-updated bogon filters. That is in large measure what is meant by not guaranteeing routeability of the addresses. ARIN, nor any other entity, can guarantee that all the other players will follow the rules. 

Additionally, and more controversially, ARIN does not set routing policy for any of the ISPs. As several have pointed out, there is an extremely strong influence by ARIN's allocation and assignment policies on how routing policy is managed, so that whenever ARIN drops the minimal allocation size, ISPs have to make decisions about routing those new smaller announcements, but there is no necessity for them to do so. Most will, because, as Leo pointed out, when you have /22s and /16s in the same netblock, it's hard to come up with TE rules that make a distinction, and that is why ISPs want to have full and frank discussions about the impact to routing whenever such policy is broached (as Marla said).

All of this has been discussed many times. ARIN cannot set routing policy not only because it is not in scope, but because it does not have any authority over the ISPs/CPs who must make the final decisions about what they will and will not accept as routing announcements. 

-Barb
On Feb 4, 2010, at 12:43 PM, William Herrin wrote:

> On Thu, Feb 4, 2010 at 11:05 AM, cja at daydream.com <packetgrrl at gmail.com> wrote:
>> Per ARIN's Number Resource Policy Manual it says this:
>> "4.1.1. Routability
>> Address allocations and assignments from ARIN are not guaranteed to be
>> routable.
> 
> Hi Cathy,
> 
> I think what's starting to happen is that as a community we're
> recognizing that statement as a major and expensive cop-out. Sure,
> sure, ARIN's not legally liable if my addresses aren't routeable. But
> we all know, wink and nod, that we get addresses from ARIN *because*
> we can use them on the public Internet.
> 
> So, why not fess up to the reality and either:
> 
> 1. Make ARIN officially the routing policy arbiter for North America
> with appropriate care given to checks and balances, or
> 2. Adjust ARIN's process so that ISPs actually do control their own
> routing policies.
> 
> 
> On Thu, Feb 4, 2010 at 2:54 PM, Leo Bicknell <bicknell at ufp.org> wrote:
>> There is a nuance in here that most people seem to ignore when
>> making their point.
>> 
>> ARIN does not control routing at any ISP.
>> 
>> ARIN has an extremely large influence on ISP's routing policies.
> 
> Hi Leo,
> 
> The dozen major airlines exert somewhat more than an "extremely large
> influence" over the route I take from DC to Hawaii, and they don't
> have ARIN's geographic monopoly.
> 
> He who controls the IP addresses controls the scope and shape of the
> choices that others can make with the IP addresses. That control can
> be used to create a rich wealth of reasonable choices or it can be
> used to narrow them to just a few.
> 
> 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 Skeeve at eintellego.net  Thu Feb  4 17:11:46 2010
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Fri, 5 Feb 2010 09:11:46 +1100
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3995.1265304209@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>
	<3995.1265304209@marajade.sandelman.ca>
Message-ID: <292AF25E62B8894C921B893B53A19D97396AF3312E@BUSINESSEX.business.ad>

I am not sure about the ARIN experience with regards to 69/8 and 70/8, but in the APNIC region here we have had an extreme amount of pain over the last 10 years.

Your suggestion that bogon filters were cleaned up after a couple of months is ridiculous as we have little way of measuring how many of those un-maintained filter lists are out there until there is a connectivity complaint.  In essence, you have no idea how much this is hurting you until it actually does so.

In APNIC, ranges such as 125/8 particularly hurt some of my customers as massive organisations such as PayPal took a VERY long time to remove filter lists - a year or more after it was allocated to our region and then allocated to LIR's.  I recall this being a massive problem over a Christmas period for some ecommerce sites.

Ranged that have been in use for 3-4 years still have the occasional problem with filter lists and the support burden on trying to track these issues down is quite significant.

...Skeeve

--
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
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Michael Richardson
> Sent: Friday, 5 February 2010 4:23 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 Non-connected networks
> 
> 
> Can you give me an example of a piece of address space (IPv4 or IPv6)
> that ARIN has issued that turned out to not be routable on the DFZ?
> 
> The only example I can see are some of the 69/8 and 70/8 (if I got
> those
> prefixes right), which many people had bogon filters for, and it took a
> few months for those filters to get completely removed.
> 
> (Please ignore micro-allocations for IXs, which are often intended not
> to be routable, but often turn out to be easily routed)
> 
> I understand covering-your-ass legalize in the document, but really,
> let's be pragmatic here.
> 
> --
> ]       He who is tired of Weird Al is tired of life!           |
> firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>    Kyoto Plus: watch the video
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition.
> 
> 
> _______________________________________________
> 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 gbonser at seven.com  Thu Feb  4 17:20:39 2010
From: gbonser at seven.com (George Bonser)
Date: Thu, 4 Feb 2010 14:20:39 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
References: <4B563F50.1070306@umn.edu>
	<9413.1265283016@marajade.sandelman.ca><c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7613@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of William Herrin
> 
> Hi Cathy,
> 
> 1. Make ARIN officially the routing policy arbiter for North America
> with appropriate care given to checks and balances, or
> 2. Adjust ARIN's process so that ISPs actually do control their own
> routing policies

I believe case number 1 is actually, as you mention, the current default
case in that routing policy must be adjusted in order to accommodate the
address allocation policies of the RIRs

Case number 2 would cause a problem because I could see the ISPs attempt
to force customers to be "stickier" to their services or take traffic
from a competitor (i.e.  protecting their customer lists by an even
greater degree).

Once a network reaches some size, it is to the benefit of the network
user to be multihomed and provider agnostic.  The idea is to endeavor
NOT to be sticky to any provider and take advantage of better pricing
opportunities as they arise where they make business sense.

The priorities of the ISP and the network provider are sometimes in
opposite directions.  The ISP wants to maximize revenues and not lose
customers to competition.  The user wants to get the best
price/performance metric they can obtain which might be counter to the
notion of being "sticky" to a provider unless that provider also offers
additional services the user requires. It is only natural that the ISPs
in a general sense are going to want to make it more difficult for
customers to be agile while customers are going to want to be as
flexible and agile as possible.

It would seem that having someone in charge of the policy that does not
stand to gain or lose financially from policy decisions would be in the
best interests of everyone.




From Skeeve at eintellego.net  Thu Feb  4 17:23:56 2010
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Fri, 5 Feb 2010 09:23:56 +1100
Subject: [arin-ppml] FW: [sig-policy] prop-083: Alternative criteria for
 subsequentIPv6 allocations
Message-ID: <292AF25E62B8894C921B893B53A19D97396AF3312F@BUSINESSEX.business.ad>

Hey all,

Given the current topic of 'IPv6 Non-Connected Networks', I thought that I would let you know of a policy that is presently in discussion on the APNIC lists that I submitted.

The crux is that even if aggregation of announcements as a policy is dropped, there is no policy that satisfies the need of LIR's to be able to build non-connected IPv6 networks in the APNIC region.

With some basic justification, an LIR should be able to gain subsequent /32 allocations for the purpose of remaining 'as routable as possible'.

While APNIC, like other RIR's do not set routing policy, they do heavily influence it.  And while they cannot control the practice of community filtering lists based on their own allocation pools, they should not ignore the situation.

Given that IPv6 is not a scarce resource and by no means am I suggesting we just burn it for the fun of it, this seems to be a philosophical debate rather than a technical one.  This is due to that even if an LIR could de-aggregate its /32 to say, 8 /35's or 16 36's, these entries in the routing table would have the exact same result as if they had 16 * /32's.

So due to this, the only restriction here is the pool allocation which the community filter lists are based on - which the RIR's essentially have created and now have the responsibility to consider.

...Skeeve

--
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
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?

From: sig-policy-bounces at lists.apnic.net [mailto:sig-policy-bounces at lists.apnic.net] On Behalf Of Terence Zhang YH(CNNIC)
Sent: Wednesday, 3 February 2010 10:46 PM
To: sig-policy at apnic.net
Subject: [sig-policy] prop-083: Alternative criteria for subsequentIPv6 allocations

Dear SIG members,

The proposal, 'Alternative criteria for subsequent IPv6 allocations',
has been sent to the Policy SIG for review. It will be presented at the
Policy SIG at APNIC 29 in Kuala Lumpur, 1-5 March 2010.

We invite you to review and comment on the proposal on the mailing list
before the meeting.

The comment period on the mailing list before an APNIC meeting is an
important part of the policy development process. We encourage you to
express your views on the proposal:

     - Do you support or oppose this proposal?
     - Does this proposal solve a problem you are experiencing? If so,
       tell the community about your situation.
     - Do you see any disadvantages in this proposal?
     - Is there anything in the proposal that is not clear?
     - What changes could be made to this proposal to make it more
       effective?


Information about this and other policy proposals is available from:

       http://www.apnic.net/policy/proposals


Randy, Ching-Heng, and Terence


___________________________________________________________________

prop-083-v001: Alternative criteria for subsequent IPv6 allocations
___________________________________________________________________


Author:    Skeeve Stevens
            <skeeve at eintellego.net>

Version:   1

Date:      3 February 2010


1.  Introduction
----------------

This is a proposal to enable current APNIC account holders with existing
IPv6 allocations to receive subsequent IPv6 allocations from APNIC for
use in networks that are not connected to the initial IPv6 allocation.


2.  Summary of current problem
------------------------------

An APNIC account holder with an existing /32 IPv6 allocation (or larger)
is unable to deaggregate that allocation into routes smaller than a /32
due to the community practice of 'filter blocking' or 'bogon lists'
associated with RIR blocks which are known to have a minimum allocation
size of /32 [1].

An LIR may want to build a network in a separate location and provide
IPv6 connectivity; however, because the LIR risks routability problems
if they deaggregate, they cannot use a subset of their initial
allocation in the new location.

For example:

      An ISP has a /32 allocation which they announce via an upstream
      in New Zealand.  The ISP wants to build a new network in Singapore.
      The ISP's new network in Singapore is not connected to the existing
      New Zealand network and the ISP is using a local transit provider
      to obtain dual stacked connectivity.

      If the network was using IPv4 addresses, the ISP would usually
      be able to deaggregate their allocation and announce one part of
      the deaggregated range to the local transit provider.

      In IPv6, however, this is not possible due to 'community filtering'
      on ranges smaller than a /32.

      Such a filter may look like the following:

          ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32

      This above statement in the IPv6 BGP filter recommendations would
      cause any announcements by an ISP which had an allocation,
      such as 2400:0000::/32, to announce smaller routes from that block,
      such as multiple /35s for example, to be filtered.  In a default
      free situation, connectivity to the ISP would be problematic.

      Instead, the ISP needs to obtain a new /32 allocation to be able to
      have IPv6 connectivity in the new location with an independent
      (from their primary network) transit provider.


3.  Situation in other RIRs
---------------------------

AfriNIC, ARIN, LACNIC and RIPE currently have no similar policies or
proposals. However, ARIN mailing lists are presently discussing this
situation and there seems to be significant support.


4.  Details of the proposal
---------------------------

4.1 It is proposed that alternative criteria be added to the subsequent
     IPv6 allocation policy [2] to allow current APNIC account holders
     with networks in multiple locations but without a connecting
     infrastructure to obtain IPv6 resources for each location.

4.2 To qualify for subsequent IPv6 allocations under the proposed
     alternative criteria, account holders must:

      - Be a current APNIC account holder with an existing IPv6
        allocation
      - Be announcing its existing IPv6 allocation
      - Demonstrate that the LIR has additional networks that are not
        connected to the network announcing its existing IPv6 allocation


5.  Advantages and disadvantages of the proposal
------------------------------------------------

5.1 Advantages

      - This proposal enables current APNIC account holders to avoid
        problematic network design issues and policy issues related to
        deaggregation.

      - Current APNIC account holders will be able to acquire resources
        and announce them separately to transit providers in disparate
        locations.


5.2 Disadvantages

      - This proposal could cause faster consumption of IPv6 address
        space. However, given the size of the total IPv6 pool, the author
        of this proposal does not see this as a significant issue.


6.  Effect on APNIC members
---------------------------

APNIC members would be able to build networks in separate locations and
obtain local IPv6 connectivity and announce their own resources.


7.  Effect on NIRs
------------------

The proposal allows for NIRs to have the choice as to when to adopt this
policy for their members.


8.   References
---------------

[1] For example, see "IPv6 BGP filter recommendations"
      http://www.space.net/~gert/RIPE/ipv6-filters.html

[2] See section 5.2, "Subsequent Allocation Section" in "IPv6 Address
      Allocation and Assignment Policy"
      http://www.apnic.net/policy/ipv6-address-policy#5.2
_______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100205/a62fe5ba/attachment.htm>

From Skeeve at eintellego.net  Thu Feb  4 17:04:11 2010
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Fri, 5 Feb 2010 09:04:11 +1100
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <9413.1265283016@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
Message-ID: <292AF25E62B8894C921B893B53A19D97396AF3312D@BUSINESSEX.business.ad>



> ARIN does define routing policy right now --- if you ask ARIN for
> address space, you get routable address space, and ARIN defines the
> policy by which you can get it.  There is presently only one question I
> can ask, and one set of criteria I can satisfy.  If I satisfy the
> criteria I get one thing: routable address space.

Hey Michael,

I would like to understand what you mean 'you get routable address space'?  Surely this should mean 'potentially routable space' ?  As ARIN cannot guarantee the routability of any address space whatsoever.

In the RIPE NCC and APNIC allocation policies they clearly state that they do not guarantee routability of any allocation as they can't control what everyone out there on the internet does, nor control the routing policies of any LIR.

...Skeeve

--
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
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?


From bill at herrin.us  Thu Feb  4 17:37:41 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 4 Feb 2010 17:37:41 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com> 
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com> 
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
Message-ID: <3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>

On Thu, Feb 4, 2010 at 4:14 PM, Barbara Roseman
<barbara.roseman at icann.org> wrote:
> I think there's a subtle but important distinction
> that's being lost, and that Cathy and Marla tried to clarify.

Hi Barbara,

If I understood the distinction that Cathy and Marla drew, the point
they're making is that nowhere does ARIN say what routes an ISP has to
carry. ARIN doesn't even say what routes an ISP ought to carry. Nor is
there any other legal obligation which compels ISPs to carry any
particular routes for addresses ARIN allocates. Like Verizon has done
with IPv6 /48's, ISPs are welcome to disregard any routes they don't
like for any reason at all. That they rarely exercise that choice
means nothing more sinister than that routing the address ARIN
allocates is good for business.

Do you feel that's a reasonable re-statement of what they said? I'd
hate to be obtuse about it, so if I'm missing the their point please
help me understand.


I think I understand the claim, but I dispute it.

Cause and effect is no less potent for being indirect. The
practicality of altering BGP routing activity based on a second feed
of assignments matched to assignment classes is doubtful. Even if it
could be done from a technical perspective, ARIN doesn't publish the
criteria by which each registrant qualified for their addresses, so
such a feed has no source for its content.

Realistically, functionally, technically, the tools I as an operator
have for implementing routing policy can only paint with a broad
brush. Discard small announcements in this /8. Depreference that one.
Unless ARIN classifies registrants in a manner consistent with those
tools, my choices for routing policy devolve to two basic options:
accept routes announcing ARIN IP addresses or don't.

In other words, ARIN sets the routing policy for North America. Not
explicitly, cleanly and openly, but haphazardly, indirectly and
silently.

The unspoken and unintentional yet cumulative net effect of ARIN's
allocation practices make ISPs a mob-style offer they can't refuse:
carry all of the addresses we approve or carry none of them and lose
your business.

At this point we're stuck with that for IPv4. The addresses are
already deployed. With some mild adjustments to our allocation
practices, we don't have to be stuck with that effect for IPv6.

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 gbonser at seven.com  Thu Feb  4 17:53:21 2010
From: gbonser at seven.com (George Bonser)
Date: Thu, 4 Feb 2010 14:53:21 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
References: <4B563F50.1070306@umn.edu>
	<9413.1265283016@marajade.sandelman.ca><c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com> 
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7619@RWC-EX1.corp.seven.com>

" The priorities of the ISP and the network provider" should be "The
priorities of the ISP and the network user"


> -----Original Message-----
> From: George Bonser
> Sent: Thursday, February 04, 2010 2:21 PM
> To: 'William Herrin'; arin-ppml at arin.net
> Subject: RE: [arin-ppml] IPv6 Non-connected networks
> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
> > Behalf Of William Herrin
> >
> > Hi Cathy,
> >
> > 1. Make ARIN officially the routing policy arbiter for North America
> > with appropriate care given to checks and balances, or
> > 2. Adjust ARIN's process so that ISPs actually do control their own
> > routing policies
> 
> I believe case number 1 is actually, as you mention, the current
> default case in that routing policy must be adjusted in order to
> accommodate the address allocation policies of the RIRs
> 
> Case number 2 would cause a problem because I could see the ISPs
> attempt to force customers to be "stickier" to their services or take
> traffic from a competitor (i.e.  protecting their customer lists by an
> even greater degree).
> 
> Once a network reaches some size, it is to the benefit of the network
> user to be multihomed and provider agnostic.  The idea is to endeavor
> NOT to be sticky to any provider and take advantage of better pricing
> opportunities as they arise where they make business sense.
> 
> The priorities of the ISP and the network provider are sometimes in
> opposite directions.  The ISP wants to maximize revenues and not lose
> customers to competition.  The user wants to get the best
> price/performance metric they can obtain which might be counter to the
> notion of being "sticky" to a provider unless that provider also
offers
> additional services the user requires. It is only natural that the
ISPs
> in a general sense are going to want to make it more difficult for
> customers to be agile while customers are going to want to be as
> flexible and agile as possible.
> 
> It would seem that having someone in charge of the policy that does
not
> stand to gain or lose financially from policy decisions would be in
the
> best interests of everyone.
> 



From scottleibrand at gmail.com  Thu Feb  4 18:30:29 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 04 Feb 2010 15:30:29 -0800
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
 Registration Requirements
In-Reply-To: <7B585B5D-AC81-4731-B3BF-7A07B6112E4B@gmail.com>
References: <4B6AF6CE.7000709@arin.net>
	<7B585B5D-AC81-4731-B3BF-7A07B6112E4B@gmail.com>
Message-ID: <4B6B5895.2090601@gmail.com>

After getting a chance to read through the sections of the NRPM that 
would be removed by this policy, I have some additional feedback inline 
below...

On 2/4/2010 8:41 AM, Scott Leibrand wrote:
> I like it.
>
> For IPv6, should the cutoff be "more
> than a /56" or "/56 and larger blocks"? IMO more than /56 is better, 
> but it needs to be made consistent.
>
> Thanks,
> Scott
>
> On Feb 4, 2010, at 8:33 AM, Member Services <info at arin.net> wrote:
>
>>
>> Policy statement:
>>
>> ## Definitions ##
>>
>> - Add:
>>
>> 2.3. Organizational Information
>>
>> When required, organization Information must include at a minimum:
>> Legal name, city, state, zip code equivalent and at least one valid
>> technical or abuse POC; inclusion of street address is highly
>> encouraged. The POC shall be designated by the organization and must
>> include at least one verifiable email address, inclusion of a phone
>> number is highly encouraged.
>>
>> ## IPv4 ##
>>
>> - Rename 4.2.3.7. "Reassignment information" to "Registration"
>>
>> - Rename 4.2.3.7.1. "Customer organization information" to
>> "Reassignment Information" and replace text with:
>>
>> When an organization holding an IPv4 address allocation makes IPv4
>> address assignments, it must register reassignment information via
>> SWIP or RWHOIS server. SWIP and RWHOIS reassignments shall include
>> each client's organizational information, except where specifically
>> exempted by this policy.
>>
>> - Replace 4.2.3.7.6. Residential Customer Privacy with:
>>
>> 4.2.3.7.6. Residential Subscribers
>>
>> 4.2.3.7.6.1. Residential Market Area
>>
>> In most cases, ISPs that have residential subscribers assign address
>> space to the infrastructure to which their customers connect rather
>> than to individual subscribers. This assignment information regarding
>> each market area holding an address block should be registered with
>> the network name used to identify each market area. Initial
>> allocations are based on total number of homes that could purchase the
>> service in a given market area. Each assignment to specific end-users
>> of /29 and larger blocks still requires individual registration.
>>
>> 4.2.3.7.6.2. Residential Customer Privacy
>>
>> To maintain the privacy of their residential customers, an
>> organization with downstream residential customers holding /29 and
>> larger blocks may substitute that organization's name for the
>> customer's name, e.g. 'Private Customer - XYZ Network', and the
>> customer's street address may read 'Private Residence'. Each private
>> downstream residential reassignment must have accurate upstream Abuse
>> and Technical POCs visible on the WHOIS record for that block.
>>
>> - Strike section 4.2.6. "Cable Address Space Policy"

Most of 4.2.6 has been moved to the new 4.2.3.7.6 above.  However, this 
portion has not:

"Using SWIP or RWHOIS, cable ISPs must show that they have reassigned at 
least 80% of their current address space, with a 50 to 80% utilization 
rate, in order to request additional addresses."

I think we need to preserve that, somehow, in order to allow cable ISPs 
to continue obtaining space as they do today.  The intent of your 
proposal seems to be to provide the same standard to any org providing 
service to an entire market area.  If that's what you want to do, then 
perhaps something like this should go into your 4.2.3.7.6 as well:

"In order to obtain additional IPv4 addresses, ISPs assigning addresses 
by market area must show, using SWIP or RWHOIS, that they have 
reassigned at least 80% of their current address space, with a >50% 
utilization rate."

-Scott

>>
>> ## IPv6 ##
>>
>> - Replace Section 6.5.5. with:
>>
>> 6.5.5. Registration
>>
>> 6.5.5.1. Reassignment information
>>
>> When an organization holding an IPv6 address allocation makes IPv6
>> address assignments, it must register reassignment information in a
>> database, accessible by RIRs as appropriate (information registered by
>> an RIR may be replaced by a distributed database for registering
>> address management information in future). These reassignment
>> registrations shall include each client's organizational information,
>> except where specifically exempted by this policy.
>>
>> 6.5.5.2. /56 registered unit
>>
>> Information is registered in units of assigned /56 networks. When more
>> than a /56 is assigned to a client organization, the assigning
>> organization is responsible for ensuring that the address space is
>> registered in an RIR database.
>>
>> 6.5.5.3. Submit within 7 days
>>
>> Any time an LIR receives a new block of address space, reassignment
>> information should be submitted within 7 days of issuance of the new
>> space.
>>
>> 6.5.5.4. Visible via WHOIS
>>
>> This information must be visible via WHOIS prior to submitting a
>> request for a new allocation. For further information on reassigning
>> IP address space, please see RFC 2050.
>>
>> 6.5.5.6. Residential Subscribers
>>
>> 6.5.5.6.1. Residential Market Area
>>
>> In most cases, ISPs that have residential subscribers assign address
>> space to the infrastructure to which their customers connect rather
>> than to individual subscribers. This assignment information regarding
>> each market area holding an address block should be registered with
>> the network name used to identify each market area. Initial
>> allocations are based on total number of homes that could purchase the
>> service in a given market area. Each assignment to specific end-users
>> of /56 and larger blocks still requires individual registration.
>>
>> 6.5.5.6.2. Residential Customer Privacy
>>
>> To maintain the privacy of their residential customers, an
>> organization with downstream residential customers holding /56 and
>> larger blocks may substitute that organization's name for the
>> customer's name, e.g. 'Private Customer - XYZ Network', and the
>> customer's street address may read 'Private Residence'. Each private
>> downstream residential reassignment must have accurate upstream Abuse
>> and Technical POCs visible on the WHOIS record for that block.
>>
>>
>> Rationale:
>>
>> This proposal intends to do several things:
>> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
>> NRPM easier to understand and comply with - at least as it relates to
>> reassignment information.
>> 2) Specifically define what organizational information is required to
>> be added to whois when reassignments are made to client organizations.
>> 3) To specifically state that a client organization may designate the
>> POC of their choice for any/all whois entries. This includes
>> designating an upstream POC as their own prefered POC.
>> 4) Expands the priviledges previously reserved solely for cable ISPs
>> to all ISPs/LIRs with residential subscribers. Namely the ability to
>> SWIP/RWHOIS an entire residential market area as one reassignment. It
>> also expands this priviledge to IPv6 reasignments, instead of just
>> IPv4 as it is now.
>>
>> 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 cgrundemann at gmail.com  Thu Feb  4 18:43:52 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 4 Feb 2010 16:43:52 -0700
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements
In-Reply-To: <4B6B5895.2090601@gmail.com>
References: <4B6AF6CE.7000709@arin.net>
	<7B585B5D-AC81-4731-B3BF-7A07B6112E4B@gmail.com>
	<4B6B5895.2090601@gmail.com>
Message-ID: <443de7ad1002041543tc320bebh20bc781b39be9e7e@mail.gmail.com>

On Thu, Feb 4, 2010 at 16:30, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>>
>>> - Replace 4.2.3.7.6. Residential Customer Privacy with:
>>>
>>> 4.2.3.7.6. Residential Subscribers
>>>
>>> 4.2.3.7.6.1. Residential Market Area
>>>
>>> In most cases, ISPs that have residential subscribers assign address
>>> space to the infrastructure to which their customers connect rather
>>> than to individual subscribers. This assignment information regarding
>>> each market area holding an address block should be registered with
>>> the network name used to identify each market area. Initial
>>> allocations are based on total number of homes that could purchase the
>>> service in a given market area. Each assignment to specific end-users
>>> of /29 and larger blocks still requires individual registration.
>>>
>>> 4.2.3.7.6.2. Residential Customer Privacy
>>>
>>> To maintain the privacy of their residential customers, an
>>> organization with downstream residential customers holding /29 and
>>> larger blocks may substitute that organization's name for the
>>> customer's name, e.g. 'Private Customer - XYZ Network', and the
>>> customer's street address may read 'Private Residence'. Each private
>>> downstream residential reassignment must have accurate upstream Abuse
>>> and Technical POCs visible on the WHOIS record for that block.
>>>
>>> - Strike section 4.2.6. "Cable Address Space Policy"
>
> Most of 4.2.6 has been moved to the new 4.2.3.7.6 above. ?However, this
> portion has not:
>
> "Using SWIP or RWHOIS, cable ISPs must show that they have reassigned at
> least 80% of their current address space, with a 50 to 80% utilization rate,
> in order to request additional addresses."

Good catch! I did not read that section carefully enough I think -
somehow I thought that it was simply restating the common 80% rule, I
did not notice the 50% to 80%.

> I think we need to preserve that, somehow, in order to allow cable ISPs to
> continue obtaining space as they do today. ?The intent of your proposal
> seems to be to provide the same standard to any org providing service to an
> entire market area. ?If that's what you want to do, then perhaps something
> like this should go into your 4.2.3.7.6 as well:
>
> "In order to obtain additional IPv4 addresses, ISPs assigning addresses by
> market area must show, using SWIP or RWHOIS, that they have reassigned at
> least 80% of their current address space, with a >50% utilization rate."

I agree. I will wait a day or two for additional comments before
submitting a second version but something along those lines (if not
those exact lines) will be included in version 2.
~Chris

>
> -Scott
>
> _______________________________________________
> 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From packetgrrl at gmail.com  Thu Feb  4 19:09:47 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 4 Feb 2010 17:09:47 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
Message-ID: <c3227e9e1002041609o205a1c4r625217c0948710a5@mail.gmail.com>

Bill,

I see what you're saying here but the reality for me was that for close to a
year a very large ISP didn't pay attention to ARIN's allocation of parts of
24.0.0.0/8.  They were big and I was little and so they won at least for a
time.  Their customers weren't complaining and so they had no need to accept
my more specific route. Those of us with parts of 24.0.0.0/8 complained but
since none of us were paying that large ISP we were ignored.

I could see this happening again if for example the ARIN community decided
on a policy that caused the global routing table to explode.   Then ISPs
would most likely filter to keep their routers from crashing and those super
specific blocks wouldn't be routable.

ARIN has no control over filtering/routing policies.  At a recent NANOG
there was a panel where ISPs in no uncertain terms told the community that
they do not want ARIN policies to include anything about routing policy.  I
believe at this point that most of the RIRs have removed routing criteria
from their IPv6 policies for that very reason.

----Cathy

On Thu, Feb 4, 2010 at 3:37 PM, William Herrin <bill at herrin.us> wrote:

> On Thu, Feb 4, 2010 at 4:14 PM, Barbara Roseman
> <barbara.roseman at icann.org> wrote:
> > I think there's a subtle but important distinction
> > that's being lost, and that Cathy and Marla tried to clarify.
>
> Hi Barbara,
>
> If I understood the distinction that Cathy and Marla drew, the point
> they're making is that nowhere does ARIN say what routes an ISP has to
> carry. ARIN doesn't even say what routes an ISP ought to carry. Nor is
> there any other legal obligation which compels ISPs to carry any
> particular routes for addresses ARIN allocates. Like Verizon has done
> with IPv6 /48's, ISPs are welcome to disregard any routes they don't
> like for any reason at all. That they rarely exercise that choice
> means nothing more sinister than that routing the address ARIN
> allocates is good for business.
>
> Do you feel that's a reasonable re-statement of what they said? I'd
> hate to be obtuse about it, so if I'm missing the their point please
> help me understand.
>
>
> I think I understand the claim, but I dispute it.
>
> Cause and effect is no less potent for being indirect. The
> practicality of altering BGP routing activity based on a second feed
> of assignments matched to assignment classes is doubtful. Even if it
> could be done from a technical perspective, ARIN doesn't publish the
> criteria by which each registrant qualified for their addresses, so
> such a feed has no source for its content.
>
> Realistically, functionally, technically, the tools I as an operator
> have for implementing routing policy can only paint with a broad
> brush. Discard small announcements in this /8. Depreference that one.
> Unless ARIN classifies registrants in a manner consistent with those
> tools, my choices for routing policy devolve to two basic options:
> accept routes announcing ARIN IP addresses or don't.
>
> In other words, ARIN sets the routing policy for North America. Not
> explicitly, cleanly and openly, but haphazardly, indirectly and
> silently.
>
> The unspoken and unintentional yet cumulative net effect of ARIN's
> allocation practices make ISPs a mob-style offer they can't refuse:
> carry all of the addresses we approve or carry none of them and lose
> your business.
>
> At this point we're stuck with that for IPv4. The addresses are
> already deployed. With some mild adjustments to our allocation
> practices, we don't have to be stuck with that effect for IPv6.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100204/7a89062d/attachment.htm>

From barbara.roseman at icann.org  Thu Feb  4 19:21:31 2010
From: barbara.roseman at icann.org (Barbara Roseman)
Date: Thu, 4 Feb 2010 16:21:31 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
Message-ID: <7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>

Bill,

I think that's a fair restatement of what I was saying, except you left out the part about uniqueness vs. routeability. My points were twofold:

1) ARIN can only offer unique registration of IP addresses, they cannot offer unique use of addresses -- nor can anyone else because Bad People tend to ignore the rules, and Ignorant People are, well, ignorant.

2) The ARIN community and the NANOG community have discussed repeatedly that it's not simple cause and effect from ARIN's allocation/assignment policies to operator's routing policies, though the influence is extreme. If the connectivity provider is large enough, as CJ notes, than they can do whatever they want.

-Barb
On Feb 4, 2010, at 2:37 PM, William Herrin wrote:

> On Thu, Feb 4, 2010 at 4:14 PM, Barbara Roseman
> <barbara.roseman at icann.org> wrote:
>> I think there's a subtle but important distinction
>> that's being lost, and that Cathy and Marla tried to clarify.
> 
> Hi Barbara,
> 
> If I understood the distinction that Cathy and Marla drew, the point
> they're making is that nowhere does ARIN say what routes an ISP has to
> carry. ARIN doesn't even say what routes an ISP ought to carry. Nor is
> there any other legal obligation which compels ISPs to carry any
> particular routes for addresses ARIN allocates. Like Verizon has done
> with IPv6 /48's, ISPs are welcome to disregard any routes they don't
> like for any reason at all. That they rarely exercise that choice
> means nothing more sinister than that routing the address ARIN
> allocates is good for business.
> 
> Do you feel that's a reasonable re-statement of what they said? I'd
> hate to be obtuse about it, so if I'm missing the their point please
> help me understand.
> 
> 
> I think I understand the claim, but I dispute it.
> 
> Cause and effect is no less potent for being indirect. The
> practicality of altering BGP routing activity based on a second feed
> of assignments matched to assignment classes is doubtful. Even if it
> could be done from a technical perspective, ARIN doesn't publish the
> criteria by which each registrant qualified for their addresses, so
> such a feed has no source for its content.
> 
> Realistically, functionally, technically, the tools I as an operator
> have for implementing routing policy can only paint with a broad
> brush. Discard small announcements in this /8. Depreference that one.
> Unless ARIN classifies registrants in a manner consistent with those
> tools, my choices for routing policy devolve to two basic options:
> accept routes announcing ARIN IP addresses or don't.
> 
> In other words, ARIN sets the routing policy for North America. Not
> explicitly, cleanly and openly, but haphazardly, indirectly and
> silently.
> 
> The unspoken and unintentional yet cumulative net effect of ARIN's
> allocation practices make ISPs a mob-style offer they can't refuse:
> carry all of the addresses we approve or carry none of them and lose
> your business.
> 
> At this point we're stuck with that for IPv4. The addresses are
> already deployed. With some mild adjustments to our allocation
> practices, we don't have to be stuck with that effect for IPv6.
> 
> 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  Thu Feb  4 20:13:58 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 4 Feb 2010 20:13:58 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com> 
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com> 
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com> 
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
Message-ID: <3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>

On Thu, Feb 4, 2010 at 7:21 PM, Barbara Roseman
<barbara.roseman at icann.org> wrote:
> I think that's a fair restatement of what I was saying,
>except you left out the part about uniqueness vs.
>routeability. My points were twofold:
>
> 1) ARIN can only offer unique registration of IP
>addresses, they cannot offer unique use of
>addresses -- nor can anyone else because
>Bad People tend to ignore the rules, and Ignorant
>People are, well, ignorant.

Hi Barbara,

Okay. That reads as a reasonable statement to me. I don't follow how
it bears on the routing policy issue.

Or at least I don't see a way that ARIN could alter its process to
make announcements inconsistent with the ARIN registrations easily
filterable. If such a thing was possible, I'd surely want to see an
ARIN policy proposal as, no doubt, would every ISP on the planet.


> 2) The ARIN community and the NANOG community
>have discussed repeatedly that it's not simple cause
>and effect from ARIN's allocation/assignment policies
>to operator's routing policies, though the influence is
>extreme. If the connectivity provider is large enough,
>as CJ notes, than they can do whatever they want.

Okay. So because providers are already able, for a time, to make
unreasonable choices which defy the defacto standards adopted by the
overwhelming majority of their peers we should not adopt practices
that enable more flexibility within the set of -reasonable- choices? I
don't follow.


On Thu, Feb 4, 2010 at 7:09 PM, cja at daydream.com <packetgrrl at gmail.com> wrote:
> Bill,
> I see what you're saying here but the reality for me was that for close to a
> year a very large ISP didn't pay attention to ARIN's allocation of parts of
> 24.0.0.0/8.  They were big and I was little and so they won at least for a
> time.

That's disappointing in this day and age, but then we're talking about
the same folks who thought their customers wouldn't cry bloody murder
when they cut off communications with cogent. If you ever have
problems with them carrying your routes again, drop me a line so I can
start claiming service credits. That'll get their attention. :)


> ARIN has no control over filtering/routing policies.  At a recent NANOG
> there was a panel where ISPs in no uncertain terms told the community that
> they do not want ARIN policies to include anything about routing policy.  I
> believe at this point that most of the RIRs have removed routing criteria
> from their IPv6 policies for that very reason.

Hi Cathy,

Poor control is not the same as no control and getting ARIN policy out
of the way of ISPs setting routing policy is not the same as saying
and doing nothing about routing policy.

In a very real sense, addressing is routing is addressing. Each
follows from the structure of the other. An addressing policy which
does not impact routing policy is simply inconsistent with reality.

I'll repeat that for emphasis: There's no such thing as addressing
policy which does not impact routing policy. It can't exist.

Thus the choices are:

1. Create an addressing policy which implicitly shapes routing policy
through the accidents of its structure.

2. Create an addressing policy which is informed by and explicitly
shapes a uniform routing policy.

3. Create an addressing policy which is an enabler for a broad range
of rational routing policies and let the overall routing policy find
its own equilibrium.


What we do now is sometimes #1 and sometimes #2. For example:

A. The unfilterability of traffic engineering is an accidental
side-effect of CIDR address allocations. Because they're all mashed
together in the same pool, operators can't tell the difference between
easily filterable TE and unfilterable multihomed downstreams.

B. Accepting /24 reassignments to multihomed customers regardless of
size is informed by the /24 boundary present in DFZ routing policy.

C. CIDR allocation (instead of simply assigning a linear range of
addresses) is an explicit attempt to bring about aggregation within
the routing system. It's routing policy directly encoded as addressing
policy.


I think we'd be wiser to pursue course #3: enable a broad range of
sensible routing policies and then step back out of the 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 packetgrrl at gmail.com  Thu Feb  4 20:45:42 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 4 Feb 2010 18:45:42 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>
Message-ID: <c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>

Bill,

I argue that we do try our best to do #3 as you have defined it below

      "3. Create an addressing policy which is an enabler for a broad range
      of rational routing policies and let the overall routing policy find
      its own equilibrium."

There is a balance, however.  The needs of the ARIN community for
assignments and allocations could easily be in conflict with routing needs.
 We have seen that over and over.  For a while it was extremely apparent
when we were running out of "class B" blocks and started allocating bit
aligned blocks of "class Cs" but there was no CIDR.  So the routing table
exploded and the ISPs had to scramble around to deploy BGP that would handle
huge blocks of "class Cs"    It was a very unpleasant time and my customers
at the time were not at all happy with the slowness of the network.

 When we moved the minimum allocation from a /19 to a /20 first we argued at
length about the routing implications and then we actually watched the
routing table over time to see the effects.   There even used to be a
Routing Table Measurement and Analysis (RTMA) working group as part of ARIN
to bring routing table information to the community as a way to help with
address policy decisions.

With IPv4 address space running out I can easily see scenarios where the
ARIN community will want assignments and/or allocations that directly
conflict with routing.    Some will gain consensus and some probably won't.
  WIth IPv6 we have in essence classfull addressing again.  At some point
will we relive these scenarios?  Probably.

It isn't that the ARIN community doesn't consider these things when
developing good policy.  These things are always discussed and considered
but in the end addressing policy has to also meet the needs of the
community. ARIN has meetings jointly with NANOG for that very reason.  It is
essential that addressing policy has input from the communities it affects.


----Cathy




010 at 6:13 PM, William Herrin <bill at herrin.us> wrote:

> On Thu, Feb 4, 2010 at 7:21 PM, Barbara Roseman
> <barbara.roseman at icann.org> wrote:
> > I think that's a fair restatement of what I was saying,
> >except you left out the part about uniqueness vs.
> >routeability. My points were twofold:
> >
> > 1) ARIN can only offer unique registration of IP
> >addresses, they cannot offer unique use of
> >addresses -- nor can anyone else because
> >Bad People tend to ignore the rules, and Ignorant
> >People are, well, ignorant.
>
> Hi Barbara,
>
> Okay. That reads as a reasonable statement to me. I don't follow how
> it bears on the routing policy issue.
>
> Or at least I don't see a way that ARIN could alter its process to
> make announcements inconsistent with the ARIN registrations easily
> filterable. If such a thing was possible, I'd surely want to see an
> ARIN policy proposal as, no doubt, would every ISP on the planet.
>
>
> > 2) The ARIN community and the NANOG community
> >have discussed repeatedly that it's not simple cause
> >and effect from ARIN's allocation/assignment policies
> >to operator's routing policies, though the influence is
> >extreme. If the connectivity provider is large enough,
> >as CJ notes, than they can do whatever they want.
>
> Okay. So because providers are already able, for a time, to make
> unreasonable choices which defy the defacto standards adopted by the
> overwhelming majority of their peers we should not adopt practices
> that enable more flexibility within the set of -reasonable- choices? I
> don't follow.
>
>
> On Thu, Feb 4, 2010 at 7:09 PM, cja at daydream.com <packetgrrl at gmail.com>
> wrote:
> > Bill,
> > I see what you're saying here but the reality for me was that for close
> to a
> > year a very large ISP didn't pay attention to ARIN's allocation of parts
> of
> > 24.0.0.0/8.  They were big and I was little and so they won at least for
> a
> > time.
>
> That's disappointing in this day and age, but then we're talking about
> the same folks who thought their customers wouldn't cry bloody murder
> when they cut off communications with cogent. If you ever have
> problems with them carrying your routes again, drop me a line so I can
> start claiming service credits. That'll get their attention. :)
>
>
> > ARIN has no control over filtering/routing policies.  At a recent NANOG
> > there was a panel where ISPs in no uncertain terms told the community
> that
> > they do not want ARIN policies to include anything about routing policy.
>  I
> > believe at this point that most of the RIRs have removed routing criteria
> > from their IPv6 policies for that very reason.
>
> Hi Cathy,
>
> Poor control is not the same as no control and getting ARIN policy out
> of the way of ISPs setting routing policy is not the same as saying
> and doing nothing about routing policy.
>
> In a very real sense, addressing is routing is addressing. Each
> follows from the structure of the other. An addressing policy which
> does not impact routing policy is simply inconsistent with reality.
>
> I'll repeat that for emphasis: There's no such thing as addressing
> policy which does not impact routing policy. It can't exist.
>
> Thus the choices are:
>
> 1. Create an addressing policy which implicitly shapes routing policy
> through the accidents of its structure.
>
> 2. Create an addressing policy which is informed by and explicitly
> shapes a uniform routing policy.
>
> 3. Create an addressing policy which is an enabler for a broad range
> of rational routing policies and let the overall routing policy find
> its own equilibrium.
>
>
> What we do now is sometimes #1 and sometimes #2. For example:
>
> A. The unfilterability of traffic engineering is an accidental
> side-effect of CIDR address allocations. Because they're all mashed
> together in the same pool, operators can't tell the difference between
> easily filterable TE and unfilterable multihomed downstreams.
>
> B. Accepting /24 reassignments to multihomed customers regardless of
> size is informed by the /24 boundary present in DFZ routing policy.
>
> C. CIDR allocation (instead of simply assigning a linear range of
> addresses) is an explicit attempt to bring about aggregation within
> the routing system. It's routing policy directly encoded as addressing
> policy.
>
>
> I think we'd be wiser to pursue course #3: enable a broad range of
> sensible routing policies and then step back out of the 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100204/6ffa06ca/attachment.htm>

From jlewis at lewis.org  Thu Feb  4 22:17:13 2010
From: jlewis at lewis.org (Jon Lewis)
Date: Thu, 4 Feb 2010 22:17:13 -0500 (EST)
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3995.1265304209@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>
	<3995.1265304209@marajade.sandelman.ca>
Message-ID: <Pine.LNX.4.61.1002042214470.22812@soloth.lewis.org>

On Thu, 4 Feb 2010, Michael Richardson wrote:

> The only example I can see are some of the 69/8 and 70/8 (if I got those
> prefixes right), which many people had bogon filters for, and it took a
> few months for those filters to get completely removed.

Have there not been similar issues with every Reserved -> Allocated 
transitioned /8 since 69/8?  It was much more than "a few months" to get 
the majority of the outdated bogon filters removed.

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


From bill at herrin.us  Thu Feb  4 22:54:04 2010
From: bill at herrin.us (William Herrin)
Date: Thu, 4 Feb 2010 22:54:04 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com> 
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com> 
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com> 
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com> 
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>
Message-ID: <3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>

On Thu, Feb 4, 2010 at 8:45 PM, cja at daydream.com <packetgrrl at gmail.com> wrote:
> I argue that we do try our best to do #3 as you have defined it below
> ?? ? ?"3. Create an addressing policy which is an enabler for a broad range
> ?? ? ?of rational routing policies and let the overall routing policy find
> ?? ? ?its own equilibrium."

Hi Cathy,

What ARIN policy, past or current, would you cite as an example of
enabling a wide range of possible, rational routing policies, from
which the community coalesced on a particular one? Let's deconstruct
it and see if it really followed course #3.


> There is a balance, however. ?The needs of the ARIN community for
> assignments and allocations could easily be in conflict with routing needs.
> ?We have seen that over and over. ?For a while it was extremely apparent
> when we were running out of "class B" blocks and started allocating bit
> aligned blocks of "class Cs" but there was no CIDR. ?So the routing table
> exploded and the ISPs had to scramble around to deploy BGP that would handle
> huge blocks of "class Cs" ? ?It was a very unpleasant time and my customers
> at the time were not at all happy with the slowness of the network.

That balance, implemented at ARIN's level, is course #2:

2. Create an addressing policy which is informed by and explicitly
shapes a uniform routing policy.

As you say, we had one routing policy: classful. But we started
running out of class-B's. So we switched to linear allocations of
class C's (they weren't reliably bit aligned IIRC. You can still find
examples in the swamp.). That nearly exploded the routing table. So
the vendors rushed out CIDR in the routing protocols and we started
allocating that way as well.

There was no range of policies here. At each particular time exactly
one policy was possible and those who didn't want to play were broken.


> ?When we moved the minimum allocation from a /19 to a /20 first we argued at
> length about the routing implications and then we actually watched the
> routing table over time to see the effects. ? There even used to be a
> Routing Table Measurement and Analysis (RTMA) working group as part of ARIN
> to bring routing table information to the community as a way to help with
> address policy decisions.

Canonical example of path #2. Here''s how that would have gone if we'd
been trying for path #3:

Without estimating routing table impact, ARIN sets aside and publish a
specific then-clean /8 for assignments without a minimum length.
Assignments in all other ARIN spaces would continue to be /19 or
larger. Assignments in the specific /8 would be /20 and shorter only.

ARIN creates a template for ASes to submit their choice of the maximum
prefix length they accept in that /8. ARIN compiles the results and
publishes a regularly updated web page with the percentage of ASes
supporting each prefix length as an FYI for folks requesting addresses
so that they know before paying the likelyhood of their addresses
being routed.

See the difference between course #2 and course #3? In course #3 ARIN
doesn't attempt to make a well-reasoned choice. There's no need.
Instead, it seeks to provide ISPs and registrants with enough
information for them to make well reasoned choices, and then ARIN
steps back and the ISPs and registrants make whatever choices they
darn well please. Initially you have a tug of war between ISPs and
registrants but then it settles out where you have 98% adoption at one
level, 80% adoption at the next and 25% beyond that.


At this point you might say: "So what?'" Well, let's look at what happens next.

On course #2, we know what happened next. We argued and debated some
more and lowered end-user assignments to /22. Now we're arguing and
debating some more and we'll lower multihomed end-user assignments to
/24.

On course #3, I'll have to spin a work of fiction and imagine how it
might have all worked out.

So, we have an unstable situation. Folks are holding or can easily get
IP addresses that are 80% routeable. There's money on the table for
someone who can figure out to get them to the other 20% of the
Internet so that they can dump their ISP-assigned addresses. That's a
recipe for innovation.

Next step, some scrappy inventor figures out that if he can just
introduce a single route for that /8, he can turn around and sell
tunnels to everybody else so they can pick up that final 20%. Not to
mention all the smaller assignments... He shops around and finds a
tier 1 who'll do it. And he's in business. And guess what, in spite of
the slowness from inefficient routing, it grows. What does he care
whether you have a /24 or a /32? You're paying him at a markup so it's
no skin off his back.

Now, the other tier-1's don't like that one bit. Not one bit at all.
Dude's stealing their bread! So, they start a joint venture to do the
same thing, camp it at the major peering points (like MAE-East) and
refuse to honor the /8 route if its announced from anybody else. Sorry
dude! You want service in the small assignments, you pay the joint
venture too.

So now we can have networks of any size right down to /32 and the
worst thing that happens is the packets take a side trip to one of the
peering points. As inefficiency goes, that's pretty darn mild. But it
isn't helpful to Joe. Joe has an ARIN /29, a DSL and a dialup as
backup. The /29 works fine with his DSL but the dialup uses a dynamic
IP address. If only there was a dyndns-like API where he could update
the tunnels quickly with an arbitrary IP address... and he'd need a
tunnel to a friendly ISP to let him source packets past the filter on
the dynamic dialup too...

Cool, so now we have failover from DSL using a $20 dialup using
provider-independent IP addresses and the worst thing that happens is
that our packets take a detour to the nearest major peering point. But
you know, if we could get that tunnel API cut-over time from 60
seconds down to one or two seconds, we could put it on a laptop with
some radio equipment and drive down the road with it. Latch on to the
next tower before we release the trailing one, get a new dynamic IP
and seamlessly move the tunnel forward...

Of course, this is all a work of fiction. When changing the minimum
allocation from /19 to /20, we might not have missed the opportunity
for IP mobility that worked really well. This whole chain of events
could easily have derailed at any step. Even if we'd been smart enough
to offer assignments at any prefix length, we might not have been
clever enough to contain them in a reasonably-sized space someone
could offer a covering announcement for or collect AS data on who
imposed what prefix length limits so that registrants could make
informed choices about it. And just because we were that clever
doesn't mean that the drop-off wouldn't be from 98% to 20% creating no
demand or that the scrappy inventor would have found a tier-1 willing
to accept the /8 announcement or found it affordable if he did.

But it didn't derail at any step. It derailed at the step where
instead of imagining an open-ended assignment process, we made a
well-reasoned decision to lower the minimum assignment from /19 to
/20.

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 gbonser at seven.com  Thu Feb  4 23:57:35 2010
From: gbonser at seven.com (George Bonser)
Date: Thu, 4 Feb 2010 20:57:35 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>
References: <4B563F50.1070306@umn.edu>
	<9413.1265283016@marajade.sandelman.ca><c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org><3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org><3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>
	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>

> 
> Now, the other tier-1's don't like that one bit. Not one bit at all.
> Dude's stealing their bread! So, they start a joint venture to do the
> same thing, camp it at the major peering points (like MAE-East) and
> refuse to honor the /8 route if its announced from anybody else. Sorry
> dude! You want service in the small assignments, you pay the joint
> venture too.
> 

Or, someone starts accepting the more specific routes without using the
tunnels and their customers don't need to pay no steeenking tunnel
broker which disrupts the entire scheme, another network does it, too,
in order to compete with them and that entire tunnel jv blows up and
everyone ends up accepting the more specifics.

What it does is allows those who are willing to make an investment in
routers with more resources (at least at their peering points) and can
handle huge routing tables to be more desirable providers and it drives
competition/innovation among the equipment vendors to ship gear that is
able to handle larger routing tables because the vendors that do so get
the business from the networks that want to offer that kind of service.

This is really going to come to a head with people who want to
dual-stack v4/v6 when v6 routes really start taking off.  Most companies
will be in both spaces. So on one hand we will see more smaller prefixes
in v4 at the same time v6 prefixes are ramping up.  Vendors better be
working on providing gear with a lot more resources for routing and
route caching than they are now.

The major constraint right now on routing table size is really a
hardware issue.  We are all working around a hardware bottleneck that is
just going to get worse.  The vendor to market with routers that handle
substantially larger routing tables without a huge increase in cost is
going to be a winner, and it pays to be a winner.




From bill at herrin.us  Fri Feb  5 00:22:50 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Feb 2010 00:22:50 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>
References: <4B563F50.1070306@umn.edu>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com> 
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com> 
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com> 
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com> 
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com> 
	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com> 
	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>
Message-ID: <3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>

On Thu, Feb 4, 2010 at 11:57 PM, George Bonser <gbonser at seven.com> wrote:
>> Now, the other tier-1's don't like that one bit. Not one bit at all.
>> Dude's stealing their bread! So, they start a joint venture to do the
>> same thing, camp it at the major peering points (like MAE-East) and
>> refuse to honor the /8 route if its announced from anybody else. Sorry
>> dude! You want service in the small assignments, you pay the joint
>> venture too.
>
> Or, someone starts accepting the more specific routes without using the
> tunnels and their customers don't need to pay no steeenking tunnel
> broker which disrupts the entire scheme, another network does it, too,
> in order to compete with them and that entire tunnel jv blows up and
> everyone ends up accepting the more specifics.

Hi George,

Likely couldn't travel that path; each new provider that accepts the
more specifics into his routing table only increases the percentage
penetration. Catch ditch the tunnel JV until you have nearly 100%
penetration and the cost of carrying all the routes in every router
versus a fraction of just the small routes in each of the JV's routers
is high enough to cost more than the small users are willing to pay.

You could, however, implement a dynamic tunnel map-encap protocol like
they've been discussing over in the RRG for the last couple of years
and let the ASes start to deploy ingress tunnel routers to catch
otherwise-unrouted packets for the /8 near their source and send them
encapsulated to their current destinations. Many outcomes are
possible; I'm not really looking to explore the whole field.

My point was that I'd really like to see us stop suffering failures of
imagination in the name of careful reason. ARIN has to be the
moderating force on the routing table only because we've failed to
imagine a individually driven process that renders the role
unnecessary.

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 owen at delong.com  Fri Feb  5 00:38:03 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Feb 2010 21:38:03 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <9413.1265283016@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
Message-ID: <EFA65331-A5E7-45C4-9FC3-F3EB8CC73B6D@delong.com>


On Feb 4, 2010, at 3:30 AM, Michael Richardson wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
>>>>>> "David" == David Farmer <farmer at umn.edu> writes:
>    David> At the Dearborn meeting I heard a lot of people say that ARIN
>    David> shouldn't dictate routing policy.  I personally would find it
>    David> hard to reconcile that stance with the idea of ARIN assigning
>    David> non-connected /48s from a separate block. At least without an
>    David> RFC defining centrally assignable ULA addressing, then ARIN
>    David> would not be defining it, the IETF would be, ARIN would only
>    David> be implementing something defined by the IETF.
> 
> I don't understand your view here.
> 
> ARIN does define routing policy right now --- if you ask ARIN for
> address space, you get routable address space, and ARIN defines the
> policy by which you can get it.  There is presently only one question I
> can ask, and one set of criteria I can satisfy.  If I satisfy the
> criteria I get one thing: routable address space.
> 
No. If you get space from ARIN now, it is up to the ISPs whether or not
they will accept the route for it or not.  For example, Verizon is currently
rejecting all IPv6 /48 routes.  Whether or not that is a good decision on
their part has nothing to do with ARIN policy.

There is nothing in ARIN policy that guarantees you can  route any
address or prefix issued by ARIN or that any ISP has to agree to route
any address or prefix issued by ARIN. Each ISP can choose to set
whatever routing policy they wish completely independent of ARIN
address registration policy.

ARIN guarantees uniqueness among a cooperating set of registration
services (the RIR system, IANA, and ICANN).

Routing is up to people who actually run routers.

The internet works because a substantial portion of the people who
run routers choose to route prefixes issued by ARIN amongst themselves
and each other. However, nothing other than good will and the desire
for a functioning system prevents any of them from choosing a completely
independent set of registries for a completely separate namespace of
similar-looking IP addresses. Nothing forces any of them to route
any particular prefix issued by ARIN or even any set or subset of
prefixes issued by ARIN.

Owen



From owen at delong.com  Fri Feb  5 00:42:43 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Feb 2010 21:42:43 -0800
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements
In-Reply-To: <4B6AF6CE.7000709@arin.net>
References: <4B6AF6CE.7000709@arin.net>
Message-ID: <3E54F9C2-FD20-43C2-8DEF-9A0FBACCB11B@delong.com>

I'd like to see some wordsmithing to rectify the following:

6.5.5.2
	...registered via SWIP or RWHOIS.


Otherwise, I could get behind this proposal and I think it is a much better
policy than 2010-3.

Owen



From matthew at matthew.at  Fri Feb  5 00:46:36 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 04 Feb 2010 21:46:36 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <EFA65331-A5E7-45C4-9FC3-F3EB8CC73B6D@delong.com>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<EFA65331-A5E7-45C4-9FC3-F3EB8CC73B6D@delong.com>
Message-ID: <4B6BB0BC.1000601@matthew.at>

Owen DeLong wrote:
> The internet works because a substantial portion of the people who
> run routers choose to route prefixes issued by ARIN amongst themselves
> and each other. However, nothing other than good will and the desire
> for a functioning system prevents any of them from choosing a completely
> independent set of registries for a completely separate namespace of
> similar-looking IP addresses. Nothing forces any of them to route
> any particular prefix issued by ARIN or even any set or subset of
> prefixes issued by ARIN.
>
>   
Or to even cooperatively accept that IANA and/or ARIN's database of 
numbers is the one true database...

Matthew Kaufman


From owen at delong.com  Fri Feb  5 00:46:25 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Feb 2010 21:46:25 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3995.1265304209@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>
	<3995.1265304209@marajade.sandelman.ca>
Message-ID: <9B8043FF-EBC9-4BAF-AA06-170F9C9FA361@delong.com>

Well, if you look in Verizon's routing table, you'll find that the following
route is missing from their perspective on the DFZ:


	2620:0:930::/48

There are many others, as well... Roughly 20% of the IPv6 routing table
seen by other providers and their customers.

The point is that ARIN does not dictate routing policy.  Yes, so far, most
ISPs choose to route most or all of what ARIN registers, but, there is nothing
in ARIN policy compelling them to do so and they are free to change that
decision at any time.

Owen

On Feb 4, 2010, at 9:23 AM, Michael Richardson wrote:

> 
> Can you give me an example of a piece of address space (IPv4 or IPv6)
> that ARIN has issued that turned out to not be routable on the DFZ?
> 
> The only example I can see are some of the 69/8 and 70/8 (if I got those
> prefixes right), which many people had bogon filters for, and it took a
> few months for those filters to get completely removed.
> 
> (Please ignore micro-allocations for IXs, which are often intended not
> to be routable, but often turn out to be easily routed)
> 
> I understand covering-your-ass legalize in the document, but really,
> let's be pragmatic here.
> 
> -- 
> ]       He who is tired of Weird Al is tired of life!           |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition. 
> 
> 
> _______________________________________________
> 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  Fri Feb  5 01:02:29 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 4 Feb 2010 23:02:29 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>
References: <4B563F50.1070306@umn.edu>
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>
	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>
	<3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>
Message-ID: <c3227e9e1002042202s4158faakc972ec6fb91fa725@mail.gmail.com>

Bill,

You are ARIN... everyone on this list is ARIN so if you want to see as you
put it

"My point was that I'd really like to see us stop suffering failures of
imagination in the name of careful reason. ARIN has to be the
moderating force on the routing table only because we've failed to
imagine a individually driven process that renders the role
unnecessary."

Then submit policy proposals to help make that happen.  The community makes
the policies so if you want them to be different then submit what you want
and help it gain support.

Thanks
----Cathy

On Thu, Feb 4, 2010 at 10:22 PM, William Herrin <bill at herrin.us> wrote:

> On Thu, Feb 4, 2010 at 11:57 PM, George Bonser <gbonser at seven.com> wrote:
> >> Now, the other tier-1's don't like that one bit. Not one bit at all.
> >> Dude's stealing their bread! So, they start a joint venture to do the
> >> same thing, camp it at the major peering points (like MAE-East) and
> >> refuse to honor the /8 route if its announced from anybody else. Sorry
> >> dude! You want service in the small assignments, you pay the joint
> >> venture too.
> >
> > Or, someone starts accepting the more specific routes without using the
> > tunnels and their customers don't need to pay no steeenking tunnel
> > broker which disrupts the entire scheme, another network does it, too,
> > in order to compete with them and that entire tunnel jv blows up and
> > everyone ends up accepting the more specifics.
>
> Hi George,
>
> Likely couldn't travel that path; each new provider that accepts the
> more specifics into his routing table only increases the percentage
> penetration. Catch ditch the tunnel JV until you have nearly 100%
> penetration and the cost of carrying all the routes in every router
> versus a fraction of just the small routes in each of the JV's routers
> is high enough to cost more than the small users are willing to pay.
>
> You could, however, implement a dynamic tunnel map-encap protocol like
> they've been discussing over in the RRG for the last couple of years
> and let the ASes start to deploy ingress tunnel routers to catch
> otherwise-unrouted packets for the /8 near their source and send them
> encapsulated to their current destinations. Many outcomes are
> possible; I'm not really looking to explore the whole field.
>
> My point was that I'd really like to see us stop suffering failures of
> imagination in the name of careful reason. ARIN has to be the
> moderating force on the routing table only because we've failed to
> imagine a individually driven process that renders the role
> unnecessary.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100204/ae6c87cb/attachment.htm>

From gbonser at seven.com  Fri Feb  5 01:25:03 2010
From: gbonser at seven.com (George Bonser)
Date: Thu, 4 Feb 2010 22:25:03 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>
References: <4B563F50.1070306@umn.edu>
	<c3227e9e1002040805h4935b1d6he77bd44c03274093@mail.gmail.com>
	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>
	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>
	<3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7632@RWC-EX1.corp.seven.com>

> My point was that I'd really like to see us stop suffering failures of
> imagination in the name of careful reason. ARIN has to be the
> moderating force on the routing table only because we've failed to
> imagine a individually driven process that renders the role
> unnecessary.
> 
> Regards,
> Bill Herrin

Hi Bill,

And my point was that the size of the routing table is only an issue
because of hardware vendors lack of resources in their gear.  Having
more resources available eliminates the entire issue.  A disruptive
player in the hardware market that introduces a router that can handle
two or four or eight times the number of concurrent flows and routes as
current gear would moot the point.

We are expending a lot of energy because of router manufacturers
unwillingness (I presume) to increase the amount of resources in the
gear and we are looking for a way to route around that failure, so to
speak.

As soon as someone comes to market with gear that handles it at a
reasonable price, the problem goes away.

Can you think of a barrier to producing hardware with more resources
other than the fact that they misjudged the growth requirements and
don't want to obsolete their existing product until they get some more
cash out of it?  Taking a quick look at the Brocade XMR I see 10 million
BGP routes, 1 million IPv4 routes in hardware (FIB), 240,000 IPv6 routes
in hardware (FIB).  One would think they would these days be able to
quadruple that density on the same real estate these days and the issue
goes away completely. (note, I believe that the v4/v6 routes is
either/or not and).  And for every v6 route in the FIB, I believe it
costs you room for four v4 routes. So with current hardware as v6 grows
and v4 grows on dual stacked gear, either we are going to have to go
through weird contortions to get things to work or the vendors are going
to have to produce more capable kit.  At some point soon price/port/pps
isn't going to be the constraining factor, it is going to be how many
routes it can use.

It isn't primarily a policy issue with the RIRs as it is a marketing
issue with the hardware vendors.  They can make this problem go away and
at some point, someone will.

George


From owen at delong.com  Fri Feb  5 01:29:09 2010
From: owen at delong.com (Owen DeLong)
Date: Thu, 4 Feb 2010 22:29:09 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002041142w232dc952q8173dd1ccfed17db@mail.gmail.com>
References: <4B563F50.1070306@umn.edu>
	<3c3e3fca1002041142w232dc952q8173dd1ccfed17db@mail.gmail.com>
Message-ID: <75F088EF-E8B5-46B5-BF57-209853386DD7@delong.com>

> 
> 
> Assigning /22's adjacent to /16's. ARIN's practice dictates that the
> /16's will be disaggregable by the assignee to /22 for TE purposes as
> well.
> 
An alternative way to view this is that ARIN does not facilitate discriminating
against the /22 holders without also affecting the TE deaggregates
of the larger players.
> 
>> So what is the direction the community wants to go for IPv6 non-connected
>> networks?
> 
> Published unique pool so that ISPs can assure that the non-connected
> networks stay non-connected, even if Jim's Bait and Network Services
> gets bribed to introduce a route.
> 
With all due respect, Bill, that's the direction you would like to go, but,
not necessarily the direction the community wants to go. Much more
input is required before a determination can be made which direction
the community would like to go, in my opinion.

Owen

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

From scottleibrand at gmail.com  Fri Feb  5 02:20:28 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 04 Feb 2010 23:20:28 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <c3227e9e1002042202s4158faakc972ec6fb91fa725@mail.gmail.com>
References: <4B563F50.1070306@umn.edu>	<3c3e3fca1002041243y7d6b2ab8p4923863d41fb7c45@mail.gmail.com>	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>	<3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>
	<c3227e9e1002042202s4158faakc972ec6fb91fa725@mail.gmail.com>
Message-ID: <4B6BC6BC.4060007@gmail.com>

On 2/4/2010 10:02 PM, cja at daydream.com wrote:
> Bill,
>
> You are ARIN... everyone on this list is ARIN so if you want to see as 
> you put it
>
> "My point was that I'd really like to see us stop suffering failures of
> imagination in the name of careful reason. ARIN has to be the
> moderating force on the routing table only because we've failed to
> imagine a individually driven process that renders the role
> unnecessary."
>
> Then submit policy proposals to help make that happen.  The community 
> makes the policies so if you want them to be different then submit 
> what you want and help it gain support.

I think Bill did exactly that with proposal #103.  #106 doesn't move us 
quite as far, but is moving in the same direction, I think.

Once again, thanks, Bill, for being such a valuable contributor to the 
public policy process.

-Scott

>
> Thanks
> ----Cathy
>
> On Thu, Feb 4, 2010 at 10:22 PM, William Herrin <bill at herrin.us 
> <mailto:bill at herrin.us>> wrote:
>
>     On Thu, Feb 4, 2010 at 11:57 PM, George Bonser <gbonser at seven.com
>     <mailto:gbonser at seven.com>> wrote:
>     >> Now, the other tier-1's don't like that one bit. Not one bit at
>     all.
>     >> Dude's stealing their bread! So, they start a joint venture to
>     do the
>     >> same thing, camp it at the major peering points (like MAE-East) and
>     >> refuse to honor the /8 route if its announced from anybody
>     else. Sorry
>     >> dude! You want service in the small assignments, you pay the joint
>     >> venture too.
>     >
>     > Or, someone starts accepting the more specific routes without
>     using the
>     > tunnels and their customers don't need to pay no steeenking tunnel
>     > broker which disrupts the entire scheme, another network does
>     it, too,
>     > in order to compete with them and that entire tunnel jv blows up and
>     > everyone ends up accepting the more specifics.
>
>     Hi George,
>
>     Likely couldn't travel that path; each new provider that accepts the
>     more specifics into his routing table only increases the percentage
>     penetration. Catch ditch the tunnel JV until you have nearly 100%
>     penetration and the cost of carrying all the routes in every router
>     versus a fraction of just the small routes in each of the JV's routers
>     is high enough to cost more than the small users are willing to pay.
>
>     You could, however, implement a dynamic tunnel map-encap protocol like
>     they've been discussing over in the RRG for the last couple of years
>     and let the ASes start to deploy ingress tunnel routers to catch
>     otherwise-unrouted packets for the /8 near their source and send them
>     encapsulated to their current destinations. Many outcomes are
>     possible; I'm not really looking to explore the whole field.
>
>     My point was that I'd really like to see us stop suffering failures of
>     imagination in the name of careful reason. ARIN has to be the
>     moderating force on the routing table only because we've failed to
>     imagine a individually driven process that renders the role
>     unnecessary.
>
>     Regards,
>     Bill Herrin
>
>
>
>     --
>     William D. Herrin ................ herrin at dirtside.com
>     <mailto:herrin at dirtside.com> bill at herrin.us <mailto: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
>     <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100204/baebec9f/attachment.htm>

From michael.dillon at bt.com  Fri Feb  5 08:12:53 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 5 Feb 2010 13:12:53 -0000
Subject: [arin-ppml] Policy Proposal 109: Standardize IP
	ReassignmentRegistration Requirements
In-Reply-To: <4B6AF6CE.7000709@arin.net>
Message-ID: <28E139F46D45AF49A31950F88C4974580513B8BB@E03MVZ2-UKDY.domain1.systemhost.net>


> Policy Proposal 109: Standardize IP Reassignment Registration 
> Requirements

Huh!?

>   - Add:
>   - Rename 4.2.3.7. "Reassignment information" to "Registration"
> 
>   - Rename 4.2.3.7.1. "Customer organization information" to 
> "Reassignment Information" and replace text with:
>   - Replace 4.2.3.7.6. Residential Customer Privacy with:
>   - Strike section 4.2.6. "Cable Address Space Policy"
>   - Replace Section 6.5.5. with:

I'm still not sure what this policy proposal is trying to do
or what is being changed. Clearly, the only way to figure
this out is to compare the existing copious verbiage in the NRPM
with the copious verbiage in this policy and I haven't time
to do this right now.

I am opposed to this proposal on the grounds of its complexity
and the lack of clarity around what, if any, kind of problem
it attempts to solve.

--Michael Dillon


From michael.dillon at bt.com  Fri Feb  5 08:17:01 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 5 Feb 2010 13:17:01 -0000
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F1048526C4DC7@ROCH-EXCH1.corp.pvt>
Message-ID: <28E139F46D45AF49A31950F88C4974580513B8CF@E03MVZ2-UKDY.domain1.systemhost.net>


>  This needs 
> to be debated heavily since its not in the Charter and 

On the contrary, it needs to be dropped or taken elsewhere
since this list is for dicsussing ARIN policies, not 
potential charter changes. Perhaps the members list would
be a better place to discuss changing ARIN's charter.

>it 
> also makes the need for Network Operators to get involved on 
> ppml to discuss the merits or lack thereof. 

They are all members so this underscores that the ARIN members
mailing list is the place for discussing whether or not ARIN
policy should mandate routing practices.

Until that happens, we should drop any such policies or at least
delete any mention of mandating routing practices.

--Michael Dillon


From michael.dillon at bt.com  Fri Feb  5 09:18:06 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 5 Feb 2010 14:18:06 -0000
Subject: [arin-ppml] FW: [sig-policy] prop-083: Alternative criteria for
	subsequentIPv6 allocations
In-Reply-To: <292AF25E62B8894C921B893B53A19D97396AF3312F@BUSINESSEX.business.ad>
Message-ID: <28E139F46D45AF49A31950F88C4974580513B9E2@E03MVZ2-UKDY.domain1.systemhost.net>


> The crux is that even if aggregation of announcements as a 
> policy is dropped, there is no policy that satisfies the need 
> of LIR's to be able to build non-connected IPv6 networks in 
> the APNIC region.
> 
> With some basic justification, an LIR should be able to gain 
> subsequent /32 allocations for the purpose of remaining 'as 
> routable as possible'.

I think you should consider some editing of your policy proposal
because I can't understand it. But, above, you seem to be
suggesting that a network operator who is operating multiple
disconnected IPv6 networks should be able to get multiple discrete
/32 allocations. 

This seems reasonable to me. However before making a final 
determination I would like to see some input from the operators
of large Internet data centres. It seems to me that a data centre
is rather like a multi-tenant building, and since a tenant in 
a multi-tenant building deserves a /48 assignment, it seems
reasonable that a data centre operator should give everyone
a /48. That means if you rent a cage, you get a /48, if you rent
a rack you get a /48, and if you colocate a 1U server with a single
ethernet connection, you get a /48. Let's face it, lots of these
servers will have multiple cores and could be running dozens or
hundreds of virtual machines with a complex internal network created
by softrouters and softswitches. See <http://openvswitch.org/> and
<http://conferences.sigcomm.org/sigcomm/2009/workshops/wren/slides/tripa
thi-crossbow-wren09.pdf>
for examples of the kind of things that people are doing.

Out of that analysis we might learn that a block size less than /32
would be more appropriate for these disconnected data centres.
Perhaps a /36 per centre would work, and they could be allocated 
out of a block designated for /36 blocks.

--Michael Dillon


From farmer at umn.edu  Fri Feb  5 09:55:58 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 05 Feb 2010 08:55:58 -0600
Subject: [arin-ppml] FW: [sig-policy] prop-083: Alternative criteria for
 subsequentIPv6 allocations
In-Reply-To: <292AF25E62B8894C921B893B53A19D97396AF3312F@BUSINESSEX.business.ad>
References: <292AF25E62B8894C921B893B53A19D97396AF3312F@BUSINESSEX.business.ad>
Message-ID: <4B6C317E.60209@umn.edu>

Thanks for the pointer.

But, this sounds more like ARIN 2009-5: IPv6 Multiple Discrete Networks 
to me.

https://www.arin.net/policy/proposals/2009_5.html

This was just implemented into ARIN's NRPM.

https://www.arin.net/policy/nrpm.html#six_11

The intent of my question is how do we want to deal with networks that 
are not connected to the Internet.  In other words, networks that have 
no intention of achieving global reachability but still many need or 
want globally unique addresses.  ARIN specifically addresses a special 
case of what I am asking about in 6.10.2 Micro Allocation for Internal 
Infrastructure.  Also, by the fact that current end-user assignments are 
based on IPv4 Policy, then section 4.3.5. Non-connected Networks allows 
such networks to get an IPv6 assignment.

But, I believe we need to address this issue much more directly and 
cleanly than in current policy.

Skeeve Stevens wrote:
> Hey all,
> 
> Given the current topic of 'IPv6 Non-Connected Networks', I thought that I would let you know of a policy that is presently in discussion on the APNIC lists that I submitted.
> 
> The crux is that even if aggregation of announcements as a policy is dropped, there is no policy that satisfies the need of LIR's to be able to build non-connected IPv6 networks in the APNIC region.
> 
> With some basic justification, an LIR should be able to gain subsequent /32 allocations for the purpose of remaining 'as routable as possible'.
> 
> While APNIC, like other RIR's do not set routing policy, they do heavily influence it.  And while they cannot control the practice of community filtering lists based on their own allocation pools, they should not ignore the situation.
> 
> Given that IPv6 is not a scarce resource and by no means am I suggesting we just burn it for the fun of it, this seems to be a philosophical debate rather than a technical one.  This is due to that even if an LIR could de-aggregate its /32 to say, 8 /35's or 16 36's, these entries in the routing table would have the exact same result as if they had 16 * /32's.
> 
> So due to this, the only restriction here is the pool allocation which the community filter lists are based on - which the RIR's essentially have created and now have the responsibility to consider.
> 
> ...Skeeve
> 
> --
> 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
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
> 
> From: sig-policy-bounces at lists.apnic.net [mailto:sig-policy-bounces at lists.apnic.net] On Behalf Of Terence Zhang YH(CNNIC)
> Sent: Wednesday, 3 February 2010 10:46 PM
> To: sig-policy at apnic.net
> Subject: [sig-policy] prop-083: Alternative criteria for subsequentIPv6 allocations
> 
> Dear SIG members,
> 
> The proposal, 'Alternative criteria for subsequent IPv6 allocations',
> has been sent to the Policy SIG for review. It will be presented at the
> Policy SIG at APNIC 29 in Kuala Lumpur, 1-5 March 2010.
> 
> We invite you to review and comment on the proposal on the mailing list
> before the meeting.
> 
> The comment period on the mailing list before an APNIC meeting is an
> important part of the policy development process. We encourage you to
> express your views on the proposal:
> 
>      - Do you support or oppose this proposal?
>      - Does this proposal solve a problem you are experiencing? If so,
>        tell the community about your situation.
>      - Do you see any disadvantages in this proposal?
>      - Is there anything in the proposal that is not clear?
>      - What changes could be made to this proposal to make it more
>        effective?
> 
> 
> Information about this and other policy proposals is available from:
> 
>        http://www.apnic.net/policy/proposals
> 
> 
> Randy, Ching-Heng, and Terence
> 
> 
> ___________________________________________________________________
> 
> prop-083-v001: Alternative criteria for subsequent IPv6 allocations
> ___________________________________________________________________
> 
> 
> Author:    Skeeve Stevens
>             <skeeve at eintellego.net>
> 
> Version:   1
> 
> Date:      3 February 2010
> 
> 
> 1.  Introduction
> ----------------
> 
> This is a proposal to enable current APNIC account holders with existing
> IPv6 allocations to receive subsequent IPv6 allocations from APNIC for
> use in networks that are not connected to the initial IPv6 allocation.
> 
> 
> 2.  Summary of current problem
> ------------------------------
> 
> An APNIC account holder with an existing /32 IPv6 allocation (or larger)
> is unable to deaggregate that allocation into routes smaller than a /32
> due to the community practice of 'filter blocking' or 'bogon lists'
> associated with RIR blocks which are known to have a minimum allocation
> size of /32 [1].
> 
> An LIR may want to build a network in a separate location and provide
> IPv6 connectivity; however, because the LIR risks routability problems
> if they deaggregate, they cannot use a subset of their initial
> allocation in the new location.
> 
> For example:
> 
>       An ISP has a /32 allocation which they announce via an upstream
>       in New Zealand.  The ISP wants to build a new network in Singapore.
>       The ISP's new network in Singapore is not connected to the existing
>       New Zealand network and the ISP is using a local transit provider
>       to obtain dual stacked connectivity.
> 
>       If the network was using IPv4 addresses, the ISP would usually
>       be able to deaggregate their allocation and announce one part of
>       the deaggregated range to the local transit provider.
> 
>       In IPv6, however, this is not possible due to 'community filtering'
>       on ranges smaller than a /32.
> 
>       Such a filter may look like the following:
> 
>           ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32
> 
>       This above statement in the IPv6 BGP filter recommendations would
>       cause any announcements by an ISP which had an allocation,
>       such as 2400:0000::/32, to announce smaller routes from that block,
>       such as multiple /35s for example, to be filtered.  In a default
>       free situation, connectivity to the ISP would be problematic.
> 
>       Instead, the ISP needs to obtain a new /32 allocation to be able to
>       have IPv6 connectivity in the new location with an independent
>       (from their primary network) transit provider.
> 
> 
> 3.  Situation in other RIRs
> ---------------------------
> 
> AfriNIC, ARIN, LACNIC and RIPE currently have no similar policies or
> proposals. However, ARIN mailing lists are presently discussing this
> situation and there seems to be significant support.
> 
> 
> 4.  Details of the proposal
> ---------------------------
> 
> 4.1 It is proposed that alternative criteria be added to the subsequent
>      IPv6 allocation policy [2] to allow current APNIC account holders
>      with networks in multiple locations but without a connecting
>      infrastructure to obtain IPv6 resources for each location.
> 
> 4.2 To qualify for subsequent IPv6 allocations under the proposed
>      alternative criteria, account holders must:
> 
>       - Be a current APNIC account holder with an existing IPv6
>         allocation
>       - Be announcing its existing IPv6 allocation
>       - Demonstrate that the LIR has additional networks that are not
>         connected to the network announcing its existing IPv6 allocation
> 
> 
> 5.  Advantages and disadvantages of the proposal
> ------------------------------------------------
> 
> 5.1 Advantages
> 
>       - This proposal enables current APNIC account holders to avoid
>         problematic network design issues and policy issues related to
>         deaggregation.
> 
>       - Current APNIC account holders will be able to acquire resources
>         and announce them separately to transit providers in disparate
>         locations.
> 
> 
> 5.2 Disadvantages
> 
>       - This proposal could cause faster consumption of IPv6 address
>         space. However, given the size of the total IPv6 pool, the author
>         of this proposal does not see this as a significant issue.
> 
> 
> 6.  Effect on APNIC members
> ---------------------------
> 
> APNIC members would be able to build networks in separate locations and
> obtain local IPv6 connectivity and announce their own resources.
> 
> 
> 7.  Effect on NIRs
> ------------------
> 
> The proposal allows for NIRs to have the choice as to when to adopt this
> policy for their members.
> 
> 
> 8.   References
> ---------------
> 
> [1] For example, see "IPv6 BGP filter recommendations"
>       http://www.space.net/~gert/RIPE/ipv6-filters.html
> 
> [2] See section 5.2, "Subsequent Allocation Section" in "IPv6 Address
>       Allocation and Assignment Policy"
>       http://www.apnic.net/policy/ipv6-address-policy#5.2
> _______________________________________________
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================


From cgrundemann at gmail.com  Fri Feb  5 09:55:19 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 5 Feb 2010 07:55:19 -0700
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements
In-Reply-To: <3E54F9C2-FD20-43C2-8DEF-9A0FBACCB11B@delong.com>
References: <4B6AF6CE.7000709@arin.net>
	<3E54F9C2-FD20-43C2-8DEF-9A0FBACCB11B@delong.com>
Message-ID: <443de7ad1002050655t50ccb685md519c2f7a6572dd0@mail.gmail.com>

On Thu, Feb 4, 2010 at 22:42, Owen DeLong <owen at delong.com> wrote:
> I'd like to see some wordsmithing to rectify the following:
>
> 6.5.5.2
> ? ? ? ?...registered via SWIP or RWHOIS.

Section 6.5.5.2 ends with "...is registered in an RIR database." Are
you saying that the text _should_ specify SWIP / RWHOIS?
~Chris

>
>
> Otherwise, I could get behind this proposal and I think it is a much better
> policy than 2010-3.
>
> Owen
>
> _______________________________________________
> 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From farmer at umn.edu  Fri Feb  5 10:27:54 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 05 Feb 2010 09:27:54 -0600
Subject: [arin-ppml] IPv6 Non-connected networks
Message-ID: <4B6C38FA.6060502@umn.edu>

This thread has mostly wondered off of my original question, but it 
still has been an interesting discussion, none the less.

The intent of my question is how do we want to deal with networks that 
are not connected to the Internet.  In other words networks that have no 
intention of achieving global reachability but still many need or want 
globally unique addresses.  ARIN Policy specifically addresses a special 
case of what I am asking about for IPv6 in 6.10.2 Micro Allocation for 
Internal Infrastructure, and it creates a special pool for this use. 
Also, by the fact that current end-user assignments are based on IPv4 
Policy, then section 4.3.5. Non-connected Networks allows such networks 
to get an IPv6 assignment, currently out of a common pool for end-user 
assignments.

Since I've been working on rewriting ARIN's IPv6 policy I want to know 
how the community want this to actually work, my goal is a more direct 
and clear path for these network to get addresses.  However, I see a 
faction of the ARIN community that want these assignments made from a 
filterable block.  Then, there is another faction that says, wait a 
minute, that means ARIN is defining Routing Policy.

I believe that these network have a right to globally unique IPv6 
addressing just as much as anyone else.  But, personally I'm mostly 
agnostic to the question if the these assignments should be made from a 
block designated for non-connected networks or just assigned from a 
common pool with all other assignments.  I can see valid arguments on 
both sides.

Basically it boils down to, if we assign from a common pool then there 
is no distinction and you can only have the address space you can 
justify connected or non-connected.  If we make a distinction then, 
anyone must to be able to get such a non-connected assignment without 
regard to if they have an assignment intended intended for global 
connectivity.

The current text I have in PP#107 calls for a common pool because that 
seemed most consistent with the current policies as I understand them. 
  But as I said, I'm mostly agnostic on this issue.  So I started this 
thread to try develop a consensus one way or the other.  Because, we 
can't do both at the same time.

So I would like to see continued discussion on the specific issue of a 
common pool for all assignments VS. a specific pool for non-connected 
networks.  Additionally, I intend to raise this issue on the floor in 
Toronto.

Thanks

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


From cgrundemann at gmail.com  Fri Feb  5 10:28:22 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 5 Feb 2010 08:28:22 -0700
Subject: [arin-ppml] Policy Proposal 109: Standardize IP
	ReassignmentRegistration Requirements
In-Reply-To: <28E139F46D45AF49A31950F88C4974580513B8BB@E03MVZ2-UKDY.domain1.systemhost.net>
References: <4B6AF6CE.7000709@arin.net>
	<28E139F46D45AF49A31950F88C4974580513B8BB@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <443de7ad1002050728o39803f20l5cadd1b8d2ef6915@mail.gmail.com>

On Fri, Feb 5, 2010 at 06:12,  <michael.dillon at bt.com> wrote:
>
>> Policy Proposal 109: Standardize IP Reassignment Registration
>> Requirements
>
> Huh!?
>
>> ? - Add:
>> ? - Rename 4.2.3.7. "Reassignment information" to "Registration"
>>
>> ? - Rename 4.2.3.7.1. "Customer organization information" to
>> "Reassignment Information" and replace text with:
>> ? - Replace 4.2.3.7.6. Residential Customer Privacy with:
>> ? - Strike section 4.2.6. "Cable Address Space Policy"
>> ? - Replace Section 6.5.5. with:
>
> I'm still not sure what this policy proposal is trying to do
> or what is being changed. Clearly, the only way to figure
> this out is to compare the existing copious verbiage in the NRPM
> with the copious verbiage in this policy and I haven't time
> to do this right now.

Yes, reading the NRPM may be a prerequisite to understanding proposed
changes to it.

> I am opposed to this proposal on the grounds of its complexity
> and the lack of clarity around what, if any, kind of problem
> it attempts to solve.

I will expound a bit on the rational for clarification:

1) This policy restructures the reassignment and registration sections
of the IPv4 and IPv6 policies.
	a) The IPv4 section is renamed "registration."
	b) The first section of the IPv4 policy is rewritten for clarity.
	c) The IPv6 policy is totally rewritten in a format that matches the
IPv4 policy.
* These structural changes are meant to make it easier to compare the
two sections. I believe that having the IPv6 and IPv4 policies written
in completely different formats and structures (as they are in many
cases now) confuses the issues and makes it very hard to understand
what is different and what is the same across the two sections.
Bringing them into a similar format should help ease the migration to
IPv6 as folks can quickly and easily understand the differences and
the similarities.

2) This policy adds a definition of "organizational information" which
is used in the existing policy but not currently defined anywhere in
the NRPM.
	a) The definition states that specific addresses are not required for
client organizations but asks that they be included when possible.
	b) The definition states that a POC is required but can be designated
by the client organization - it spells out that the client org can
choose to use their upstream as a POC.
	c) The definition requires that the POC have a valid email address
but only suggests that it include a phone number.
* This definition is meant to address the customer confidentiality
concerns that have been brought up recently (by specifically removing
the requirement to publish client addresses and telephone numbers),
with the smallest negative impact to whois usefulness (retains a valid
POC w/ email contact).

3) This policy takes the privileges granted specifically to IPv4 cable
operators in section 4.2.6. "Cable Address Space Policy" and grants
them to all ISPs who serve residential areas.
	a) It allows all ISPs with residential coverage to
register/swip/rwhois an entire market area.
	b) It retains the existing residential customer privacy policy for
all customers with larger IP blocks.
* This change removes the need for any ISP to enter residential
customers into whois at all.

4) In the text that Scott pointed out (and that will be added), this
policy will also extend the >50% utilization rate currently granted
only to IPv4 cable operators to all ISPs with a residential footprint.
* This change will make it easier for ISPs serving residential areas
to get the addresses they need - this is key for FTTH operators as
well as fixed-wireless and other residential ISPs.

Cheers,
~Chris

>
> --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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From packetgrrl at gmail.com  Fri Feb  5 12:28:45 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Fri, 5 Feb 2010 10:28:45 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B6C38FA.6060502@umn.edu>
References: <4B6C38FA.6060502@umn.edu>
Message-ID: <c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>

I think a common pool is a good idea. It allows these non-connected
networks to connect if their needs change and keeps them from having
to get another allocation/assingment if they do choose to connect at a
later date.

I do see the desire to perhaps filter the non-connected networks and
that having them out of a dedicated block facilitates that purpose but
long-term when we are in an exhaustion phase again that address space
would be stranded and although globally unique perhaps highly
filtered.  You could argue that we have SO much IPv6 that we're never
going to run out but I don't buy that argument.

As does David.. I would love to hear what other folks think about this.
----Cathy

Sent from my iPhone

On Feb 5, 2010, at 8:27 AM, David Farmer <farmer at umn.edu> wrote:

> This thread has mostly wondered off of my original question, but it
> still has been an interesting discussion, none the less.
>
> The intent of my question is how do we want to deal with networks
> that are not connected to the Internet.  In other words networks
> that have no intention of achieving global reachability but still
> many need or want globally unique addresses.  ARIN Policy
> specifically addresses a special case of what I am asking about for
> IPv6 in 6.10.2 Micro Allocation for Internal Infrastructure, and it
> creates a special pool for this use. Also, by the fact that current
> end-user assignments are based on IPv4 Policy, then section 4.3.5.
> Non-connected Networks allows such networks to get an IPv6
> assignment, currently out of a common pool for end-user assignments.
>
> Since I've been working on rewriting ARIN's IPv6 policy I want to
> know how the community want this to actually work, my goal is a more
> direct and clear path for these network to get addresses.  However,
> I see a faction of the ARIN community that want these assignments
> made from a filterable block.  Then, there is another faction that
> says, wait a minute, that means ARIN is defining Routing Policy.
>
> I believe that these network have a right to globally unique IPv6
> addressing just as much as anyone else.  But, personally I'm mostly
> agnostic to the question if the these assignments should be made
> from a block designated for non-connected networks or just assigned
> from a common pool with all other assignments.  I can see valid
> arguments on both sides.
>
> Basically it boils down to, if we assign from a common pool then
> there is no distinction and you can only have the address space you
> can justify connected or non-connected.  If we make a distinction
> then, anyone must to be able to get such a non-connected assignment
> without regard to if they have an assignment intended intended for
> global connectivity.
>
> The current text I have in PP#107 calls for a common pool because
> that seemed most consistent with the current policies as I
> understand them.  But as I said, I'm mostly agnostic on this issue.
> So I started this thread to try develop a consensus one way or the
> other.  Because, we can't do both at the same time.
>
> So I would like to see continued discussion on the specific issue of
> a common pool for all assignments VS. a specific pool for non-
> connected networks.  Additionally, I intend to raise this issue on
> the floor in Toronto.
>
> Thanks
>
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> 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  Fri Feb  5 12:46:44 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Fri, 5 Feb 2010 10:46:44 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <10468.1265391143@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>
	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>
	<3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>
	<c3227e9e1002042202s4158faakc972ec6fb91fa725@mail.gmail.com>
	<10468.1265391143@marajade.sandelman.ca>
Message-ID: <c3227e9e1002050946i6c2094b9he7748a11ccc2187a@mail.gmail.com>

I got this note from Michael and I wanted to clarify my statements.  I was
just trying to comment on the "ARIN should be doing this or that"
statements.  ARIN doesn't decide the policy so they do what the community
tells them to via the policy process.  If folks don't like what ARIN is
doing then there is a process to make things change.  This includes policy
proposal submissions as well as the petition process.  I am sorry if I
wasn't clear.

On with the discussion of a separate pool or a combined pool for
non-connected networks per David's summary email.

Thanks!
----Cathy

On Fri, Feb 5, 2010 at 10:32 AM, Michael Richardson <mcr at sandelman.ca>wrote:

>
> >>>>> "packetgrrl" == packetgrrl  <cja at daydream.com> writes:
>     packetgrrl> Then submit policy proposals to help make that happen.
>    packetgrrl> The community makes the policies so if you want them to
>    packetgrrl> be different then submit what you want and help it gain
>    packetgrrl> support.
>
> That was policy 103, which the AC declined to put on the agenda, but
> enouraged further discussion, which we are having.
>
> --
> ]       He who is tired of Weird Al is tired of life!           |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>                       then sign the petition.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100205/29fd4275/attachment.htm>

From bill at herrin.us  Fri Feb  5 13:38:20 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Feb 2010 13:38:20 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7632@RWC-EX1.corp.seven.com>
References: <4B563F50.1070306@umn.edu>
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org> 
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com> 
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com> 
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com> 
	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com> 
	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com> 
	<3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com> 
	<5A6D953473350C4B9995546AFE9939EE081F7632@RWC-EX1.corp.seven.com>
Message-ID: <3c3e3fca1002051038p50a77436u7e8db46c2dfd1e85@mail.gmail.com>

On Fri, Feb 5, 2010 at 1:25 AM, George Bonser <gbonser at seven.com> wrote:
>> My point was that I'd really like to see us stop suffering failures of
>> imagination in the name of careful reason. ARIN has to be the
>> moderating force on the routing table only because we've failed to
>> imagine a individually driven process that renders the role
>> unnecessary.
>
> And my point was that the size of the routing table is only an issue
> because of hardware vendors lack of resources in their gear. ?Having
> more resources available eliminates the entire issue.

Well sure. But are you familiar with how the hardware works in the
high-end routers? The stuff is seriously expensive to build,
especially in the relatively low quantities that populate the core of
the DFZ.


> A disruptive
> player in the hardware market that introduces a router that can handle
> two or four or eight times the number of concurrent flows and routes as
> current gear would moot the point.

The current kit deals with packets rather than flows. Flows was
investigated thoroughly and looks very much like a blind alley. It has
some useful niches but the failure modes are catastrophic.

Granted someone could stumble on a brilliant insight tomorrow,
especially if under pressure to innovate,. But understand that you're
talking about a scientific advance, not a technological advance.
Technology can be predictably built from the existing science at
demand. Scientific advances are unpredictable; they happen almost at
random. If you're a betting man, don't bet on the timely discovery of
science that doesn't yet exist and right now the science of routing is
Tries or TCAMs.

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 mcr at sandelman.ca  Fri Feb  5 13:11:09 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Fri, 05 Feb 2010 13:11:09 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <EFA65331-A5E7-45C4-9FC3-F3EB8CC73B6D@delong.com> 
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<EFA65331-A5E7-45C4-9FC3-F3EB8CC73B6D@delong.com> 
Message-ID: <16548.1265393469@marajade.sandelman.ca>

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


>>>>> "Owen" == Owen DeLong <owen at delong.com> writes:
    David> At the Dearborn meeting I heard a lot of people say that ARIN
    David> shouldn't dictate routing policy.  I personally would find it
    David> hard to reconcile that stance with the idea of ARIN assigning
    David> non-connected /48s from a separate block. At least without an
    David> RFC defining centrally assignable ULA addressing, then ARIN
    David> would not be defining it, the IETF would be, ARIN would only
    David> be implementing something defined by the IETF.

    >> I don't understand your view here.
    >> 
    >> ARIN does define routing policy right now --- if you ask ARIN for
    >> address space, you get routable address space, and ARIN defines
    >> the policy by which you can get it.  There is presently only one
    >> question I can ask, and one set of criteria I can satisfy.  If I
    >> satisfy the criteria I get one thing: routable address space.

    Owen> No. If you get space from ARIN now, it is up to the ISPs
    Owen> whether or not they will accept the route for it or not.  For
    Owen> example, Verizon is currently rejecting all IPv6 /48 routes.
    Owen> Whether or not that is a good decision on their part has
    Owen> nothing to do with ARIN policy.

Remember that thread is about non-connected networks.


1) I said that I would like address space that is non-connected

2) I wanted it marked as such

3) people said that this would never work because people would persuade
   ISPs to route it anyway, and this is bad, because it means that
   people would try to get non-connected address space as a loop around
   ARIN "policy"

4) I then said, but you see, the allocation policy is being used as a 
   proxy for limiting who can routed!

5) then I was re-assured that ARIN allocations are not guaranteed to
   be routeable, so I shouldn't confuse the two.

6) then you say that it's really up to the ISPs to decide, and isn't
   it terrible that some ISP has some policy not route some set of
   address space, even through ARIN has given it out.


Remember: I'm arguing that should be very liberal with small (/48+ ) 
          allocations, charging a very nominal book-keeping fee, and do
          non-connected allocations out of a pool that can be clearly
          identified as such, so that ISPs can clearly make up the
          policy they want.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS2xfO4CLcPvd0N1lAQLQcgf/Su5SOK/pSmFIOJ0SzqsR1+5lKGUHARpD
yklEuEzrciybfWR7RUO6eZqBCwzh+XozbnA4RYTurwWfYQ9PIWFxZz4moS0YKYnm
0GCsATr7+xyfnDixpjx2ylrgdIa0MJsl2A5/JyHmiJuDuAe2XXd1ekGbPPOY79Se
6JSIuz3wQxeH1Nt3u+nEAhlIZSzMPcB+wVyDtL7qZqVWdvlhn2Jiv30xuO1VxiN2
3EGLI+oe469GLpMbPI3Kg4rrdgAP+irgpNQo+8df9iwFjGfGWX1CQLEW9iijmm8v
JDFk+/D0i4K3GMnMOFnnTqBYobn4WI5+4WrtD18v5RVgaO6hegctmA==
=Q6PN
-----END PGP SIGNATURE-----


From gbonser at seven.com  Fri Feb  5 13:55:28 2010
From: gbonser at seven.com (George Bonser)
Date: Fri, 5 Feb 2010 10:55:28 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002051038p50a77436u7e8db46c2dfd1e85@mail.gmail.com>
References: <4B563F50.1070306@umn.edu>
	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>
	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>
	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>
	<3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F7632@RWC-EX1.corp.seven.com>
	<3c3e3fca1002051038p50a77436u7e8db46c2dfd1e85@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7645@RWC-EX1.corp.seven.com>

> The current kit deals with packets rather than flows. Flows was
> investigated thoroughly and looks very much like a blind alley. It has
> some useful niches but the failure modes are catastrophic.

Yeah, I know that, but they tend to cache information regarding a flow.
The cache isn't big enough is the problem I am worried about.  Some gear
likes to populate the routes (FIB) in hardware and if you don't have
enough space, they don't all get in there. Chip density being what it
is, I would think that more storage is available in the same form factor
today than was available when the module was initially designed.  It
isn't so much a performance issue with a large table these days because
that is switched in hardware, not by the CPU.  The problem is a lack of
space to hold all the routes in the hardware.

When you are talking about the ability to hold 250K routes of IPv6 or
1,000K routes of v4, the problem gets bad when multihomed v4 nets become
multihomed v4 AND v6 nets and have a route to their net in both
protocols because they are running both.  If you want to have space for
500K v4 routes in FIB that leaves you with only enough room for 125K v6
routes and while that is ok now, will that still be OK when A: more
networks begin to appear in both spaces and B: smaller v4 allocations
are made?  That is the concern I had.

I see the pushback against routing table growth as more of a hardware
limitation than anything else (problems with instability in a network
with more routes to announce/withdraw notwithstanding).

"dual stacking" might only work for some period of time before both
protocols combined outgrow the capability of the hardware and people
need to split the infrastructure from dual-stacked to dedicated stacks.

But this is more of an operational issue than an ARIN policy issue, the
point being that operational issues and RIR policy issues are tightly
coupled.

George



From matthew at matthew.at  Fri Feb  5 14:08:09 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 05 Feb 2010 11:08:09 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7645@RWC-EX1.corp.seven.com>
References: <4B563F50.1070306@umn.edu>	<08528F8D-8E5A-497F-85E3-8B3317F6ABB4@icann.org>	<3c3e3fca1002041437ja51ee80i9e3c5afa0d13fff7@mail.gmail.com>	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>	<3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>	<5A6D953473350C4B9995546AFE9939EE081F7632@RWC-EX1.corp.seven.com>	<3c3e3fca1002051038p50a77436u7e8db46c2dfd1e85@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F7645@RWC-EX1.corp.seven.com>
Message-ID: <4B6C6C99.20900@matthew.at>

George Bonser wrote:
> But this is more of an operational issue than an ARIN policy issue, the
> point being that operational issues and RIR policy issues are tightly
> coupled.
>
>   
For some people, yes. For others, no.

It is fairly easy to show that RIR policy around allocation of addresses 
people expect to be routed is coupled in the RIR->Operator direction.

If is less easy to show why, exactly, operator policy around routing 
must necessarily dictate RIR policy.

It is especially difficult to show why, exactly, operator policy around 
routing should dictate RIR policy around allocation of objects that are 
not expected to be routed by operators.

Matthew Kaufman


From bill at herrin.us  Fri Feb  5 14:15:21 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Feb 2010 14:15:21 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B6C6C99.20900@matthew.at>
References: <4B563F50.1070306@umn.edu>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com> 
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com> 
	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com> 
	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com> 
	<3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com> 
	<5A6D953473350C4B9995546AFE9939EE081F7632@RWC-EX1.corp.seven.com> 
	<3c3e3fca1002051038p50a77436u7e8db46c2dfd1e85@mail.gmail.com> 
	<5A6D953473350C4B9995546AFE9939EE081F7645@RWC-EX1.corp.seven.com> 
	<4B6C6C99.20900@matthew.at>
Message-ID: <3c3e3fca1002051115p71e04e10w4f373a6989b3fb86@mail.gmail.com>

On Fri, Feb 5, 2010 at 2:08 PM, Matthew Kaufman <matthew at matthew.at> wrote:
> It is especially difficult to show why, exactly, operator policy around
> routing should dictate RIR policy around allocation of objects that are not
> expected to be routed by operators.

Matthew,

Failure modes. If the objects are not expected to be routed by
operators then correction should be actionable when they show up
anyway.

Beyond the consideration of failure modes, you're basically right:
operator routing policy should not inform RIR policy for non-routed
objects.

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 mcr at sandelman.ca  Fri Feb  5 14:17:40 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Fri, 05 Feb 2010 14:17:40 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B6C38FA.6060502@umn.edu> 
References: <4B6C38FA.6060502@umn.edu> 
Message-ID: <22925.1265397460@marajade.sandelman.ca>


>>>>> "David" == David Farmer <farmer at umn.edu> writes:
    David> Since I've been working on rewriting ARIN's IPv6 policy I
    David> want to know how the community want this to actually work, my
    David> goal is a more direct and clear path for these network to get
    David> addresses.  However, I see a faction of the ARIN community
    David> that want these assignments made from a filterable block.
    David> Then, there is another faction that says, wait a minute, that
    David> means ARIN is defining Routing Policy.

If the assignments are not made from a trivially filterable block, then
the assignments are not special in any way, and if you can convince an
ISP to carry them, they are exactly the same as connected blocks, and so
should be charged in the same way.

The argument against giving out IPv6 /32s to any and all (regardless of
need) is, I think, that it causes DFZ router table explosion.

(Remember, there are enough /40s to give every man, woman and child one,
but I see no reason why any individual human needs more than a /60...)

We are told that ARIN doesn't do routing policy, yet it seems to me that
a large amount of ARINs reluctance to make IPv6 addressing available is
the result of a concern about DFZ router size.

If we had a way to assign a routing table congestion cost to
assignments then maybe it would be okay.
Maybe SIDR will provide a mechanism to do that, since the "routability"
of a block could expressed in the authorization certificate binding it
to an ASN.  

Until such time, ISPs are guardians of a scarce public (distributed)
resource known as the DFZ.  It's a tragedy of the commons, and a
fax-effect (at the same time),  were once one ISP starts to pollute the
table, other ISPs are encouraged by peer pressure to do the same thing.

    David> Basically it boils down to, if we assign from a common pool
    David> then there is no distinction and you can only have the
    David> address space you can justify connected or non-connected.  If
    David> we make a distinction then, anyone must to be able to get
    David> such a non-connected assignment without regard to if they
    David> have an assignment intended intended for global connectivity.

I can't parse the second sentence, but I think I know what you mean.
Can you rewrite it for me?

    David> So I would like to see continued discussion on the specific
    David> issue of a common pool for all assignments VS. a specific
    David> pool for non-connected networks.  Additionally, I intend to
    David> raise this issue on the floor in Toronto.

Thanks for bring us back to the topic.

(It seems amazing that ARIN has only ever once provided aN IPv4 prefix
that wasn't routable, which is the 24.y/11... )

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 


From gbonser at seven.com  Fri Feb  5 14:27:07 2010
From: gbonser at seven.com (George Bonser)
Date: Fri, 5 Feb 2010 11:27:07 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>
References: <4B6C38FA.6060502@umn.edu>
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F764B@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of cja
> Sent: Friday, February 05, 2010 9:29 AM
> Subject: Re: [arin-ppml] IPv6 Non-connected networks
> 
> I think a common pool is a good idea. It allows these non-connected
> networks to connect if their needs change and keeps them from having
> to get another allocation/assingment if they do choose to connect at a
> later date.

I also believe having non-connected networks out of a common pool is a
good idea.  For one thing, it allows two networks that are not connected
to the global Internet to interconnect without worrying about address
space collisions provided both networks got their addresses from the
same issuer.   I am thinking of it as a "regionally unique" address
space.

But if they were to retain those net blocks if they do become connected,
would that present some problems as holes would then have to be punched
in the "not connected to the Internet" block filters?

George







From bill at herrin.us  Fri Feb  5 14:39:15 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Feb 2010 14:39:15 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>
References: <4B6C38FA.6060502@umn.edu>
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>
Message-ID: <3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com>

On Fri, Feb 5, 2010 at 12:28 PM, cja at daydream.com <packetgrrl at gmail.com> wrote:
> I think a common pool is a good idea. It allows these non-connected
> networks to connect if their needs change and keeps them from having
> to get another allocation/assingment if they do choose to connect at a
> later date.

And if that later date is the one following the assignment, so much the better.

> I do see the desire to perhaps filter the non-connected networks and
> that having them out of a dedicated block facilitates that purpose but
> long-term when we are in an exhaustion phase again that address space
> would be stranded and although globally unique perhaps highly
> filtered. ?You could argue that we have SO much IPv6 that we're never
> going to run out but I don't buy that argument.

Yeah, but the IETF set aside fc00::/7 for that purpose already and
only fd00::/8 is used for the so-called statistically unique
assignments. So we don't actually *have* to waste any new space to
make non-connected assignments from a distinct pool. At worst we'd
need a global policy to open fc00::/8 for assignment to the RIRs.

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  Fri Feb  5 14:41:35 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 5 Feb 2010 14:41:35 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com>
References: <4B6C38FA.6060502@umn.edu>
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com> 
	<3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com>
Message-ID: <3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>

On Fri, Feb 5, 2010 at 2:39 PM, William Herrin <bill at herrin.us> wrote:
> Yeah, but the IETF set aside fc00::/7 for that purpose already and
> only fd00::/8 is used for the so-called statistically unique
> assignments. So we don't actually *have* to waste any new space to
> make non-connected assignments from a distinct pool. At worst we'd
> need a global policy to open fc00::/8 for assignment to the RIRs.

Excuse me, the IANA at the request of the IETF set aside fc00::/7 for
the purpose of addressing non-connected networks.

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 packetgrrl at gmail.com  Fri Feb  5 15:11:39 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Fri, 5 Feb 2010 13:11:39 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F764B@RWC-EX1.corp.seven.com>
References: <4B6C38FA.6060502@umn.edu>
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F764B@RWC-EX1.corp.seven.com>
Message-ID: <c3227e9e1002051211q7d426e77p67013fec03fa0c12@mail.gmail.com>

I believe David's definition of a common pool were that they were out of a
block with other similar but "connected to the Internet" blocks not that
they were out of one unique block just for non-connected sites.

---Cathy

On Fri, Feb 5, 2010 at 12:27 PM, George Bonser <gbonser at seven.com> wrote:

>
>
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> On
> > Behalf Of cja
> > Sent: Friday, February 05, 2010 9:29 AM
> > Subject: Re: [arin-ppml] IPv6 Non-connected networks
> >
> > I think a common pool is a good idea. It allows these non-connected
> > networks to connect if their needs change and keeps them from having
> > to get another allocation/assingment if they do choose to connect at a
> > later date.
>
> I also believe having non-connected networks out of a common pool is a
> good idea.  For one thing, it allows two networks that are not connected
> to the global Internet to interconnect without worrying about address
> space collisions provided both networks got their addresses from the
> same issuer.   I am thinking of it as a "regionally unique" address
> space.
>
> But if they were to retain those net blocks if they do become connected,
> would that present some problems as holes would then have to be punched
> in the "not connected to the Internet" block filters?
>
> George
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100205/479e0445/attachment.htm>

From matthew at matthew.at  Fri Feb  5 15:47:20 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 05 Feb 2010 12:47:20 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>
References: <4B6C38FA.6060502@umn.edu>	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>
	<3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com>
	<3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>
Message-ID: <4B6C83D8.7020109@matthew.at>

William Herrin wrote:
> On Fri, Feb 5, 2010 at 2:39 PM, William Herrin <bill at herrin.us> wrote:
>   
>> Yeah, but the IETF set aside fc00::/7 for that purpose already and
>> only fd00::/8 is used for the so-called statistically unique
>> assignments. So we don't actually *have* to waste any new space to
>> make non-connected assignments from a distinct pool. At worst we'd
>> need a global policy to open fc00::/8 for assignment to the RIRs.
>>     
>
> Excuse me, the IANA at the request of the IETF set aside fc00::/7 for
> the purpose of addressing non-connected networks.
>
>   
Perhaps one or more Regional Not-The-Internet Registries should apply to 
IANA to administer assignments within that space.

Matthew Kaufman


From farmer at umn.edu  Fri Feb  5 15:48:30 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 05 Feb 2010 14:48:30 -0600
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <c3227e9e1002051211q7d426e77p67013fec03fa0c12@mail.gmail.com>
References: <4B6C38FA.6060502@umn.edu>	
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>	
	<5A6D953473350C4B9995546AFE9939EE081F764B@RWC-EX1.corp.seven.com>
	<c3227e9e1002051211q7d426e77p67013fec03fa0c12@mail.gmail.com>
Message-ID: <4B6C841E.6000405@umn.edu>

Yes,

When I said common pool I was referring to a common block of address 
that both Internet connected and non-connected assignments would be 
made.  Such that it would not be possible to filter the non-connected 
assignments.

Or the other option is to have a block dedicated to non-connected 
assignments that could be filtered.

cja at daydream.com wrote:
> I believe David's definition of a common pool were that they were out of a
> block with other similar but "connected to the Internet" blocks not that
> they were out of one unique block just for non-connected sites.
> 
> ---Cathy
> 
> On Fri, Feb 5, 2010 at 12:27 PM, George Bonser <gbonser at seven.com> wrote:
> 
>>
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>> On
>>> Behalf Of cja
>>> Sent: Friday, February 05, 2010 9:29 AM
>>> Subject: Re: [arin-ppml] IPv6 Non-connected networks
>>>
>>> I think a common pool is a good idea. It allows these non-connected
>>> networks to connect if their needs change and keeps them from having
>>> to get another allocation/assingment if they do choose to connect at a
>>> later date.
>> I also believe having non-connected networks out of a common pool is a
>> good idea.  For one thing, it allows two networks that are not connected
>> to the global Internet to interconnect without worrying about address
>> space collisions provided both networks got their addresses from the
>> same issuer.   I am thinking of it as a "regionally unique" address
>> space.

There is nothing regional about it, they would be globally unique.


>> But if they were to retain those net blocks if they do become connected,
>> would that present some problems as holes would then have to be punched
>> in the "not connected to the Internet" block filters?
>>
>> George

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


From gbonser at seven.com  Fri Feb  5 16:10:12 2010
From: gbonser at seven.com (George Bonser)
Date: Fri, 5 Feb 2010 13:10:12 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B6C83D8.7020109@matthew.at>
References: <4B6C38FA.6060502@umn.edu>	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com><3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com><3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>
	<4B6C83D8.7020109@matthew.at>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>



> >
> > Excuse me, the IANA at the request of the IETF set aside fc00::/7
for
> > the purpose of addressing non-connected networks.
> >
> >

So what is really being looked at, then, is a registry for fc00::/7
space with the L bit set to 0, or in other words, defining the L bit per
section 3.2 of RFC4193 as "assigned by RIR or whomever" with chunks of
fd00::/8 being doled out by the various RIRs (or whomever) for networks
in their area.

> Perhaps one or more Regional Not-The-Internet Registries should apply
> to
> IANA to administer assignments within that space.

Would seem to me like a better idea than using globally unique space for
unconnected networks. It would require renumbering if you went
connected, though.  So does it boil down to wanting space that is not
connected so your unconnected address space nets doesn't count against
density requirements for connected space but allows you to connect it
without renumbering later?  And if so, how do you know when someone has
converted their "unconnected" net to "connected" by announcing the route
and that space should now count against requirements to justify space?

What is to prevent someone from requesting space for "unconnected"
networks in addition to "connected" for a total of more space than they
would otherwise be able to justify and then announcing the unconnected
space a week later?

I think "unconnected space" space should be just that and not
"temporarily unconnected space for right now".  But having pieces of it
doled out from a central authority would make it easier for two networks
that are not connected to the global internet to interconnect without
address space collision.





From farmer at umn.edu  Fri Feb  5 16:16:42 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 05 Feb 2010 15:16:42 -0600
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <22925.1265397460@marajade.sandelman.ca>
References: <4B6C38FA.6060502@umn.edu> <22925.1265397460@marajade.sandelman.ca>
Message-ID: <4B6C8ABA.4000101@umn.edu>

Michael Richardson wrote:
>>>>>> "David" == David Farmer <farmer at umn.edu> writes:
>     David> Since I've been working on rewriting ARIN's IPv6 policy I
>     David> want to know how the community want this to actually work, my
>     David> goal is a more direct and clear path for these network to get
>     David> addresses.  However, I see a faction of the ARIN community
>     David> that want these assignments made from a filterable block.
>     David> Then, there is another faction that says, wait a minute, that
>     David> means ARIN is defining Routing Policy.
> 
> If the assignments are not made from a trivially filterable block, then
> the assignments are not special in any way, and if you can convince an
> ISP to carry them, they are exactly the same as connected blocks, and so
> should be charged in the same way.

I believe the cost is not part of the policy.

> The argument against giving out IPv6 /32s to any and all (regardless of
> need) is, I think, that it causes DFZ router table explosion.
> 
> (Remember, there are enough /40s to give every man, woman and child one,
> but I see no reason why any individual human needs more than a /60...)
> 
> We are told that ARIN doesn't do routing policy, yet it seems to me that
> a large amount of ARINs reluctance to make IPv6 addressing available is
> the result of a concern about DFZ router size.
> 
> If we had a way to assign a routing table congestion cost to
> assignments then maybe it would be okay.
> Maybe SIDR will provide a mechanism to do that, since the "routability"
> of a block could expressed in the authorization certificate binding it
> to an ASN.  
> 
> Until such time, ISPs are guardians of a scarce public (distributed)
> resource known as the DFZ.  It's a tragedy of the commons, and a
> fax-effect (at the same time),  were once one ISP starts to pollute the
> table, other ISPs are encouraged by peer pressure to do the same thing.
> 
>     David> Basically it boils down to, if we assign from a common pool
>     David> then there is no distinction and you can only have the
>     David> address space you can justify connected or non-connected.  If
>     David> we make a distinction then, anyone must to be able to get
>     David> such a non-connected assignment without regard to if they
>     David> have an assignment intended intended for global connectivity.
> 
> I can't parse the second sentence, but I think I know what you mean.
> Can you rewrite it for me?

Sorry I wasn't clear, how about these;

- If we make a distinction between Internet connected and non-connected, 
them having an assignment from one or the other can't affect your 
ability to get the other type of space.

- If I have an Internet connected assignment, that should not disqualify 
me from getting a non-connected assignment and visa-versa.

- If I meet the requirements for both, I should be able to get both. I 
would still have to properly meet the requirements independently for 
each assignment, but I should be able to get both.

>     David> So I would like to see continued discussion on the specific
>     David> issue of a common pool for all assignments VS. a specific
>     David> pool for non-connected networks.  Additionally, I intend to
>     David> raise this issue on the floor in Toronto.
> 
> Thanks for bring us back to the topic.
> 
> (It seems amazing that ARIN has only ever once provided aN IPv4 prefix
> that wasn't routable, which is the 24.y/11... )
> 


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


From leo.vegoda at icann.org  Fri Feb  5 16:19:08 2010
From: leo.vegoda at icann.org (Leo Vegoda)
Date: Fri, 5 Feb 2010 13:19:08 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B6C83D8.7020109@matthew.at>
References: <4B6C38FA.6060502@umn.edu>
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>
	<3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com>
	<3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>
	<4B6C83D8.7020109@matthew.at>
Message-ID: <57AF8076-FA54-443A-B664-1F8D4901F580@icann.org>

On 5 Feb 2010, at 12:47, Matthew Kaufman wrote:
> William Herrin wrote:
>> On Fri, Feb 5, 2010 at 2:39 PM, William Herrin <bill at herrin.us> wrote:
>> 
>>> Yeah, but the IETF set aside fc00::/7 for that purpose already and
>>> only fd00::/8 is used for the so-called statistically unique
>>> assignments. So we don't actually *have* to waste any new space to
>>> make non-connected assignments from a distinct pool. At worst we'd
>>> need a global policy to open fc00::/8 for assignment to the RIRs.
>>> 
>> Excuse me, the IANA at the request of the IETF set aside fc00::/7 for
>> the purpose of addressing non-connected networks.
>> 
> Perhaps one or more Regional Not-The-Internet Registries should apply to 
> IANA to administer assignments within that space.

As that /7 was registered following the publication of a Standards Track RFC (4193), we won't just be accepting applications without a suitable RFC telling us to do so.

Regards,

Leo Vegoda

From matthew at matthew.at  Fri Feb  5 16:22:26 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 05 Feb 2010 13:22:26 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <57AF8076-FA54-443A-B664-1F8D4901F580@icann.org>
References: <4B6C38FA.6060502@umn.edu>
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>
	<3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com>
	<3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>
	<4B6C83D8.7020109@matthew.at>
	<57AF8076-FA54-443A-B664-1F8D4901F580@icann.org>
Message-ID: <4B6C8C12.7070309@matthew.at>

Leo Vegoda wrote:
> On 5 Feb 2010, at 12:47, Matthew Kaufman wrote:
>   
>> William Herrin wrote:
>>     
>>> On Fri, Feb 5, 2010 at 2:39 PM, William Herrin <bill at herrin.us> wrote:
>>>
>>>       
>>>> Yeah, but the IETF set aside fc00::/7 for that purpose already and
>>>> only fd00::/8 is used for the so-called statistically unique
>>>> assignments. So we don't actually *have* to waste any new space to
>>>> make non-connected assignments from a distinct pool. At worst we'd
>>>> need a global policy to open fc00::/8 for assignment to the RIRs.
>>>>
>>>>         
>>> Excuse me, the IANA at the request of the IETF set aside fc00::/7 for
>>> the purpose of addressing non-connected networks.
>>>
>>>       
>> Perhaps one or more Regional Not-The-Internet Registries should apply to 
>> IANA to administer assignments within that space.
>>     
>
> As that /7 was registered following the publication of a Standards Track RFC (4193), we won't just be accepting applications without a suitable RFC telling us to do so.
>   

Of course... but the ARIN PDP isn't how such an RFC would be produced.

But this all does suggest that no ARIN PDP is necessary at all, since 
ARIN shouldn't be in that business (yet) anyway.

If we're going to hand out space which must be marked in such a way that 
it can never be routed, it really should come from space for which IANA 
(and everyone else) agrees will never be routed, not just from a spare 
end of space on hand.

Matthew Kaufman


From aaron at wholesaleinternet.net  Fri Feb  5 16:30:14 2010
From: aaron at wholesaleinternet.net (Aaron Wendel)
Date: Fri, 5 Feb 2010 15:30:14 -0600
Subject: [arin-ppml] Policy Proposal 109: Standardize IP
	Reassignment	Registration Requirements
In-Reply-To: <4B6AF6CE.7000709@arin.net>
References: <4B6AF6CE.7000709@arin.net>
Message-ID: <0b5d01caa6aa$6784ad80$368e0880$@net>

I oppose this proposal.  It further restricts information and
overcomplicates policies that should be made simpler and more flexible.

Aaron


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Member Services
Sent: Thursday, February 04, 2010 10:33 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
Registration Requirements

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.

Draft Policies and Proposals under discussion can be found 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

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 109: Standardize IP Reassignment Registration Requirements

Proposal Originator: Chris Grundemann

Proposal Version: 1.0

Date: 4 FEB 2010

Proposal type: Modify

Policy term: Permanent

Policy statement:

## Definitions ##

  - Add:

2.3. Organizational Information

When required, organization Information must include at a minimum:
Legal name, city, state, zip code equivalent and at least one valid
technical or abuse POC; inclusion of street address is highly
encouraged. The POC shall be designated by the organization and must
include at least one verifiable email address, inclusion of a phone
number is highly encouraged.

## IPv4 ##

  - Rename 4.2.3.7. "Reassignment information" to "Registration"

  - Rename 4.2.3.7.1. "Customer organization information" to
"Reassignment Information" and replace text with:

When an organization holding an IPv4 address allocation makes IPv4
address assignments, it must register reassignment information via
SWIP or RWHOIS server. SWIP and RWHOIS reassignments shall include
each client's organizational information, except where specifically
exempted by this policy.

  - Replace 4.2.3.7.6. Residential Customer Privacy with:

4.2.3.7.6. Residential Subscribers

4.2.3.7.6.1. Residential Market Area

In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather
than to individual subscribers. This assignment information regarding
each market area holding an address block should be registered with
the network name used to identify each market area. Initial
allocations are based on total number of homes that could purchase the
service in a given market area. Each assignment to specific end-users
of /29 and larger blocks still requires individual registration.

4.2.3.7.6.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /29 and
larger blocks may substitute that organization's name for the
customer's name, e.g. 'Private Customer - XYZ Network', and the
customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.

  - Strike section 4.2.6. "Cable Address Space Policy"

## IPv6 ##

  - Replace Section 6.5.5. with:

6.5.5. Registration

6.5.5.1. Reassignment information

When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register reassignment information in a
database, accessible by RIRs as appropriate (information registered by
an RIR may be replaced by a distributed database for registering
address management information in future). These reassignment
registrations shall include each client's organizational information,
except where specifically exempted by this policy.

6.5.5.2. /56 registered unit

Information is registered in units of assigned /56 networks. When more
than a /56 is assigned to a client organization, the assigning
organization is responsible for ensuring that the address space is
registered in an RIR database.

6.5.5.3. Submit within 7 days

Any time an LIR receives a new block of address space, reassignment
information should be submitted within 7 days of issuance of the new
space.

6.5.5.4. Visible via WHOIS

This information must be visible via WHOIS prior to submitting a
request for a new allocation. For further information on reassigning
IP address space, please see RFC 2050.

6.5.5.6. Residential Subscribers

6.5.5.6.1. Residential Market Area

In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather
than to individual subscribers. This assignment information regarding
each market area holding an address block should be registered with
the network name used to identify each market area. Initial
allocations are based on total number of homes that could purchase the
service in a given market area. Each assignment to specific end-users
of /56 and larger blocks still requires individual registration.

6.5.5.6.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an
organization with downstream residential customers holding /56 and
larger blocks may substitute that organization's name for the
customer's name, e.g. 'Private Customer - XYZ Network', and the
customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.


Rationale:

This proposal intends to do several things:
1) Bring IPv4 and IPv6 policy more in line with each other to make the
NRPM easier to understand and comply with - at least as it relates to
reassignment information.
2) Specifically define what organizational information is required to
be added to whois when reassignments are made to client organizations.
3) To specifically state that a client organization may designate the
POC of their choice for any/all whois entries. This includes
designating an upstream POC as their own prefered POC.
4) Expands the priviledges previously reserved solely for cable ISPs
to all ISPs/LIRs with residential subscribers. Namely the ability to
SWIP/RWHOIS an entire residential market area as one reassignment. It
also expands this priviledge to IPv6 reasignments, instead of just
IPv4 as it is now.

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.

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.733 / Virus Database: 271.1.1/2659 - Release Date: 02/04/10
01:35:00



From gbonser at seven.com  Fri Feb  5 16:29:16 2010
From: gbonser at seven.com (George Bonser)
Date: Fri, 5 Feb 2010 13:29:16 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
References: <4B6C38FA.6060502@umn.edu>	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com><3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com><3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com><4B6C83D8.7020109@matthew.at>
	<5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7651@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of George Bonser
> Sent: Friday, February 05, 2010 1:10 PM
> To: matthew at matthew.at; William Herrin
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 Non-connected networks


> So what is really being looked at, then, is a registry for fc00::/7
> space with the L bit set to 0, or in other words, defining the L bit
> per
> section 3.2 of RFC4193 as "assigned by RIR or whomever" with chunks of
> fd00::/8 being doled out by the various RIRs (or whomever) for
networks
> in their area.

Meant to say defining L=0 and it should be fc00::/8

So some central authority handing out fc00::/8 space out of fc00::/7  

fd00::/8 would belong to anyone who wants to use it and potentially at
risk of collision as rfc1918 is today.




From farmer at umn.edu  Fri Feb  5 16:51:12 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 05 Feb 2010 15:51:12 -0600
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
References: <4B6C38FA.6060502@umn.edu>	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com><3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com><3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>	<4B6C83D8.7020109@matthew.at>
	<5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
Message-ID: <4B6C92D0.7080709@umn.edu>

George Bonser wrote:
> 
>>> Excuse me, the IANA at the request of the IETF set aside fc00::/7
> for
>>> the purpose of addressing non-connected networks.
>>>
>>>
> 
> So what is really being looked at, then, is a registry for fc00::/7
> space with the L bit set to 0, or in other words, defining the L bit per
> section 3.2 of RFC4193 as "assigned by RIR or whomever" with chunks of
> fd00::/8 being doled out by the various RIRs (or whomever) for networks
> in their area.

No that is what Bill is proposing, I'm not completely opposed to that, 
but it is not currently being proposed.  Nor do I think ARIN could do 
this unilaterally.  I was thinking this would take IETF action.  Bill 
proposed the idea of a RIR global policy, and maybe that could be an 
option, I need to think about that more.

>> Perhaps one or more Regional Not-The-Internet Registries should apply
>> to
>> IANA to administer assignments within that space.
> 
> Would seem to me like a better idea than using globally unique space for
> unconnected networks. It would require renumbering if you went
> connected, though.  So does it boil down to wanting space that is not
> connected so your unconnected address space nets doesn't count against
> density requirements for connected space but allows you to connect it
> without renumbering later?  And if so, how do you know when someone has
> converted their "unconnected" net to "connected" by announcing the route
> and that space should now count against requirements to justify space?
> 
> What is to prevent someone from requesting space for "unconnected"
> networks in addition to "connected" for a total of more space than they
> would otherwise be able to justify and then announcing the unconnected
> space a week later?

If there is no distention, you just get one kind of space, the question 
is how did you justify it.

> I think "unconnected space" space should be just that and not
> "temporarily unconnected space for right now".  But having pieces of it
> doled out from a central authority would make it easier for two networks
> that are not connected to the global internet to interconnect without
> address space collision.

I want people to realize that current IPv6 policy allows someone who 
could justify a non-connected network under IPv4 policy and to get 
globally unique IPv4 addresses per 4.3.5 to get an globally unique IPv6 
addresses too.

I believe we should do one of the following;

1. Implement PP#107 as written allowing non-connected network 
assignments from common blocks with Internet connected assignments, or; 
  (I believe this is the status-quo of the current convoluted IPv6 policy)

2. Define a separate blocks of address space for non-connected networks 
from the space ARIN has already or get more space from 2000:/3 for this. 
By directing ARIN in PP#107 to make assignments for non-connected 
networks from separate defined and published blocks, or;

3. Implement ULA-Central or a similar proposal, either through the IETF 
or the RIR global policy process, as make assignments from a block 
within fc00::/7.  In this case I would suggest pull non-connected 
networks out of PP#107 and starting a whole new policy for this.


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


From cgrundemann at gmail.com  Fri Feb  5 17:10:39 2010
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 5 Feb 2010 15:10:39 -0700
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements
In-Reply-To: <0b5d01caa6aa$6784ad80$368e0880$@net>
References: <4B6AF6CE.7000709@arin.net> <0b5d01caa6aa$6784ad80$368e0880$@net>
Message-ID: <443de7ad1002051410j3bdf1842s4003071290e159ae@mail.gmail.com>

On Fri, Feb 5, 2010 at 14:30, Aaron Wendel <aaron at wholesaleinternet.net> wrote:
> I oppose this proposal. ?It further restricts information and
> overcomplicates policies that should be made simpler and more flexible.

To make sure that I understand you correctly:

You believe that all residential customers should be listed in WHOIS?

You believe that this proposal makes the policy more complicated than
it is today?

I would really appreciate your feedback!
~Chris

>
> Aaron
>
>
> 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.
>




-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org


From matthew at matthew.at  Fri Feb  5 17:16:21 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 05 Feb 2010 14:16:21 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B6C92D0.7080709@umn.edu>
References: <4B6C38FA.6060502@umn.edu>	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com><3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com><3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>	<4B6C83D8.7020109@matthew.at>
	<5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
	<4B6C92D0.7080709@umn.edu>
Message-ID: <4B6C98B5.8010506@matthew.at>

David Farmer wrote:
> George Bonser wrote:
>>
>>>> Excuse me, the IANA at the request of the IETF set aside fc00::/7
>> for
>>>> the purpose of addressing non-connected networks.
>>>>
>>>>
>>
>> So what is really being looked at, then, is a registry for fc00::/7
>> space with the L bit set to 0, or in other words, defining the L bit per
>> section 3.2 of RFC4193 as "assigned by RIR or whomever" with chunks of
>> fd00::/8 being doled out by the various RIRs (or whomever) for networks
>> in their area.
>
> No that is what Bill is proposing, I'm not completely opposed to that, 
> but it is not currently being proposed.  Nor do I think ARIN could do 
> this unilaterally.  I was thinking this would take IETF action.  Bill 
> proposed the idea of a RIR global policy, and maybe that could be an 
> option, I need to think about that more.
>
>>> Perhaps one or more Regional Not-The-Internet Registries should apply
>>> to
>>> IANA to administer assignments within that space.
>>
>> Would seem to me like a better idea than using globally unique space for
>> unconnected networks. It would require renumbering if you went
>> connected, though.  So does it boil down to wanting space that is not
>> connected so your unconnected address space nets doesn't count against
>> density requirements for connected space but allows you to connect it
>> without renumbering later?  And if so, how do you know when someone has
>> converted their "unconnected" net to "connected" by announcing the route
>> and that space should now count against requirements to justify space?
>>
>> What is to prevent someone from requesting space for "unconnected"
>> networks in addition to "connected" for a total of more space than they
>> would otherwise be able to justify and then announcing the unconnected
>> space a week later?
>
> If there is no distention, you just get one kind of space, the 
> question is how did you justify it.
>
>> I think "unconnected space" space should be just that and not
>> "temporarily unconnected space for right now".  But having pieces of it
>> doled out from a central authority would make it easier for two networks
>> that are not connected to the global internet to interconnect without
>> address space collision.
>
> I want people to realize that current IPv6 policy allows someone who 
> could justify a non-connected network under IPv4 policy and to get 
> globally unique IPv4 addresses per 4.3.5 to get an globally unique 
> IPv6 addresses too.
>
> I believe we should do one of the following;
>
> 1. Implement PP#107 as written allowing non-connected network 
> assignments from common blocks with Internet connected assignments, 
> or;  (I believe this is the status-quo of the current convoluted IPv6 
> policy)
Right. You can already do this, but they look just like connected ones. 
These are the kind you should get if you're not connected *now* but plan 
to connect *later* and don't want to renumber.
>
> 2. Define a separate blocks of address space for non-connected 
> networks from the space ARIN has already or get more space from 
> 2000:/3 for this. By directing ARIN in PP#107 to make assignments for 
> non-connected networks from separate defined and published blocks, or;
This is a bad idea.
>
> 3. Implement ULA-Central or a similar proposal, either through the 
> IETF or the RIR global policy process, as make assignments from a 
> block within fc00::/7.  In this case I would suggest pull 
> non-connected networks out of PP#107 and starting a whole new policy 
> for this.
>
>
If there's going to be a central registrar for never-to-be-connected 
networks (something for which I believe there are good arguments), this 
is what would need to happen, and the ARIN PDP wouldn't be involved 
until late in this process, and then only if ARIN was going to be the 
world's or this region's registrar for that kind of space (something 
which I don't believe should be a given).

Matthew Kaufman



From farmer at umn.edu  Fri Feb  5 18:15:55 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 05 Feb 2010 17:15:55 -0600
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B6C98B5.8010506@matthew.at>
References: <4B6C38FA.6060502@umn.edu>	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com><3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com><3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>	<4B6C83D8.7020109@matthew.at>
	<5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
	<4B6C92D0.7080709@umn.edu> <4B6C98B5.8010506@matthew.at>
Message-ID: <4B6CA6AB.7020101@umn.edu>

Matthew Kaufman wrote:
> David Farmer wrote:
>> I want people to realize that current IPv6 policy allows someone who 
>> could justify a non-connected network under IPv4 policy and to get 
>> globally unique IPv4 addresses per 4.3.5 to get an globally unique 
>> IPv6 addresses too.
>>
>> I believe we should do one of the following;
>>
>> 1. Implement PP#107 as written allowing non-connected network 
>> assignments from common blocks with Internet connected assignments, 
>> or;  (I believe this is the status-quo of the current convoluted IPv6 
>> policy)
>
> Right. You can already do this, but they look just like connected ones. 
> These are the kind you should get if you're not connected *now* but plan 
> to connect *later* and don't want to renumber.

Should they have to meet basically the same criteria as a Internet 
connected assignments them?

>> 2. Define a separate blocks of address space for non-connected 
>> networks from the space ARIN has already or get more space from 
>> 2000:/3 for this. By directing ARIN in PP#107 to make assignments for 
>> non-connected networks from separate defined and published blocks, or;
>
>  This is a bad idea.

To maybe help develop a consensus, could you expand on why you think 
this is a bad idea?

>> 3. Implement ULA-Central or a similar proposal, either through the 
>> IETF or the RIR global policy process, as make assignments from a 
>> block within fc00::/7.  In this case I would suggest pull 
>> non-connected networks out of PP#107 and starting a whole new policy 
>> for this.
>
> If there's going to be a central registrar for never-to-be-connected 
> networks (something for which I believe there are good arguments), this 
> is what would need to happen, and the ARIN PDP wouldn't be involved 
> until late in this process, and then only if ARIN was going to be the 
> world's or this region's registrar for that kind of space (something 
> which I don't believe should be a given).

Are you suggestion we should do both #1 and #3?  It kind of seems to me 
that you are, and I hadn't thought of that option.  I think I hear you 
saying there are three types of network in question;

1. Internet Connected
2. Non-Connected
3. Never to be Connected

And, never to be connected networks should be served by ULA or 
ULA-Central, and that filtering them is probably OK.  But, that 
non-connected networks should be served out of 2000::/3 and that making 
them easy to filter them is not OK.

This is an interesting idea I need to think about more.

> Matthew Kaufman

Thanks

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


From mysidia at gmail.com  Fri Feb  5 21:57:08 2010
From: mysidia at gmail.com (James Hess)
Date: Fri, 5 Feb 2010 20:57:08 -0600
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements
In-Reply-To: <443de7ad1002051410j3bdf1842s4003071290e159ae@mail.gmail.com>
References: <4B6AF6CE.7000709@arin.net> <0b5d01caa6aa$6784ad80$368e0880$@net>
	<443de7ad1002051410j3bdf1842s4003071290e159ae@mail.gmail.com>
Message-ID: <6eb799ab1002051857v19b7908cxf91217f8fc3efdd4@mail.gmail.com>

On Fri, Feb 5, 2010 at 4:10 PM, Chris Grundemann
<cgrundemann at gmail.com> wrote:
> On Fri, Feb 5, 2010 at 14:30, Aaron Wendel <aaron at wholesaleinternet.net> wrote:
> You believe that all residential customers should be listed in WHOIS?

Residential  customers do not have to be identified by name or address
in WHOIS  under current policy. So the proposal is neutral in regards
to that.. By my reading of it,  proposal 109 requires more
information, not less, to be recorded in an assignment.

We don't need to add re-assignment form standardization to the NRPM,
because  this can be done most effectively by ARIN staff;  it makes
the number policy more complicated, and does not appear to confer a
benefit.    The re-assigning ISP and ARIN  should exercise discretion
in regards to the contents of re-assignment records.    The  NRPM
doesn't need to standardize this, any more than it needs to
standardize  what specific documents a new organization needs to fax
in to _prove_ to ARIN that they really exist, or the fee levels.


Believe Sec 3.2  is sufficient
"3.2. Distributed Information Server Use Requirements
...
The minimal requirements for an organization to setup a distributed
information service to advertise reassignment information are:
The distributed information service must respond to a query with the
minimal set of attributes per object as defined by ARIN staff."




Also, in regards to the following:   merging and revising the "Cable
Address Space" policy  into a  "Residential Market Area"  policy,  is
a potential can of worms.

 "Initial  allocations are based on total number of homes that could
purchase the
service in a given market area. Each assignment to specific end-users
of /29 and larger blocks still requires individual registration."

Problem with this wording:  _every_  home  in a given market area
COULD purchase  certain services,  such as  dial-up  networking or VPN
services for residential users, even in cases where 15% or fewer
actually will.     Then in those cases, the initial allocation would
have been based on the higher fictional quantity,   the number "that
could" buy service in that market.

Cable networks that involve IP addressing for residential customers
are normally local monopolies,  and have well-defined  market areas.

So basing initial allocation on  potential market size  is  not wasteful.
But for  other types of services it could be wasteful.

Perhaps it's just a wording issue...

--
-J


From joe at joesdatacenter.com  Fri Feb  5 23:31:03 2010
From: joe at joesdatacenter.com (Joe Morgan)
Date: Fri, 5 Feb 2010 22:31:03 -0600
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements
In-Reply-To: <6eb799ab1002051857v19b7908cxf91217f8fc3efdd4@mail.gmail.com>
References: <4B6AF6CE.7000709@arin.net> <0b5d01caa6aa$6784ad80$368e0880$@net>
	<443de7ad1002051410j3bdf1842s4003071290e159ae@mail.gmail.com>
	<6eb799ab1002051857v19b7908cxf91217f8fc3efdd4@mail.gmail.com>
Message-ID: <38dd4e411002052031y5e62c0edp41bcc1b996dc31c6@mail.gmail.com>

I oppose this proposal.

Joe Morgan
Joe's Datacenter, LLC
http://joesdatacenter.com


On Fri, Feb 5, 2010 at 8:57 PM, James Hess <mysidia at gmail.com> wrote:
> On Fri, Feb 5, 2010 at 4:10 PM, Chris Grundemann
> <cgrundemann at gmail.com> wrote:
>> On Fri, Feb 5, 2010 at 14:30, Aaron Wendel <aaron at wholesaleinternet.net> wrote:
>> You believe that all residential customers should be listed in WHOIS?
>
> Residential ?customers do not have to be identified by name or address
> in WHOIS ?under current policy. So the proposal is neutral in regards
> to that.. By my reading of it, ?proposal 109 requires more
> information, not less, to be recorded in an assignment.
>
> We don't need to add re-assignment form standardization to the NRPM,
> because ?this can be done most effectively by ARIN staff; ?it makes
> the number policy more complicated, and does not appear to confer a
> benefit. ? ?The re-assigning ISP and ARIN ?should exercise discretion
> in regards to the contents of re-assignment records. ? ?The ?NRPM
> doesn't need to standardize this, any more than it needs to
> standardize ?what specific documents a new organization needs to fax
> in to _prove_ to ARIN that they really exist, or the fee levels.
>
>
> Believe Sec 3.2 ?is sufficient
> "3.2. Distributed Information Server Use Requirements
> ...
> The minimal requirements for an organization to setup a distributed
> information service to advertise reassignment information are:
> The distributed information service must respond to a query with the
> minimal set of attributes per object as defined by ARIN staff."
>
>
>
>
> Also, in regards to the following: ? merging and revising the "Cable
> Address Space" policy ?into a ?"Residential Market Area" ?policy, ?is
> a potential can of worms.
>
> ?"Initial ?allocations are based on total number of homes that could
> purchase the
> service in a given market area. Each assignment to specific end-users
> of /29 and larger blocks still requires individual registration."
>
> Problem with this wording: ?_every_ ?home ?in a given market area
> COULD purchase ?certain services, ?such as ?dial-up ?networking or VPN
> services for residential users, even in cases where 15% or fewer
> actually will. ? ? Then in those cases, the initial allocation would
> have been based on the higher fictional quantity, ? the number "that
> could" buy service in that market.
>
> Cable networks that involve IP addressing for residential customers
> are normally local monopolies, ?and have well-defined ?market areas.
>
> So basing initial allocation on ?potential market size ?is ?not wasteful.
> But for ?other types of services it could be wasteful.
>
> Perhaps it's just a wording issue...
>
> --
> -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.
>



-- 
Thank You,
Joe Morgan
Joe's Datacenter, LLC
http://joesdatacenter.com


From matthew at matthew.at  Sat Feb  6 02:05:03 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Fri, 05 Feb 2010 23:05:03 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B6CA6AB.7020101@umn.edu>
References: <4B6C38FA.6060502@umn.edu>	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com><3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com><3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>	<4B6C83D8.7020109@matthew.at>
	<5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
	<4B6C92D0.7080709@umn.edu> <4B6C98B5.8010506@matthew.at>
	<4B6CA6AB.7020101@umn.edu>
Message-ID: <4B6D149F.6000001@matthew.at>

(Keeping all context for clarity)

David Farmer wrote:
> Matthew Kaufman wrote:
>> David Farmer wrote:
>>> I want people to realize that current IPv6 policy allows someone who 
>>> could justify a non-connected network under IPv4 policy and to get 
>>> globally unique IPv4 addresses per 4.3.5 to get an globally unique 
>>> IPv6 addresses too.
>>>
>>> I believe we should do one of the following;
>>>
>>> 1. Implement PP#107 as written allowing non-connected network 
>>> assignments from common blocks with Internet connected assignments, 
>>> or;  (I believe this is the status-quo of the current convoluted 
>>> IPv6 policy)
>>
>> Right. You can already do this, but they look just like connected 
>> ones. These are the kind you should get if you're not connected *now* 
>> but plan to connect *later* and don't want to renumber.
>
> Should they have to meet basically the same criteria as a Internet 
> connected assignments them?
It sure seems that way. From ARIN's POV, there's no difference between 
an address you've chosen to route and one you've chosen to not route 
yet. The operator probably charges you less to not have service, but 
that's an operator issue.

It should be possible to justify such space, however, just as it was 
possible in the past to justify IPv4 space for networks that were not 
yet connected but had some probability of being connected in the future.

The real problem is if you try to keep the split where there's no such 
thing as PI addresses unless you have some crazy criteria like that 
you're actively multihomed... especially this early in the adoption 
cycle. A Fortune 500 company that wants to get their IPv6 now but 
doesn't intend to actually hook up for another year shouldn't need to 
lie on their application to get the space.
>
>>> 2. Define a separate blocks of address space for non-connected 
>>> networks from the space ARIN has already or get more space from 
>>> 2000:/3 for this. By directing ARIN in PP#107 to make assignments 
>>> for non-connected networks from separate defined and published 
>>> blocks, or;
>>
>>  This is a bad idea.
>
> To maybe help develop a consensus, could you expand on why you think 
> this is a bad idea?
Because either the addresses are in a set for which there is worldwide 
IETF and/or IANA-level agreement that the prefix WILL NEVER BE ROUTED 
EVER, or the addresses are in a set which is suspiciously similar to 
allocated-to-RIR, will-be-routed-some-day address space. The latter 
*will* be routed, for one reason or another... which just makes them 
otherwise identical to the blocks from choice 1, only the space is 
strangely sparse in the routing table for a while.

Imagine if we'd known that CIDR was coming, and that the Internet was 
going to be a big popular thing, and we'd said "well, we're going to 
reserve 192.0.0.0/8 and just give those addresses out to people who want 
a class C to play with internally but who don't plan to spend all that 
money it takes to hook up to the Internet". How many of those addresses 
would be in the global routing table at this point?
>
>>> 3. Implement ULA-Central or a similar proposal, either through the 
>>> IETF or the RIR global policy process, as make assignments from a 
>>> block within fc00::/7.  In this case I would suggest pull 
>>> non-connected networks out of PP#107 and starting a whole new policy 
>>> for this.
>>
>> If there's going to be a central registrar for never-to-be-connected 
>> networks (something for which I believe there are good arguments), 
>> this is what would need to happen, and the ARIN PDP wouldn't be 
>> involved until late in this process, and then only if ARIN was going 
>> to be the world's or this region's registrar for that kind of space 
>> (something which I don't believe should be a given).
>
> Are you suggestion we should do both #1 and #3?  It kind of seems to 
> me that you are, and I hadn't thought of that option.  I think I hear 
> you saying there are three types of network in question;
>
> 1. Internet Connected
> 2. Non-Connected
> 3. Never to be Connected
>
> And, never to be connected networks should be served by ULA or 
> ULA-Central, and that filtering them is probably OK.  But, that 
> non-connected networks should be served out of 2000::/3 and that 
> making them easy to filter them is not OK.
That's what I'm saying.

Clearly there is a need (or, I should say, "customer demand") for blocks 
of type 3 which are guaranteed-unique with a central registrar, and not 
simply likely-unique. Whether or not ARIN should be in that business, I 
don't know... there's no reason, really, that the registrars for that 
space must necessarily be the same as the registrars for the other 
space. But it should be possible to get that kind of block.

Several *years* ago I was at a big company that wanted to have a whole 
lot of equipment in things like test labs assigned IPv6 addresses, and 
wanted to be sure those would never overlap the space of companies they 
might merge with, and wanted them "officially assigned", but didn't want 
to pay *too* much for them because, well, they'd *never* be externally 
accessible. Likely-unique local addresses wasn't good enough for them, 
and getting an IPv6 ISP and some PA addresses was exactly the opposite 
of what they needed. I think this would make this set of potential IPv6 
numbering customers happy.

Matthew Kaufman



From tedm at ipinc.net  Sat Feb  6 02:10:52 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Fri, 05 Feb 2010 23:10:52 -0800
Subject: [arin-ppml] Policy Proposal 109: Standardize
 IP	ReassignmentRegistration Requirements
In-Reply-To: <443de7ad1002050728o39803f20l5cadd1b8d2ef6915@mail.gmail.com>
References: <4B6AF6CE.7000709@arin.net>	<28E139F46D45AF49A31950F88C4974580513B8BB@E03MVZ2-UKDY.domain1.systemhost.net>
	<443de7ad1002050728o39803f20l5cadd1b8d2ef6915@mail.gmail.com>
Message-ID: <4B6D15FC.3060409@ipinc.net>

Chris Grundemann wrote:
> On Fri, Feb 5, 2010 at 06:12,  <michael.dillon at bt.com> wrote:
>>> Policy Proposal 109: Standardize IP Reassignment Registration
>>> Requirements
>> Huh!?
>>
>>>   - Add:
>>>   - Rename 4.2.3.7. "Reassignment information" to "Registration"
>>>
>>>   - Rename 4.2.3.7.1. "Customer organization information" to
>>> "Reassignment Information" and replace text with:
>>>   - Replace 4.2.3.7.6. Residential Customer Privacy with:
>>>   - Strike section 4.2.6. "Cable Address Space Policy"
>>>   - Replace Section 6.5.5. with:
>> I'm still not sure what this policy proposal is trying to do
>> or what is being changed. Clearly, the only way to figure
>> this out is to compare the existing copious verbiage in the NRPM
>> with the copious verbiage in this policy and I haven't time
>> to do this right now.
> 
> Yes, reading the NRPM may be a prerequisite to understanding proposed
> changes to it.
> 
>> I am opposed to this proposal on the grounds of its complexity
>> and the lack of clarity around what, if any, kind of problem
>> it attempts to solve.
> 

I was going to remain neutral on this policy proposal.  on one
hand I like standardized disclosure.  On the other hand I do not
like removing the onus to register anyone, even a residential
user, in WHOIS.

However after seeing Dillon's comment I am going to come out
SOLIDLY IN FAVOR of this policy proposal if for no other reason
than to counteract his no vote.

In the future perhaps it might occur to certain people that if they
don't have time to read and understand certain policy proposal changes
that they lack the knowledge to make good policy decisions on them, and
should just say nothing and let the folks who do understand a
particular proposal to comment on it.



Ted


From joe at joesdatacenter.com  Sat Feb  6 02:50:46 2010
From: joe at joesdatacenter.com (Joe Morgan)
Date: Sat, 6 Feb 2010 01:50:46 -0600
Subject: [arin-ppml] Policy Proposal 109: Standardize IP
	ReassignmentRegistration Requirements
In-Reply-To: <4B6D15FC.3060409@ipinc.net>
References: <4B6AF6CE.7000709@arin.net>
	<28E139F46D45AF49A31950F88C4974580513B8BB@E03MVZ2-UKDY.domain1.systemhost.net>
	<443de7ad1002050728o39803f20l5cadd1b8d2ef6915@mail.gmail.com>
	<4B6D15FC.3060409@ipinc.net>
Message-ID: <38dd4e411002052350i648896ceu971dc800d4aaa777@mail.gmail.com>

Ted Mittelstaedt

> In the future perhaps it might occur to certain people that if they
> don't have time to read and understand certain policy proposal changes
> that they lack the knowledge to make good policy decisions on them, and
> should just say nothing and let the folks who do understand a
> particular proposal to comment on it.

I feel he was making a point as much as anyone else has. Its probably
best we stay on topic instead of using this as your way of attacking
people. I personally have to agree with his point of what, if any,
kind of problem
does it attempt to solve.


On Sat, Feb 6, 2010 at 1:10 AM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> Chris Grundemann wrote:
>>
>> On Fri, Feb 5, 2010 at 06:12, ?<michael.dillon at bt.com> wrote:
>>>>
>>>> Policy Proposal 109: Standardize IP Reassignment Registration
>>>> Requirements
>>>
>>> Huh!?
>>>
>>>> ?- Add:
>>>> ?- Rename 4.2.3.7. "Reassignment information" to "Registration"
>>>>
>>>> ?- Rename 4.2.3.7.1. "Customer organization information" to
>>>> "Reassignment Information" and replace text with:
>>>> ?- Replace 4.2.3.7.6. Residential Customer Privacy with:
>>>> ?- Strike section 4.2.6. "Cable Address Space Policy"
>>>> ?- Replace Section 6.5.5. with:
>>>
>>> I'm still not sure what this policy proposal is trying to do
>>> or what is being changed. Clearly, the only way to figure
>>> this out is to compare the existing copious verbiage in the NRPM
>>> with the copious verbiage in this policy and I haven't time
>>> to do this right now.
>>
>> Yes, reading the NRPM may be a prerequisite to understanding proposed
>> changes to it.
>>
>>> I am opposed to this proposal on the grounds of its complexity
>>> and the lack of clarity around what, if any, kind of problem
>>> it attempts to solve.
>>
>
> I was going to remain neutral on this policy proposal. ?on one
> hand I like standardized disclosure. ?On the other hand I do not
> like removing the onus to register anyone, even a residential
> user, in WHOIS.
>
> However after seeing Dillon's comment I am going to come out
> SOLIDLY IN FAVOR of this policy proposal if for no other reason
> than to counteract his no vote.
>
> In the future perhaps it might occur to certain people that if they
> don't have time to read and understand certain policy proposal changes
> that they lack the knowledge to make good policy decisions on them, and
> should just say nothing and let the folks who do understand a
> particular proposal to comment on it.
>
>
>
> Ted
> _______________________________________________
> 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.
>



-- 
Thank You,
Joe Morgan
Joe's Datacenter, LLC
http://joesdatacenter.com


From mcr at sandelman.ca  Sat Feb  6 13:11:54 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Sat, 06 Feb 2010 13:11:54 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
References: <4B6C38FA.6060502@umn.edu>
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com><3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com><3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>
	<4B6C83D8.7020109@matthew.at>
	<5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
Message-ID: <8896.1265479914@marajade.sandelman.ca>


>>>>> "George" == George Bonser <gbonser at seven.com> writes:
    George> Would seem to me like a better idea than using globally
    George> unique space for unconnected networks. It would require
    George> renumbering if you went connected, though.  So does it boil

No renumbering required.  That's IPv4 think.

In IPv6 is common and routine to have multiple addresses per interface.
If you connect, then you get PA address space from your ISP (de jour).

    George> What is to prevent someone from requesting space for
    George> "unconnected" networks in addition to "connected" for a
    George> total of more space than they would otherwise be able to
    George> justify and then announcing the unconnected space a week
    George> later?

Nothing at all.  IPv6 is to big, not only is this to be permitted, but
it is to be encouraged.

    George> I think "unconnected space" space should be just that and
    George> not "temporarily unconnected space for right now".  But
    George> having pieces of it doled out from a central authority would
    George> make it easier for two networks that are not connected to
    George> the global internet to interconnect without address space
    George> collision.

I agree.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 


From gbonser at seven.com  Sat Feb  6 13:40:00 2010
From: gbonser at seven.com (George Bonser)
Date: Sat, 6 Feb 2010 10:40:00 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B6D149F.6000001@matthew.at>
References: <4B6C38FA.6060502@umn.edu>	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com><3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com><3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com>	<4B6C83D8.7020109@matthew.at>
	<5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
	<4B6C92D0.7080709@umn.edu> <4B6C98B5.8010506@matthew.at>
	<4B6CA6AB.7020101@umn.edu> <4B6D149F.6000001@matthew.at>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7676@RWC-EX1.corp.seven.com>

> The real problem is if you try to keep the split where there's no such
> thing as PI addresses unless you have some crazy criteria like that
> you're actively multihomed... especially this early in the adoption
> cycle. A Fortune 500 company that wants to get their IPv6 now but
> doesn't intend to actually hook up for another year shouldn't need to
> lie on their application to get the space.

For the reason above, the proposed policy makes sense.  And multihomed
v4 may not mean multihomed v6 as one's upstreams may not support v6. If
this proposal is specifically for unconnected networks who have a clear
intention of connecting the space and given that in many cases there is
no way directly to one's upstream, the connectivity should not be a
requirement.

But I also believe there should also be a block for "never connected"
that has a chance of being unique to the organization.  The most logical
way to do that would be to work with IETF for a formal definition of the
L bit of fc00::/7 space as defined in RFC 4193 to mean "assigned by
registry of unconnected networks" or something to that effect and
generation of another proposal.  



From mcr at sandelman.ca  Sun Feb  7 18:35:22 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Sun, 07 Feb 2010 18:35:22 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <292AF25E62B8894C921B893B53A19D97396AF3312D@BUSINESSEX.business.ad>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<292AF25E62B8894C921B893B53A19D97396AF3312D@BUSINESSEX.business.ad>
Message-ID: <19243.1265585722@marajade.sandelman.ca>

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


Let me put it a different way.

When registrants that were allocated 69/8 or 24.0.0.0/11 were trying to
negotiate with ISPs to remove bogon filters, did those ISPs ever respond
with a statement like:
     "according to RFCxyz, these addresses should never be routed"?

Was there any policy of the IETF, IANA, ICANN or ARIN that was cited as
a reason why these addresses should not be routed?

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBS29OOICLcPvd0N1lAQKBxwgAhj4lkRUxYlmVU/MyZ91CDOqy8qUytdDc
6fD00tmgMsBbRG2ze9A+bsT737LAcM7Yt8c02oEES6DEE/vdGIv5CdWCJJArNo+a
X9J/OyTuBgITSPFbv0DmPQjaI/gKkl5F0WxbI1qXfO7MEXmCznnnfY30dBqXWzZ0
6cYIcjffgyVfhQfR68kUa6SNpdD6xQK4jgkN1iz+it5/d4B8ZrTsg/dEy75ACvIN
7tbsjfakFg2rHP20pu6YiQwXIabZtRnZgYHVVC9Yoc2yB1WwdgISOjQexVSXId3u
Li4bfob1TT3LnIcOSkaSbd8t1nwxBLCm4hU79eZez2XmfYHTcvLuDg==
=zKDi
-----END PGP SIGNATURE-----


From mcr at sandelman.ca  Sun Feb  7 18:36:13 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Sun, 07 Feb 2010 18:36:13 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F764B@RWC-EX1.corp.seven.com>
References: <4B6C38FA.6060502@umn.edu>
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F764B@RWC-EX1.corp.seven.com>
Message-ID: <19300.1265585773@marajade.sandelman.ca>


>>>>> "George" == George Bonser <gbonser at seven.com> writes:
    >> -----Original Message----- From: arin-ppml-bounces at arin.net
    >> [mailto:arin-ppml-bounces at arin.net]
    George> On
    >> Behalf Of cja Sent: Friday, February 05, 2010 9:29 AM Subject:
    >> Re: [arin-ppml] IPv6 Non-connected networks
    >> 
    >> I think a common pool is a good idea. It allows these
    >> non-connected networks to connect if their needs change and keeps
    >> them from having to get another allocation/assingment if they do
    >> choose to connect at a later date.

    George> I also believe having non-connected networks out of a common
    George> pool is a good idea.  For one thing, it allows two networks
    George> that are not connected to the global Internet to
    George> interconnect without worrying about address space collisions
    George> provided both networks got their addresses from the same
    George> issuer.  I am thinking of it as a "regionally unique"
    George> address space.

George, what matters is that the addresses are unique for this to happen.
It doesn't matter what pool they come out of.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 


From bill at herrin.us  Sun Feb  7 20:23:52 2010
From: bill at herrin.us (William Herrin)
Date: Sun, 7 Feb 2010 20:23:52 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <8896.1265479914@marajade.sandelman.ca>
References: <4B6C38FA.6060502@umn.edu>
	<c3227e9e1002050928j6cbf9c0cn530248886d5eefb1@mail.gmail.com> 
	<3c3e3fca1002051139m10794e26sb869e432114b2643@mail.gmail.com> 
	<3c3e3fca1002051141h582df0b8o545ea3eaf58d1ab3@mail.gmail.com> 
	<4B6C83D8.7020109@matthew.at>
	<5A6D953473350C4B9995546AFE9939EE081F764F@RWC-EX1.corp.seven.com>
	<8896.1265479914@marajade.sandelman.ca>
Message-ID: <3c3e3fca1002071723k192c2299pe9374ab65c7a125b@mail.gmail.com>

On Sat, Feb 6, 2010 at 1:11 PM, Michael Richardson <mcr at sandelman.ca> wrote:
>
>>>>>> "George" == George Bonser <gbonser at seven.com> writes:
> ? ?George> Would seem to me like a better idea than using globally
> ? ?George> unique space for unconnected networks. It would require
> ? ?George> renumbering if you went connected, though. ?So does it boil
>
> No renumbering required. ?That's IPv4 think.
>
> In IPv6 is common and routine to have multiple addresses per interface.
> If you connect, then you get PA address space from your ISP (de jour).

Michael,

Unfortunately, that's not true in any practical sense of the word.
Multiply-connected hosts was a goal in IPv6's design but it's only
partially implemented in deployed IPv6. The full suite of capabilities
necessary for it to work in a manner that justifies a comment along
the lines of "renumbering is IPv4-think" don't yet exist.

The IETF has at least two working groups in the early phases of trying
to make IPv6's multi-addressing promise come true: MultipathTCP and
MIF. The Multiple InterFaces WG is the most directly involved in the
issue and unfortunately the closest to square-one. There's also some
routing work needed to enable multi-addressed hosts in nontrivial
networks but that has not yet begun. When it does, look for it to
appear in working groups like GROW and RRG.

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 packetgrrl at gmail.com  Mon Feb  8 00:00:09 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Sun, 7 Feb 2010 22:00:09 -0700
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <19243.1265585722@marajade.sandelman.ca>
References: <4B563F50.1070306@umn.edu> <9413.1265283016@marajade.sandelman.ca>
	<292AF25E62B8894C921B893B53A19D97396AF3312D@BUSINESSEX.business.ad>
	<19243.1265585722@marajade.sandelman.ca>
Message-ID: <c3227e9e1002072100r76c8528fk965fdfaf21a477cc@mail.gmail.com>

Michael...

In my experience with 24.0.0.0/14 none of these were cited.

The other problems we had were software that simply wasn't configured to
understand pieces of classically classful blocks.   Most of the software
supported this it just had to be turned on.

----Cathy

On Sun, Feb 7, 2010 at 4:35 PM, Michael Richardson <mcr at sandelman.ca> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Let me put it a different way.
>
> When registrants that were allocated 69/8 or 24.0.0.0/11 were trying to
> negotiate with ISPs to remove bogon filters, did those ISPs ever respond
> with a statement like:
>     "according to RFCxyz, these addresses should never be routed"?
>
> Was there any policy of the IETF, IANA, ICANN or ARIN that was cited as
> a reason why these addresses should not be routed?
>
> - --
> ]       He who is tired of Weird Al is tired of life!           |
>  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
>                       then sign the petition.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Finger me for keys
>
> iQEVAwUBS29OOICLcPvd0N1lAQKBxwgAhj4lkRUxYlmVU/MyZ91CDOqy8qUytdDc
> 6fD00tmgMsBbRG2ze9A+bsT737LAcM7Yt8c02oEES6DEE/vdGIv5CdWCJJArNo+a
> X9J/OyTuBgITSPFbv0DmPQjaI/gKkl5F0WxbI1qXfO7MEXmCznnnfY30dBqXWzZ0
> 6cYIcjffgyVfhQfR68kUa6SNpdD6xQK4jgkN1iz+it5/d4B8ZrTsg/dEy75ACvIN
> 7tbsjfakFg2rHP20pu6YiQwXIabZtRnZgYHVVC9Yoc2yB1WwdgISOjQexVSXId3u
> Li4bfob1TT3LnIcOSkaSbd8t1nwxBLCm4hU79eZez2XmfYHTcvLuDg==
> =zKDi
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20100207/f5aae7a7/attachment.htm>

From michael.dillon at bt.com  Mon Feb  8 03:54:48 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 8 Feb 2010 08:54:48 -0000
Subject: [arin-ppml] Policy Proposal 109: Standardize IP
	ReassignmentRegistration Requirements
In-Reply-To: <443de7ad1002050655t50ccb685md519c2f7a6572dd0@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C4974580513BEDB@E03MVZ2-UKDY.domain1.systemhost.net>


> On Thu, Feb 4, 2010 at 22:42, Owen DeLong <owen at delong.com> wrote:
> > I'd like to see some wordsmithing to rectify the following:
> >
> > 6.5.5.2
> > ? ? ? ?...registered via SWIP or RWHOIS.
> 
> Section 6.5.5.2 ends with "...is registered in an RIR 
> database." Are you saying that the text _should_ specify SWIP 
> / RWHOIS?

The RIRs run many databases, most of which have nothing to do
with whois. It really should say:

         ...published in the whois directory.

This avoids specifying the mechanism since SWIP and RWHOIS
may not be the only mechanisms any more, and if the whois
directory is defined in the NRPM, the above phrase is
clear and concise.

--Michael Dillon


From michael.dillon at bt.com  Mon Feb  8 04:38:41 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 8 Feb 2010 09:38:41 -0000
Subject: [arin-ppml] Policy Proposal 109: Standardize
	IP	ReassignmentRegistration Requirements
In-Reply-To: <4B6D15FC.3060409@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C4974580513BF98@E03MVZ2-UKDY.domain1.systemhost.net>

> However after seeing Dillon's comment I am going to come out 
> SOLIDLY IN FAVOR of this policy proposal if for no other 
> reason than to counteract his no vote.

That's not how the PPML works. You don't have a vote and neither
do I, so you're so-called vote doesn't counteract anything.

> In the future perhaps it might occur to certain people that 
> if they don't have time to read and understand certain policy 
> proposal changes that they lack the knowledge to make good 
> policy decisions on them, and should just say nothing and let 
> the folks who do understand a particular proposal to comment on it.

That's not how the PPML works. This list is not just for the elite
who have the spare time to pore over complex policy changes. It is
for everybody with a stake in Internet addressing policy. 
Like a canary in a coal mine, it can be very valuable for the
average reader to pipe up and say, this proposal is just too
complex. This is a valid reason to reject a proposal, and it
is not the only reason that I reject this one. I also have not
seen a clear statement of what problem it is trying to solve.

--Michael Dillon


From mueller at syr.edu  Mon Feb  8 11:06:33 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 8 Feb 2010 11:06:33 -0500
Subject: [arin-ppml] Policy Proposal 109: Standardize
	IP	ReassignmentRegistration Requirements
In-Reply-To: <443de7ad1002050728o39803f20l5cadd1b8d2ef6915@mail.gmail.com>
References: <4B6AF6CE.7000709@arin.net>
	<28E139F46D45AF49A31950F88C4974580513B8BB@E03MVZ2-UKDY.domain1.systemhost.net>,
	<443de7ad1002050728o39803f20l5cadd1b8d2ef6915@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C79C6C81@SUEX07-MBX-04.ad.syr.edu>

This seems like a quite reasonable and well thought out proposal. I especially like the parts about giving users a POC option and eliminating arbitrary status differences between cable operators and other ISPs. 
--MM

1) This policy restructures the reassignment and registration sections
of the IPv4 and IPv6 policies.
        a) The IPv4 section is renamed "registration."
        b) The first section of the IPv4 policy is rewritten for clarity.
        c) The IPv6 policy is totally rewritten in a format that matches the
IPv4 policy.
* These structural changes are meant to make it easier to compare the
two sections. I believe that having the IPv6 and IPv4 policies written
in completely different formats and structures (as they are in many
cases now) confuses the issues and makes it very hard to understand
what is different and what is the same across the two sections.
Bringing them into a similar format should help ease the migration to
IPv6 as folks can quickly and easily understand the differences and
the similarities.

2) This policy adds a definition of "organizational information" which
is used in the existing policy but not currently defined anywhere in
the NRPM.
        a) The definition states that specific addresses are not required for
client organizations but asks that they be included when possible.
        b) The definition states that a POC is required but can be designated
by the client organization - it spells out that the client org can
choose to use their upstream as a POC.
        c) The definition requires that the POC have a valid email address
but only suggests that it include a phone number.
* This definition is meant to address the customer confidentiality
concerns that have been brought up recently (by specifically removing
the requirement to publish client addresses and telephone numbers),
with the smallest negative impact to whois usefulness (retains a valid
POC w/ email contact).

3) This policy takes the privileges granted specifically to IPv4 cable
operators in section 4.2.6. "Cable Address Space Policy" and grants
them to all ISPs who serve residential areas.
        a) It allows all ISPs with residential coverage to
register/swip/rwhois an entire market area.
        b) It retains the existing residential customer privacy policy for
all customers with larger IP blocks.
* This change removes the need for any ISP to enter residential
customers into whois at all.

4) In the text that Scott pointed out (and that will be added), this
policy will also extend the >50% utilization rate currently granted
only to IPv4 cable operators to all ISPs with a residential footprint.
* This change will make it easier for ISPs serving residential areas
to get the addresses they need - this is key for FTTH operators as
well as fixed-wireless and other residential ISPs.

Cheers,
~Chris

From info at arin.net  Tue Feb  9 15:03:06 2010
From: info at arin.net (Member Services)
Date: Tue, 09 Feb 2010 15:03:06 -0500
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
 Registration Requirements - revised
Message-ID: <4B71BF7A.6090107@arin.net>

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.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 109: Standardize IP Reassignment Registration
Requirements

Proposal Version: 2.0

Date: 9 FEB 2010

Proposal type: New

Policy term: Permanent

Policy statement:

## Definitions ##

  - Add:

2.3. Organizational Information

When required, organization Information must include at a minimum:
Legal name, city, state, zip code equivalent and at least one valid
technical or abuse POC; inclusion of street address is highly encouraged.

The POC shall be designated by the organization and must include at
least one verifiable email address, inclusion of a phone number is
highly encouraged.

## IPv4 ##

  - Rename 4.2.3.7. "Reassignment information" to "Registration"

  - Rename 4.2.3.7.1. "Customer organization information" to
"Reassignment Information" and replace text with:

When an organization holding an IPv4 address allocation makes IPv4
address assignments, it must register reassignment information via SWIP
or RWHOIS server. SWIP and RWHOIS reassignments shall include each
client's organizational information, except where specifically exempted
by this policy.

  - Replace 4.2.3.7.6. Residential Customer Privacy with:

4.2.3.7.6. Residential Subscribers

4.2.3.7.6.1. Residential Market Area

In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather than
to individual subscribers. This assignment information regarding each
market area holding an address block should be registered with the
network name used to identify each market area. Initial allocations are
based on total number of homes that could purchase the service in a
given market area. Each assignment to specific end-users holding /29 and
larger blocks still requires registration. In order to obtain additional
IPv4 addresses, ISPs assigning addresses by market area must show, using
reassignment information published in whois, that they have reassigned
at least 80% of their current address space, with a >50% utilization rate.

4.2.3.7.6.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization
with downstream residential customers holding /29 and larger blocks may
substitute that organization's name for the customer's name, e.g.
'Private Customer - XYZ Network', and the customer's street address may
read 'Private Residence'. Each private downstream residential
reassignment must have accurate upstream Abuse and Technical POCs
visible on the WHOIS record for that block.

  - Strike section 4.2.6. "Cable Address Space Policy"

## IPv6 ##

  - Replace Section 6.5.5. with:

6.5.5. Registration

6.5.5.1. Reassignment information

When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register reassignment information in a
database, accessible by RIRs as appropriate (information registered by
an RIR may be replaced by a distributed database for registering address
management information in future). These reassignment registrations
shall include each client's organizational information, except where
specifically exempted by this policy.

6.5.5.2. /56 registered unit

Information is registered in units of assigned /56 networks. When more
than a /56 is assigned to a client organization, the assigning
organization is responsible for ensuring that the address space is
properly registered.

6.5.5.3. Submit within 7 days

Any time an LIR receives a new block of address space, reassignment
information should be submitted within 7 days of issuance of the new space.

6.5.5.4. Visible via WHOIS

This information must be visible via WHOIS prior to submitting a
request for a new allocation. For further information on reassigning IP
address space, please see RFC 2050.

6.5.5.6. Residential Subscribers

6.5.5.6.1. Residential Market Area

In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather than
to individual subscribers. This assignment information regarding each
market area holding an address block should be registered with the
network name used to identify each market area. Initial allocations are
based on total number of homes that could purchase the service in a
given market area. Each assignment to specific end-users holding /56 and
larger blocks still requires registration. In order to obtain additional
IPv6 addresses, ISPs assigning addresses by market area must show, using
reassignment information published in whois, that they have reassigned
at least 80% of their current address space, with a >50% utilization rate.


6.5.5.6.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization
with downstream residential customers holding /56 and larger blocks may
substitute that organization's name for the customer's name, e.g.
'Private Customer - XYZ Network', and the customer's street address may
read 'Private Residence'. Each private downstream residential
reassignment must have accurate upstream Abuse and Technical POCs
visible on the WHOIS record for that block.


Rationale:

#Short Version:
This proposal intends to do several things:
1) Bring IPv4 and IPv6 policy more in line with each other to make the
NRPM easier to understand and comply with - at least as it relates to
reassignment information.
2) Specifically define what organizational information is required to
be added to whois when reassignments are made to client organizations.
3) To specifically state that a client organization may designate the
POC of their choice for any/all whois entries. This includes
designating an upstream POC as their own prefered POC.
4) Expands the priviledges previously reserved solely for IPv4 cable
ISPs to all ISPs/LIRs with residential subscribers.

#Expanded version:
1) This policy restructures the reassignment and registration sections
of the IPv4 and IPv6 policies.
        a) The IPv4 section is renamed "registration."
        b) The first section of the IPv4 policy is rewritten for clarity.
        c) The IPv6 policy is totally rewritten in a format that matches
the IPv4 policy.
* These structural changes are meant to make it easier to compare the
two sections. I believe that having the IPv6 and IPv4 policies written
in completely different formats and structures (as they are in many
cases now) confuses the issues and makes it very hard to understand
what is different and what is the same across the two sections.
Bringing them into a similar format should help ease the migration to
IPv6 as folks can quickly and easily understand the differences and
the similarities.

2) This policy adds a definition of "organizational information" which
is used in the existing policy but not currently defined anywhere in
the NRPM.
        a) The definition states that specific addresses are not
required for
client organizations but asks that they be included when possible.
        b) The definition states that a POC is required but can be
designated
by the client organization - it spells out that the client org can
choose to use their upstream as a POC.
        c) The definition requires that the POC have a valid email
address but only suggests that it include a phone number.
* This definition is meant to address the customer confidentiality
concerns that have been brought up recently (by specifically removing
the requirement to publish client addresses and telephone numbers),
with the smallest negative impact to whois usefulness (retains a valid
POC w/ email contact).

3) This policy takes the privileges granted specifically to IPv4 cable
operators in section 4.2.6. "Cable Address Space Policy" and grants
them to all ISPs who serve residential areas.
        a) It allows all ISPs with residential coverage to
register/swip/rwhois an entire market area.
        b) It retains the existing residential customer privacy policy
for all customers with larger IP blocks.
* This change removes the need for any ISP to enter residential
customers into whois at all.

4) This policy also extends the >50% utilization rate, currently granted
only to IPv4 cable operators, to all ISPs with a residential footprint.
* This change will make it easier for ISPs serving residential areas
to get the addresses they need - this is key for FTTH operators as
well as fixed-wireless and other residential ISPs.

#Specific changes in this version:
1) Sections 4.2.3.7.6.1. and 6.5.5.6.1. have an added sentance: "In
order to obtain additional IPvX addresses, ISPs assigning addresses by
market area must show, using reassignment information published in
whois, that they have reassigned at least 80% of their current address
space, with a >50% utilization rate." Currently this >50% utilization
rate is reserved solely for IPv4 cable operators, this addition
spreads it to all residential ISPs, both IPv4 and IPv6 alike.

2) The last line of section 6.5.5.2. was changed from "...is
registered in an RIR database." to "...is properly registered." To
reflect the fact that RWHOIS and other potential methods of publishing
WHOIS information are not in fact RIR databases.

#Note: Specific mention of SWIP and RWHOIS has been left in the IPv4
policy to avoid complicating this proposal further by rewriting the
entire IPv4 section without any substantive change. The IPv6 policy
has been written to be agnostic concerning the method of publishing
WHOIS information.

Timetable for implementation: Immediate




From owen at delong.com  Wed Feb 10 16:40:23 2010
From: owen at delong.com (Owen DeLong)
Date: Wed, 10 Feb 2010 13:40:23 -0800
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements - revised
In-Reply-To: <4B71BF7A.6090107@arin.net>
References: <4B71BF7A.6090107@arin.net>
Message-ID: <F85ED45D-904C-41ED-9F22-5D7FC2046CC9@delong.com>

I oppose the wording in section 6.5.5.1. The database should be accessible
to more than just the RIRs, it should be accessible to the general internet.

Section 4.2.3.7.1 could use some wordsmithing and there is no reason not
to align the requirements for IPv4 and IPv6.

Suggested replacement:


4.2.3.7.1	Reassignment Information

Each IPv4 assignment containing a /29 or more addresses shall be maintained
in a directory via SWIP or a distributed service which meets the standards set
forth in section 3.2

6.5.5.1	Reassignment information

Each IPv6 assignment containing a /56 or more addresses shall be maintained
in a directory via SWIP or a distributed service which meets the standards set
forth in section 3.2

This would also allow you to delete section 6.5.5.4.

Additionally, I would suggest that we replace sections 4.2.3.7.3 and proposed
section 6.5.5.3 with the following:

4.2.3.7.3	Assignments visible within 7 days

All assignments shall be made visible as required in section 4.2.3.7.1 within
seven calendar days of assignment.

6.5.5.4	Assignments visible within 7 days

All assignments shall be made visible as required in section 6.5.5.1 within
seven calendar days of assignment.

I believe that wording is simpler, provides greater clarity, and, more closely
matches the intent and desires of the community than the existing and proposed
language.

Owen

On Feb 9, 2010, at 12:03 PM, Member Services wrote:

> 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.
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal 109: Standardize IP Reassignment Registration
> Requirements
> 
> Proposal Version: 2.0
> 
> Date: 9 FEB 2010
> 
> Proposal type: New
> 
> Policy term: Permanent
> 
> Policy statement:
> 
> ## Definitions ##
> 
> - Add:
> 
> 2.3. Organizational Information
> 
> When required, organization Information must include at a minimum:
> Legal name, city, state, zip code equivalent and at least one valid
> technical or abuse POC; inclusion of street address is highly encouraged.
> 
> The POC shall be designated by the organization and must include at
> least one verifiable email address, inclusion of a phone number is
> highly encouraged.
> 
> ## IPv4 ##
> 
> - Rename 4.2.3.7. "Reassignment information" to "Registration"
> 
> - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
> 
> When an organization holding an IPv4 address allocation makes IPv4
> address assignments, it must register reassignment information via SWIP
> or RWHOIS server. SWIP and RWHOIS reassignments shall include each
> client's organizational information, except where specifically exempted
> by this policy.
> 
> - Replace 4.2.3.7.6. Residential Customer Privacy with:
> 
> 4.2.3.7.6. Residential Subscribers
> 
> 4.2.3.7.6.1. Residential Market Area
> 
> In most cases, ISPs that have residential subscribers assign address
> space to the infrastructure to which their customers connect rather than
> to individual subscribers. This assignment information regarding each
> market area holding an address block should be registered with the
> network name used to identify each market area. Initial allocations are
> based on total number of homes that could purchase the service in a
> given market area. Each assignment to specific end-users holding /29 and
> larger blocks still requires registration. In order to obtain additional
> IPv4 addresses, ISPs assigning addresses by market area must show, using
> reassignment information published in whois, that they have reassigned
> at least 80% of their current address space, with a >50% utilization rate.
> 
> 4.2.3.7.6.2. Residential Customer Privacy
> 
> To maintain the privacy of their residential customers, an organization
> with downstream residential customers holding /29 and larger blocks may
> substitute that organization's name for the customer's name, e.g.
> 'Private Customer - XYZ Network', and the customer's street address may
> read 'Private Residence'. Each private downstream residential
> reassignment must have accurate upstream Abuse and Technical POCs
> visible on the WHOIS record for that block.
> 
> - Strike section 4.2.6. "Cable Address Space Policy"
> 
> ## IPv6 ##
> 
> - Replace Section 6.5.5. with:
> 
> 6.5.5. Registration
> 
> 6.5.5.1. Reassignment information
> 
> When an organization holding an IPv6 address allocation makes IPv6
> address assignments, it must register reassignment information in a
> database, accessible by RIRs as appropriate (information registered by
> an RIR may be replaced by a distributed database for registering address
> management information in future). These reassignment registrations
> shall include each client's organizational information, except where
> specifically exempted by this policy.
> 
> 6.5.5.2. /56 registered unit
> 
> Information is registered in units of assigned /56 networks. When more
> than a /56 is assigned to a client organization, the assigning
> organization is responsible for ensuring that the address space is
> properly registered.
> 
> 6.5.5.3. Submit within 7 days
> 
> Any time an LIR receives a new block of address space, reassignment
> information should be submitted within 7 days of issuance of the new space.
> 
> 6.5.5.4. Visible via WHOIS
> 
> This information must be visible via WHOIS prior to submitting a
> request for a new allocation. For further information on reassigning IP
> address space, please see RFC 2050.
> 
> 6.5.5.6. Residential Subscribers
> 
> 6.5.5.6.1. Residential Market Area
> 
> In most cases, ISPs that have residential subscribers assign address
> space to the infrastructure to which their customers connect rather than
> to individual subscribers. This assignment information regarding each
> market area holding an address block should be registered with the
> network name used to identify each market area. Initial allocations are
> based on total number of homes that could purchase the service in a
> given market area. Each assignment to specific end-users holding /56 and
> larger blocks still requires registration. In order to obtain additional
> IPv6 addresses, ISPs assigning addresses by market area must show, using
> reassignment information published in whois, that they have reassigned
> at least 80% of their current address space, with a >50% utilization rate.
> 
> 
> 6.5.5.6.2. Residential Customer Privacy
> 
> To maintain the privacy of their residential customers, an organization
> with downstream residential customers holding /56 and larger blocks may
> substitute that organization's name for the customer's name, e.g.
> 'Private Customer - XYZ Network', and the customer's street address may
> read 'Private Residence'. Each private downstream residential
> reassignment must have accurate upstream Abuse and Technical POCs
> visible on the WHOIS record for that block.
> 
> 
> Rationale:
> 
> #Short Version:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to whois when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all whois entries. This includes
> designating an upstream POC as their own prefered POC.
> 4) Expands the priviledges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential subscribers.
> 
> #Expanded version:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
>       a) The IPv4 section is renamed "registration."
>       b) The first section of the IPv4 policy is rewritten for clarity.
>       c) The IPv6 policy is totally rewritten in a format that matches
> the IPv4 policy.
> * These structural changes are meant to make it easier to compare the
> two sections. I believe that having the IPv6 and IPv4 policies written
> in completely different formats and structures (as they are in many
> cases now) confuses the issues and makes it very hard to understand
> what is different and what is the same across the two sections.
> Bringing them into a similar format should help ease the migration to
> IPv6 as folks can quickly and easily understand the differences and
> the similarities.
> 
> 2) This policy adds a definition of "organizational information" which
> is used in the existing policy but not currently defined anywhere in
> the NRPM.
>       a) The definition states that specific addresses are not
> required for
> client organizations but asks that they be included when possible.
>       b) The definition states that a POC is required but can be
> designated
> by the client organization - it spells out that the client org can
> choose to use their upstream as a POC.
>       c) The definition requires that the POC have a valid email
> address but only suggests that it include a phone number.
> * This definition is meant to address the customer confidentiality
> concerns that have been brought up recently (by specifically removing
> the requirement to publish client addresses and telephone numbers),
> with the smallest negative impact to whois usefulness (retains a valid
> POC w/ email contact).
> 
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants
> them to all ISPs who serve residential areas.
>       a) It allows all ISPs with residential coverage to
> register/swip/rwhois an entire market area.
>       b) It retains the existing residential customer privacy policy
> for all customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential
> customers into whois at all.
> 
> 4) This policy also extends the >50% utilization rate, currently granted
> only to IPv4 cable operators, to all ISPs with a residential footprint.
> * This change will make it easier for ISPs serving residential areas
> to get the addresses they need - this is key for FTTH operators as
> well as fixed-wireless and other residential ISPs.
> 
> #Specific changes in this version:
> 1) Sections 4.2.3.7.6.1. and 6.5.5.6.1. have an added sentance: "In
> order to obtain additional IPvX addresses, ISPs assigning addresses by
> market area must show, using reassignment information published in
> whois, that they have reassigned at least 80% of their current address
> space, with a >50% utilization rate." Currently this >50% utilization
> rate is reserved solely for IPv4 cable operators, this addition
> spreads it to all residential ISPs, both IPv4 and IPv6 alike.
> 
> 2) The last line of section 6.5.5.2. was changed from "...is
> registered in an RIR database." to "...is properly registered." To
> reflect the fact that RWHOIS and other potential methods of publishing
> WHOIS information are not in fact RIR databases.
> 
> #Note: Specific mention of SWIP and RWHOIS has been left in the IPv4
> policy to avoid complicating this proposal further by rewriting the
> entire IPv4 section without any substantive change. The IPv6 policy
> has been written to be agnostic concerning the method of publishing
> WHOIS information.
> 
> 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 Scott.Beuker at sjrb.ca  Wed Feb 10 17:06:34 2010
From: Scott.Beuker at sjrb.ca (Scott Beuker)
Date: Wed, 10 Feb 2010 15:06:34 -0700
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements - revised
In-Reply-To: <4B71BF7A.6090107@arin.net>
References: <4B71BF7A.6090107@arin.net>
Message-ID: <1EA76BAD7F050648910C041BDDED8CD5155EC4@PRDCG4EXVW01-5.OSS.PRD>

I oppose this proposal. It could have significant consequences for the
IPv4 free pool.

Furthermore, there's too much going on here in one proposal, these
changes should be broken out into multiple proposals based on what it is
they hope to accomplish so that we can address them individually.

The new '4.2.3.7.6.1. Residential Market Area', as I read it, lowers the
requirement for IPv4 address space from 80% utilization to 50%
utilization for all ISPs (if they so choose)... which means we could
suddenly see some of ARINs larger users of IPv4 addresses instantly
qualified to increase their unused space by ~60% overnight, without any
technical merit.

It also makes the NRPM self-contradictory, as I don't see what would
distinguish the applicability of this new utilization requirement versus
'4.2.4.1' to an ISP, other than an arbitrary decision by the ISP
themselves. Similarly for IPv6, '6.5.5.6.1' would seem to me to
contradict '6.5.2' and the HD-ratio concept for IPv6 (which is good
policy I might add).

It's too late in the game for moves like this that grant many large
organizations much more IP space; we can only afford to be more
restrictive. If you have an issue with 4.2.6, address it directly and in
its own policy proposal. And be up front about what it is you aim to
accomplish. Tip: assume it was put there for a reason, and start from
there.

If you force me to vote on a proposal like this that has changes I like,
and changes I do not like, I'm going to vote "no" and then wait for you
to correct the problem.

Thanks,
Scott Beuker


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of Member Services
> Sent: Tuesday, February 09, 2010 1:03 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
> Registration Requirements - revised
> 
> 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.
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Policy Proposal 109: Standardize IP Reassignment Registration
> Requirements
> 
> Proposal Version: 2.0
> 
> Date: 9 FEB 2010
> 
> Proposal type: New
> 
> Policy term: Permanent
> 
> Policy statement:
> 
> ## Definitions ##
> 
>   - Add:
> 
> 2.3. Organizational Information
> 
> When required, organization Information must include at a minimum:
> Legal name, city, state, zip code equivalent and at least one valid
> technical or abuse POC; inclusion of street address is highly
> encouraged.
> 
> The POC shall be designated by the organization and must include at
> least one verifiable email address, inclusion of a phone number is
> highly encouraged.
> 
> ## IPv4 ##
> 
>   - Rename 4.2.3.7. "Reassignment information" to "Registration"
> 
>   - Rename 4.2.3.7.1. "Customer organization information" to
> "Reassignment Information" and replace text with:
> 
> When an organization holding an IPv4 address allocation makes IPv4
> address assignments, it must register reassignment information via
SWIP
> or RWHOIS server. SWIP and RWHOIS reassignments shall include each
> client's organizational information, except where specifically
exempted
> by this policy.
> 
>   - Replace 4.2.3.7.6. Residential Customer Privacy with:
> 
> 4.2.3.7.6. Residential Subscribers
> 
> 4.2.3.7.6.1. Residential Market Area
> 
> In most cases, ISPs that have residential subscribers assign address
> space to the infrastructure to which their customers connect rather
than
> to individual subscribers. This assignment information regarding each
> market area holding an address block should be registered with the
> network name used to identify each market area. Initial allocations
are
> based on total number of homes that could purchase the service in a
> given market area. Each assignment to specific end-users holding /29
and
> larger blocks still requires registration. In order to obtain
additional
> IPv4 addresses, ISPs assigning addresses by market area must show,
using
> reassignment information published in whois, that they have reassigned
> at least 80% of their current address space, with a >50% utilization
> rate.
> 
> 4.2.3.7.6.2. Residential Customer Privacy
> 
> To maintain the privacy of their residential customers, an
organization
> with downstream residential customers holding /29 and larger blocks
may
> substitute that organization's name for the customer's name, e.g.
> 'Private Customer - XYZ Network', and the customer's street address
may
> read 'Private Residence'. Each private downstream residential
> reassignment must have accurate upstream Abuse and Technical POCs
> visible on the WHOIS record for that block.
> 
>   - Strike section 4.2.6. "Cable Address Space Policy"
> 
> ## IPv6 ##
> 
>   - Replace Section 6.5.5. with:
> 
> 6.5.5. Registration
> 
> 6.5.5.1. Reassignment information
> 
> When an organization holding an IPv6 address allocation makes IPv6
> address assignments, it must register reassignment information in a
> database, accessible by RIRs as appropriate (information registered by
> an RIR may be replaced by a distributed database for registering
address
> management information in future). These reassignment registrations
> shall include each client's organizational information, except where
> specifically exempted by this policy.
> 
> 6.5.5.2. /56 registered unit
> 
> Information is registered in units of assigned /56 networks. When more
> than a /56 is assigned to a client organization, the assigning
> organization is responsible for ensuring that the address space is
> properly registered.
> 
> 6.5.5.3. Submit within 7 days
> 
> Any time an LIR receives a new block of address space, reassignment
> information should be submitted within 7 days of issuance of the new
> space.
> 
> 6.5.5.4. Visible via WHOIS
> 
> This information must be visible via WHOIS prior to submitting a
> request for a new allocation. For further information on reassigning
IP
> address space, please see RFC 2050.
> 
> 6.5.5.6. Residential Subscribers
> 
> 6.5.5.6.1. Residential Market Area
> 
> In most cases, ISPs that have residential subscribers assign address
> space to the infrastructure to which their customers connect rather
than
> to individual subscribers. This assignment information regarding each
> market area holding an address block should be registered with the
> network name used to identify each market area. Initial allocations
are
> based on total number of homes that could purchase the service in a
> given market area. Each assignment to specific end-users holding /56
and
> larger blocks still requires registration. In order to obtain
additional
> IPv6 addresses, ISPs assigning addresses by market area must show,
using
> reassignment information published in whois, that they have reassigned
> at least 80% of their current address space, with a >50% utilization
> rate.
> 
> 
> 6.5.5.6.2. Residential Customer Privacy
> 
> To maintain the privacy of their residential customers, an
organization
> with downstream residential customers holding /56 and larger blocks
may
> substitute that organization's name for the customer's name, e.g.
> 'Private Customer - XYZ Network', and the customer's street address
may
> read 'Private Residence'. Each private downstream residential
> reassignment must have accurate upstream Abuse and Technical POCs
> visible on the WHOIS record for that block.
> 
> 
> Rationale:
> 
> #Short Version:
> This proposal intends to do several things:
> 1) Bring IPv4 and IPv6 policy more in line with each other to make the
> NRPM easier to understand and comply with - at least as it relates to
> reassignment information.
> 2) Specifically define what organizational information is required to
> be added to whois when reassignments are made to client organizations.
> 3) To specifically state that a client organization may designate the
> POC of their choice for any/all whois entries. This includes
> designating an upstream POC as their own prefered POC.
> 4) Expands the priviledges previously reserved solely for IPv4 cable
> ISPs to all ISPs/LIRs with residential subscribers.
> 
> #Expanded version:
> 1) This policy restructures the reassignment and registration sections
> of the IPv4 and IPv6 policies.
>         a) The IPv4 section is renamed "registration."
>         b) The first section of the IPv4 policy is rewritten for
> clarity.
>         c) The IPv6 policy is totally rewritten in a format that
matches
> the IPv4 policy.
> * These structural changes are meant to make it easier to compare the
> two sections. I believe that having the IPv6 and IPv4 policies written
> in completely different formats and structures (as they are in many
> cases now) confuses the issues and makes it very hard to understand
> what is different and what is the same across the two sections.
> Bringing them into a similar format should help ease the migration to
> IPv6 as folks can quickly and easily understand the differences and
> the similarities.
> 
> 2) This policy adds a definition of "organizational information" which
> is used in the existing policy but not currently defined anywhere in
> the NRPM.
>         a) The definition states that specific addresses are not
> required for
> client organizations but asks that they be included when possible.
>         b) The definition states that a POC is required but can be
> designated
> by the client organization - it spells out that the client org can
> choose to use their upstream as a POC.
>         c) The definition requires that the POC have a valid email
> address but only suggests that it include a phone number.
> * This definition is meant to address the customer confidentiality
> concerns that have been brought up recently (by specifically removing
> the requirement to publish client addresses and telephone numbers),
> with the smallest negative impact to whois usefulness (retains a valid
> POC w/ email contact).
> 
> 3) This policy takes the privileges granted specifically to IPv4 cable
> operators in section 4.2.6. "Cable Address Space Policy" and grants
> them to all ISPs who serve residential areas.
>         a) It allows all ISPs with residential coverage to
> register/swip/rwhois an entire market area.
>         b) It retains the existing residential customer privacy policy
> for all customers with larger IP blocks.
> * This change removes the need for any ISP to enter residential
> customers into whois at all.
> 
> 4) This policy also extends the >50% utilization rate, currently
granted
> only to IPv4 cable operators, to all ISPs with a residential
footprint.
> * This change will make it easier for ISPs serving residential areas
> to get the addresses they need - this is key for FTTH operators as
> well as fixed-wireless and other residential ISPs.
> 
> #Specific changes in this version:
> 1) Sections 4.2.3.7.6.1. and 6.5.5.6.1. have an added sentance: "In
> order to obtain additional IPvX addresses, ISPs assigning addresses by
> market area must show, using reassignment information published in
> whois, that they have reassigned at least 80% of their current address
> space, with a >50% utilization rate." Currently this >50% utilization
> rate is reserved solely for IPv4 cable operators, this addition
> spreads it to all residential ISPs, both IPv4 and IPv6 alike.
> 
> 2) The last line of section 6.5.5.2. was changed from "...is
> registered in an RIR database." to "...is properly registered." To
> reflect the fact that RWHOIS and other potential methods of publishing
> WHOIS information are not in fact RIR databases.
> 
> #Note: Specific mention of SWIP and RWHOIS has been left in the IPv4
> policy to avoid complicating this proposal further by rewriting the
> entire IPv4 section without any substantive change. The IPv6 policy
> has been written to be agnostic concerning the method of publishing
> WHOIS information.
> 
> 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 farmer at umn.edu  Fri Feb 12 09:44:09 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 12 Feb 2010 08:44:09 -0600
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the	NRPM
In-Reply-To: <4B698066.6010604@chl.com>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com>
Message-ID: <4B756939.2000206@umn.edu>

Joe Maimon wrote:
> I support this policy proposal, as it conforms to my viewpoint that 
> numbers cannot confer rights of property in any way, allocations are 
> only an entry in a database operated and owned by a registrar and any 
> impact registrars have on the configuration of routers and hosts and the 
> operating of networks is due to consensus and not force of law.
> 
> While my viewpoint would favor stronger language on the subject than is 
> contained in the proposal, it is a significant step in the right direction.

How would you suggest we make the language stronger?  I believe the 
language is fairly strong already, but I'm willing to consider 
suggestions you might have.

The idea was to clearly state that number resource are not property and 
that the RSA and the policies in the NRPM are in control of how number 
resource are allocated and assigned.

In my view the NRPM shouldn't should like a contract, that kind of 
language generally belongs in the RSA.  But this is an important enough 
concept that having it stated in both the NRPM and the RSA makes sense.

This got started because of section 6.4.1 currently in the NRPM and 
especially its use of the term license.  So, at almost the last minute, 
I though of searching the NRPM for any other uses of the term license, 
and found the one in 11.4 too.  It seemed that it could be eliminated 
without a complete rewrite of that section.  This change to 11.4 could 
probably have been made as a editorial change, but since 6.4.1 needed a 
complete rewrite and such a change needed to go through the PDP, it 
seemed appropriate to tack this additional simple change on to that process.

This is on a fast track to try to make it on to the Toronto meeting 
agenda, so any suggestions you might have would be appreciated by early 
to the middle of next week.

> Thanks David.
> 
> Joe
> 
> 
> 
> 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.
>>
>> Draft Policies and Proposals under discussion can be found 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
>>
>> 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 108: Eliminate the term license in the NRPM
>>
>> Proposal Originator: David Farmer
>>
>> Proposal Version: 1.0
>>
>> Date: 2 February 2010
>>
>> Proposal type: modify
>>
>> Policy term: Permanent
>>
>> Policy statement:
>>
>> Delete section 6.4.1 and replace with a new section;
>>
>> 1.1 Number resources are not property
>>
>> To serve the interests of the Internet community as a whole, number
>> resources are not property (real, personal, or intellectual). The
>> allocation and assignment of IP addresses, ASNs, and other number
>> resources are subject to the terms of the ARIN Registration Services
>> Agreement, the policies in this document, and any amendments as may be
>> made to either one.
>>
>> Modify section 11.4 by removing ?on a lease/license basis?, leaving the
>> following;
>>
>> 11.4 Resource Allocation Term and Renewal
>>
>> The Numbering Resources are allocated for a period of one year. The
>> allocation can be renewed on application to ARIN providing information
>> as per Detail One. The identity and details of the applicant and the
>> allocated Numbering Resources will be published under the conditions of
>> ARIN's normal publication policy. At the end of the experiment,
>> resources allocated under this policy will be returned to the available
>> pool.
>>
>> Rationale:
>>
>> As part of the discussion of Policy Proposal #106 the issue of the use
>> of the term ?license? in section 6.4.1 and that it is not likely in
>> harmony with the ARIN Registration Services Agreement was recognized.
>> The AC feels that this issue is important enough to make it a separate
>> Draft Policy that stands on its own.
>>
>> This section could not be fixed by simple editorial changes and it
>> requires a complete rewrite in order to fix the issues. It was further
>> recognized that the concept that ?Number resources are not property? is
>> not exclusively an IPv6 issue and should be moved out of section 6, so
>> that it is clear that it applies to all number resources.
>>
>> Finally, the rest of the NRPM was searched for any additional uses of
>> the term ?license?. One additional use was found in section 11.4, in
>> this case deleting it and a few other words surrounding it, fixes the
>> issue without significantly changing the meaning of the section.
>>
>> 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
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================


From michael.dillon at bt.com  Fri Feb 12 11:30:47 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 12 Feb 2010 16:30:47 -0000
Subject: [arin-ppml] Policy Proposal 109: Standardize IP
	ReassignmentRegistration Requirements - revised
In-Reply-To: <F85ED45D-904C-41ED-9F22-5D7FC2046CC9@delong.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805271599@E03MVZ2-UKDY.domain1.systemhost.net>

> I oppose the wording in section 6.5.5.1. The database should 
> be accessible to more than just the RIRs, it should be 
> accessible to the general internet.

We really should try to tighten up on the wording in areas
like this, just as we make a distinction between assign
and allocate, even though the two words are synonymous in
general usage.

Can we use the term "database" only to refer to something
that stores data, and use the term "directory" for something
that is published? 

Then we can say that some providers use SWIP to update
ARIN's registration database, others use the web portal.
When adding a record to the registration database, 
people must indicate whether or not it is to be published
in the whois directory. This directory is refreshed daily
from the registration data. The directory can be queried
via whois protocol or through ARIN's website, and for
certain uses, ARIN will make the entire directory available
for bulk download.

Then we can have policy that talks about various databases
that can be kept separate from policy that talks about various
directories.

--Michael Dillon


From rudi.daniel at gmail.com  Fri Feb 12 12:40:43 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Fri, 12 Feb 2010 13:40:43 -0400
Subject: [arin-ppml] ARIN-PPML Digest, Vol 56, Issue 41
In-Reply-To: <mailman.3.1265994001.18692.arin-ppml@arin.net>
References: <mailman.3.1265994001.18692.arin-ppml@arin.net>
Message-ID: <8aeeaff61002120940w1fdc1863tb8b2c7395ed2792e@mail.gmail.com>

I support this policy proposal in principle, however I am undecided on the
wording. Example: I want to query the use of the word "normal"  in favor of
" publication policy" . Does the use of the word "normal" invite questions
about what is normal and what is not, in the event of future changes in
publication policies?
RD


Joe Maimon wrote:
> > I support this policy proposal, as it conforms to my viewpoint that
> > numbers cannot confer rights of property in any way, allocations are
> > only an entry in a database operated and owned by a registrar and any
> > impact registrars have on the configuration of routers and hosts and the
> > operating of networks is due to consensus and not force of law.
> >
> > While my viewpoint would favor stronger language on the subject than is
> > contained in the proposal, it is a significant step in the right
> direction.
>
> How would you suggest we make the language stronger?  I believe the
> language is fairly strong already, but I'm willing to consider
> suggestions you might have.
>
> The idea was to clearly state that number resource are not property and
> that the RSA and the policies in the NRPM are in control of how number
> resource are allocated and assigned.
>
> In my view the NRPM shouldn't should like a contract, that kind of
> language generally belongs in the RSA.  But this is an important enough
> concept that having it stated in both the NRPM and the RSA makes sense.
>
> This got started because of section 6.4.1 currently in the NRPM and
> especially its use of the term license.  So, at almost the last minute,
> I though of searching the NRPM for any other uses of the term license,
> and found the one in 11.4 too.  It seemed that it could be eliminated
> without a complete rewrite of that section.  This change to 11.4 could
> probably have been made as a editorial change, but since 6.4.1 needed a
> complete rewrite and such a change needed to go through the PDP, it
> seemed appropriate to tack this additional simple change on to that
> process.
>
> This is on a fast track to try to make it on to the Toronto meeting
> agenda, so any suggestions you might have would be appreciated by early
> to the middle of next week.
>
> > Thanks David.
> >
> > Joe
> >
> >
> >
> > 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.
> >>
> >> Draft Policies and Proposals under discussion can be found 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
> >>
> >> 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 108: Eliminate the term license in the NRPM
> >>
> >> Proposal Originator: David Farmer
> >>
> >> Proposal Version: 1.0
> >>
> >> Date: 2 February 2010
> >>
> >> Proposal type: modify
> >>
> >> Policy term: Permanent
> >>
> >> Policy statement:
> >>
> >> Delete section 6.4.1 and replace with a new section;
> >>
> >> 1.1 Number resources are not property
> >>
> >> To serve the interests of the Internet community as a whole, number
> >> resources are not property (real, personal, or intellectual). The
> >> allocation and assignment of IP addresses, ASNs, and other number
> >> resources are subject to the terms of the ARIN Registration Services
> >> Agreement, the policies in this document, and any amendments as may be
> >> made to either one.
> >>
> >> Modify section 11.4 by removing ?on a lease/license basis?, leaving the
> >> following;
> >>
> >> 11.4 Resource Allocation Term and Renewal
> >>
> >> The Numbering Resources are allocated for a period of one year. The
> >> allocation can be renewed on application to ARIN providing information
> >> as per Detail One. The identity and details of the applicant and the
> >> allocated Numbering Resources will be published under the conditions of
> >> ARIN's normal publication policy. At the end of the experiment,
> >> resources allocated under this policy will be returned to the available
> >> pool.
> >>
> >> Rationale:
> >>
> >> As part of the discussion of Policy Proposal #106 the issue of the use
> >> of the term ?license? in section 6.4.1 and that it is not likely in
> >> harmony with the ARIN Registration Services Agreement was recognized.
> >> The AC feels that this issue is important enough to make it a separate
> >> Draft Policy that stands on its own.
> >>
> >> This section could not be fixed by simple editorial changes and it
> >> requires a complete rewrite in order to fix the issues. It was further
> >> recognized that the concept that ?Number resources are not property? is
> >> not exclusively an IPv6 issue and should be moved out of section 6, so
> >> that it is clear that it applies to all number resources.
> >>
> >> Finally, the rest of the NRPM was searched for any additional uses of
> >> the term ?license?. One additional use was found in section 11.4, in
> >> this case deleting it and a few other words surrounding it, fixes the
> >> issue without significantly changing the meaning of the section.
> >>
> >> 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 <Email%3Afarmer at umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE      Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 12 Feb 2010 16:30:47 -0000
> From: <michael.dillon at bt.com>
> To: <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Policy Proposal 109: Standardize IP
>        ReassignmentRegistration Requirements - revised
> Message-ID:
>        <
> 28E139F46D45AF49A31950F88C49745805271599 at E03MVZ2-UKDY.domain1.systemhost.net
> >
>
> Content-Type: text/plain;       charset="us-ascii"
>
> > I oppose the wording in section 6.5.5.1. The database should
> > be accessible to more than just the RIRs, it should be
> > accessible to the general internet.
>
> We really should try to tighten up on the wording in areas
> like this, just as we make a distinction between assign
> and allocate, even though the two words are synonymous in
> general usage.
>
> Can we use the term "database" only to refer to something
> that stores data, and use the term "directory" for something
> that is published?
>
> Then we can say that some providers use SWIP to update
> ARIN's registration database, others use the web portal.
> When adding a record to the registration database,
> people must indicate whether or not it is to be published
> in the whois directory. This directory is refreshed daily
> from the registration data. The directory can be queried
> via whois protocol or through ARIN's website, and for
> certain uses, ARIN will make the entire directory available
> for bulk download.
>
> Then we can have policy that talks about various databases
> that can be kept separate from policy that talks about various
> directories.
>
> --Michael Dillon
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 56, Issue 41
> *****************************************
>



-- 
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
?The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.? - Bertrand
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100212/349efd37/attachment.htm>

From bill at herrin.us  Fri Feb 12 12:43:24 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 12 Feb 2010 12:43:24 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
	the NRPM
In-Reply-To: <4B683AAD.4020502@arin.net>
References: <4B683AAD.4020502@arin.net>
Message-ID: <3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>

On Tue, Feb 2, 2010 at 9:46 AM, Member Services <info at arin.net> wrote:
> Policy Proposal 108: Eliminate the term license in the NRPM

David.

Unless this proposal was instigated at counsel's request, you may want
to consider letting sleeping dogs lie. The US has a public policy
tradition dating back to before there was a US that anything of value
can and should be ownable and owned by everyday citizens. ARIN
practice is out of step with that tradition.

You may have heard that there's a high-stakes free pool depletion
crisis looming on the horizon. Now may not be the best time to reopen
Pandora's box.

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 jmaimon at chl.com  Fri Feb 12 13:10:06 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 12 Feb 2010 13:10:06 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the	NRPM
In-Reply-To: <4B756939.2000206@umn.edu>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com>
	<4B756939.2000206@umn.edu>
Message-ID: <4B75997E.2030804@chl.com>



David Farmer wrote:
> Joe Maimon wrote:
>> While my viewpoint would favor stronger language on the subject than 
>> is contained in the proposal, it is a significant step in the right 
>> direction.
>
> How would you suggest we make the language stronger?  I believe the 
> language is fairly strong already, but I'm willing to consider 
> suggestions you might have.

Thats a generous offer. So here goes.

>>>
>>>
>>> Delete section 6.4.1 and replace with a new section;
>>>
>>> 1.1 Number resources are not property
>>>
>>> To serve the interests of the Internet community as a whole, number
>>> resources are not property (real, personal, or intellectual). The
>>> allocation and assignment of IP addresses, ASNs, and other number
>>> resources are subject to the terms of the ARIN Registration Services
>>> Agreement, the policies in this document, and any amendments as may be
>>> made to either one.
>>>

To serve the interests of the Internet community as a whole, while 
number resources are not to be considered property (real, personal, or 
intellectual) of any sort, ARIN provides number resources in the form of 
recording allocations and assignments in its function as a Regional 
Internet Registry. The allocations and assignments are a service subject 
solely to the terms of the ARIN Registration Services Agreement, the 
policies in this document, and any amendments as may be made to either one.


>>> Modify section 11.4 by removing ?on a lease/license basis?, leaving the
>>> following;
>>>
>>> 11.4 Resource Allocation Term and Renewal
>>>
>>> The Numbering Resources are allocated for a period of one year. The
>>> allocation can be renewed on application to ARIN providing information
>>> as per Detail One. The identity and details of the applicant and the
>>> allocated Numbering Resources will be published under the conditions of
>>> ARIN's normal publication policy. At the end of the experiment,
>>> resources allocated under this policy will be returned to the available
>>> pool.

The Numbering Resources, consisting of an ARIN recorded allocation, are 
for a period of one year. The resources can be renewed on application to 
ARIN providing information as per Detail One. The identity and details 
of the applicant and the allocated Numbering Resources will be published 
under the conditions of ARIN's normal publication policy. At the end of 
the experiment, resources allocated under this policy will be returned 
to the available pool.

>>>
>>> Rationale:
>>>
Recasting allocations and assignments clearly as a service without any 
property rights, real or implied, governed solely by the PDP and RSA and 
not subject to any property or intellectual property or similar 
jurisdictions is actually a net benefit to ARIN and its community as well.




From jmaimon at chl.com  Fri Feb 12 13:31:06 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Fri, 12 Feb 2010 13:31:06 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
References: <4B683AAD.4020502@arin.net>
	<3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
Message-ID: <4B759E6A.30403@chl.com>



William Herrin wrote:
> On Tue, Feb 2, 2010 at 9:46 AM, Member Services<info at arin.net>  wrote:
>> Policy Proposal 108: Eliminate the term license in the NRPM
>
> David.
>
> Unless this proposal was instigated at counsel's request, you may want
> to consider letting sleeping dogs lie. The US has a public policy
> tradition dating back to before there was a US that anything of value
> can and should be ownable and owned by everyday citizens. ARIN
> practice is out of step with that tradition.
>
> You may have heard that there's a high-stakes free pool depletion
> crisis looming on the horizon. Now may not be the best time to reopen
> Pandora's box.
>
> Regards,
> Bill Herrin
>


I vehemently disagree. In this context the value of the numerical exists 
solely due to consensus of uniqueness.

Consensus is not property.

Private property is private. Numbers in abstract cannot be owned. The 
value in allocations lies in the database entry and the general 
willingness of non-contractually bound third parties to adhere to the 
database contents, as a consensus.

Entries in private databases cannot be owned by other private parties 
without grant of ownership. Numbers in use by people on their privately 
owned networks cannot be viewed as private property of any other entity. 
Networks do not have to respect these non-existent property rights.

Making this clear is in the best interest of all.

Tortious interference and any other torturous legal theories may apply, 
but this has always been my understanding of the situation.

Joe



From stephen at sprunk.org  Fri Feb 12 13:34:39 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 12 Feb 2010 12:34:39 -0600
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
References: <4B683AAD.4020502@arin.net>
	<3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
Message-ID: <4B759F3F.4080005@sprunk.org>

On 12 Feb 2010 11:43, William Herrin wrote:
> On Tue, Feb 2, 2010 at 9:46 AM, Member Services <info at arin.net> wrote:
>   
>> Policy Proposal 108: Eliminate the term license in the NRPM
>>     
> David.
>
> Unless this proposal was instigated at counsel's request, you may want
> to consider letting sleeping dogs lie.

Agreed.  ARIN has excellent counsel and attempting to do his job for him
is a waste of both our time and his.  If he doesn't have a problem with
the existing policy, few if any of us on PPML are qualified to
second-guess him.

If this proposal _was_ requested by counsel, that should be clearly
stated in the text so that folks can view it in the appropriate light
when considering whether to support or oppose it.

> The US has a public policy tradition dating back to before there was a US that anything of value can and should be ownable and owned by everyday citizens.

Such as human beings?  Not all traditions are good ones.

> ARIN practice is out of step with that tradition.
>   

I don't see it that way.  Numbers are "facts of nature" and one _cannot_
own them (though some fraudsters might try to convince you otherwise to
make a quick buck).  What ARIN deals with are slots in a registration
database, and as the owner of that database ARIN can do whatever it
wants with those slots.  If a property owner decides to rent its
property out rather than sell it, that doesn't contradict public policy
in any way.  In fact, this is perfectly in line with how one (in effect,
if not precisely) rents ZIP codes, phone numbers, radio frequencies,
Social Security Numbers, etc.

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/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100212/fbe0eb2e/attachment.p7s>

From michael.dillon at bt.com  Fri Feb 12 13:46:56 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 12 Feb 2010 18:46:56 -0000
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license
	inthe NRPM
In-Reply-To: <3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C497458052716A5@E03MVZ2-UKDY.domain1.systemhost.net>


> Unless this proposal was instigated at counsel's request, you 
> may want to consider letting sleeping dogs lie. The US has a 
> public policy tradition dating back to before there was a US 
> that anything of value can and should be ownable and owned by 
> everyday citizens. ARIN practice is out of step with that tradition.

Which range of addresses do you propose to hand over to Canada
as our private property for the exclusive use of Canadian companies
operating in Canada. We expect you to sign over ownership of
about 10% of all ARIN's allocation given that the population of
Canada is roughly 10% that of the USA.

You can expect our government to make this a formal request to
the President, as soon as ARIN has firmed up plans for turning
IP addresses into private property, as God made them to be.

--Michael Dillon, 
Canadian citizen and founder of the CARIN' project.
The Canadian Association for the Registration of Internet Numbers
does ARIN "one" better, for carin' Canadians. Inuktitut translators
wanted for our trilingual charter.

P.S. If you don't believe that ARIN will retreat from the
position that IP addresses are private property, then you
can ignore the above, or treat it as a little northern 
humour. 


From bill at herrin.us  Fri Feb 12 14:19:08 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 12 Feb 2010 14:19:08 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
	the NRPM
In-Reply-To: <4B759E6A.30403@chl.com>
References: <4B683AAD.4020502@arin.net>
	<3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com> 
	<4B759E6A.30403@chl.com>
Message-ID: <3c3e3fca1002121119u7b7b22a2qed92c218b1ad6a3e@mail.gmail.com>

On Fri, Feb 12, 2010 at 1:31 PM, Joe Maimon <jmaimon at chl.com> wrote:
> William Herrin wrote:
>> Unless this proposal was instigated at counsel's request, you may want
>> to consider letting sleeping dogs lie. The US has a public policy
>> tradition dating back to before there was a US that anything of value
>> can and should be ownable and owned by everyday citizens. ARIN
>> practice is out of step with that tradition.
>>
>> You may have heard that there's a high-stakes free pool depletion
>> crisis looming on the horizon. Now may not be the best time to reopen
>> Pandora's box.
>
> I vehemently disagree. In this context the value of the numerical exists
> solely due to consensus of uniqueness.


As much as I'd like to jump in to the argument, I think you've
demonstrated my point: this area of policy is a Pandora's box which,
at least for now, is best left closed.

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 farmer at umn.edu  Fri Feb 12 16:51:40 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 12 Feb 2010 15:51:40 -0600
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <3c3e3fca1002121119u7b7b22a2qed92c218b1ad6a3e@mail.gmail.com>
References: <4B683AAD.4020502@arin.net>	<3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
	<4B759E6A.30403@chl.com>
	<3c3e3fca1002121119u7b7b22a2qed92c218b1ad6a3e@mail.gmail.com>
Message-ID: <4B75CD6C.9000304@umn.edu>

William Herrin wrote:
> On Fri, Feb 12, 2010 at 1:31 PM, Joe Maimon <jmaimon at chl.com> wrote:
>> William Herrin wrote:
>>> Unless this proposal was instigated at counsel's request, you may want
>>> to consider letting sleeping dogs lie. The US has a public policy
>>> tradition dating back to before there was a US that anything of value
>>> can and should be ownable and owned by everyday citizens. ARIN
>>> practice is out of step with that tradition.
>>>
>>> You may have heard that there's a high-stakes free pool depletion
>>> crisis looming on the horizon. Now may not be the best time to reopen
>>> Pandora's box.
>> I vehemently disagree. In this context the value of the numerical exists
>> solely due to consensus of uniqueness.
> 
> 
> As much as I'd like to jump in to the argument, I think you've
> demonstrated my point: this area of policy is a Pandora's box which,
> at least for now, is best left closed.
> 
> Regards,
> Bill Herrin

I do not want to open Pandora's box either. I'm trying not to, and I 
don't think we are.  6.4.1 says that number resource are not property, 
the RSA says that number resource are not property, this says number 
resource are not property. It uses language that is almost a direct 
quote from the RSA.

The issue that this intends to resolve is that the use of the term 
"license" in section 6.4.1.  The intent was to rewrite 6.4.1 using 
language in harmony with the RSA. I need to let Counsel or John Curran 
provide any legal opinion, but I will say that Counsel has been involved 
in the process, from the beginning.  As the shepherd for PP#106, once 
this issue came up on PPML, I requested input from Staff and Counsel 
regarding this issue.

I do not think this opens a debate on the issue of Number Resource being 
Property, all of the texts involved here says they are NOT, this is 
completely consistent.  The only thing this opens is how we are saying 
that they are not property.

If we were to simply delete 6.4.1 then nothing in the NRPM would say 
that Number Resource are not Property. It is arguable that doing so 
could create a conflict between the NRPM and the RSA, that would be 
opening Pandora's box if you ask me.  I also believe it is clear to most 
people that the language in 6.4.1 is out dated, ARIN provides Services 
and not Licenses.

Finally, it is inconceivableness to me how 6.4.1 could be changed in a 
way that one could realistically say it is only a simple editorial 
change like what is being proposed for section 11.4.  Therefore, even 
though I don't think this language changes the policy intent, I believe 
it is necessary for a change of this extent in the language to go 
through the PDP process.

----


 From RSA: Version 10.0 (17 February 2009)

9. NO PROPERTY RIGHTS
Applicant acknowledges and agrees that the number resources are not 
property (real, personal, or intellectual) and that Applicant does not 
acquire any property rights in or to any number resources by virtue of 
this Agreement or otherwise.  Applicant further agrees that it will not 
attempt, directly or indirectly, to obtain or assert any trademark, 
service mark, copyright, or any other form of property rights in any 
number resources in the United States or any other country.

----

 From NRPM: Version 2010.1 - 13 January 2010

6.4.1. Address space not to be considered property

It is contrary to the goals of this document and is not in the interests 
of the Internet community as a whole for address space to be considered 
freehold property.

The policies in this document are based upon the understanding that 
globally-unique IPv6 unicast address space is licensed for use rather 
than owned. Specifically, IP addresses will be allocated and assigned on 
a license basis, with licenses subject to renewal on a periodic basis. 
The granting of a license is subject to specific conditions applied at 
the start or renewal of the license.

RIRs will generally renew licenses automatically, provided requesting 
organizations are making a good-faith effort at meeting the criteria 
under which they qualified for or were granted an allocation or 
assignment. However, in those cases where a requesting organization is 
not using the address space as intended, or is showing bad faith in 
following through on the associated obligation, RIRs reserve the right 
to not renew the license.

Note that when a license is renewed, the new license will be evaluated 
under and governed by the applicable IPv6 address policies in place at 
the time of renewal, which may differ from the policy in place at the 
time of the original allocation or assignment.

----

Proposed language: Policy Proposal #108

1.1 Number resources are not property

To serve the interests of the Internet community as a whole, number
resources are not property (real, personal, or intellectual). The
allocation and assignment of IP addresses, ASNs, and other number
resources are subject to the terms of the ARIN Registration Services
Agreement, the policies in this document, and any amendments as may be
made to either one.

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


From mueller at syr.edu  Fri Feb 12 16:59:06 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 12 Feb 2010 16:59:06 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the	NRPM
In-Reply-To: <4B756939.2000206@umn.edu>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com>
	<4B756939.2000206@umn.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB3854@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 David Farmer

>> 1.1 Number resources are not property
>>
>> To serve the interests of the Internet community as a whole, number
>> resources are not property (real, personal, or intellectual). The
>> allocation and assignment of IP addresses, ASNs, and other number
>> resources are subject to the terms of the ARIN Registration Services
>> Agreement, the policies in this document, and any amendments as may be
>> made to either one.

David:
What is the purpose of this? What does it accomplish technically, legally, politically or economically? How does it make IP addresses and routing function better? Does it make addresses more abundant, easier to use, etc.? 

The concept of "property" and "property rights" is far more flexible and much less dichotomous that you seem to understand. Radio spectrum has been declared a "public resource" since 1927 and the notion that they are "property" has attracted angry denunciations from Congresscritters and others for decades after. But anyone who understands what actually goes on in licensed spectrum and applies well-established and useful ways of thinking drawn from economics and law knows that the assignment of a license is in fact a grant of exclusivity, one that allows the person so granted to economically exploit the resource in regulated and conditioned ways, and which (in the case of spectrum) allows the grantee to sell the right, and thus qualifies in economic theory as a property right. The same is true of IP addresses, except that some people have an irrational fetish against the transfer of the resource for money (which of course doesn't stop it from happening routinely). 

Oliver Williamson just received the Nobel Prize for his analysis of how contracts constitute an exchange of property rights. ARIN governs addresses via contract; i.e., it issues contracts granting exclusive assignment of a block of addresses. 

> This is on a fast track to try to make it on to the Toronto 
> meeting agenda, so any suggestions you might have would be 
> appreciated by early to the middle of next week.

My humble suggestion is that you abandon this proposal completely and do a bit more research into what the terms "license," "property" and "property rights" mean when used by lawyers, regulators, economists and institutionalists, and how those concepts are actually applied in the allocation and assignment of virtual resources. You can insist that addresses are "not property" until you are blue in the face. But as long as they are scarce, exclusive, transferable to some degree and can be used to generate economic value then they meet all the conditions of the definition of a property right. We can deal with reality, or we can deal with labels. 

--MM



From mueller at syr.edu  Fri Feb 12 17:09:01 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 12 Feb 2010 17:09:01 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the	NRPM
In-Reply-To: <4B75997E.2030804@chl.com>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com>
	<4B756939.2000206@umn.edu> <4B75997E.2030804@chl.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB3855@SUEX07-MBX-04.ad.syr.edu>

> To serve the interests of the Internet community as a whole

Stop right there. No one has bothered to explain how it better serves the interests of the Internet community as a whole to insist that a scarce, exclusively used, transferable resource isn't property. Start there, and move forward. If you can. 

> ARIN provides number resources in 
> the form of recording allocations and assignments in 
> its function as a Regional Internet Registry. 

So? Every form of resource allocation requires a registry or some other mechanism of establishing and publicly validating the boundaries of the resource and matching the particular resource to an owner or user. True of real estate, taxi medallions, stock certificates, futures contracts, mineral deposits, etc., etc., the examples are endless. The number and virtuality of things that can be bounded and reassigned or traded boggles the mind. 

> The allocations and assignments are a service subject 
> solely to the terms of the ARIN Registration Services Agreement, the 
> policies in this document, and any amendments as may be made 
> to either one.

The distinction between service and property is legally significant, but probably a lot more subtle than you realize, and there is no evidence here that you have any idea what implications that distinction has or how it improves ip address allocation to insist on one or the other. Let me just say that, from a political economy point of view, the assertion that ip address allocations "are a service subject SOLELY to..." ARIN simply means that the ip address space is the exclusive property of ARIN (or IANA). Is it your intention to assert monopoly power here? Tell me how that serves the interests of the internet community as a whole.

--MM



From mueller at syr.edu  Fri Feb 12 17:25:11 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 12 Feb 2010 17:25:11 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <4B759F3F.4080005@sprunk.org>
References: <4B683AAD.4020502@arin.net>
	<3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
	<4B759F3F.4080005@sprunk.org>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB3856@SUEX07-MBX-04.ad.syr.edu>


> I don't see it that way.  Numbers are "facts of nature" and 
> one _cannot_ own them (though some fraudsters might try to 
> convince you otherwise to make a quick buck).  What ARIN 
> deals with are slots in a registration database, and as the 
> owner of that database ARIN can do whatever it
> wants with those slots.  If a property owner decides to rent its
> property out rather than sell it, that doesn't contradict 
> public policy in any way.  In fact, this is perfectly in line 
> with how one (in effect, if not precisely) rents ZIP codes, 
> phone numbers, radio frequencies, Social Security Numbers, etc.

Oh, I love this post! 

> Numbers are "facts of nature" and one _cannot_ own them 

Two observations. 

1. Owning (i.e., maintaining exclusive control of the right to use and benefit from) an ip address or block is not "owning a number." A number is an abstract concept (not a fact of nature), and assigning me 10.10.10.10 does not give me the right to prevent you from using 10,101,010 in a mathematical equation, or from naming your restaurant 10.10.10.10, or from creating a silver bracelet composed or those numerals, or from writing that number on your wall, etc., etc. There is utterly no connection betweem the property status of ip addresses and the property status of "numbers." I declare this argument officially dead.

2. If ownership of ip addresses were truly impossible we wouldn't need a statement of policy from ARIN that ip addresses are not property and we wouldn't be having five years of debate over making ip addresses transferable, now would we? So if it's all impossible let's not worry about it, cuz it won't/can't happen. I declare that argument self-contradictory.

> as the 
> owner of that database ARIN can do whatever it
> wants with those slots. 

Ah. Ownership suddenly reasserts itself. Suddenly, absolute property rights _do_ have a place in this discourse. 

So let's get this straight. If it's ordinary internet users and organizations asserting some kind of a property right over the addresses they depend on, this is evil, selfish and will destroy the internet. But its ok for a centralized organization, ARIN, to assert ownership of the entire database and a corresponding right to do "whatever it wants" with the resource. 

Voila. The enemies of property have, through the dialectical process, become their logical opposite. 



From mueller at syr.edu  Fri Feb 12 17:30:41 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 12 Feb 2010 17:30:41 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term
	license	inthe NRPM
In-Reply-To: <28E139F46D45AF49A31950F88C497458052716A5@E03MVZ2-UKDY.domain1.systemhost.net>
References: <3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458052716A5@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB3857@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> 
> Which range of addresses do you propose to hand over to Canada
> as our private property for the exclusive use of Canadian companies

I believe Bill was talking about ownership by people, not governments. Providing for one does not in the least require the other.  



From mueller at syr.edu  Fri Feb 12 17:38:18 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 12 Feb 2010 17:38:18 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <6F51B50ECF32084788B9B3A8469A71B553DA113798@EXCHCLUSTER1-02.win.slac.stanford.edu>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com>
	<4B756939.2000206@umn.edu> <4B75997E.2030804@chl.com>
	<75822E125BCB994F8446858C4B19F0D701C7AB3855@SUEX07-MBX-04.ad.syr.edu>
	<6F51B50ECF32084788B9B3A8469A71B553DA113798@EXCHCLUSTER1-02.win.slac.stanford.edu>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB3858@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> From: Buhrmaster, Gary [mailto:gtb at slac.stanford.edu] 
> 
> 
> Can we agree that at least in recent practice(*) the number
> resource agreement in the various regions have stated that
> the numbers are not property?

As a statement of fact, that is obviously true. What I am saying is that the rationale for these assertions escapes me.  
 
> It seems to me that this proposal is simply trying to codify
> that practice by eliminating ambiguity with the agreements
> that one is already signing.  Ambiguity leads to misunderstanding.
> Misunderstandings (in contracts/policy/pracitice) are bad.

I understand your point. What I don't understand is why some members of the internet technical community are so intent on codyfying and rationalizing a principle that is so obviously out of step with current realities. As the free pool depletes and the need for a transfer market becomes urgent, why is it that these ideological siren songs get in the way of sound policy responses to scarce address resources.

--MM

From jradel at vantage.com  Fri Feb 12 17:45:10 2010
From: jradel at vantage.com (Jon Radel)
Date: Fri, 12 Feb 2010 17:45:10 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the
 term	license	inthe NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB3857@SUEX07-MBX-04.ad.syr.edu>
References: <3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>	<28E139F46D45AF49A31950F88C497458052716A5@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB3857@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4B75D9F6.50005@vantage.com>



Milton L Mueller wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>>
>> Which range of addresses do you propose to hand over to Canada
>> as our private property for the exclusive use of Canadian companies
>>     
>
> I believe Bill was talking about ownership by people, not governments. Providing for one does not in the least require the other.  
>
>   
And I believe that Michael was merely objecting to the use of a US 
"public policy tradition" as justification for (or against) ARIN policy 
and suggesting that the Canadians should be allowed to take their 
marbles (or virtual, non-property rights to use "their" marbles) home 
and apply their own public policy traditions, were we to go down that 
road.  But northern humor can be subtle, and I might have missed the 
whole and entire point. ;-)

--Jon Radel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3303 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100212/91092997/attachment.bin>

From gtb at slac.stanford.edu  Fri Feb 12 17:28:54 2010
From: gtb at slac.stanford.edu (Buhrmaster, Gary)
Date: Fri, 12 Feb 2010 14:28:54 -0800
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB3855@SUEX07-MBX-04.ad.syr.edu>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com>
	<4B756939.2000206@umn.edu> <4B75997E.2030804@chl.com>
	<75822E125BCB994F8446858C4B19F0D701C7AB3855@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <6F51B50ECF32084788B9B3A8469A71B553DA113798@EXCHCLUSTER1-02.win.slac.stanford.edu>

> Stop right there. No one has bothered to explain how it better
> serves the interests of the Internet community as a whole to
> insist that a scarce, exclusively used, transferable resource
> isn't property.

Can we agree that at least in recent practice(*) the number
resource agreement in the various regions have stated that
the numbers are not property?

It seems to me that this proposal is simply trying to codify
that practice by eliminating ambiguity with the agreements
that one is already signing.  Ambiguity leads to misunderstanding.
Misunderstandings (in contracts/policy/pracitice) are bad.

Gary

(*) Let us not forget, but not deal with, the pre-ARIN
    (legacy) number resources which is where the possible
    future numbergeddon lawsuits will likely start.  



From farmer at umn.edu  Fri Feb 12 18:17:07 2010
From: farmer at umn.edu (David Farmer)
Date: Fri, 12 Feb 2010 17:17:07 -0600
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the	NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com>
	<4B756939.2000206@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4B75E173.6030204@umn.edu>

Milton L Mueller wrote:
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net 
>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
> 
>>> 1.1 Number resources are not property
>>>
>>> To serve the interests of the Internet community as a whole, number
>>> resources are not property (real, personal, or intellectual). The
>>> allocation and assignment of IP addresses, ASNs, and other number
>>> resources are subject to the terms of the ARIN Registration Services
>>> Agreement, the policies in this document, and any amendments as may be
>>> made to either one.
> 
> David:
> What is the purpose of this? What does it accomplish technically, legally, politically or economically? How does it make IP addresses and routing function better? Does it make addresses more abundant, easier to use, etc.? 

As I said, its only intent is to edit text of the NRPM, no changes to 
the policy intent.  Do you believe this changes the policy intent of 6.4.1?

> The concept of "property" and "property rights" is far more flexible and much less dichotomous that you seem to understand. Radio spectrum has been declared a "public resource" since 1927 and the notion that they are "property" has attracted angry denunciations from Congresscritters and others for decades after. But anyone who understands what actually goes on in licensed spectrum and applies well-established and useful ways of thinking drawn from economics and law knows that the assignment of a license is in fact a grant of exclusivity, one that allows the person so granted to economically exploit the resource in regulated and conditioned ways, and which (in the case of spectrum) allows the grantee to sell the right, and thus qualifies in economic theory as a property right. The same is true of IP addresses, except that some people have an irrational fetish against the transfer of the resource for money (which of course doesn't stop it from happening routinely). 
> 
> Oliver Williamson just received the Nobel Prize for his analysis of how contracts constitute an exchange of property rights. ARIN governs addresses via contract; i.e., it issues contracts granting exclusive assignment of a block of addresses. 
> 
>> This is on a fast track to try to make it on to the Toronto 
>> meeting agenda, so any suggestions you might have would be 
>> appreciated by early to the middle of next week.
> 
> My humble suggestion is that you abandon this proposal completely and do a bit more research into what the terms "license," "property" and "property rights" mean when used by lawyers, regulators, economists and institutionalists, and how those concepts are actually applied in the allocation and assignment of virtual resources. You can insist that addresses are "not property" until you are blue in the face. But as long as they are scarce, exclusive, transferable to some degree and can be used to generate economic value then they meet all the conditions of the definition of a property right. We can deal with reality, or we can deal with labels. 

So do you prefer the text in 6.4.1 as it is now?  I don't.

I believe that the text proposed is completely consistent with the 
policy intent 6.4.1 and the RSA, I'm not looking to change the policy 
intent of either, only change some bad text in my opinion.

Bill and Milton,

You have confirmed for me that this is a completely separate issue from 
the rest of PP#106, and that separating it from PP#106 was an essential 
move.  I would hate to see good policy changes for IPv6 to get bogged 
down in the debate you two seem to want to engage in.

If you would like to change the policy intent of 6.4.1 then you are 
welcome to make your own proposal.  I do not believe that this proposal 
opens up a policy debate on the merits of number resources being 
property.  While that certainly is an appropriate topic for PPML, I do 
not wish to engage in it, I would appreciate you take such a debate to a 
different thread.

Thank you.

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


From bill at herrin.us  Fri Feb 12 19:15:41 2010
From: bill at herrin.us (William Herrin)
Date: Fri, 12 Feb 2010 19:15:41 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
	the NRPM
In-Reply-To: <4B75E173.6030204@umn.edu>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com> 
	<4B756939.2000206@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
	<4B75E173.6030204@umn.edu>
Message-ID: <3c3e3fca1002121615s4862b852pe135dc94c2e9bb1@mail.gmail.com>

On Fri, Feb 12, 2010 at 6:17 PM, David Farmer <farmer at umn.edu> wrote:
> So do you prefer the text in 6.4.1 as it is now?

David,

Yes, actually, I do. The existing 6.4.1 says stuff like "RIRs will
generally renew licenses automatically, provided requesting
organizations are making a good-faith effort at meeting the criteria
under which they qualified for or were granted an allocation or
assignment." And it applies only to IPv6 addresses.

Your version makes no assurances about registrant treatment and
expands the principle of non-ownership to additional number resources
beyond IPv6, not just as a matter of contract but as a matter of
public policy. I don't know the intent of the author of 6.4.1 as he
negotiated his way to consensus, but your proposed text is not
consistent with where 6.4.1 ended up. It should not be described as
minor editorial adjustment.


Look, here's the deal: the idea that folks don't own their cyberspace
real estate, that they merely have a limited grant of rights and
privileges formed of a consensus of the interested managed by some
NGO... well, it's a gross parody of feudal economics. It has some
really arcane and harmful side-effects that make life hard for folks
who don't have the time or desire to be in the thick of it. It's more
or less workable for now but sooner or later we're going to have to
revisit the issue in detail and come up with a design that's less 14th
century.

In the mean time, a little ambiguity is a good thing. Eliminating
ambiguity in favor of the interpretation that ARIN can revoke
addresses critical for your and my networks at its pleasure is an
unhealthy and, by more than a few, unwanted change.


The change I would endorse to 6.4.1 is its deletion and replacement
with nothing at all. The RSA says what "needs" saying. As it already
does with IPv4, let the NRPM stand mute on the question of whether IP
addresses are some kind of property.

I OPPOSE proposal 108 in its current form.

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 steve at ibctech.ca  Fri Feb 12 19:36:15 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 12 Feb 2010 19:36:15 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the	NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB3855@SUEX07-MBX-04.ad.syr.edu>
References: <4B683AAD.4020502@arin.net>
	<4B698066.6010604@chl.com>	<4B756939.2000206@umn.edu>
	<4B75997E.2030804@chl.com>
	<75822E125BCB994F8446858C4B19F0D701C7AB3855@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4B75F3FF.2060005@ibctech.ca>

Milton L Mueller wrote:
>> To serve the interests of the Internet community as a whole
> 
> Stop right there. No one has bothered to explain how it better serves the interests of the Internet community as a whole to insist that a scarce, exclusively used, transferable resource isn't property. Start there, and move forward. If you can. 
> 
>> ARIN provides number resources in 
>> the form of recording allocations and assignments in 
>> its function as a Regional Internet Registry. 
> 
> So? Every form of resource allocation requires a registry or some other mechanism of establishing and publicly validating the boundaries of the resource and matching the particular resource to an owner or user. True of real estate, taxi medallions, stock certificates, futures contracts, mineral deposits, etc., etc., the examples are endless. The number and virtuality of things that can be bounded and reassigned or traded boggles the mind. 
> 
>> The allocations and assignments are a service subject 
>> solely to the terms of the ARIN Registration Services Agreement, the 
>> policies in this document, and any amendments as may be made 
>> to either one.
> 
> The distinction between service and property is legally significant, but probably a lot more subtle than you realize, and there is no evidence here that you have any idea what implications that distinction has or how it improves ip address allocation to insist on one or the other. Let me just say that, from a political economy point of view, the assertion that ip address allocations "are a service subject SOLELY to..." ARIN simply means that the ip address space is the exclusive property of ARIN (or IANA). Is it your intention to assert monopoly power here? 

It almost seems as though you *do* have an idea of "what implications
that distinction has or how it improves..." [or doesn't improve] "...ip
address allocation".

Can you elaborate?

Steve


From mueller at syr.edu  Fri Feb 12 20:01:10 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 12 Feb 2010 20:01:10 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the
	term	license	inthe NRPM
In-Reply-To: <4B75D9F6.50005@vantage.com>
References: <3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458052716A5@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB3857@SUEX07-MBX-04.ad.syr.edu>
	<4B75D9F6.50005@vantage.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB385F@SUEX07-MBX-04.ad.syr.edu>

>   
> And I believe that Michael was merely objecting to the use of a US 
> "public policy tradition" as justification for (or against) 
> ARIN policy 
> and suggesting that the Canadians should be allowed to take their 
> marbles (or virtual, non-property rights to use "their" marbles) home 
> and apply their own public policy traditions, were we to go down that 
> road.  But northern humor can be subtle, and I might have missed the 
> whole and entire point. ;-)
> 
> --Jon Radel
> 

Fair enough. I agree that US traditions are not and should not be a factor here, but find Bill's general perspective on this issue to be quite convincing and unrelated to his chauvinistic slip up. 

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


From owen at delong.com  Fri Feb 12 19:59:00 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 12 Feb 2010 16:59:00 -0800
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
	the NRPM
In-Reply-To: <3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
References: <4B683AAD.4020502@arin.net>
	<3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
Message-ID: <53E2DEE9-65C6-43EC-B264-E112F692A3EA@delong.com>


On Feb 12, 2010, at 9:43 AM, William Herrin wrote:

> On Tue, Feb 2, 2010 at 9:46 AM, Member Services <info at arin.net> wrote:
>> Policy Proposal 108: Eliminate the term license in the NRPM
> 
> David.
> 
> Unless this proposal was instigated at counsel's request, you may want
> to consider letting sleeping dogs lie. The US has a public policy
> tradition dating back to before there was a US that anything of value
> can and should be ownable and owned by everyday citizens. ARIN
> practice is out of step with that tradition.
> 
Bill,
	I believe that the US has a public policy tradition that you cannot
own simple words, integers, or other primary language or mathematical
elements. IP addresses and Autonomous system numbers are simple
numbers, so, should be subject to that same tradition.

	If you can explain the ownership or intrinsic value of "4"
to me (not 4 of something or 4 dollars or 4 units, but, 4, four, etc.
itself), perhaps you can make a case that IP numbers have value.
Otherwise, the numbers themselves are not what is being traded,
but, the consent of the community to allow you to use those numbers
expressed as a registration in the RIR system.

	In reality, there is absolutely nothing that stops any cooperating
group of people who own routers from reassigning all of the IPv4
address space on their own terms completely independent of the
RIR system.  The Internet depends on the general cooperation of
the community in enlightened self interest, expressed as the RIR
system. There is no force of law in ARIN policy, nor should there
be.

Owen



From mueller at syr.edu  Fri Feb 12 20:12:53 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 12 Feb 2010 20:12:53 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license
	in	the NRPM
In-Reply-To: <53E2DEE9-65C6-43EC-B264-E112F692A3EA@delong.com>
References: <4B683AAD.4020502@arin.net>
	<3c3e3fca1002120943k778fc69dh2b5027de2e670675@mail.gmail.com>
	<53E2DEE9-65C6-43EC-B264-E112F692A3EA@delong.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB3860@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> 	I believe that the US has a public policy tradition 
> that you cannot
> own simple words, integers, or other primary language or mathematical
> elements. IP addresses and Autonomous system numbers are simple
> numbers, so, should be subject to that same tradition.

I've already explained the fallacy behind this. Creating an exclusivity in a block of ip addresses cannot in any way be equated with ownership of the mathematical abstractions (integers) that we use to identify the block. Any more than using latitude and longitude to identify a land parcel means that you own those numbers. 

Note however that all national laws recognize a property right in a word when it is used an an identifier of the source or origin of goods. And this illustrates my point perfectly: you can own, transfer, license or otherwise benefit economically from the trademark "Apple" (or the IP address 123.123.123.123) but you do not own the "word" apple in all its generic and non-infringing uses (nor do you own the integers 123 when you get assigned that IP address). 

> 	In reality, there is absolutely nothing that stops any 
> cooperating group of people who own routers from reassigning all 
> of the IPv4 address space on their own terms completely independent 
> of the
> RIR system.  The Internet depends on the general cooperation of
> the community in enlightened self interest, expressed as the RIR
> system. There is no force of law in ARIN policy, nor should there
> be.

I suspect that if any cooperating group of people attempted to reassign IPv4 address space in a way that conflicted with RIR assignments you would run screaming to the world's governments and demand that they be stopped. This has already happened with respect to the DNS root, which was also, supposedly, based entirely on "cooperation." 

--MM

From john.sweeting at twcable.com  Fri Feb 12 22:47:01 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Fri, 12 Feb 2010 22:47:01 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license
	in	the NRPM
Message-ID: <6C245EFEC0ABBD4E8C810D9BAE4E269D3B3965D7@PRVPEXVS10.corp.twcable.com>

Bill,

Thanks for your thoughts and input. The AC will certainly take your input into account. 

+++++

----- Original Message -----
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net>
To: David Farmer <farmer at umn.edu>
Cc: arin-ppml at arin.net <arin-ppml at arin.net>
Sent: Fri Feb 12 19:15:41 2010
Subject: Re: [arin-ppml] Policy Proposal 108: Eliminate the term license in	the NRPM

On Fri, Feb 12, 2010 at 6:17 PM, David Farmer <farmer at umn.edu> wrote:
> So do you prefer the text in 6.4.1 as it is now?

David,

Yes, actually, I do. The existing 6.4.1 says stuff like "RIRs will
generally renew licenses automatically, provided requesting
organizations are making a good-faith effort at meeting the criteria
under which they qualified for or were granted an allocation or
assignment." And it applies only to IPv6 addresses.

Your version makes no assurances about registrant treatment and
expands the principle of non-ownership to additional number resources
beyond IPv6, not just as a matter of contract but as a matter of
public policy. I don't know the intent of the author of 6.4.1 as he
negotiated his way to consensus, but your proposed text is not
consistent with where 6.4.1 ended up. It should not be described as
minor editorial adjustment.


Look, here's the deal: the idea that folks don't own their cyberspace
real estate, that they merely have a limited grant of rights and
privileges formed of a consensus of the interested managed by some
NGO... well, it's a gross parody of feudal economics. It has some
really arcane and harmful side-effects that make life hard for folks
who don't have the time or desire to be in the thick of it. It's more
or less workable for now but sooner or later we're going to have to
revisit the issue in detail and come up with a design that's less 14th
century.

In the mean time, a little ambiguity is a good thing. Eliminating
ambiguity in favor of the interpretation that ARIN can revoke
addresses critical for your and my networks at its pleasure is an
unhealthy and, by more than a few, unwanted change.


The change I would endorse to 6.4.1 is its deletion and replacement
with nothing at all. The RSA says what "needs" saying. As it already
does with IPv4, let the NRPM stand mute on the question of whether IP
addresses are some kind of property.

I OPPOSE proposal 108 in its current form.

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.
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 steve at ibctech.ca  Fri Feb 12 23:09:47 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 12 Feb 2010 23:09:47 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license	in
 the NRPM
In-Reply-To: <6C245EFEC0ABBD4E8C810D9BAE4E269D3B3965D7@PRVPEXVS10.corp.twcable.com>
References: <6C245EFEC0ABBD4E8C810D9BAE4E269D3B3965D7@PRVPEXVS10.corp.twcable.com>
Message-ID: <4B76260B.5090505@ibctech.ca>

Sweeting, John wrote:
> Bill,
> 
> Thanks for your thoughts and input. The AC will certainly take your input into account. 

I did not realize that my emphasis on the term 'license' in a past
discussion would come to this.

Personally, I do not know what the ramifications will be whether the
NRPM is changed or it isn't.

'License' is not a word that I like much, but because IANAL, I don't
know how to decide here. I do want the term removed, but before it is, I
want to be assured that the removal of the term will be in the best
long-term interest of the community from legal, economical, practical,
and 'fair' standpoints.

Because I don't know of any other method to do this, I formally request
that if Proposal 108 does not succeed, I want my Suggestion 2010.3
eradicated along with it, as to eliminate any discrepancies.

Steve

ps.

fwiw, Suggestion 2010.3:

Inline with Proposal 108, "Eliminate the term license...", I have found
the term 'license' used on the ARIN website, outside of the scope of the
NRPM:

- under "Experimental Allocation Fee" in

https://www.arin.net/fees/fee_schedule.html

I request that this term be removed/replaced as necessary, if necessary
and feasible.


From john.sweeting at twcable.com  Sat Feb 13 08:27:52 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Sat, 13 Feb 2010 08:27:52 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license	in
 the NRPM
Message-ID: <6C245EFEC0ABBD4E8C810D9BAE4E269D3B3965D9@PRVPEXVS10.corp.twcable.com>

Steve,

We have an excellent attorney supporting us and he is not shy when it comes to legal opinions. Thanks for this input as well.

-john


++++

----- Original Message -----
From: Steve Bertrand <steve at ibctech.ca>
To: Sweeting, John
Cc: 'bill at herrin.us' <bill at herrin.us>; 'farmer at umn.edu' <farmer at umn.edu>; 'arin-ppml at arin.net' <arin-ppml at arin.net>
Sent: Fri Feb 12 23:09:47 2010
Subject: Re: [arin-ppml] Policy Proposal 108: Eliminate the term license	in the NRPM

Sweeting, John wrote:
> Bill,
> 
> Thanks for your thoughts and input. The AC will certainly take your input into account. 

I did not realize that my emphasis on the term 'license' in a past
discussion would come to this.

Personally, I do not know what the ramifications will be whether the
NRPM is changed or it isn't.

'License' is not a word that I like much, but because IANAL, I don't
know how to decide here. I do want the term removed, but before it is, I
want to be assured that the removal of the term will be in the best
long-term interest of the community from legal, economical, practical,
and 'fair' standpoints.

Because I don't know of any other method to do this, I formally request
that if Proposal 108 does not succeed, I want my Suggestion 2010.3
eradicated along with it, as to eliminate any discrepancies.

Steve

ps.

fwiw, Suggestion 2010.3:

Inline with Proposal 108, "Eliminate the term license...", I have found
the term 'license' used on the ARIN website, outside of the scope of the
NRPM:

- under "Experimental Allocation Fee" in

https://www.arin.net/fees/fee_schedule.html

I request that this term be removed/replaced as necessary, if necessary
and feasible.
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 farmer at umn.edu  Sat Feb 13 10:59:19 2010
From: farmer at umn.edu (David Farmer)
Date: Sat, 13 Feb 2010 09:59:19 -0600
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license	in
 the NRPM
In-Reply-To: <8aeeaff61002120940w1fdc1863tb8b2c7395ed2792e@mail.gmail.com>
References: <mailman.3.1265994001.18692.arin-ppml@arin.net>
	<8aeeaff61002120940w1fdc1863tb8b2c7395ed2792e@mail.gmail.com>
Message-ID: <4B76CC57.10304@umn.edu>

Rudolph Daniel wrote:
> 
> I support this policy proposal in principle, however I am undecided on 
> the wording. Example: I want to query the use of the word "normal"  in 
> favor of " publication policy" . Does the use of the word "normal" 
> invite questions about what is normal and what is not, in the event of 
> future changes in publication policies?
> RD

Rudy,

It wasn't my intent to completely rewrite 11.4, I simply wanted to 
remove the terms lease and license.  When I looked at it it seemed that 
we could remove the one phrase without significantly changing the 
policies intent.  I guess we could remove the word normal too, but this 
doesn't real conform to the intent of the Policy Proposal, to "Eliminate 
the term license in the NRPM".  Also, the more we change the more likely 
we could have unintended side effects. But, looking at this I think we 
could remove the word "normal" and not change the intent.

----

Modify section 11.4 by removing ?on a lease/license basis? and "normal", 
leaving the following;

11.4 Resource Allocation Term and Renewal

The Numbering Resources are allocated for a period of one year. The
allocation can be renewed on application to ARIN providing information
as per Detail One. The identity and details of the applicant and the
allocated Numbering Resources will be published under the conditions of
ARIN's publication policy. At the end of the experiment, resources 
allocated under this policy will be returned to the available pool.

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


From farmer at umn.edu  Sat Feb 13 11:00:46 2010
From: farmer at umn.edu (David Farmer)
Date: Sat, 13 Feb 2010 10:00:46 -0600
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <3c3e3fca1002121615s4862b852pe135dc94c2e9bb1@mail.gmail.com>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com>
	<4B756939.2000206@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
	<4B75E173.6030204@umn.edu>
	<3c3e3fca1002121615s4862b852pe135dc94c2e9bb1@mail.gmail.com>
Message-ID: <4B76CCAE.8050806@umn.edu>

William Herrin wrote:
> On Fri, Feb 12, 2010 at 6:17 PM, David Farmer <farmer at umn.edu> wrote:
>> So do you prefer the text in 6.4.1 as it is now?
> 
> David,
> 
> Yes, actually, I do. The existing 6.4.1 says stuff like "RIRs will
> generally renew licenses automatically, provided requesting
> organizations are making a good-faith effort at meeting the criteria
> under which they qualified for or were granted an allocation or
> assignment." 

You make a fair point.  The automatic renewal with good-faith effort on 
the part of the resource holder should be retained.  That is good policy 
that probably shouldn't have been removed.

> And it applies only to IPv6 addresses. 
>
> Your version makes no assurances about registrant treatment and
> expands the principle of non-ownership to additional number resources
> beyond IPv6, not just as a matter of contract but as a matter of
> public policy. I don't know the intent of the author of 6.4.1 as he
> negotiated his way to consensus, but your proposed text is not
> consistent with where 6.4.1 ended up. 

The fact that this is in section 6 of the NRPM, for IPv6 policy, one 
could interpret that it only was intended to apply to IPv6.  However, 
reading the text it is reasonable to interpret it as a general concept 
applying to all IP addresses, in this case including IPv6, one could 
argue that that is its intent.

A question, what makes IPv6 unique that this should only apply to IPv6 
and not IPv4 or ASNs?

So, I'll give you that this is a technical change, but I do not believe 
that it is a change in the policy's intent.  But, I recognize that 
others may reasonably disagree with me on this point.

> It should not be described as minor editorial adjustment.

I agree it is not a minor editorial change, while I don't believe that 
this changes the policy's intent it does make more than just editorial 
changes.  Therefore it is necessary for this to go through the PDP and 
not simply an editorial change process.  And when change words to the 
extent involved here there is always the possibility of unintended side 
effects

> Look, here's the deal: the idea that folks don't own their cyberspace
> real estate, that they merely have a limited grant of rights and
> privileges formed of a consensus of the interested managed by some
> NGO... well, it's a gross parody of feudal economics. It has some
> really arcane and harmful side-effects that make life hard for folks
> who don't have the time or desire to be in the thick of it. It's more
> or less workable for now but sooner or later we're going to have to
> revisit the issue in detail and come up with a design that's less 14th
> century.
>
> In the mean time, a little ambiguity is a good thing.

I simply disagree with how you characterize the situation.

> Eliminating
> ambiguity in favor of the interpretation that ARIN can revoke
> addresses critical for your and my networks at its pleasure is an
> unhealthy and, by more than a few, unwanted change.

I agree that ARIN shouldn't be able to revoke addresses at its pleasure, 
also know as "for convenience" or "at will".  ARIN should be able to 
revoke resources "for cause" though.  I will note that one of the 
changes made to the LRSA in version 2.0 was to remove the ability of 
ARIN to terminate the agreement for ARIN's convenience, this change was 
also made in the RSA for version 10.0.  Now only the Applicant may 
terminate the agreement for convenience, ARIN may only terminate the 
agreement for cause.

I believe that this is important enough concept, that it shouldn't just 
be left to the contract, it should be included in policy too, and for 
IPv4 and ASNs too, not just IPv6.

> The change I would endorse to 6.4.1 is its deletion and replacement
> with nothing at all. The RSA says what "needs" saying. As it already
> does with IPv4, let the NRPM stand mute on the question of whether IP
> addresses are some kind of property.

I believe this is defiantly a change in the policy's intent.

> I OPPOSE proposal 108 in its current form.
> 
> Regards,
> Bill Herrin
> 
> 


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


From bill at herrin.us  Sat Feb 13 19:59:51 2010
From: bill at herrin.us (William Herrin)
Date: Sat, 13 Feb 2010 19:59:51 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
	the NRPM
In-Reply-To: <4B76CCAE.8050806@umn.edu>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com> 
	<4B756939.2000206@umn.edu>
	<75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
	<4B75E173.6030204@umn.edu>
	<3c3e3fca1002121615s4862b852pe135dc94c2e9bb1@mail.gmail.com> 
	<4B76CCAE.8050806@umn.edu>
Message-ID: <3c3e3fca1002131659t4ee0dd32ybf135ebc0f6f71b1@mail.gmail.com>

On Sat, Feb 13, 2010 at 11:00 AM, David Farmer <farmer at umn.edu> wrote:
> William Herrin wrote:
>> NGO... well, it's a gross parody of feudal economics. It has some
>> really arcane and harmful side-effects that make life hard for folks
>
> I simply disagree with how you characterize the situation.

"Those who don't know history are destined to repeat it." - Edmund Burke.

Medieval economics was in many respects more complex than modern
economics. King and court sat at the top of the food chain. Below that
you had the lords of the land (nobles) and under them the leaseholders
(serfs).

The King was not a despot; his influence was massive but his word was
not quite absolute. His court ruled with the consensus and support of
the the lords who more directly ruled the lands in their domain. In
theory the King owned all the land in the kingdom. In practice the
lords (from whom we derive the modern term "landlord") controlled it
with a relatively light touch from the court.

The serfs were not slaves, not the property of the lords. They were
free to a degree. However, they were bound to the lords (and the lords
to them) via complex multigenerational leases of the land on which
they lived and worked. These leases bore almost no resemblance to the
modern lease based on a simple payment of currency. They had complex
terms governing use and privilege, everything from minimum utilization
rates governing how much of the land the leaseholder had to keep under
cultivation to allowances for additional consumption of the land's
resources like timber.

Feudalism also had the rare freeholders who through their own merit or
that of their predecessors acquired grants directly from the court,
owing allegiance to no land lord.

Sound vaguely familiar? The great North American court of ARIN? IP
Addresses controlled (but not owned) mainly by the ISPs (land lords)
but also by the occasional freeholder (direct assignee). Complex
formulas of use and obligation (HD ratio anyone?) under which each
level is entitled to revoke the next level's address grant if the
obligations aren't met?


You may recall another part of history: the American Indians thought
the notion of real estate was ridiculous. It's nature. Wind, water and
dirt. You can drink the water and walk on the dirt but how can anyone
own the wind?

How can anyone own an integer?

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 Feb 15 04:32:20 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 15 Feb 2010 09:32:20 -0000
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
	the	NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <28E139F46D45AF49A31950F88C4974580527188A@E03MVZ2-UKDY.domain1.systemhost.net>

> What is the purpose of this? What does it accomplish 
> technically, legally, politically or economically? How does 
> it make IP addresses and routing function better? Does it 
> make addresses more abundant, easier to use, etc.?

The things that you are asking, are the province of the
IETF. On the question of abundance, the IETF has created
IPv6.
 
> The concept of "property" and "property rights" is far more 
> flexible and much less dichotomous that you seem to 
> understand.

Not if you understand the history of IP addressing. They have
always been loaned out to organizations who have technical
justification under terms which included "IP addresses are 
not property". Trying to apply property rights to something
that has explicitly been "not property" for many years
is beyond the flexibility of the concept.

> Oliver Williamson just received the Nobel Prize for his 
> analysis of how contracts constitute an exchange of property 
> rights. ARIN governs addresses via contract; i.e., it issues 
> contracts granting exclusive assignment of a block of addresses. 

You can only buy and sell contracts if the contracts 
are specifically structured to accomodate this. That 
is the whole basis of derivatives. However, the ARIN 
contracts do not grant exclusive assignment in the way
that you are using the term. ARIN grants exclusivity 
only insofar as they guarantee to you that they will
not grant the same addresses to any other party. But
your right to use the addresses is always strictly 
limited to technical needs, and when those needs go
away, you no longer have a right to the addresses.
This is one of the reasons why ARIN contracts cannot
be used to exchange property rights.

--Michael Dillon


From michael.dillon at bt.com  Mon Feb 15 04:38:10 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 15 Feb 2010 09:38:10 -0000
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term
	licenseinthe NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB3857@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <28E139F46D45AF49A31950F88C497458052718A6@E03MVZ2-UKDY.domain1.systemhost.net>

> > Which range of addresses do you propose to hand over to 
> Canada as our 
> > private property for the exclusive use of Canadian companies
> 
> I believe Bill was talking about ownership by people, not 
> governments. Providing for one does not in the least require 
> the other.  

How Canadians manage and divide up our share of the ARIN
address pool is none of your business. If we want the 
government to own our IP addresses, that is up to us to
decide.

Did anyone else notice that the message referred to
here was a joke. Call it reductio ad absurdum if you will,
but please let it end here. Bill proposed a wild idea, and
I pointed out the absurdity that it implied. If you really
want to discuss Bill's idea, please go back to the source
and start from there.

--Michael Dillon


From tedm at ipinc.net  Mon Feb 15 12:29:15 2010
From: tedm at ipinc.net (Ted Mittelstaedt)
Date: Mon, 15 Feb 2010 09:29:15 -0800
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the	NRPM
In-Reply-To: <4B683AAD.4020502@arin.net>
References: <4B683AAD.4020502@arin.net>
Message-ID: <4B79846B.5050805@ipinc.net>

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.
> 
> Draft Policies and Proposals under discussion can be found 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
> 
> 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 108: Eliminate the term license in the NRPM
> 
> Proposal Originator: David Farmer
> 
> Proposal Version: 1.0
> 
> Date: 2 February 2010
> 
> Proposal type: modify
> 
> Policy term: Permanent
> 
> Policy statement:
> 
> Delete section 6.4.1 and replace with a new section;
> 
> 1.1 Number resources are not property
> 
> To serve the interests of the Internet community as a whole, number
> resources are not property (real, personal, or intellectual). The
> allocation and assignment of IP addresses, ASNs, and other number
> resources are subject to the terms of the ARIN Registration Services
> Agreement, the policies in this document, and any amendments as may be
> made to either one.
> 
> Modify section 11.4 by removing ?on a lease/license basis?, leaving the
> following;
> 
> 11.4 Resource Allocation Term and Renewal
> 
> The Numbering Resources are allocated for a period of one year. The
> allocation can be renewed on application to ARIN providing information
> as per Detail One. The identity and details of the applicant and the
> allocated Numbering Resources will be published under the conditions of
> ARIN's normal publication policy. At the end of the experiment,
> resources allocated under this policy will be returned to the available
> pool.
> 
> Rationale:
> 
> As part of the discussion of Policy Proposal #106 the issue of the use
> of the term ?license? in section 6.4.1 and that it is not likely in
> harmony with the ARIN Registration Services Agreement was recognized.
> The AC feels that this issue is important enough to make it a separate
> Draft Policy that stands on its own.
> 
> This section could not be fixed by simple editorial changes and it
> requires a complete rewrite in order to fix the issues. It was further
> recognized that the concept that ?Number resources are not property? is
> not exclusively an IPv6 issue and should be moved out of section 6, so
> that it is clear that it applies to all number resources.
> 
> Finally, the rest of the NRPM was searched for any additional uses of
> the term ?license?. One additional use was found in section 11.4, in
> this case deleting it and a few other words surrounding it, fixes the
> issue without significantly changing the meaning of the section.
> 
> Timetable for implementation: Immediate
> 

We (my org) opposes this policy proposal.

We feel that changes of this nature  - namely a change that has a
stated goal of NOT modifying the intent of the NRPM, merely clarifying
it - are best made by counsel.

This policy proposal does not belong here.  If the proposers intent is
to eliminate "bad language" in the NRPM WITHOUT changing the meaning of
the NRPM, it is best accomplished via the Suggestion Box, through a 
request to have ARIN counsel review the document and make the edits,
then submit them to the membership via the policy proposal process.

If ARIN counsel decides the edits are unwarranted, then they will 
respond with why that is the case, and that will be that.

ARIN counsel has to use the NRPM when ARIN is sued court, that is
what they are paid to do.  They are paid by us (ARIN) to (among other
things) inform us of deficiencies in the NRPM that would imped their
ability to use the NRPM to do the job we are paying them.

Proposals of this type need to originate from ARIN counsel, not the
other way around.

If the submitter actually wishes to modify policy intent, then that is
a different thing.  But this proposal is being pitched specifically as
NOT a modification of policy intent.

Ted


From michael.dillon at bt.com  Mon Feb 15 12:41:20 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 15 Feb 2010 17:41:20 -0000
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
	the	NRPM
In-Reply-To: <4B79846B.5050805@ipinc.net>
Message-ID: <28E139F46D45AF49A31950F88C497458052F3CFC@E03MVZ2-UKDY.domain1.systemhost.net>

> This policy proposal does not belong here.  If the proposers 
> intent is to eliminate "bad language" in the NRPM WITHOUT 
> changing the meaning of the NRPM, it is best accomplished via 
> the Suggestion Box, through a request to have ARIN counsel 
> review the document and make the edits, then submit them to 
> the membership via the policy proposal process.

The suggestion box can be found here
<https://www.arin.net/app/suggestion/>

I don't understand why it is not used more often.

I'm not commenting on whether or not this particular
policy proposal should be a suggestion, but it would not
do any harm to try a suggestion if you are not sure about
whether or not your idea fits with policy changes.

For that matter, people could consult with one of the
AC members, email addresses are available here
<https://www.arin.net/about_us/ac.html>,


--Michael Dillon


From john.sweeting at twcable.com  Tue Feb 16 08:37:23 2010
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 16 Feb 2010 08:37:23 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <4B79846B.5050805@ipinc.net>
Message-ID: <C7A009C3.F5B1%john.sweeting@twcable.com>

Ted,

This was discussed among AC, ARIN Counsel and ARIN staff and it was felt that a policy was the best course as the PDP brings the most attention to a matter. While this is not intended to modify policy, we did not consider it a "minor" edit of the NRPM. Since we did not consider it a minor edit then we decided a proposal would be the best vehicle for change. This will have a full Legal review by ARIN counsel.

-john


+++++++


On 2/15/10 12:29 PM, "Ted Mittelstaedt" <tedm at ipinc.net> wrote:

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.
>
> Draft Policies and Proposals under discussion can be found 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
>
> 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 108: Eliminate the term license in the NRPM
>
> Proposal Originator: David Farmer
>
> Proposal Version: 1.0
>
> Date: 2 February 2010
>
> Proposal type: modify
>
> Policy term: Permanent
>
> Policy statement:
>
> Delete section 6.4.1 and replace with a new section;
>
> 1.1 Number resources are not property
>
> To serve the interests of the Internet community as a whole, number
> resources are not property (real, personal, or intellectual). The
> allocation and assignment of IP addresses, ASNs, and other number
> resources are subject to the terms of the ARIN Registration Services
> Agreement, the policies in this document, and any amendments as may be
> made to either one.
>
> Modify section 11.4 by removing "on a lease/license basis", leaving the
> following;
>
> 11.4 Resource Allocation Term and Renewal
>
> The Numbering Resources are allocated for a period of one year. The
> allocation can be renewed on application to ARIN providing information
> as per Detail One. The identity and details of the applicant and the
> allocated Numbering Resources will be published under the conditions of
> ARIN's normal publication policy. At the end of the experiment,
> resources allocated under this policy will be returned to the available
> pool.
>
> Rationale:
>
> As part of the discussion of Policy Proposal #106 the issue of the use
> of the term "license" in section 6.4.1 and that it is not likely in
> harmony with the ARIN Registration Services Agreement was recognized.
> The AC feels that this issue is important enough to make it a separate
> Draft Policy that stands on its own.
>
> This section could not be fixed by simple editorial changes and it
> requires a complete rewrite in order to fix the issues. It was further
> recognized that the concept that "Number resources are not property" is
> not exclusively an IPv6 issue and should be moved out of section 6, so
> that it is clear that it applies to all number resources.
>
> Finally, the rest of the NRPM was searched for any additional uses of
> the term "license". One additional use was found in section 11.4, in
> this case deleting it and a few other words surrounding it, fixes the
> issue without significantly changing the meaning of the section.
>
> Timetable for implementation: Immediate
>

We (my org) opposes this policy proposal.

We feel that changes of this nature  - namely a change that has a
stated goal of NOT modifying the intent of the NRPM, merely clarifying
it - are best made by counsel.

This policy proposal does not belong here.  If the proposers intent is
to eliminate "bad language" in the NRPM WITHOUT changing the meaning of
the NRPM, it is best accomplished via the Suggestion Box, through a
request to have ARIN counsel review the document and make the edits,
then submit them to the membership via the policy proposal process.

If ARIN counsel decides the edits are unwarranted, then they will
respond with why that is the case, and that will be that.

ARIN counsel has to use the NRPM when ARIN is sued court, that is
what they are paid to do.  They are paid by us (ARIN) to (among other
things) inform us of deficiencies in the NRPM that would imped their
ability to use the NRPM to do the job we are paying them.

Proposals of this type need to originate from ARIN counsel, not the
other way around.

If the submitter actually wishes to modify policy intent, then that is
a different thing.  But this proposal is being pitched specifically as
NOT a modification of policy intent.

Ted
_______________________________________________
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  Tue Feb 16 09:56:15 2010
From: jmaimon at chl.com (Joe Maimon)
Date: Tue, 16 Feb 2010 09:56:15 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the	NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB3855@SUEX07-MBX-04.ad.syr.edu>
References: <4B683AAD.4020502@arin.net>
	<4B698066.6010604@chl.com>	<4B756939.2000206@umn.edu>
	<4B75997E.2030804@chl.com>
	<75822E125BCB994F8446858C4B19F0D701C7AB3855@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4B7AB20F.20500@chl.com>



Milton L Mueller wrote:
>>      
> Stop right there. No one has bothered to explain how it better serves the interests of the Internet community as a whole
>    
Asserting property rights on protocol numbers is mutually exclusive with 
consensus based self regulation and development as it requires trampling 
over the private property rights of others.

> The distinction between service and property is legally significant
>    
A service without property rights is the only thing ARIN or any other 
protocol number Registrar has ever provided. Please expound if you 
believe you have anything of materiel relevance to add on the matter of 
subtleties and implications.
> --MM
>    

Joe



From bill at herrin.us  Tue Feb 16 10:23:49 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 16 Feb 2010 10:23:49 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
	the NRPM
In-Reply-To: <4B7AB20F.20500@chl.com>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com> 
	<4B756939.2000206@umn.edu> <4B75997E.2030804@chl.com>
	<75822E125BCB994F8446858C4B19F0D701C7AB3855@SUEX07-MBX-04.ad.syr.edu>
	<4B7AB20F.20500@chl.com>
Message-ID: <3c3e3fca1002160723p310f6ab1v1358e71a39bbc5e5@mail.gmail.com>

On Tue, Feb 16, 2010 at 9:56 AM, Joe Maimon <jmaimon at chl.com> wrote:
> Asserting property rights on protocol numbers is mutually exclusive with
> consensus based self regulation and development

Possibly. One could argue that "common law" is a form of
consensus-based self-regulation. Or taking into account your implied
point distinguishing government and NGOs, one could point out that
homeowners' associations work as well or better than condominiums even
though the individual homes are owned by individual owners instead of
the stakeholders collectively owning the condominium and merely
controlling their personal part of it.


> as it requires trampling
> over the private property rights of others.

I'll have to ask you to expand on and justify that claim; it doesn't
follow from the evidence I'm aware of.


> A service without property rights is the only thing ARIN or any other
> protocol number Registrar has ever provided.

That's debatable for InterNIC on back. The arguments are stale so I
won't repeat them but it is by no means a settled question.

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 mueller at syr.edu  Wed Feb 17 10:35:40 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 17 Feb 2010 10:35:40 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license
	in	the	NRPM
In-Reply-To: <28E139F46D45AF49A31950F88C4974580527188A@E03MVZ2-UKDY.domain1.systemhost.net>
References: <75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
	<28E139F46D45AF49A31950F88C4974580527188A@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----

> > The concept of "property" and "property rights" is far more
> > flexible and much less dichotomous that you seem to
> > understand.
> 
> Not if you understand the history of IP addressing. They have
> always been loaned out to organizations who have technical

A loan is a conditional transfer of property rights. 

> justification under terms which included "IP addresses are
> not property". 

You can make any assertions you like about social ontology ("not property") but that doesn't change the basic reality of what is going on. A loan, lease or assignment always confers specific rights upon the recipient of a resource and retains specific rights for the person making the loan/lease/assignment. Ya'll seem to be hung up on the word property for reasons that have no practical basis. I don't (and I suspect Bill Herrin doesn't) care whether you call those "property rights" or "lemonade", what we care about are the obligations, claims and conditions associated with the transfer of resources from one party to another. 

Categorical, ideological assertions that addresses are "not property" does nothing to clarify, or make more reasonable and just, the conditions users and organizations face when receiving addresses from ARIN. All it seems to be is a blanket (and increasingly panicky) assertion of absolute power by a monopoly institution.

> Trying to apply property rights to something
> that has explicitly been "not property" for many years
> is beyond the flexibility of the concept.

As I said before, this is because you have a rigid concept of property rights and seem to be unaware of how that term is used by people in law, economics, regulatory economics, and policy. I respect your knowledge of the technical configuration of routing and addressing, I just think in this area you don't know what you're talking about. 

> You can only buy and sell contracts if the contracts
> are specifically structured to accomodate this. That
> is the whole basis of derivatives. However, the ARIN
> contracts do not grant exclusive assignment in the way
> that you are using the term.

Now we are getting somewhere more reasonable. Yes, contracts can be structured to allow the parties more or less rights, more or less exclusivity, more or less transferability. But that is a choice. So lets have a discussion about that. It is obvious that ARIN does not allow free transferability of the rights it assigns, but this is just a policy decision it makes and that policy could be modified in hundreds of ways. You contribute nothing useful to that policy debate by making the word "property rights" a taboo and attempting to banish it from the discussion. 

> ARIN grants exclusivity
> only insofar as they guarantee to you that they will
> not grant the same addresses to any other party. But
> your right to use the addresses is always strictly
> limited to technical needs, and when those needs go
> away, you no longer have a right to the addresses.
> This is one of the reasons why ARIN contracts cannot
> be used to exchange property rights.

Except, of course, when one business buys another (an obvious exchange of property rights). And except when the address transfer policy is invoked. And except when we are talking about IPv6 and no real needs assessment is performed. And except when we decide to use some other criterion for assigning addresses. Except.... get the point? 

There is ALWAYS going to be a dialogue about what rights assignees have in relation to the assigning authority and we will always have a lot of options to consider.  



From michael.dillon at bt.com  Wed Feb 17 12:48:09 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Wed, 17 Feb 2010 17:48:09 -0000
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license
	inthe	NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <28E139F46D45AF49A31950F88C4974580534CC2F@E03MVZ2-UKDY.domain1.systemhost.net>


> > Not if you understand the history of IP addressing. They 
> have always 
> > been loaned out to organizations who have technical
> 
> A loan is a conditional transfer of property rights. 

I did not say "a loan was made", I said they have been
loaned out. Whether or not this loaning out constitutes
a conditional transfer of property rights depends entirely
on the nature of what was transfered, plus the nature of 
the agreement.

If I owned a male horse and loaned it to you for a day
at no charge, to impregnate your mare. Then at the end
of the day, even though a horse is clearly an object
of commerce which is bought and sold and whose ownership
is registered, nevertheless you no longer have any
right whatsoever to that horse. If you try to sue me
because the mare did not get pregnant, then you will
lose, because the nature of the agreement did not 
specify that you can keep the stallion until the mare
is pregnant.

Similarly when ARIN loans out IP addresses, the recipient
doesn't end up with much. They have no guarantee that they
can earn a profit on those addresses, indeed they have no
guarantee that other ISPs will route traffic for those
addresses. About all that ARIN does assert is that you can
configure those addresses into an IP network device, and
they will make it hum. You may not like the sound of the
hum, but that is not ARIN's problem.

The rights that are gained with an ARIN allocation are 
so restricted, and so minimal, that it is hard to see
how they could be interpreted as a property right or what
benefit anyone would get (other than lawyers) from any
attempt to apply property right law to IP address allocations.

> You can make any assertions you like about social ontology 
> ("not property") but that doesn't change the basic reality of 
> what is going on. A loan, lease or assignment always confers 
> specific rights upon the recipient of a resource and retains 
> specific rights for the person making the 
> loan/lease/assignment.

That is precisely why ARIN does not allocate any IP addresses
until the recipient has signed the RSA. If there is any doubt
as to the recipient's legal status, they have to sign another
RSA, just to be sure. This happened to us when the acquisition
of Radianz by BT went from a paper exercise to a reorganization
of people and corporate entities. Since it wasn't entirely clear
that the RADIANZ Americas, Inc. corporate entity was the same
one that had signed the RSA many years ago, we had to sign one
again a couple of allocations back.

If you want to see what specific rights are conferred, look
at the RSA. It's right here
<https://www.arin.net/resources/agreements/rsa.pdf>
and it has a short section entitled NO PROPERTY RIGHTS.

> Categorical, ideological assertions that addresses are "not 
> property" does nothing to clarify, or make more reasonable 
> and just, the conditions users and organizations face when 
> receiving addresses from ARIN.

Of course not. That's why the language is in both ARIN policy
and in the signed contract. Listen to the judge, man. He said
that if you didn't want the numbers without the property 
rights, you shouldn't have signed the dadburned contract.
But seein' as how you went ahead and signed the goldarned
thing, you ain't got no PROPERTY rights and if you show
your face in this courtroom again, it will be thutty days
or thutty dollars for you, sir!

> As I said before, this is because you have a rigid concept of 
> property rights and seem to be unaware of how that term is 
> used by people in law, economics, regulatory economics, and 
> policy. I respect your knowledge of the technical 
> configuration of routing and addressing, I just think in this 
> area you don't know what you're talking about. 

Oh, I do know what I am talking about, because I have discussed
this very issue with lawyers, including ARIN's esteemed counsel,
and more to the point, I have READ THE RSA TEXT. 

> > However, the ARIN contracts do not grant exclusive 
> assignment in the 
> > way that you are using the term.
> 
> Now we are getting somewhere more reasonable. Yes, contracts 
> can be structured to allow the parties more or less rights, 
> more or less exclusivity, more or less transferability. But 
> that is a choice. So lets have a discussion about that.

Why? The RSA is not a derivatives contract. I have read the actual
text used in real-world derivatives contracts. They are very
complex contracts, much more complex than the RSA. We are not
talking about simple factoring of receivables here.

> It is 
> obvious that ARIN does not allow free transferability of the 
> rights it assigns, but this is just a policy decision it 
> makes and that policy could be modified in hundreds of ways. 

ARIN is not at liberty to do anything it chooses. Something as
fundamental as you are suggesting would have to be coordinated
with the other RIRs and involve IANA approval as well.

> > ARIN grants exclusivity
> > only insofar as they guarantee to you that they will not grant the 
> > same addresses to any other party. But your right to use 
> the addresses 
> > is always strictly limited to technical needs, and when 
> those needs go 
> > away, you no longer have a right to the addresses.
> > This is one of the reasons why ARIN contracts cannot be used to 
> > exchange property rights.
> 
> Except, of course, when one business buys another (an obvious 
> exchange of property rights). 

No, that is NOT an exception. If one business buys the network
of another, then yes, the technical need for the addresses is
also transfered, however simply changing business ownership is
not sufficient. It is common in business sales, for the current
assets of the business (and liabilities) to be split in such a 
way that the new owner does not take all. 

This is why section 8 of the NRPM says this:

   Number resources are nontransferable and are not 
   assignable to any other organization unless ARIN 
   has expressly and in writing approved a request 
   for transfer. ARIN is tasked with making prudent 
   decisions on whether to approve the transfer of 
   number resources.

And later on in Section 8:

   ARIN will consider requests for the transfer of 
   number resources in the case of mergers and 
   acquisitions upon receipt of evidence that the 
   new entity has acquired the assets which had, 
   as of the date of the acquisition or proposed 
   reorganization, justified the current entity's 
   use of the number resource.

--Michael Dillon



From lar at mwtcorp.net  Wed Feb 17 12:49:36 2010
From: lar at mwtcorp.net (lar at mwtcorp.net)
Date: Wed, 17 Feb 2010 10:49:36 -0700
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term
 license	in	the	NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu>
References: <75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
	<28E139F46D45AF49A31950F88C4974580527188A@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <web-2363522@be1.mail.trib.com>

IMNAL!!

I find this whole thread very troubling. To those of us that have or are
affiliated with businesses where Internet connectivity is the core of our
business our IP numbers goes to the essence of our business.

Where you want to call numbers property or a virtual box of fairy dust the
facts are simple. The very real property of equipment and contracts we have
entered into that makeup a business and give it value, is dependent on those
numbers. Losing those numbers or even being forced to re-number into other
numbers destroys some or all of that value. When a company is sold, having
an outside party that can affect it's ability to continue as an ongoing
concern seriously affects the value of the business. "Standing inspection"
once a year is a burden that will fall most heavily on the smaller operators
that lack the personnel to stay ahead of the process. It is even more 
troubling
when you consider that IPV6 lacks the scarcity that originally drove the
argument.

It seems that we need to do just the opposite to facilitate a growing and
stable Internet. So it appears taht the NRPM needs revision but prop108 is
very much the wrong one.

Larry Ash
Network Administrator
Mountain West Telephone
400 East 1st St.
Casper, WY 82601
Office 307 233-8387


From spiffnolee at yahoo.com  Wed Feb 17 14:17:27 2010
From: spiffnolee at yahoo.com (Lee Howard)
Date: Wed, 17 Feb 2010 11:17:27 -0800 (PST)
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
	the NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu>
References: <75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
	<28E139F46D45AF49A31950F88C4974580527188A@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <103375.29072.qm@web63301.mail.re1.yahoo.com>

Milton Mueller wrote:


> Now we are getting somewhere more reasonable. Yes, 
> contracts can be structured to allow the parties more or 
> less rights, more or less exclusivity, more or less 
> transferability. But that is a choice. So lets have a 
> discussion about that. It is obvious that ARIN does not 
> allow free transferability of the rights it assigns, but this is 
> just a policy decision it makes and that policy could be 
> modified in hundreds of ways. You contribute nothing 
> useful to that policy debate by making the word "property 
> rights" a taboo and attempting to banish it from the discussion. 


Can I suggest that this conversation move in that direction?
The back-and-forth of "address cannot be property" vs.
"addresses are inherently property" seems to be deadlocked.
There may be policies that would follow from a definition of
addresses as property; what policies would you propose?

Lee



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

From jcurran at arin.net  Wed Feb 17 23:40:55 2010
From: jcurran at arin.net (John Curran)
Date: Wed, 17 Feb 2010 23:40:55 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <4B756939.2000206@umn.edu>
References: <4B683AAD.4020502@arin.net> <4B698066.6010604@chl.com>
	<4B756939.2000206@umn.edu>
Message-ID: <2D6BB510-B8B6-4837-8ABB-45B896F24EEF@arin.net>

On Feb 12, 2010, at 9:44 AM, David Farmer wrote:
> 
> The idea was to clearly state that number resource are not property and that the RSA and the policies in the NRPM are in control of how number resource are allocated and assigned.
> 
> In my view the NRPM shouldn't should like a contract, that kind of language generally belongs in the RSA.  But this is an important enough concept that having it stated in both the NRPM and the RSA makes sense.
> 
> This got started because of section 6.4.1 currently in the NRPM and especially its use of the term license.  So, at almost the last minute, I though of searching the NRPM for any other uses of the term license, and found the one in 11.4 too.  It seemed that it could be eliminated without a complete rewrite of that section.  This change to 11.4 could probably have been made as a editorial change, but since 6.4.1 needed a complete rewrite and such a change needed to go through the PDP, it seemed appropriate to tack this additional simple change on to that process.

Folks - 

As noted by David Farmer above, the purpose of this proposal is 
to clean up language which referenced the term "license" in the 
NRPM, as the term might be interpreted in conflict with the 
Resource Services Agreements between ARIN and resource holders.  

ARIN performs address allocations under the framework which was 
established by the IETF in RFC2008 and RFC2050, both of which 
are recognized as Best Current Practice (BCP) documents via the 
IETF process. ARIN recognizes the IETF's responsibility to provide
this framework as part of their specifications for the Internet 
Protocol (IP) itself.

Those interested in the nature of the Internet Protocol (IP) number 
resource allocations should also review those BCP documents as they 
provide significant background which is helpful in understanding 
the context in which allocations are made under RSA agreement.

The objective of Policy Proposal 108 is an administrative change, 
not a modification of the existing policy intention.  As such, after 
careful review, I have recommended to the Advisory Council (ARIN AC) 
that policy proposal 108 be abandonded, so that ARIN Counsel & staff
may develop an administrative change with the appropriate language.  
Per existing practice, such a change will be sent to the ARIN AC for 
their review prior to action by the ARIN Board of Trustees.

Thank you,
/John

John Curran
President and CEO
ARIN








From mysidia at gmail.com  Thu Feb 18 00:11:27 2010
From: mysidia at gmail.com (James Hess)
Date: Wed, 17 Feb 2010 23:11:27 -0600
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license
	inthe NRPM
In-Reply-To: <28E139F46D45AF49A31950F88C4974580534CC2F@E03MVZ2-UKDY.domain1.systemhost.net>
References: <75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu>
	<28E139F46D45AF49A31950F88C4974580534CC2F@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <6eb799ab1002172111wb4a338eqc024e4d6db71866d@mail.gmail.com>

On Wed, Feb 17, 2010 at 11:48 AM,  <michael.dillon at bt.com> wrote:
>> > Not if you understand the history of IP addressing. They
>> have always
>> > been loaned out to organizations who have technical
>> A loan is a conditional transfer of property rights.
> I did not say "a loan was made", I said they have been
> loaned out. Whether or not this loaning out constitutes

"Making a loan"  means the same thing as  "lending".  You want to say
IP addresses should be clearly indicated as not property, and then you
are using words in discussion that imply they are.

It's a bit confusing to say IP addresses aren't property, and then use
words like "lend" that imply they are  property that  someone
temporarily confers, instead of selling or transferring, okay.

Let's back up a bit...  and say  if the IP address itself is indeed
not property:  then  neither  assignee nor ARIN   _OWN_   IPs.
Because they are not property,  nobody  can "lend" IP addresses.
Nobody can  "license"  the legal use of IP addresses,   because
ownership  or some other exclusive right would be required to do these
things.  Nobody can transfer  or assign property rights to IP
addresses.

Perhaps these words like "lend" are being used in attempt to compare
something more complicated using everyday terms that are simple  (but
less precise).


Any of the above words like "lend" or "license" when used seem to
strongly suggest that  the  "IP  address"  itself is an  owned object
that ARIN had acquired legal ownership of and confers  some  exclusive
legally protected monopoly  to the use of that  IP number,  when
configuring hosts on a network.

Policy could  be less-confusing by referring to other things owned
besides the IP address,

For example,  the  "act of assigning an IP address",    or  the
slot  in ARIN's contact database.      Recognition of   user of the IP
address by the registry.

E.g.      The  registry  confers   to the user allocated IP address
space by the registry,   the special  right,   to be reported by the
registry  as a  legitimate unique assignee of that  IP address space,
according and within that registry.


They don't get a license to the address space,  instead  they get
provided a service by ARIN.

The service that ARIN performs is to  provide  contact information to
the internet community  and provide verification  that  they  were
assigned that address space  by the  registry  (through WHOIS and
RDNS).


--
-J


From gbonser at seven.com  Thu Feb 18 01:02:22 2010
From: gbonser at seven.com (George Bonser)
Date: Wed, 17 Feb 2010 22:02:22 -0800
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term
	licenseinthe NRPM
In-Reply-To: <6eb799ab1002172111wb4a338eqc024e4d6db71866d@mail.gmail.com>
References: <75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu><28E139F46D45AF49A31950F88C4974580534CC2F@E03MVZ2-UKDY.domain1.systemhost.net>
	<6eb799ab1002172111wb4a338eqc024e4d6db71866d@mail.gmail.com>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F7891@RWC-EX1.corp.seven.com>



> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
On
> Behalf Of James Hess
> Sent: Wednesday, February 17, 2010 9:11 PM
> Subject: Re: [arin-ppml] Policy Proposal 108: Eliminate the term
> licenseinthe NRPM
> 
> On Wed, Feb 17, 2010 at 11:48 AM,  <michael.dillon at bt.com> wrote:
> >> > Not if you understand the history of IP addressing. They
> >> have always
> >> > been loaned out to organizations who have technical
> >> A loan is a conditional transfer of property rights.
> > I did not say "a loan was made", I said they have been
> > loaned out. Whether or not this loaning out constitutes


> It's a bit confusing to say IP addresses aren't property, and then use
> words like "lend" that imply they are  property that  someone
> temporarily confers, instead of selling or transferring, okay.

I would say that they are community property and that the use of it is
assigned according to rules set by the community.

It is simply an agreed upon assignment of a resource and that assignment
can be revoked if the use of that resource is no longer within the
guidelines set by the community.

So it wouldn't be a "license" and it wouldn't be a transfer of
ownership.  It would be an assignment.  And that assignment is
conditional upon various criteria being met.

Maybe an analog would be water allotments in the Western US.  You would
have certain "water rights" but they could be modified by whatever
agency issues those allotments.

I like the words "allotment" or "assignment" better.

George



From michael.dillon at bt.com  Thu Feb 18 03:26:12 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 18 Feb 2010 08:26:12 -0000
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license
	inthe NRPM
In-Reply-To: <6eb799ab1002172111wb4a338eqc024e4d6db71866d@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C4974580534CCF5@E03MVZ2-UKDY.domain1.systemhost.net>


> "Making a loan"  means the same thing as  "lending".  You 
> want to say IP addresses should be clearly indicated as not 
> property, and then you are using words in discussion that 
> imply they are.

That's not what the judge says. According to the judge, the
words used to describe something are important. That's why
legal documents sound so formal, because they use certain 
words in certain ways according to established traditions of
law, either common law or case law. If you don't use a formal
term, but instead choose to use an informal one, the judge 
will not just ASSUME that you mean the same thing.

> It's a bit confusing to say IP addresses aren't property, and 
> then use words like "lend" that imply they are  property that 
>  someone temporarily confers, instead of selling or 
> transferring, okay.

Saying that IP addresses aren't property is clarifying, not
confusing. 

> Let's back up a bit...  and say  if the IP address itself is indeed
> not property:  then  neither  assignee nor ARIN   _OWN_   IPs.

Precisely! Now you are beginning to understand.

> Because they are not property,  nobody  can "lend" IP addresses.
> Nobody can  "license"  the legal use of IP addresses,   because
> ownership  or some other exclusive right would be required to 
> do these things.

We're in the desert where water is scarce. It is two km to the
nearest well. You are thirsty and have no money to buy water
so you ask me for a drink, and promise to give me a drink in
return, the next time that you have water. I'm a nice guy and
give you a LOAN of some water. Next day, you go to the well,
and fill your waterskins. Later that day you give me a drink,
thus fulfilling the loan agreement. Except that nobody owns
the water. It flows freely from the wells, for anyone to take.
You pay nothing for it, and nothing distinguishes it from 
the water in anyone else's jugs and pots and waterskins.

Perhaps the water isn't property at all, and I didn't actually
LEND you any water, but performed a service for you of bringing
you water from the well. You could have given me money for the
service, because the service has value, but that doesn't mean 
that the water is property. What if I want to bring lots of 
water from the well and sell it to local folks to save them 
a trip. And what if I allow you to sell some of my water, i.e.
licence you to sell the water. 

You cannot really discuss this whole property issue in isolation
from the services involved in registering IP addresses, running
an in-addr.arpa server, managing the whois directory. Let's face
it, if I want to number my nameserver 4.2.2.2, there is nothing
stopping me, and if I run into problems with it, it is not because
I don't own the IP address, but because I don't receive various
ARIN services associated with that IP address.

>  Nobody can transfer  or assign property 
> rights to IP addresses.

Says so in the RFCs, in ARIN policy and in the RSA.

> Any of the above words like "lend" or "license" when used 
> seem to strongly suggest that  the  "IP  address"  itself is 
> an  owned object that ARIN had acquired legal ownership of 
> and confers  some  exclusive legally protected monopoly  to 
> the use of that  IP number,  when configuring hosts on a network.

I agree. ARIN should make sure to explicitly state that IP
addresses are not property to make things perfectly clear.
Oh wait...

--Michael Dillon


From packetgrrl at gmail.com  Thu Feb 18 16:51:09 2010
From: packetgrrl at gmail.com (cja@daydream.com)
Date: Thu, 18 Feb 2010 14:51:09 -0700
Subject: [arin-ppml] PP#109 and 2010-3 discussions at the upcoming meeting
Message-ID: <c3227e9e1002181351p731f28e5pf551a21486310ef2@mail.gmail.com>

ARIN Community,

Policy Proposal 109 is under consideration as well as Draft Policy 2010-3.
 However, due to
timeline, proposal 109 will not make it to adoption discussion at the
Toronto meeting although
we will make time on the agenda for a presentation and some discussion of
proposal 109.
Draft Policy 2010-3 will be discussed at the Toronto meeting for possible
adoption.

Since proposal 109 and draft policy 2010-3 relate to the same topic, but
contain very
different approaches to the issue, the AC feels it is important to call the
community's
attention to the fact that they will be at different stages in the policy
development
process when we meet in Toronto.

Thank you,

Cathy Aronson
ARIN AC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100218/9600b0ee/attachment.htm>

From Daniel_Alexander at Cable.Comcast.com  Thu Feb 18 17:25:45 2010
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Thu, 18 Feb 2010 17:25:45 -0500
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
	Registration Requirements - revised
In-Reply-To: <4B71BF7A.6090107@arin.net>
References: <4B71BF7A.6090107@arin.net>
Message-ID: <997BC128AE961E4A8B880CD7442D94801311EFF7@NJCHLEXCMB01.cable.comcast.com>

Hello All,

There has been some discussion about section 4.2.6 Cable Address Space
Policy, and I wanted to offer some thoughts. 

The purpose of this section is not to distinguish residential from
commercial customers. The reason for the section was to distinguish
utilization of IP address space that is provisioned to a customer via
dhcp, versus prefixes allocated to a downstream customer. There are
commercial customers that get provisioned a single IP through dhcp, and
there are residential customers who use static prefixes allocated to
their home. The intent of the cable policy is to draw the line at IP
addresses provisioned to customers versus blocks assigned to customers. 

The other item was the distinction of 50% utilization. It is a little
ambiguous, but the intent is to reach a 50% utilization of your most
recent allocation, but you still need 80% of all other allocations. It
is only the most recent allocation received that has the 50% threshold
applied. If it were actually applied across the board, I would be one
happy camper. 

The 50% mark on the most recent allocation is because you can quickly
distribute most of your address space across your provisioning
footprint, leaving nothing left for growth while the lease count of the
provisioned customers catches up to the blocks allocated. This is a very
different topic from whether the user is a residential or commercial
customer. 

Thanks,
Dan


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Member Services
Sent: Tuesday, February 09, 2010 3:03 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] Policy Proposal 109: Standardize IP Reassignment
Registration Requirements - revised

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.

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal 109: Standardize IP Reassignment Registration
Requirements

Proposal Version: 2.0

Date: 9 FEB 2010

Proposal type: New

Policy term: Permanent

Policy statement:

## Definitions ##

  - Add:

2.3. Organizational Information

When required, organization Information must include at a minimum:
Legal name, city, state, zip code equivalent and at least one valid
technical or abuse POC; inclusion of street address is highly
encouraged.

The POC shall be designated by the organization and must include at
least one verifiable email address, inclusion of a phone number is
highly encouraged.

## IPv4 ##

  - Rename 4.2.3.7. "Reassignment information" to "Registration"

  - Rename 4.2.3.7.1. "Customer organization information" to
"Reassignment Information" and replace text with:

When an organization holding an IPv4 address allocation makes IPv4
address assignments, it must register reassignment information via SWIP
or RWHOIS server. SWIP and RWHOIS reassignments shall include each
client's organizational information, except where specifically exempted
by this policy.

  - Replace 4.2.3.7.6. Residential Customer Privacy with:

4.2.3.7.6. Residential Subscribers

4.2.3.7.6.1. Residential Market Area

In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather than
to individual subscribers. This assignment information regarding each
market area holding an address block should be registered with the
network name used to identify each market area. Initial allocations are
based on total number of homes that could purchase the service in a
given market area. Each assignment to specific end-users holding /29 and
larger blocks still requires registration. In order to obtain additional
IPv4 addresses, ISPs assigning addresses by market area must show, using
reassignment information published in whois, that they have reassigned
at least 80% of their current address space, with a >50% utilization
rate.

4.2.3.7.6.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization
with downstream residential customers holding /29 and larger blocks may
substitute that organization's name for the customer's name, e.g.
'Private Customer - XYZ Network', and the customer's street address may
read 'Private Residence'. Each private downstream residential
reassignment must have accurate upstream Abuse and Technical POCs
visible on the WHOIS record for that block.

  - Strike section 4.2.6. "Cable Address Space Policy"

## IPv6 ##

  - Replace Section 6.5.5. with:

6.5.5. Registration

6.5.5.1. Reassignment information

When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register reassignment information in a
database, accessible by RIRs as appropriate (information registered by
an RIR may be replaced by a distributed database for registering address
management information in future). These reassignment registrations
shall include each client's organizational information, except where
specifically exempted by this policy.

6.5.5.2. /56 registered unit

Information is registered in units of assigned /56 networks. When more
than a /56 is assigned to a client organization, the assigning
organization is responsible for ensuring that the address space is
properly registered.

6.5.5.3. Submit within 7 days

Any time an LIR receives a new block of address space, reassignment
information should be submitted within 7 days of issuance of the new
space.

6.5.5.4. Visible via WHOIS

This information must be visible via WHOIS prior to submitting a
request for a new allocation. For further information on reassigning IP
address space, please see RFC 2050.

6.5.5.6. Residential Subscribers

6.5.5.6.1. Residential Market Area

In most cases, ISPs that have residential subscribers assign address
space to the infrastructure to which their customers connect rather than
to individual subscribers. This assignment information regarding each
market area holding an address block should be registered with the
network name used to identify each market area. Initial allocations are
based on total number of homes that could purchase the service in a
given market area. Each assignment to specific end-users holding /56 and
larger blocks still requires registration. In order to obtain additional
IPv6 addresses, ISPs assigning addresses by market area must show, using
reassignment information published in whois, that they have reassigned
at least 80% of their current address space, with a >50% utilization
rate.


6.5.5.6.2. Residential Customer Privacy

To maintain the privacy of their residential customers, an organization
with downstream residential customers holding /56 and larger blocks may
substitute that organization's name for the customer's name, e.g.
'Private Customer - XYZ Network', and the customer's street address may
read 'Private Residence'. Each private downstream residential
reassignment must have accurate upstream Abuse and Technical POCs
visible on the WHOIS record for that block.


Rationale:

#Short Version:
This proposal intends to do several things:
1) Bring IPv4 and IPv6 policy more in line with each other to make the
NRPM easier to understand and comply with - at least as it relates to
reassignment information.
2) Specifically define what organizational information is required to
be added to whois when reassignments are made to client organizations.
3) To specifically state that a client organization may designate the
POC of their choice for any/all whois entries. This includes
designating an upstream POC as their own prefered POC.
4) Expands the priviledges previously reserved solely for IPv4 cable
ISPs to all ISPs/LIRs with residential subscribers.

#Expanded version:
1) This policy restructures the reassignment and registration sections
of the IPv4 and IPv6 policies.
        a) The IPv4 section is renamed "registration."
        b) The first section of the IPv4 policy is rewritten for
clarity.
        c) The IPv6 policy is totally rewritten in a format that matches
the IPv4 policy.
* These structural changes are meant to make it easier to compare the
two sections. I believe that having the IPv6 and IPv4 policies written
in completely different formats and structures (as they are in many
cases now) confuses the issues and makes it very hard to understand
what is different and what is the same across the two sections.
Bringing them into a similar format should help ease the migration to
IPv6 as folks can quickly and easily understand the differences and
the similarities.

2) This policy adds a definition of "organizational information" which
is used in the existing policy but not currently defined anywhere in
the NRPM.
        a) The definition states that specific addresses are not
required for
client organizations but asks that they be included when possible.
        b) The definition states that a POC is required but can be
designated
by the client organization - it spells out that the client org can
choose to use their upstream as a POC.
        c) The definition requires that the POC have a valid email
address but only suggests that it include a phone number.
* This definition is meant to address the customer confidentiality
concerns that have been brought up recently (by specifically removing
the requirement to publish client addresses and telephone numbers),
with the smallest negative impact to whois usefulness (retains a valid
POC w/ email contact).

3) This policy takes the privileges granted specifically to IPv4 cable
operators in section 4.2.6. "Cable Address Space Policy" and grants
them to all ISPs who serve residential areas.
        a) It allows all ISPs with residential coverage to
register/swip/rwhois an entire market area.
        b) It retains the existing residential customer privacy policy
for all customers with larger IP blocks.
* This change removes the need for any ISP to enter residential
customers into whois at all.

4) This policy also extends the >50% utilization rate, currently granted
only to IPv4 cable operators, to all ISPs with a residential footprint.
* This change will make it easier for ISPs serving residential areas
to get the addresses they need - this is key for FTTH operators as
well as fixed-wireless and other residential ISPs.

#Specific changes in this version:
1) Sections 4.2.3.7.6.1. and 6.5.5.6.1. have an added sentance: "In
order to obtain additional IPvX addresses, ISPs assigning addresses by
market area must show, using reassignment information published in
whois, that they have reassigned at least 80% of their current address
space, with a >50% utilization rate." Currently this >50% utilization
rate is reserved solely for IPv4 cable operators, this addition
spreads it to all residential ISPs, both IPv4 and IPv6 alike.

2) The last line of section 6.5.5.2. was changed from "...is
registered in an RIR database." to "...is properly registered." To
reflect the fact that RWHOIS and other potential methods of publishing
WHOIS information are not in fact RIR databases.

#Note: Specific mention of SWIP and RWHOIS has been left in the IPv4
policy to avoid complicating this proposal further by rewriting the
entire IPv4 section without any substantive change. The IPv6 policy
has been written to be agnostic concerning the method of publishing
WHOIS information.

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 mueller at syr.edu  Sun Feb 21 12:59:45 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 21 Feb 2010 12:59:45 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the term license in
 the NRPM
In-Reply-To: <103375.29072.qm@web63301.mail.re1.yahoo.com>
References: <75822E125BCB994F8446858C4B19F0D701C7AB3854@SUEX07-MBX-04.ad.syr.edu>
	<28E139F46D45AF49A31950F88C4974580527188A@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu>,
	<103375.29072.qm@web63301.mail.re1.yahoo.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C79C6CBA@SUEX07-MBX-04.ad.syr.edu>

Sorry to respond slowly to this, Lee, have been on the road. Honestly, to me the issue is not at all about insisting that addresses are "inherently property"; it is about the attitudes and policies that inform the ARIN contracts.
I think the key policy conflicts have to do with transferability, which I continue to believe is very important in the ipv4 context. The terms and conditions under which RIRs can reclaim addresses, and the tying of address resources to routing and aggregation constraints is another long term area of concern.

I continue to see liberalized transferability as a key to dealing with the address shortages that will probably occur in the short term as the hoped-for migration to ipv6 drags on. Ithink the ARIN policy toward that is too restrictive, and will not be used. I believe that a more reasonable, less trading-hostile attitude toward address markets would free up a lot of resources for use and rationalize the address scarcity problem by properly pricing addresses. this would also create another incentive to adopt ipv6.

You were probably hoping for something more specific; e.g., alter section x.y.(z) of the NPRM; however, the debate over PP 108 has revealed a continuing, higher-level attitudinal and philosophical disagreement in the community that makes debates over specifics become proxies for these larger disagreements. As the proponents of 108 have correctly noted, the idea that assignees have no transferable property rights is deeply embedded on documents and policies that go way back. Lacking the resources and time to review and revise the whole shebang, I have to limit my role to urging and supporting some attitudinal changes that might, in the future, lead to more specific alterations in policy.

________________________________
From: Lee Howard [spiffnolee at yahoo.com]
Sent: Wednesday, February 17, 2010 2:17 PM
To: Milton L Mueller; michael.dillon at bt.com; arin-ppml at arin.net
Subject: Re: [arin-ppml] Policy Proposal 108: Eliminate the term license in the NRPM

Milton Mueller wrote:

> Now we are getting somewhere more reasonable. Yes,
> contracts can be structured to allow the parties more or
> less rights, more or less exclusivity, more or less
> transferability. But that is a choice. So lets have a
> discussion about that. It is obvious that ARIN does not
> allow free transferability of the rights it assigns, but this is
> just a policy decision it makes and that policy could be
> modified in hundreds of ways. You contribute nothing
> useful to that policy debate by making the word "property
> rights" a taboo and attempting to banish it from the discussion.

Can I suggest that this conversation move in that direction?
The back-and-forth of "address cannot be property" vs.
"addresses are inherently property" seems to be deadlocked.
There may be policies that would follow from a definition of
addresses as property; what policies would you propose?

Lee

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

From mueller at syr.edu  Sun Feb 21 13:02:06 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 21 Feb 2010 13:02:06 -0500
Subject: [arin-ppml] Policy Proposal 108: Eliminate the
	term	licenseinthe NRPM
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7891@RWC-EX1.corp.seven.com>
References: <75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu><28E139F46D45AF49A31950F88C4974580534CC2F@E03MVZ2-UKDY.domain1.systemhost.net>
	<6eb799ab1002172111wb4a338eqc024e4d6db71866d@mail.gmail.com>,
	<5A6D953473350C4B9995546AFE9939EE081F7891@RWC-EX1.corp.seven.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C79C6CBB@SUEX07-MBX-04.ad.syr.edu>



________________________________________
From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of George Bonser [gbonser at seven.com]

>Maybe an analog would be water allotments in the Western US.  You would
>have certain "water rights" but they could be modified by whatever
>agency issues those allotments.


Dear George:
Here's a brief selection from an article by a legal expert on water rights law: 

"The scarcity of water in the Rocky Mountain and southwestern states has led to the development of a system of water allocation very different from that which exists in regions graced with more abundant rainfall. Rights to water are established by actual use of the water, and maintained by continued use and need. Water rights are treated similarly to rights to real property, can be conveyed, mortgaged, and encumbered in the same manner, all independently of the land on which the water originates, or on which it is used. The following is a summary of the legal framework governing water rights in the arid areas of the country." 

http://library.findlaw.com/1999/Jan/1/241492.html if you want to read more

From gbonser at seven.com  Sun Feb 21 13:35:36 2010
From: gbonser at seven.com (George Bonser)
Date: Sun, 21 Feb 2010 10:35:36 -0800
Subject: [arin-ppml] Policy Proposal 108: Eliminate the termlicenseinthe
	NRPM
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6CBB@SUEX07-MBX-04.ad.syr.edu>
References: <75822E125BCB994F8446858C4B19F0D701C78E5A71@SUEX07-MBX-04.ad.syr.edu><28E139F46D45AF49A31950F88C4974580534CC2F@E03MVZ2-UKDY.domain1.systemhost.net><6eb799ab1002172111wb4a338eqc024e4d6db71866d@mail.gmail.com>,
	<5A6D953473350C4B9995546AFE9939EE081F7891@RWC-EX1.corp.seven.com>
	<75822E125BCB994F8446858C4B19F0D701C79C6CBB@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <5A6D953473350C4B9995546AFE9939EE081F790E@RWC-EX1.corp.seven.com>

I think how they are handled depends upon jurisdiction and water is not
a finite resource, the amount of it varies from year to year.  IP
address space is a fixed asset.  There are always the same total number
of IP addresses from year to year.  "Water rights" was an
orifice-extracted analog.

As the addresses are a certain fixed quantity and more can never be
"discovered".  Water is different in that regard.

The community has a fixed supply of addresses.  I don't have a problem
with someone having an excess of that resource transferring that excess
to someone who would qualify for more space but can't get a direct
allocation due to address depletion.  I do have a problem with money
changing hands for those addresses.  The reason is that the resource is
a community resource.  If someone has an excess, then the excess should
have been returned to the community.  Selling them means that they have
an incentive not to return excess resources to the community for
allocation on a first-come first-served basis.  It means the allocation
goes to highest bidder.  The problem then becomes one of equal access to
a community resource.  A network that qualifies for address space but
cannot obtain them from the RIR because of resource depletion but can't
compete against a Google for bidding on them is kept out of the
community.

You end up with a situation where a few large players end up with all of
a fixed resource and there is the potential for corruption.  Company A
notices that Company B has more address space than they are using.  They
demand that Company B sell them half the excess or they are going to
"report" company B as having too much.  Big players end up extorting
more address space from others and then maybe someone makes an attempt
to "corner the market" in IP addresses in order to prevent competition
just as large agricultural operations can buy up much more water
allocation than they actually use for no other reason than to keep
anyone else in the area from having them.  IP addresses then become
"money in the bank"

IP addresses should never be regarded as property any more than letters
of the alphabet should be property.  They are only an address.  When you
move, can you take your house number with you? Can you sell your house
number to someone else?  What if someone cornered the market in address
numbers and nobody else could build a house?  It is hard to find a good
analog because the Internet is different.  But a major developer buying
up all the house numbers in an area might prevent a person from building
their own home and getting mail service unless they buy it from the
developer.

I see the notion of IP addresses being property as potentially allowing
large operators to control address space outside of their actual
provision of service.  I see it as potentially stifling of competition.
I see it as potentially preventing small operators from access to the
Internet except by going through the larger operators.

In a perfect world, everyone would be audited every few years and any
address space they do not qualify for should be returned.  In a slightly
less perfect world, any time addresses are transferred, both parties
should be audited and the transfer only taking place if the receiving
party qualifies for them under existing rules and the party giving the
IPs would return all excess IPs they hold to the RIR.  

 

> -----Original Message-----
> From: Milton L Mueller [mailto:mueller at syr.edu]
> Sent: Sunday, February 21, 2010 10:02 AM
> To: George Bonser; James Hess; michael.dillon at bt.com
> Cc: arin-ppml at arin.net
> Subject: RE: [arin-ppml] Policy Proposal 108: Eliminate the
> termlicenseinthe NRPM
> 
> 
> 
> ________________________________________
> From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On
Behalf
> Of George Bonser [gbonser at seven.com]
> 
> >Maybe an analog would be water allotments in the Western US.  You
> would
> >have certain "water rights" but they could be modified by whatever
> >agency issues those allotments.
> 
> 
> Dear George:
> Here's a brief selection from an article by a legal expert on water
> rights law:
> 
> "The scarcity of water in the Rocky Mountain and southwestern states
> has led to the development of a system of water allocation very
> different from that which exists in regions graced with more abundant
> rainfall. Rights to water are established by actual use of the water,
> and maintained by continued use and need. Water rights are treated
> similarly to rights to real property, can be conveyed, mortgaged, and
> encumbered in the same manner, all independently of the land on which
> the water originates, or on which it is used. The following is a
> summary of the legal framework governing water rights in the arid
areas
> of the country."
> 
> http://library.findlaw.com/1999/Jan/1/241492.html if you want to read
> more


From christopher.morrow at gmail.com  Mon Feb 22 00:02:22 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Mon, 22 Feb 2010 00:02:22 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <5A6D953473350C4B9995546AFE9939EE081F7645@RWC-EX1.corp.seven.com>
References: <4B563F50.1070306@umn.edu>
	<7E625125-914A-45B6-B3B2-D03EE6FC6DFA@icann.org>
	<3c3e3fca1002041713o72b057fcqe09f93b5e846d1b8@mail.gmail.com>
	<c3227e9e1002041745mc38356bva537b25ad15e20e2@mail.gmail.com>
	<3c3e3fca1002041954p3baf46f3sd8ccb8dd5d2246b5@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F762E@RWC-EX1.corp.seven.com>
	<3c3e3fca1002042122x4a503c0sa4d8c02b9b4182ae@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F7632@RWC-EX1.corp.seven.com>
	<3c3e3fca1002051038p50a77436u7e8db46c2dfd1e85@mail.gmail.com>
	<5A6D953473350C4B9995546AFE9939EE081F7645@RWC-EX1.corp.seven.com>
Message-ID: <75cb24521002212102u4940942ck7a3a7e4c327db141@mail.gmail.com>

On Fri, Feb 5, 2010 at 1:55 PM, George Bonser <gbonser at seven.com> wrote:
>> The current kit deals with packets rather than flows. Flows was
>> investigated thoroughly and looks very much like a blind alley. It has
>> some useful niches but the failure modes are catastrophic.
>
> Yeah, I know that, but they tend to cache information regarding a flow.

huh? a CRS or T-series device doesn't cache anything about flows. each
packet in turn on input is looked up in the FIB for send to the proper
output interface. (extreme, as another vendor also doesn't cache flow
info...)

> The cache isn't big enough is the problem I am worried about. ?Some gear
> likes to populate the routes (FIB) in hardware and if you don't have
> enough space, they don't all get in there. Chip density being what it
> is, I would think that more storage is available in the same form factor
> today than was available when the module was initially designed. ?It

See scudder's talk about 100g and how long you have to lookup before
your input buffer is full with a full interface.

There are 2 parts to this problem (and this is wandering way off
topic) size of the FIB and rate of change of the FIB.

Back to the original topic though... As to providing globally unique
addresses to end sites who want this for their internal uses only,
that seems like a worthy goal, to me. I have 2 concerns:

1) creating another rfc1918-ish block. (registration of this space
seems to avoid this)
2) leakages into the global table, unintended ones. (pulling from a
set supernet seems to cover this concern as well)

-Chris


From mksmith at adhost.com  Mon Feb 22 09:45:42 2010
From: mksmith at adhost.com (Michael K. Smith)
Date: Mon, 22 Feb 2010 08:45:42 -0600
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <75cb24521002212102u4940942ck7a3a7e4c327db141@mail.gmail.com>
Message-ID: <C7A7F4B6.F964E%mksmith@adhost.com>




On 2/21/10 9:02 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
wrote:

> On Fri, Feb 5, 2010 at 1:55 PM, George Bonser <gbonser at seven.com> wrote:
>>> The current kit deals with packets rather than flows. Flows was
>>> investigated thoroughly and looks very much like a blind alley. It has
>>> some useful niches but the failure modes are catastrophic.
>> 
>> Yeah, I know that, but they tend to cache information regarding a flow.
> 
> huh? a CRS or T-series device doesn't cache anything about flows. each
> packet in turn on input is looked up in the FIB for send to the proper
> output interface. (extreme, as another vendor also doesn't cache flow
> info...)
> 
>> The cache isn't big enough is the problem I am worried about. ?Some gear
>> likes to populate the routes (FIB) in hardware and if you don't have
>> enough space, they don't all get in there. Chip density being what it
>> is, I would think that more storage is available in the same form factor
>> today than was available when the module was initially designed. ?It
> 
> See scudder's talk about 100g and how long you have to lookup before
> your input buffer is full with a full interface.
> 
> There are 2 parts to this problem (and this is wandering way off
> topic) size of the FIB and rate of change of the FIB.
> 
> Back to the original topic though... As to providing globally unique
> addresses to end sites who want this for their internal uses only,
> that seems like a worthy goal, to me. I have 2 concerns:
> 
> 1) creating another rfc1918-ish block. (registration of this space
> seems to avoid this)
> 2) leakages into the global table, unintended ones. (pulling from a
> set supernet seems to cover this concern as well)
> 
Why wouldn't we just allocate them normally, like any other block?  If we
don't give them the 1918'ish status then we don't have to worry about
unintended consequences.  Instead, it's up to the end user to make sure the
routes are not leaked but, if they are, they just end up in the DFZ with
everything else.

I guess I'm thinking that it would be better to change the restriction on
6.5.1.1 than create a new set of policies for "unconnected" networks.

Regards,

Mike



From christopher.morrow at gmail.com  Mon Feb 22 10:05:13 2010
From: christopher.morrow at gmail.com (Christopher Morrow)
Date: Mon, 22 Feb 2010 10:05:13 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <C7A7F4B6.F964E%mksmith@adhost.com>
References: <75cb24521002212102u4940942ck7a3a7e4c327db141@mail.gmail.com>
	<C7A7F4B6.F964E%mksmith@adhost.com>
Message-ID: <75cb24521002220705l1283decy46be540b23be810@mail.gmail.com>

On Mon, Feb 22, 2010 at 9:45 AM, Michael K. Smith <mksmith at adhost.com> wrote:
>
>
>
> On 2/21/10 9:02 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
> wrote:
>
>> On Fri, Feb 5, 2010 at 1:55 PM, George Bonser <gbonser at seven.com> wrote:
>>>> The current kit deals with packets rather than flows. Flows was
>>>> investigated thoroughly and looks very much like a blind alley. It has
>>>> some useful niches but the failure modes are catastrophic.
>>>
>>> Yeah, I know that, but they tend to cache information regarding a flow.
>>
>> huh? a CRS or T-series device doesn't cache anything about flows. each
>> packet in turn on input is looked up in the FIB for send to the proper
>> output interface. (extreme, as another vendor also doesn't cache flow
>> info...)
>>
>>> The cache isn't big enough is the problem I am worried about. ?Some gear
>>> likes to populate the routes (FIB) in hardware and if you don't have
>>> enough space, they don't all get in there. Chip density being what it
>>> is, I would think that more storage is available in the same form factor
>>> today than was available when the module was initially designed. ?It
>>
>> See scudder's talk about 100g and how long you have to lookup before
>> your input buffer is full with a full interface.
>>
>> There are 2 parts to this problem (and this is wandering way off
>> topic) size of the FIB and rate of change of the FIB.
>>
>> Back to the original topic though... As to providing globally unique
>> addresses to end sites who want this for their internal uses only,
>> that seems like a worthy goal, to me. I have 2 concerns:
>>
>> 1) creating another rfc1918-ish block. (registration of this space
>> seems to avoid this)
>> 2) leakages into the global table, unintended ones. (pulling from a
>> set supernet seems to cover this concern as well)
>>
> Why wouldn't we just allocate them normally, like any other block? ?If we
> don't give them the 1918'ish status then we don't have to worry about
> unintended consequences. ?Instead, it's up to the end user to make sure the
> routes are not leaked but, if they are, they just end up in the DFZ with
> everything else.

one of the original ideas was to lower the bar for 'internal use only'
prefixes. For instance:

You run a large enterprise, you have some internal server things that
you want v6 for but won't ever see the light of day.
These servers/nets may interconnect with business partners today or as
you M&A your way info infamy.
You don't have 200 customers nor do you qualify for PI space (and you
don't want that anyway), ULA doesn't provide enough uniqueness
guarantee either...

I think the policy should be able to serve these folks, it should also
make sure that providers have a simple method to drop these routes on
ingress. Willy-Nilly assigning these from current allocations won't
help the route filtering problem, lowering the bar across the board
seems to be unpalatable.

> I guess I'm thinking that it would be better to change the restriction on
> 6.5.1.1 than create a new set of policies for "unconnected" networks.

6.5.8 I think is more along the lines of the proposed users though
(not LIR's but EndSites) isn't it?

-Chris


From michael.dillon at bt.com  Mon Feb 22 10:26:58 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 22 Feb 2010 15:26:58 -0000
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <75cb24521002220705l1283decy46be540b23be810@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C497458054324FC@E03MVZ2-UKDY.domain1.systemhost.net>


> You run a large enterprise, you have some internal server 
> things that you want v6 for but won't ever see the light of day.
> These servers/nets may interconnect with business partners 
> today or as you M&A your way info infamy.
> You don't have 200 customers nor do you qualify for PI space 
> (and you don't want that anyway), ULA doesn't provide enough 
> uniqueness guarantee either...

ULA random (FD00::/8) does not provide the uniqueness guarantee.
There is another kind of ULA set aside for assignments to 
organizations that would provide a uniqueness guarantee.

The problem is that the IETF has not yet figured out how
to manage assignments of FC00::/8.

As far as I know, there isn't currently an active Internet 
draft on this topic.

--Michael Dillon


From mksmith at adhost.com  Mon Feb 22 11:53:01 2010
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Mon, 22 Feb 2010 08:53:01 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <75cb24521002220705l1283decy46be540b23be810@mail.gmail.com>
Message-ID: <C7A8128D.F96F3%mksmith@adhost.com>




On 2/22/10 9:05 AM, "Christopher Morrow" <christopher.morrow at gmail.com>
wrote:

> On Mon, Feb 22, 2010 at 9:45 AM, Michael K. Smith <mksmith at adhost.com> wrote:
>> 
>> 
>> 
>> On 2/21/10 9:02 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
>> wrote:
>> 
>>> On Fri, Feb 5, 2010 at 1:55 PM, George Bonser <gbonser at seven.com> wrote:
>>>>> The current kit deals with packets rather than flows. Flows was
>>>>> investigated thoroughly and looks very much like a blind alley. It has
>>>>> some useful niches but the failure modes are catastrophic.
>>>> 
>>>> Yeah, I know that, but they tend to cache information regarding a flow.
>>> 
>>> huh? a CRS or T-series device doesn't cache anything about flows. each
>>> packet in turn on input is looked up in the FIB for send to the proper
>>> output interface. (extreme, as another vendor also doesn't cache flow
>>> info...)
>>> 
>>>> The cache isn't big enough is the problem I am worried about. ?Some gear
>>>> likes to populate the routes (FIB) in hardware and if you don't have
>>>> enough space, they don't all get in there. Chip density being what it
>>>> is, I would think that more storage is available in the same form factor
>>>> today than was available when the module was initially designed. ?It
>>> 
>>> See scudder's talk about 100g and how long you have to lookup before
>>> your input buffer is full with a full interface.
>>> 
>>> There are 2 parts to this problem (and this is wandering way off
>>> topic) size of the FIB and rate of change of the FIB.
>>> 
>>> Back to the original topic though... As to providing globally unique
>>> addresses to end sites who want this for their internal uses only,
>>> that seems like a worthy goal, to me. I have 2 concerns:
>>> 
>>> 1) creating another rfc1918-ish block. (registration of this space
>>> seems to avoid this)
>>> 2) leakages into the global table, unintended ones. (pulling from a
>>> set supernet seems to cover this concern as well)
>>> 
>> Why wouldn't we just allocate them normally, like any other block? ?If we
>> don't give them the 1918'ish status then we don't have to worry about
>> unintended consequences. ?Instead, it's up to the end user to make sure the
>> routes are not leaked but, if they are, they just end up in the DFZ with
>> everything else.
> 
> one of the original ideas was to lower the bar for 'internal use only'
> prefixes. For instance:
> 
> You run a large enterprise, you have some internal server things that
> you want v6 for but won't ever see the light of day.
> These servers/nets may interconnect with business partners today or as
> you M&A your way info infamy.
> You don't have 200 customers nor do you qualify for PI space (and you
> don't want that anyway), ULA doesn't provide enough uniqueness
> guarantee either...
> 
> I think the policy should be able to serve these folks, it should also
> make sure that providers have a simple method to drop these routes on
> ingress. Willy-Nilly assigning these from current allocations won't
> help the route filtering problem, lowering the bar across the board
> seems to be unpalatable.

It seems like we're back to ULA again.  It seems that we all want the same
thing, "unroutable" address space for internal use only.  There are any
number of reasons to have RFC 1918'ish space in v6 and the real difference
now is that, given the size of the v6 address space, we don't have to
allocate blocks to be used by all providers.  Instead, we're in a position
where we *can* give everyone their own block.

We could even do the old multicast thing and auto-assign a ULA (or whatever
it's called) block to each ARIN allocation.  In thinking about it, I do
agree that having a defined block for filtering purposes is preferred.
> 
>> I guess I'm thinking that it would be better to change the restriction on
>> 6.5.1.1 than create a new set of policies for "unconnected" networks.
> 
> 6.5.8 I think is more along the lines of the proposed users though
> (not LIR's but EndSites) isn't it?
> 
Agreed.  It might even need to be a 6.5.10.

Regards,

Mike

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

From michael.dillon at bt.com  Mon Feb 22 12:05:06 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Mon, 22 Feb 2010 17:05:06 -0000
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <C7A8128D.F96F3%mksmith@adhost.com>
Message-ID: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>

> It seems like we're back to ULA again.  It seems that we all 
> want the same thing, "unroutable" address space for internal 
> use only.  There are any number of reasons to have RFC 
> 1918'ish space in v6 and the real difference now is that, 
> given the size of the v6 address space, we don't have to 
> allocate blocks to be used by all providers.  Instead, we're 
> in a position where we *can* give everyone their own block.
> 
> We could even do the old multicast thing and auto-assign a 
> ULA (or whatever it's called) block to each ARIN allocation.  
> In thinking about it, I do agree that having a defined block 
> for filtering purposes is preferred.

GLOP addressing uses the 16-bit ASN to specify a /24 block 
of multicast addresses, if I remember correctly. So, if we
used the 32-bit ASN to specify a /48 block of private use
addresses, we could probably fit it in. 

I don't believe that this has ever been proposed before
so it may be worthwhile writing a draft to see what happens.
And why not also include the "assigned ULA" addresses in 
the draft as well. If people like one idea better than the
other, then simplify the draft.

So we would have

16 bits defined prefix for private use IPv6 addresses
32 bits ASN number
16 bits subnetting space
64 bits IIDs
Total 128 bits of IPv6 address.

And given that there are some private-use ASNs defined, that
gives everyone the option to use those private-use addresses
whether or not they have an assigned ASN. That is essentially
the same as RFC 1918 addresses in IPv4.

--Michael Dillon


From JOHN at egh.com  Mon Feb 22 12:19:44 2010
From: JOHN at egh.com (John Santos)
Date: Mon, 22 Feb 2010 12:19:44 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <1100222121447.428A-100000@Ives.egh.com>

On Mon, 22 Feb 2010 michael.dillon at bt.com wrote:

> > It seems like we're back to ULA again.  It seems that we all 
> > want the same thing, "unroutable" address space for internal 
> > use only.  There are any number of reasons to have RFC 
> > 1918'ish space in v6 and the real difference now is that, 
> > given the size of the v6 address space, we don't have to 
> > allocate blocks to be used by all providers.  Instead, we're 
> > in a position where we *can* give everyone their own block.
> > 
> > We could even do the old multicast thing and auto-assign a 
> > ULA (or whatever it's called) block to each ARIN allocation.  
> > In thinking about it, I do agree that having a defined block 
> > for filtering purposes is preferred.
> 
> GLOP addressing uses the 16-bit ASN to specify a /24 block 
> of multicast addresses, if I remember correctly. So, if we
> used the 32-bit ASN to specify a /48 block of private use
> addresses, we could probably fit it in. 
> 
> I don't believe that this has ever been proposed before
> so it may be worthwhile writing a draft to see what happens.
> And why not also include the "assigned ULA" addresses in 
> the draft as well. If people like one idea better than the
> other, then simplify the draft.
> 
> So we would have
> 
> 16 bits defined prefix for private use IPv6 addresses
> 32 bits ASN number
> 16 bits subnetting space
> 64 bits IIDs
> Total 128 bits of IPv6 address.
> 
> And given that there are some private-use ASNs defined, that
> gives everyone the option to use those private-use addresses
> whether or not they have an assigned ASN. That is essentially
> the same as RFC 1918 addresses in IPv4.
> 
> --Michael Dillon

People with private networks may not/probably don't have ASNs.

Same for people with legacy class "C" addesses that upstreams
refuse to route, but which are extemely useful for private internets
because they can't collide with customer/vendor/peer internal addresses,
unlike RFC1918.



-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From mcr at sandelman.ca  Mon Feb 22 14:11:24 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 22 Feb 2010 14:11:24 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <24397.1266865884@marajade.sandelman.ca>


>>>>> "michael" == michael dillon <michael.dillon at bt.com> writes:
    >> It seems like we're back to ULA again.  It seems that we all 
    >> want the same thing, "unroutable" address space for internal 
    >> use only.  There are any number of reasons to have RFC 
    >> 1918'ish space in v6 and the real difference now is that, 
    >> given the size of the v6 address space, we don't have to 
    >> allocate blocks to be used by all providers.  Instead, we're 
    >> in a position where we *can* give everyone their own block.
    >> 
    >> We could even do the old multicast thing and auto-assign a 
    >> ULA (or whatever it's called) block to each ARIN allocation.  
    >> In thinking about it, I do agree that having a defined block 
    >> for filtering purposes is preferred.

    michael> GLOP addressing uses the 16-bit ASN to specify a /24 block 
    michael> of multicast addresses, if I remember correctly. So, if we
    michael> used the 32-bit ASN to specify a /48 block of private use
    michael> addresses, we could probably fit it in. 

    michael> I don't believe that this has ever been proposed before
    michael> so it may be worthwhile writing a draft to see what happens.
    michael> And why not also include the "assigned ULA" addresses in 
    michael> the draft as well. If people like one idea better than the
    michael> other, then simplify the draft.

    michael> So we would have

    michael> 16 bits defined prefix for private use IPv6 addresses
    michael> 32 bits ASN number
    michael> 16 bits subnetting space
    michael> 64 bits IIDs
    michael> Total 128 bits of IPv6 address.

So this is basically a gift of a /48 to every owner of an ASN.
To most of them, they don't need an extra /48.  A few could use them,
but as John Santos says, most of the Enterprise types who need an
RFC1918 or swamp-class-C equivalent, they don't have an ASN already.

    michael> And given that there are some private-use ASNs defined, that
    michael> gives everyone the option to use those private-use addresses
    michael> whether or not they have an assigned ASN. That is essentially
    michael> the same as RFC 1918 addresses in IPv4.

The combination of the private-USE ASN with this proposal makes this
into EXACTLY rfc1918, aka "SITE-LOCAL" addresses.

This is a bad idea --- make it easy to get address space, and people
will use unique address space for unconnected things.  Your description
of COINs was very relevant.

So far I haven't seen a proposal (other than 103) which really addresses
this need.   It seems like the best answer is an RFC to be written to
tell IANA to delegate FC00::/16 to the RIRs.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 


From matthew at matthew.at  Mon Feb 22 14:29:26 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 22 Feb 2010 11:29:26 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <24397.1266865884@marajade.sandelman.ca>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>
Message-ID: <4B82DB16.8010105@matthew.at>

Michael Richardson wrote:
>
> So far I haven't seen a proposal (other than 103) which really addresses
> this need.   It seems like the best answer is an RFC to be written to
> tell IANA to delegate FC00::/16 to the RIRs.
>
>   
This is approximately what I said two weeks ago, and so I still agree 
entirely. If the RIR wants to hand out addresses which "will never be 
routed" then IETF needs to specify what bits are set that mean "never be 
routed", rather than "lets just pick a corner of space we've been delegated"

Matthew Kaufman


From bill at herrin.us  Mon Feb 22 15:15:49 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 22 Feb 2010 15:15:49 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B82DB16.8010105@matthew.at>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca> <4B82DB16.8010105@matthew.at>
Message-ID: <3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>

On Mon, Feb 22, 2010 at 2:29 PM, Matthew Kaufman <matthew at matthew.at> wrote:
> Michael Richardson wrote:
>> So far I haven't seen a proposal (other than 103) which really addresses
>> this need. ? It seems like the best answer is an RFC to be written to
>> tell IANA to delegate FC00::/16 to the RIRs.
>
> This is approximately what I said two weeks ago, and so I still agree
> entirely. If the RIR wants to hand out addresses which "will never be
> routed" then IETF needs to specify what bits are set that mean "never be
> routed", rather than "lets just pick a corner of space we've been delegated"

I concur as well. And if we want to hand out addresses for "may be
connected in the future" instead then they should meet the same
criteria as the ones for "are connected single-homed now."

One additional thought:  there's no hard and fast rule as to which has
to come first: the RFC or the policy. An obvious objection to the RFC
is that the RIRs haven't requested it. Having a policy in place for
what to do with the numbers might help "grease the skids" for an RFC.

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 joelja at bogus.com  Mon Feb 22 15:32:59 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 22 Feb 2010 21:32:59 +0100
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <28E139F46D45AF49A31950F88C497458054324FC@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458054324FC@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4B82E9FB.5030102@bogus.com>



michael.dillon at bt.com wrote:
>> You run a large enterprise, you have some internal server 
>> things that you want v6 for but won't ever see the light of day.
>> These servers/nets may interconnect with business partners 
>> today or as you M&A your way info infamy.
>> You don't have 200 customers nor do you qualify for PI space 
>> (and you don't want that anyway), ULA doesn't provide enough 
>> uniqueness guarantee either...
> 
> ULA random (FD00::/8) does not provide the uniqueness guarantee.
> There is another kind of ULA set aside for assignments to 
> organizations that would provide a uniqueness guarantee.

neither does rfc 1918... and yet, these same organzations run dozens of
parallel deployments of that.

if you're got a deployment that big, how can you possibly not be able
come up with a justification for the appropriate sized pi prefix, or put
differently whose request for such a prefix has been denied?

> The problem is that the IETF has not yet figured out how
> to manage assignments of FC00::/8.
> 
> As far as I know, there isn't currently an active Internet 
> draft on this topic.
> 
> --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 matthew at matthew.at  Mon Feb 22 16:01:10 2010
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 22 Feb 2010 13:01:10 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>
	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
Message-ID: <4B82F096.1030007@matthew.at>

William Herrin wrote:
>
> I concur as well. And if we want to hand out addresses for "may be
> connected in the future" instead then they should meet the same
> criteria as the ones for "are connected single-homed now."
>
>   
As long as those criteria cover "plan to soon be multihomed" 
situations... for example, I might be a large corporation preparing to 
deploy IPv6, have 4 IPv4 transit providers, and only one of them can do 
IPv6 today... so clearly when more of my transit providers can do v6, 
I'll be multi-homed. There should be no reason to renumber in this case.

I presume that this is already how it works, just like I can get an AS 
number because I am ordering circuits to (but am not yet present at) an 
exchange point.

Matthew Kaufman


From kkargel at polartel.com  Mon Feb 22 16:31:44 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 22 Feb 2010 15:31:44 -0600
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca> <4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD28876D4188@MAIL1.polartel.local>

What is the difference between networks (numbers is IPv4 think) that may be routed next year and networks that may be routed next week? In the end they are going to take the same number of slots and consume the same quantity of backbone at any point in time regardless of which pool they come from.

The discriminator here is not whether the networks will be globally routed, most everyone admits that is transmutable.  The discriminator is whether the networks are globally unique.  If they are in fact globally unique then the cost and acquisition requirements should be the same regardless of the intended use.  

There is no shortage of IPv6.  Get what you need, route what needs to be connected globally and don't route what doesn't, you are in control of your networks.  If you need separate blocks for internal and external networks then get them, you obviously have the requirements to justify the resources.  If you cannot justify another allocation then just carve out a block from your primary allocation for internal use and you are all set.  In the future when you want that network to go public all it takes is an adjustment to advertisement and/or firewall ACL's and you are off and running.  

I would much rather see liberalized allocation policies than restricted routing policies.  Let the ISP manage what is global and what is local by local policy according to local requirements.  

The simpler we can keep all of this the better off we will all be.  Complexity builds cost.  Simplicity engenders efficiency.  

 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of William Herrin
> Sent: Monday, February 22, 2010 2:16 PM
> To: matthew at matthew.at
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 Non-connected networks
> 
> On Mon, Feb 22, 2010 at 2:29 PM, Matthew Kaufman <matthew at matthew.at>
> wrote:
> > Michael Richardson wrote:
> >> So far I haven't seen a proposal (other than 103) which really
> addresses
> >> this need. ? It seems like the best answer is an RFC to be written to
> >> tell IANA to delegate FC00::/16 to the RIRs.
> >
> > This is approximately what I said two weeks ago, and so I still agree
> > entirely. If the RIR wants to hand out addresses which "will never be
> > routed" then IETF needs to specify what bits are set that mean "never be
> > routed", rather than "lets just pick a corner of space we've been
> delegated"
> 
> I concur as well. And if we want to hand out addresses for "may be
> connected in the future" instead then they should meet the same
> criteria as the ones for "are connected single-homed now."
> 
> One additional thought:  there's no hard and fast rule as to which has
> to come first: the RFC or the policy. An obvious objection to the RFC
> is that the RIRs haven't requested it. Having a policy in place for
> what to do with the numbers might help "grease the skids" for an RFC.
> 
> 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  Mon Feb 22 16:29:43 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 22 Feb 2010 13:29:43 -0800
Subject: [arin-ppml] Policy for connected vs. non-connected networks
Message-ID: <63F2A808-CF62-4722-B9B3-DCA15130FCA2@delong.com>

In the discussion of non-connected networks and the perceived need for a separate
policy to support them instead of just assigning numbers to meet uniqueness requirements
and taking ARIN out of the routing policy issue, it occurred to me that the following may not
be well understood by some of the people discussing this issue.


There are two semi-independent, but, interlinked finite resource pools.

Pool 1: IP Addresses -- easy.

Pool 2: DFZ Routing Table Slots -- complex.

ARIN is responsible for administering Pool 1 in accordance with policies set by the community.

ARIN is not and, IMHO, should not be responsible for managing pool 2. This should be left
to the people and organizations who actually run routers. It is possible for a company to
reject prefixes that are assigned by ARIN and still survive in business. Verizon is currently
rejecting ARIN assigned /48s as an example.

I believe that the ideal policy from an administration of unique numbers perspective would be
such that connected and non-connected networks can get the unique numbers they need
through a reasonable justification process. I do not believe that the community significantly
benefits from disparate policies for assignments of numbers to these two classes of use,
nor do I believe that membership in one of these classes is immutable. Connected networks
sometimes disconnect and disconnected networks sometimes connect.

Further, I believe that if we have a liberalized policy for acquisition of unique numbers
based on a claim that said numbers will not be connected, such numbers will end up
being abused for connected purposes in order to avoid the less liberal policies.

Owen



From farmer at umn.edu  Mon Feb 22 16:57:48 2010
From: farmer at umn.edu (David Farmer)
Date: Mon, 22 Feb 2010 15:57:48 -0600
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <4B82F096.1030007@matthew.at>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at>
Message-ID: <4B82FDDC.8080706@umn.edu>

This is wondering into a different subject so, I'm starting a new one.

Matthew Kaufman wrote:
> William Herrin wrote:
>>
>> I concur as well. And if we want to hand out addresses for "may be
>> connected in the future" instead then they should meet the same
>> criteria as the ones for "are connected single-homed now."
>>
>>   
> As long as those criteria cover "plan to soon be multihomed" 
> situations... for example, I might be a large corporation preparing to 
> deploy IPv6, have 4 IPv4 transit providers, and only one of them can do 
> IPv6 today... so clearly when more of my transit providers can do v6, 
> I'll be multi-homed. There should be no reason to renumber in this case.
> 
> I presume that this is already how it works, just like I can get an AS 
> number because I am ordering circuits to (but am not yet present at) an 
> exchange point.

So assuming you have a direct assignment of IPv4 from ARIN today, then 
in PP#107, you don't need to be multihomed to immediately get an IPv6 
assignment.  By the fact you have an IPv4 assignment directly from ARIN 
you qualify for an IPv6 assignment.

However, if you have IPv4 assignment from your provider then, you 
wouldn't automatically qualify for IPv6 because of a direct assignment 
from ARIN.  If you were IPv6 multihomed or immediately becoming 
multihomed, they you would qualify for an IPv6 assignment otherwise you 
would need to provide a more detail justification for an assignment.

I had thought about a clause in PP#107, that allowed those that are IPv4 
multihomed to immediately get an IPv6 assignment, regardless if you had 
a direct assignment from ARIN.  But I thought the IPv4 direct assignment 
would handle the majority of the cases, and wasn't sure it was actually 
needed.  If you think it is, I'd be willing to rethink that and probably 
add it in.

I believe for PP#106 there would be a separate block of addresses for 
multihomed assignments.  Therefore, you would have to renumber when you 
  become multihomed. Currently, I oppose this idea in PP#106, I think 
segregating assignment or allocation based on criteria other that size 
is a really bad idea.  With the possible exception of networks that 
never intend to be connected.  But that belongs back on the other 
subject line.

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


From kkargel at polartel.com  Mon Feb 22 17:06:07 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 22 Feb 2010 16:06:07 -0600
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <4B82FDDC.8080706@umn.edu>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at> <4B82FDDC.8080706@umn.edu>
Message-ID: <8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>

For my own edification, why are we treating IPv6 like it is a rare and precious commodity?  Wouldn't it actually be better for the community if the requirement for the base level IPv6 allocation were simply filling out the request form and paying the fee?  

This isn't like IPv4 where we needed to make sure that anyone who ever got any would actually use it..  I would suggest that the minimum assignment of IPv6 should be available simply for the asking (filling out the form with contact info) and payment of minimum fees.
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Farmer
> Sent: Monday, February 22, 2010 3:58 PM
> To: matthew at matthew.at
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] IPv6 Multihomed networks
> 
> This is wondering into a different subject so, I'm starting a new one.
> 
> Matthew Kaufman wrote:
> > William Herrin wrote:
> >>
> >> I concur as well. And if we want to hand out addresses for "may be
> >> connected in the future" instead then they should meet the same
> >> criteria as the ones for "are connected single-homed now."
> >>
> >>
> > As long as those criteria cover "plan to soon be multihomed"
> > situations... for example, I might be a large corporation preparing to
> > deploy IPv6, have 4 IPv4 transit providers, and only one of them can do
> > IPv6 today... so clearly when more of my transit providers can do v6,
> > I'll be multi-homed. There should be no reason to renumber in this case.
> >
> > I presume that this is already how it works, just like I can get an AS
> > number because I am ordering circuits to (but am not yet present at) an
> > exchange point.
> 
> So assuming you have a direct assignment of IPv4 from ARIN today, then
> in PP#107, you don't need to be multihomed to immediately get an IPv6
> assignment.  By the fact you have an IPv4 assignment directly from ARIN
> you qualify for an IPv6 assignment.
> 
> However, if you have IPv4 assignment from your provider then, you
> wouldn't automatically qualify for IPv6 because of a direct assignment
> from ARIN.  If you were IPv6 multihomed or immediately becoming
> multihomed, they you would qualify for an IPv6 assignment otherwise you
> would need to provide a more detail justification for an assignment.
> 
> I had thought about a clause in PP#107, that allowed those that are IPv4
> multihomed to immediately get an IPv6 assignment, regardless if you had
> a direct assignment from ARIN.  But I thought the IPv4 direct assignment
> would handle the majority of the cases, and wasn't sure it was actually
> needed.  If you think it is, I'd be willing to rethink that and probably
> add it in.
> 
> I believe for PP#106 there would be a separate block of addresses for
> multihomed assignments.  Therefore, you would have to renumber when you
>   become multihomed. Currently, I oppose this idea in PP#106, I think
> segregating assignment or allocation based on criteria other that size
> is a really bad idea.  With the possible exception of networks that
> never intend to be connected.  But that belongs back on the other
> subject line.
> 
> --
> ===============================================
> David Farmer               Email:farmer at umn.edu
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE	    Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> _______________________________________________
> 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  Mon Feb 22 17:14:24 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 22 Feb 2010 17:14:24 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <8695009A81378E48879980039EEDAD28876D4188@MAIL1.polartel.local>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca> <4B82DB16.8010105@matthew.at> 
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com> 
	<8695009A81378E48879980039EEDAD28876D4188@MAIL1.polartel.local>
Message-ID: <3c3e3fca1002221414r7d88c5dcu96aa38752af85687@mail.gmail.com>

On Mon, Feb 22, 2010 at 4:31 PM, Kevin Kargel <kkargel at polartel.com> wrote:
> What is the difference between networks (numbers is IPv4 think)
> that may be routed next year and networks that may be routed
> next week?

Hi Kevin,

The difference is the "needs basis." If I'm turning up a multihomed
network next week, I need a block of routable IP addresses. If I might
do so next year then I don't need those addresses yet and may never
need them.

My thoughts on the value of needs-based addressing in IPv6 are on
record, but until we choose to replace it with a smarter design, we
should continue doing a responsible job of evaluating need during the
assignment process. The routing system's cost and stability depends on
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 joelja at bogus.com  Mon Feb 22 17:19:31 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 22 Feb 2010 23:19:31 +0100
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <1100222121447.428A-100000@Ives.egh.com>
References: <1100222121447.428A-100000@Ives.egh.com>
Message-ID: <4B8302F3.1070903@bogus.com>



John Santos wrote:
> On Mon, 22 Feb 2010 michael.dillon at bt.com wrote:


> People with private networks may not/probably don't have ASNs.
> 
> Same for people with legacy class "C" addesses that upstreams
> refuse to route, but which are extemely useful for private internets
> because they can't collide with customer/vendor/peer internal addresses,
> unlike RFC1918.

if you don't adevertise it for log enough,chances are someone else will.

> 
> 


From farmer at umn.edu  Mon Feb 22 17:20:23 2010
From: farmer at umn.edu (David Farmer)
Date: Mon, 22 Feb 2010 16:20:23 -0600
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>	<4B82F096.1030007@matthew.at>
	<4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
Message-ID: <4B830327.3060808@umn.edu>

In PP#107, the standard I'm trying to work from is justified operational 
need.  I think even for IPv6 the standard shouldn't just be, I want it 
and here is my check.  I would like to see it be more like, I need it, 
here is why, and here is my check.  And, if the "why" is a common 
standard reason, it shouldn't take much more that telling ARIN what your 
reason is, like "I'm multihoming to the Internet".  If you want 
addresses for less standard reasons, you should still be able to get 
them, but you might need to provide more information for your 
justification.

Kevin Kargel wrote:
> For my own edification, why are we treating IPv6 like it is a rare and precious commodity?  Wouldn't it actually be better for the community if the requirement for the base level IPv6 allocation were simply filling out the request form and paying the fee?  
> 
> This isn't like IPv4 where we needed to make sure that anyone who ever got any would actually use it..  I would suggest that the minimum assignment of IPv6 should be available simply for the asking (filling out the form with contact info) and payment of minimum fees.
>  
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of David Farmer
>> Sent: Monday, February 22, 2010 3:58 PM
>> To: matthew at matthew.at
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] IPv6 Multihomed networks
>>
>> This is wondering into a different subject so, I'm starting a new one.
>>
>> Matthew Kaufman wrote:
>>> William Herrin wrote:
>>>> I concur as well. And if we want to hand out addresses for "may be
>>>> connected in the future" instead then they should meet the same
>>>> criteria as the ones for "are connected single-homed now."
>>>>
>>>>
>>> As long as those criteria cover "plan to soon be multihomed"
>>> situations... for example, I might be a large corporation preparing to
>>> deploy IPv6, have 4 IPv4 transit providers, and only one of them can do
>>> IPv6 today... so clearly when more of my transit providers can do v6,
>>> I'll be multi-homed. There should be no reason to renumber in this case.
>>>
>>> I presume that this is already how it works, just like I can get an AS
>>> number because I am ordering circuits to (but am not yet present at) an
>>> exchange point.
>> So assuming you have a direct assignment of IPv4 from ARIN today, then
>> in PP#107, you don't need to be multihomed to immediately get an IPv6
>> assignment.  By the fact you have an IPv4 assignment directly from ARIN
>> you qualify for an IPv6 assignment.
>>
>> However, if you have IPv4 assignment from your provider then, you
>> wouldn't automatically qualify for IPv6 because of a direct assignment
>> from ARIN.  If you were IPv6 multihomed or immediately becoming
>> multihomed, they you would qualify for an IPv6 assignment otherwise you
>> would need to provide a more detail justification for an assignment.
>>
>> I had thought about a clause in PP#107, that allowed those that are IPv4
>> multihomed to immediately get an IPv6 assignment, regardless if you had
>> a direct assignment from ARIN.  But I thought the IPv4 direct assignment
>> would handle the majority of the cases, and wasn't sure it was actually
>> needed.  If you think it is, I'd be willing to rethink that and probably
>> add it in.
>>
>> I believe for PP#106 there would be a separate block of addresses for
>> multihomed assignments.  Therefore, you would have to renumber when you
>>   become multihomed. Currently, I oppose this idea in PP#106, I think
>> segregating assignment or allocation based on criteria other that size
>> is a really bad idea.  With the possible exception of networks that
>> never intend to be connected.  But that belongs back on the other
>> subject line.
>>
>> --
>> ===============================================
>> David Farmer               Email:farmer at umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE	    Phone: 612-626-0815
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>> _______________________________________________
>> 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
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================


From JOHN at egh.com  Mon Feb 22 17:29:57 2010
From: JOHN at egh.com (John Santos)
Date: Mon, 22 Feb 2010 17:29:57 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B82E9FB.5030102@bogus.com>
Message-ID: <1100222172035.428C-100000@Ives.egh.com>

On Mon, 22 Feb 2010, Joel Jaeggli wrote:

> 
> 
> michael.dillon at bt.com wrote:
> >> You run a large enterprise, you have some internal server 
> >> things that you want v6 for but won't ever see the light of day.
> >> These servers/nets may interconnect with business partners 
> >> today or as you M&A your way info infamy.
> >> You don't have 200 customers nor do you qualify for PI space 
> >> (and you don't want that anyway), ULA doesn't provide enough 
> >> uniqueness guarantee either...
> > 
> > ULA random (FD00::/8) does not provide the uniqueness guarantee.
> > There is another kind of ULA set aside for assignments to 
> > organizations that would provide a uniqueness guarantee.
> 
> neither does rfc 1918... and yet, these same organzations run dozens of
> parallel deployments of that.

That's what we're trying to fix.

> 
> if you're got a deployment that big, how can you possibly not be able
> come up with a justification for the appropriate sized pi prefix, or put
> differently whose request for such a prefix has been denied?
> 

How big is "that big?"  We have about 200 hosts total, but private
routes to 4 different customers.  Without our legacy class C, we
would constantly be having to renumber in RFC1918 space.

We definitely could not qualify for PI under current rules.

We've already encountered collisions within RFC1918 due to trying to be
good net citizens and using RFC1918 for infrastucture, test networks,
VPNs, etc.  Which is worse, having 100 people trying to renumber 20,000
hosts or 1 person having to renumber 200 hosts?


> > The problem is that the IETF has not yet figured out how
> > to manage assignments of FC00::/8.
> > 
> > As far as I know, there isn't currently an active Internet 
> > draft on this topic.
> > 
> > --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.
> 
> 

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From farmer at umn.edu  Mon Feb 22 17:36:34 2010
From: farmer at umn.edu (David Farmer)
Date: Mon, 22 Feb 2010 16:36:34 -0600
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B8302F3.1070903@bogus.com>
References: <1100222121447.428A-100000@Ives.egh.com>
	<4B8302F3.1070903@bogus.com>
Message-ID: <4B8306F2.7030707@umn.edu>

Joel Jaeggli wrote:
> 
> John Santos wrote:
>> On Mon, 22 Feb 2010 michael.dillon at bt.com wrote:
> 
> 
>> People with private networks may not/probably don't have ASNs.
>>
>> Same for people with legacy class "C" addesses that upstreams
>> refuse to route, but which are extemely useful for private internets
>> because they can't collide with customer/vendor/peer internal addresses,
>> unlike RFC1918.
> 
> if you don't adevertise it for log enough,chances are someone else will.

This is the reason I'm at least willing to consider a way to filter 
"never to be advertised networks".  However, if/when resource 
certification (A.K.A. RPKI) come into common use this could be much less 
of a problem.  So, I'm not absolutely sure even these networks need to 
be filterable, especially in the long-term.  But, maybe in the near-term 
this could be helpful to prevent abuse, and what happens if RPKI is 
stillborn.

Just thinking out loud.

> _______________________________________________
> 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
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================


From joelja at bogus.com  Mon Feb 22 17:41:23 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Mon, 22 Feb 2010 23:41:23 +0100
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <1100222172035.428C-100000@Ives.egh.com>
References: <1100222172035.428C-100000@Ives.egh.com>
Message-ID: <4B830813.10601@bogus.com>



John Santos wrote:
> On Mon, 22 Feb 2010, Joel Jaeggli wrote:
> 
>>
>> michael.dillon at bt.com wrote:
>>>> You run a large enterprise, you have some internal server 
>>>> things that you want v6 for but won't ever see the light of day.
>>>> These servers/nets may interconnect with business partners 
>>>> today or as you M&A your way info infamy.
>>>> You don't have 200 customers nor do you qualify for PI space 
>>>> (and you don't want that anyway), ULA doesn't provide enough 
>>>> uniqueness guarantee either...
>>> ULA random (FD00::/8) does not provide the uniqueness guarantee.
>>> There is another kind of ULA set aside for assignments to 
>>> organizations that would provide a uniqueness guarantee.
>> neither does rfc 1918... and yet, these same organzations run dozens of
>> parallel deployments of that.
> 
> That's what we're trying to fix.
> 
>> if you're got a deployment that big, how can you possibly not be able
>> come up with a justification for the appropriate sized pi prefix, or put
>> differently whose request for such a prefix has been denied?
>>
> 
> How big is "that big?"  We have about 200 hosts total, but private
> routes to 4 different customers.  Without our legacy class C, we
> would constantly be having to renumber in RFC1918 space.

So your pi /48 request has been denied?

the ipv6 nrpm states the following:

6.5.8.1. Criteria
To qualify for a direct assignment, an organization must:
not be an IPv6 LIR; and qualify for an IPv4 assignment or allocation
from ARIN under the IPv4 policy currently in effect, or demonstrate
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
efficient utilization of all direct IPv4 assignments and allocations,
each of which must be covered by any current ARIN RSA, or be a
qualifying Community Network as defined in Section 2.8, with assignment
criteria defined in section 6.5.9.

*further reading backwards to 4.3.5*

4.3.5. Non-connected Networks

End-users not currently connected to an ISP and/or not planning to be
connected to the Internet are encouraged to use private IP address
numbers reserved for non-connected networks (see RFC 1918). When
private, non-connected networks require interconnectivity and the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
private IP address numbers are ineffective, globally unique addresses
may be requested and used to provide this interconnectivity.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


> We definitely could not qualify for PI under current rules.

Really?

> We've already encountered collisions within RFC1918 due to trying to be
> good net citizens and using RFC1918 for infrastucture, test networks,
> VPNs, etc.  Which is worse, having 100 people trying to renumber 20,000
> hosts or 1 person having to renumber 200 hosts?
> 
> 
>>> The problem is that the IETF has not yet figured out how
>>> to manage assignments of FC00::/8.
>>>
>>> As far as I know, there isn't currently an active Internet 
>>> draft on this topic.
>>>
>>> --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 kkargel at polartel.com  Mon Feb 22 17:42:27 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Mon, 22 Feb 2010 16:42:27 -0600
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <4B830327.3060808@umn.edu>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at> <4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
	<4B830327.3060808@umn.edu>
Message-ID: <8695009A81378E48879980039EEDAD28876D4191@MAIL1.polartel.local>


> 
> In PP#107, the standard I'm trying to work from is justified operational
> need.  I think even for IPv6 the standard shouldn't just be, I want it
> and here is my check.  I would like to see it be more like, I need it,
> here is why, and here is my check.  And, if the "why" is a common
> standard reason, it shouldn't take much more that telling ARIN what your
> reason is, like "I'm multihoming to the Internet".  If you want
> addresses for less standard reasons, you should still be able to get
> them, but you might need to provide more information for your
> justification.

I still think that needs-based allocation is antiquated IPv4 thinking.  What does it matter if someone gets some IPv6 space they don't need right now?  Would it be a bad thing if every household in the world got a /48 just because they wanted to?  Even if they are a single homed so what? 

The world may need to figure out how to route all those /48's, but that is not for ARIN to dictate.  When it becomes a reality the world will figure out a way to make it work.  Do I have all the answers right now?  Of course not.  Do I trust human ingenuity to figure it out?  Of course I do.


> 
> Kevin Kargel wrote:
> > For my own edification, why are we treating IPv6 like it is a rare and
> precious commodity?  Wouldn't it actually be better for the community if
> the requirement for the base level IPv6 allocation were simply filling out
> the request form and paying the fee?
> >
> > This isn't like IPv4 where we needed to make sure that anyone who ever
> got any would actually use it..  I would suggest that the minimum
> assignment of IPv6 should be available simply for the asking (filling out
> the form with contact info) and payment of minimum fees.
> >
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> >> Behalf Of David Farmer
> >> Sent: Monday, February 22, 2010 3:58 PM
> >> To: matthew at matthew.at
> >> Cc: arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] IPv6 Multihomed networks
> >>
> >> This is wondering into a different subject so, I'm starting a new one.
> >>
> >> Matthew Kaufman wrote:
> >>> William Herrin wrote:
> >>>> I concur as well. And if we want to hand out addresses for "may be
> >>>> connected in the future" instead then they should meet the same
> >>>> criteria as the ones for "are connected single-homed now."
> >>>>
> >>>>
> >>> As long as those criteria cover "plan to soon be multihomed"
> >>> situations... for example, I might be a large corporation preparing to
> >>> deploy IPv6, have 4 IPv4 transit providers, and only one of them can
> do
> >>> IPv6 today... so clearly when more of my transit providers can do v6,
> >>> I'll be multi-homed. There should be no reason to renumber in this
> case.
> >>>
> >>> I presume that this is already how it works, just like I can get an AS
> >>> number because I am ordering circuits to (but am not yet present at)
> an
> >>> exchange point.
> >> So assuming you have a direct assignment of IPv4 from ARIN today, then
> >> in PP#107, you don't need to be multihomed to immediately get an IPv6
> >> assignment.  By the fact you have an IPv4 assignment directly from ARIN
> >> you qualify for an IPv6 assignment.
> >>
> >> However, if you have IPv4 assignment from your provider then, you
> >> wouldn't automatically qualify for IPv6 because of a direct assignment
> >> from ARIN.  If you were IPv6 multihomed or immediately becoming
> >> multihomed, they you would qualify for an IPv6 assignment otherwise you
> >> would need to provide a more detail justification for an assignment.
> >>
> >> I had thought about a clause in PP#107, that allowed those that are
> IPv4
> >> multihomed to immediately get an IPv6 assignment, regardless if you had
> >> a direct assignment from ARIN.  But I thought the IPv4 direct
> assignment
> >> would handle the majority of the cases, and wasn't sure it was actually
> >> needed.  If you think it is, I'd be willing to rethink that and
> probably
> >> add it in.
> >>
> >> I believe for PP#106 there would be a separate block of addresses for
> >> multihomed assignments.  Therefore, you would have to renumber when you
> >>   become multihomed. Currently, I oppose this idea in PP#106, I think
> >> segregating assignment or allocation based on criteria other that size
> >> is a really bad idea.  With the possible exception of networks that
> >> never intend to be connected.  But that belongs back on the other
> >> subject line.
> >>
> >> --
> >> ===============================================
> >> David Farmer               Email:farmer at umn.edu
> >> Networking & Telecommunication Services
> >> Office of Information Technology
> >> University of Minnesota
> >> 2218 University Ave SE	    Phone: 612-626-0815
> >> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> >> ===============================================
> >> _______________________________________________
> >> 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
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE	    Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================


From JOHN at egh.com  Mon Feb 22 17:43:19 2010
From: JOHN at egh.com (John Santos)
Date: Mon, 22 Feb 2010 17:43:19 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B8302F3.1070903@bogus.com>
Message-ID: <1100222173936.428A-100000@Ives.egh.com>

On Mon, 22 Feb 2010, Joel Jaeggli wrote:

> 
> 
> John Santos wrote:
> > On Mon, 22 Feb 2010 michael.dillon at bt.com wrote:
> 
> 
> > People with private networks may not/probably don't have ASNs.
> > 
> > Same for people with legacy class "C" addesses that upstreams
> > refuse to route, but which are extemely useful for private internets
> > because they can't collide with customer/vendor/peer internal addresses,
> > unlike RFC1918.
> 
> if you don't adevertise it for log enough,chances are someone else will.
> 

Huh?  If someone else attempts to use our IP addresses on the Internet,
they *will* see lawyers.

If someone pulls our RDNS and replaces it with their own, ARIN will
need to talk to their own lawyers about their failure to adequately
safeguard the network infrastructure, and what the consequences will
be.

If you are talking about anything other than someone hijacking our
network, then you are as clear as mud.



-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From JOHN at egh.com  Mon Feb 22 18:34:06 2010
From: JOHN at egh.com (John Santos)
Date: Mon, 22 Feb 2010 18:34:06 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B830813.10601@bogus.com>
Message-ID: <1100222174556.428A-100000@Ives.egh.com>

On Mon, 22 Feb 2010, Joel Jaeggli wrote:

> 
> 
> John Santos wrote:
> > On Mon, 22 Feb 2010, Joel Jaeggli wrote:
> > 
> >>
> >> michael.dillon at bt.com wrote:
> >>>> You run a large enterprise, you have some internal server 
> >>>> things that you want v6 for but won't ever see the light of day.
> >>>> These servers/nets may interconnect with business partners 
> >>>> today or as you M&A your way info infamy.
> >>>> You don't have 200 customers nor do you qualify for PI space 
> >>>> (and you don't want that anyway), ULA doesn't provide enough 
> >>>> uniqueness guarantee either...
> >>> ULA random (FD00::/8) does not provide the uniqueness guarantee.
> >>> There is another kind of ULA set aside for assignments to 
> >>> organizations that would provide a uniqueness guarantee.
> >> neither does rfc 1918... and yet, these same organzations run dozens of
> >> parallel deployments of that.
> > 
> > That's what we're trying to fix.
> > 
> >> if you're got a deployment that big, how can you possibly not be able
> >> come up with a justification for the appropriate sized pi prefix, or put
> >> differently whose request for such a prefix has been denied?
> >>
> > 
> > How big is "that big?"  We have about 200 hosts total, but private
> > routes to 4 different customers.  Without our legacy class C, we
> > would constantly be having to renumber in RFC1918 space.
> 
> So your pi /48 request has been denied?
> 
> the ipv6 nrpm states the following:
> 
> 6.5.8.1. Criteria
> To qualify for a direct assignment, an organization must:
> not be an IPv6 LIR; and qualify for an IPv4 assignment or allocation
> from ARIN under the IPv4 policy currently in effect, or demonstrate
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> efficient utilization of all direct IPv4 assignments and allocations,
> each of which must be covered by any current ARIN RSA, or be a
> qualifying Community Network as defined in Section 2.8, with assignment
> criteria defined in section 6.5.9.
> 
> *further reading backwards to 4.3.5*
> 
> 4.3.5. Non-connected Networks
> 
> End-users not currently connected to an ISP and/or not planning to be
> connected to the Internet are encouraged to use private IP address
> numbers reserved for non-connected networks (see RFC 1918). When
> private, non-connected networks require interconnectivity and the
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> private IP address numbers are ineffective, globally unique addresses
> may be requested and used to provide this interconnectivity.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We *are* connected to an ISP, but use NAT for that.  So are we
connectedt or non-connected?

> 
> 
> > We definitely could not qualify for PI under current rules.
> 
> Really?

Current rules require efficient use of a /22.  We have less than
200 hosts (including DHCP address ranges for employees, customers,
and other vistors who need to hook up their laptops), and our
growth rate is very slow (60 to 180 over 17 years.)

> 
> > We've already encountered collisions within RFC1918 due to trying to be
> > good net citizens and using RFC1918 for infrastucture, test networks,
> > VPNs, etc.  Which is worse, having 100 people trying to renumber 20,000
> > hosts or 1 person having to renumber 200 hosts?
> > 
> > 
> >>> The problem is that the IETF has not yet figured out how
> >>> to manage assignments of FC00::/8.
> >>>
> >>> As far as I know, there isn't currently an active Internet 
> >>> draft on this topic.
> >>>
> >>> --Michael Dillon

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From joelja at bogus.com  Mon Feb 22 18:57:07 2010
From: joelja at bogus.com (Joel Jaeggli)
Date: Tue, 23 Feb 2010 00:57:07 +0100
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <1100222174556.428A-100000@Ives.egh.com>
References: <1100222174556.428A-100000@Ives.egh.com>
Message-ID: <4B8319D3.9070004@bogus.com>



John Santos wrote:
> On Mon, 22 Feb 2010, Joel Jaeggli wrote:
> 
>>
>> John Santos wrote:
>>> On Mon, 22 Feb 2010, Joel Jaeggli wrote:
>>>
>>>> michael.dillon at bt.com wrote:
>>>>>> You run a large enterprise, you have some internal server 
>>>>>> things that you want v6 for but won't ever see the light of day.
>>>>>> These servers/nets may interconnect with business partners 
>>>>>> today or as you M&A your way info infamy.
>>>>>> You don't have 200 customers nor do you qualify for PI space 
>>>>>> (and you don't want that anyway), ULA doesn't provide enough 
>>>>>> uniqueness guarantee either...
>>>>> ULA random (FD00::/8) does not provide the uniqueness guarantee.
>>>>> There is another kind of ULA set aside for assignments to 
>>>>> organizations that would provide a uniqueness guarantee.
>>>> neither does rfc 1918... and yet, these same organzations run dozens of
>>>> parallel deployments of that.
>>> That's what we're trying to fix.
>>>
>>>> if you're got a deployment that big, how can you possibly not be able
>>>> come up with a justification for the appropriate sized pi prefix, or put
>>>> differently whose request for such a prefix has been denied?
>>>>
>>> How big is "that big?"  We have about 200 hosts total, but private
>>> routes to 4 different customers.  Without our legacy class C, we
>>> would constantly be having to renumber in RFC1918 space.
>> So your pi /48 request has been denied?
>>
>> the ipv6 nrpm states the following:
>>
>> 6.5.8.1. Criteria
>> To qualify for a direct assignment, an organization must:
>> not be an IPv6 LIR; and qualify for an IPv4 assignment or allocation
>> from ARIN under the IPv4 policy currently in effect, or demonstrate
>>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> efficient utilization of all direct IPv4 assignments and allocations,
>> each of which must be covered by any current ARIN RSA, or be a
>> qualifying Community Network as defined in Section 2.8, with assignment
>> criteria defined in section 6.5.9.
>>
>> *further reading backwards to 4.3.5*
>>
>> 4.3.5. Non-connected Networks
>>
>> End-users not currently connected to an ISP and/or not planning to be
>> connected to the Internet are encouraged to use private IP address
>> numbers reserved for non-connected networks (see RFC 1918). When
>> private, non-connected networks require interconnectivity and the
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> private IP address numbers are ineffective, globally unique addresses
>> may be requested and used to provide this interconnectivity.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> We *are* connected to an ISP, but use NAT for that.  So are we
> connectedt or non-connected?

You stated that you have private non-internet customer interconnections.

>>
>>> We definitely could not qualify for PI under current rules.
>> Really?
> 
> Current rules require efficient use of a /22.  We have less than
> 200 hosts (including DHCP address ranges for employees, customers,
> and other vistors who need to hook up their laptops), and our
> growth rate is very slow (60 to 180 over 17 years.)

read 6.5.8.1 again:

"or demonstrate efficient utilization of all direct IPv4 assignments and
allocations."

You've got an ipv4 allocation, you fill out the request, demonstrate
your current utilization, demonstrate the need for private
interconnection and the /48 is likely to be yours.

>>> We've already encountered collisions within RFC1918 due to trying to be
>>> good net citizens and using RFC1918 for infrastucture, test networks,
>>> VPNs, etc.  Which is worse, having 100 people trying to renumber 20,000
>>> hosts or 1 person having to renumber 200 hosts?
>>>
>>>
>>>>> The problem is that the IETF has not yet figured out how
>>>>> to manage assignments of FC00::/8.
>>>>>
>>>>> As far as I know, there isn't currently an active Internet 
>>>>> draft on this topic.
>>>>>
>>>>> --Michael Dillon
> 


From owen at delong.com  Mon Feb 22 19:01:14 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 22 Feb 2010 16:01:14 -0800
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <1100222174556.428A-100000@Ives.egh.com>
References: <1100222174556.428A-100000@Ives.egh.com>
Message-ID: <F3DF5824-2D8B-491D-BCD4-26D17081D625@delong.com>


On Feb 22, 2010, at 3:34 PM, John Santos wrote:

> On Mon, 22 Feb 2010, Joel Jaeggli wrote:
> 
>> 
>> 
>> John Santos wrote:
>>> On Mon, 22 Feb 2010, Joel Jaeggli wrote:
>>> 
>>>> 
>>>> michael.dillon at bt.com wrote:
>>>>>> You run a large enterprise, you have some internal server 
>>>>>> things that you want v6 for but won't ever see the light of day.
>>>>>> These servers/nets may interconnect with business partners 
>>>>>> today or as you M&A your way info infamy.
>>>>>> You don't have 200 customers nor do you qualify for PI space 
>>>>>> (and you don't want that anyway), ULA doesn't provide enough 
>>>>>> uniqueness guarantee either...
>>>>> ULA random (FD00::/8) does not provide the uniqueness guarantee.
>>>>> There is another kind of ULA set aside for assignments to 
>>>>> organizations that would provide a uniqueness guarantee.
>>>> neither does rfc 1918... and yet, these same organzations run dozens of
>>>> parallel deployments of that.
>>> 
>>> That's what we're trying to fix.
>>> 
>>>> if you're got a deployment that big, how can you possibly not be able
>>>> come up with a justification for the appropriate sized pi prefix, or put
>>>> differently whose request for such a prefix has been denied?
>>>> 
>>> 
>>> How big is "that big?"  We have about 200 hosts total, but private
>>> routes to 4 different customers.  Without our legacy class C, we
>>> would constantly be having to renumber in RFC1918 space.
>> 
>> So your pi /48 request has been denied?
>> 
>> the ipv6 nrpm states the following:
>> 
>> 6.5.8.1. Criteria
>> To qualify for a direct assignment, an organization must:
>> not be an IPv6 LIR; and qualify for an IPv4 assignment or allocation
>> from ARIN under the IPv4 policy currently in effect, or demonstrate
>>          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> efficient utilization of all direct IPv4 assignments and allocations,
>> each of which must be covered by any current ARIN RSA, or be a
>> qualifying Community Network as defined in Section 2.8, with assignment
>> criteria defined in section 6.5.9.
>> 
>> *further reading backwards to 4.3.5*
>> 
>> 4.3.5. Non-connected Networks
>> 
>> End-users not currently connected to an ISP and/or not planning to be
>> connected to the Internet are encouraged to use private IP address
>> numbers reserved for non-connected networks (see RFC 1918). When
>> private, non-connected networks require interconnectivity and the
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> private IP address numbers are ineffective, globally unique addresses
>> may be requested and used to provide this interconnectivity.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> We *are* connected to an ISP, but use NAT for that.  So are we
> connectedt or non-connected?
> 
I believe you said you had a legacy class C.

If you sign the LRSA and show efficient use of that (180 hosts in a
class C would qualify), then, you meet the criteria of:

...or demonstrate efficient utilization of all direct IPv4 assignments
and allocations, each of which must be covered by any current
ARIN RSA...

Unless you have other assignments or allocations which are
either not covered (easy to fix) or not efficiently utilized (well
worth resolving).


>> 
>> 
>>> We definitely could not qualify for PI under current rules.
>> 
>> Really?
> 
> Current rules require efficient use of a /22.  We have less than
> 200 hosts (including DHCP address ranges for employees, customers,
> and other vistors who need to hook up their laptops), and our
> growth rate is very slow (60 to 180 over 17 years.)
> 
That's the current IPv4 policy, and, there is a policy proposal on the
table (2010-2) to change that to /24.  I would encourage you to support
that policy proposal if you feel that would improve things.

Owen



From steve at ibctech.ca  Mon Feb 22 19:19:23 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Mon, 22 Feb 2010 19:19:23 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B8306F2.7030707@umn.edu>
References: <1100222121447.428A-100000@Ives.egh.com>	<4B8302F3.1070903@bogus.com>
	<4B8306F2.7030707@umn.edu>
Message-ID: <4B831F0B.7010309@ibctech.ca>

On 2010.02.22 17:36, David Farmer wrote:
> Joel Jaeggli wrote:
>>
>> John Santos wrote:
>>> On Mon, 22 Feb 2010 michael.dillon at bt.com wrote:
>>
>>
>>> People with private networks may not/probably don't have ASNs.
>>>
>>> Same for people with legacy class "C" addesses that upstreams
>>> refuse to route, but which are extemely useful for private internets
>>> because they can't collide with customer/vendor/peer internal addresses,
>>> unlike RFC1918.
>>
>> if you don't adevertise it for log enough,chances are someone else will.
> 
> This is the reason I'm at least willing to consider a way to filter
> "never to be advertised networks".  However, if/when resource
> certification (A.K.A. RPKI) come into common use this could be much less
> of a problem.  So, I'm not absolutely sure even these networks need to
> be filterable, especially in the long-term.  But, maybe in the near-term
> this could be helpful to prevent abuse, and what happens if RPKI is
> stillborn.

This is why I think that ALL IP allocations/assignments should be
'within a block designated for that purpose'.

Steve


From steve at ibctech.ca  Mon Feb 22 19:23:53 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Mon, 22 Feb 2010 19:23:53 -0500
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <4B831F0B.7010309@ibctech.ca>
References: <1100222121447.428A-100000@Ives.egh.com>	<4B8302F3.1070903@bogus.com>	<4B8306F2.7030707@umn.edu>
	<4B831F0B.7010309@ibctech.ca>
Message-ID: <4B832019.8010209@ibctech.ca>

On 2010.02.22 19:19, Steve Bertrand wrote:
> On 2010.02.22 17:36, David Farmer wrote:
>> Joel Jaeggli wrote:
>>>
>>> John Santos wrote:
>>>> On Mon, 22 Feb 2010 michael.dillon at bt.com wrote:
>>>
>>>
>>>> People with private networks may not/probably don't have ASNs.
>>>>
>>>> Same for people with legacy class "C" addesses that upstreams
>>>> refuse to route, but which are extemely useful for private internets
>>>> because they can't collide with customer/vendor/peer internal addresses,
>>>> unlike RFC1918.
>>>
>>> if you don't adevertise it for log enough,chances are someone else will.
>>
>> This is the reason I'm at least willing to consider a way to filter
>> "never to be advertised networks".  However, if/when resource
>> certification (A.K.A. RPKI) come into common use this could be much less
>> of a problem.  So, I'm not absolutely sure even these networks need to
>> be filterable, especially in the long-term.  But, maybe in the near-term
>> this could be helpful to prevent abuse, and what happens if RPKI is
>> stillborn.
> 
> This is why I think that ALL IP allocations/assignments should be
> 'within a block designated for that purpose'.

To further a bit...

If you *think* that you might want to take your 'private' space public
some day, you have two choices...either apply for a global unique now,
or apply for space within the private arena and plan to renumber in the
future.

Steve


From mcr at sandelman.ca  Mon Feb 22 19:38:27 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 22 Feb 2010 19:38:27 -0500
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local> 
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>
	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at> <4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
Message-ID: <11099.1266885507@marajade.sandelman.ca>


>>>>> "Kevin" == Kevin Kargel <kkargel at polartel.com> writes:
    Kevin> For my own edification, why are we treating IPv6 like it is a
    Kevin> rare and precious commodity?  

ARIN AC distinctly gives me the impression that they think IPv6 is
a rare and precious thing. 

When pushed, someone says that there are concerns about routing slots, and
how someone might use unconnected network policy to go around ARIN
"routing policy" to get routable networks.  

When cross-examined about this, the community says that ARIN does not
concern itself with a policy about what gets routed --- contradicting the
concern over routing slots, and ignoring why we are asking for clearly
identifable bits of address space for non-connected networks so that it
won't be a concern.

What's clear to me is that ARIN as a community isn't interested in
solving this problem.  The IETF had considered this to be a RIR policy
issue for many years, but apparently it falls into a crack.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 




From steve at ibctech.ca  Mon Feb 22 19:39:07 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Mon, 22 Feb 2010 19:39:07 -0500
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <8695009A81378E48879980039EEDAD28876D4191@MAIL1.polartel.local>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>	<4B82F096.1030007@matthew.at>
	<4B82FDDC.8080706@umn.edu>	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>	<4B830327.3060808@umn.edu>
	<8695009A81378E48879980039EEDAD28876D4191@MAIL1.polartel.local>
Message-ID: <4B8323AB.2040601@ibctech.ca>

On 2010.02.22 17:42, Kevin Kargel wrote:
> 
>>
>> In PP#107, the standard I'm trying to work from is justified operational
>> need.  I think even for IPv6 the standard shouldn't just be, I want it
>> and here is my check.  I would like to see it be more like, I need it,
>> here is why, and here is my check.  And, if the "why" is a common
>> standard reason, it shouldn't take much more that telling ARIN what your
>> reason is, like "I'm multihoming to the Internet".  If you want
>> addresses for less standard reasons, you should still be able to get
>> them, but you might need to provide more information for your
>> justification.
> 
> I still think that needs-based allocation is antiquated IPv4 thinking.  What does it matter if someone gets some IPv6 space they don't need right now?  Would it be a bad thing if every household in the world got a /48 just because they wanted to?  Even if they are a single homed so what? 

I'm happy with this thinking. IPv6 for all... however...

> The world may need to figure out how to route all those /48's, but that is not for ARIN to dictate.  When it becomes a reality the world will figure out a way to make it work.  Do I have all the answers right now?  Of course not.  Do I trust human ingenuity to figure it out?  Of course I do.

it would be prudent for the community to come up with a solution so that
ARIN doesn't dictate operation policy, but makes it as easy as possible
for the ops and eng people to filter out what they don't want, in one
huge fell swoop.

If all single-homed /48's are within a single large block, it makes it
very easy for me to decide if I want to accept it or not, or at minimum,
it makes pref-lists easy to write/automate.

The 'give everyone v6' is a great theory in purpose, but I don't want my
hardware collapsing suddenly one day because ARIN gave out several /48s,
and they all light up at once without me being able to identify an easy
one-line method to stunt the collapse (even temporarily).

A baseline must be created, and operations must be involved. There has
to be a way to identify what 'type' of block you belong to.

Steve

ps. fwiw, I accept ALL /48 and shorter prefixes at this time.

Steve


From owen at delong.com  Mon Feb 22 19:59:52 2010
From: owen at delong.com (Owen DeLong)
Date: Mon, 22 Feb 2010 16:59:52 -0800
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <11099.1266885507@marajade.sandelman.ca>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>
	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at> <4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
	<11099.1266885507@marajade.sandelman.ca>
Message-ID: <71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>

I cannot speak for the entire AC, however:

1.	I do not think that IPv6 is a rare or precious commodity.
2.	I do think we need some controls on IPv6 or it will become such.
3.	I do think that there is a lot of pushback in the community when
	we try to create policies that do not take routing policy into
	account. Personally, I wish that we could focus strictly on
	numbering policy and leave routing policy out of ARIN policy,
	but, the community thus far has been unwilling to allow that.
	There are members of the AC and members of the community
	on both sides of this question.
4.	I have expressed concerns and continue to have concerns that
	if we create two classes of address space and make one significantly
	easier and/or cheaper to obtain than the other based on the
	belief that we can draw a magic line in the sand about routable
	or not, we are going to learn the following lessons:

	1.	Magic lines don't work.
	2.	People will obtain the resources they need through the path
		of least resistance, then, push for those resources to fit their
		needs regardless of original intent of resource policy.

		(Think about people who buy inexpensive houses next
		to airports, then complain about airplane noise and try
		to have the airport removed.)

	In other words, I think that "non-routable" space would get
	routed and the policies for routable space would become
	irrelevant.

I'm all for relaxing the policies for routable space. I'm opposed
to replacing them with a policy which was put in place under the
guise of creating "non-routable" space.

Making assignments for various things out of "a block reserved for
that purpose" essentially creates an artificial class system. Such
systems mostly serve to promote discrimination and allow members
of some subset of the classes to facilitate subjugation of members
of other classes.  Often, this is viewed as desirable by the members
of the subjugating classes.  Rarely is it considered ideal by the
members of the subjugated classes.

Owen

On Feb 22, 2010, at 4:38 PM, Michael Richardson wrote:

> 
>>>>>> "Kevin" == Kevin Kargel <kkargel at polartel.com> writes:
>    Kevin> For my own edification, why are we treating IPv6 like it is a
>    Kevin> rare and precious commodity?  
> 
> ARIN AC distinctly gives me the impression that they think IPv6 is
> a rare and precious thing. 
> 
> When pushed, someone says that there are concerns about routing slots, and
> how someone might use unconnected network policy to go around ARIN
> "routing policy" to get routable networks.  
> 
> When cross-examined about this, the community says that ARIN does not
> concern itself with a policy about what gets routed --- contradicting the
> concern over routing slots, and ignoring why we are asking for clearly
> identifable bits of address space for non-connected networks so that it
> won't be a concern.
> 
> What's clear to me is that ARIN as a community isn't interested in
> solving this problem.  The IETF had considered this to be a RIR policy
> issue for many years, but apparently it falls into a crack.
> 
> -- 
> ]       He who is tired of Weird Al is tired of life!           |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition. 
> 
> 
> _______________________________________________
> 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 steve at ibctech.ca  Mon Feb 22 20:33:14 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Mon, 22 Feb 2010 20:33:14 -0500
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>	<4B82F096.1030007@matthew.at>
	<4B82FDDC.8080706@umn.edu>	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>	<11099.1266885507@marajade.sandelman.ca>
	<71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>
Message-ID: <4B83305A.7020409@ibctech.ca>

On 2010.02.22 19:59, Owen DeLong wrote:
> I cannot speak for the entire AC, however:

> I'm all for relaxing the policies for routable space. I'm opposed
> to replacing them with a policy which was put in place under the
> guise of creating "non-routable" space.
> 
> Making assignments for various things out of "a block reserved for
> that purpose" essentially creates an artificial class system. 

Then there should be no distinction between 'private' and 'public', and
there should be no difference in policy requirements for acquiring either.

imho, if this is the case, then the entire discussion of "Non-connected
networks" is futile, isn't it?

I mean, if you already know that the path of least resistance is already
going to be allowed, why bother creating policy?

Steve


From mcr at sandelman.ca  Mon Feb 22 20:47:01 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Mon, 22 Feb 2010 20:47:01 -0500
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com> 
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>
	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at> <4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
	<11099.1266885507@marajade.sandelman.ca>
	<71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com> 
Message-ID: <15968.1266889621@marajade.sandelman.ca>


Owen, I want to thank you for so clearly articulating the connection
between routing policy and numbering policy.

I am not disputing anything you write.

I want to point out that in IPv6, (SM)Enterprises and individuals are
already a subjugated class.  We are expected to use PA addresses.

Non-connected address spaces gives us freedom to change ISPs without
disrupting the internal network.

To those that say you can't run multiple prefixes on the same wire ---
it's true that there are issues, but it does work, and it does let you
change ISPs, and I've done it repeatedly.  

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 


From steve at ibctech.ca  Mon Feb 22 20:51:14 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Mon, 22 Feb 2010 20:51:14 -0500
Subject: [arin-ppml] Policy for connected vs. non-connected networks
In-Reply-To: <63F2A808-CF62-4722-B9B3-DCA15130FCA2@delong.com>
References: <63F2A808-CF62-4722-B9B3-DCA15130FCA2@delong.com>
Message-ID: <4B833492.1000704@ibctech.ca>

On 2010.02.22 16:29, Owen DeLong wrote:
> In the discussion of non-connected networks and the perceived need for a separate
> policy to support them instead of just assigning numbers to meet uniqueness requirements
> and taking ARIN out of the routing policy issue, it occurred to me that the following may not
> be well understood by some of the people discussing this issue.
> 
> 
> There are two semi-independent, but, interlinked finite resource pools.
> 
> Pool 1: IP Addresses -- easy.
> 
> Pool 2: DFZ Routing Table Slots -- complex.
> 
> ARIN is responsible for administering Pool 1 in accordance with policies set by the community.
> 
> ARIN is not and, IMHO, should not be responsible for managing pool 2. This should be left
> to the people and organizations who actually run routers. It is possible for a company to
> reject prefixes that are assigned by ARIN and still survive in business. Verizon is currently
> rejecting ARIN assigned /48s as an example.
> 
> I believe that the ideal policy from an administration of unique numbers perspective would be
> such that connected and non-connected networks can get the unique numbers they need
> through a reasonable justification process. I do not believe that the community significantly
> benefits from disparate policies for assignments of numbers to these two classes of use,
> nor do I believe that membership in one of these classes is immutable. Connected networks
> sometimes disconnect and disconnected networks sometimes connect.
> 
> Further, I believe that if we have a liberalized policy for acquisition of unique numbers
> based on a claim that said numbers will not be connected, such numbers will end up
> being abused for connected purposes in order to avoid the less liberal policies.

If this is the case, then I propose that all (currently available global
unique) IP(v6) space be merged into one, and that all current and
proposed policies that deal with 'non-connected' or otherwise 'private'
IP space be abolished, and no distinction shall be made between the two.

One policy for all, no matter what.

Steve


From bill at herrin.us  Mon Feb 22 22:38:55 2010
From: bill at herrin.us (William Herrin)
Date: Mon, 22 Feb 2010 22:38:55 -0500
Subject: [arin-ppml] Policy for connected vs. non-connected networks
In-Reply-To: <63F2A808-CF62-4722-B9B3-DCA15130FCA2@delong.com>
References: <63F2A808-CF62-4722-B9B3-DCA15130FCA2@delong.com>
Message-ID: <3c3e3fca1002221938y4dd4c23drf13d67703ca69da5@mail.gmail.com>

On Mon, Feb 22, 2010 at 4:29 PM, Owen DeLong <owen at delong.com> wrote:
> There are two semi-independent, but, interlinked finite resource pools.
>
> Pool 1: IP Addresses -- easy.
> Pool 2: DFZ Routing Table Slots -- complex.
>
> ARIN is responsible for administering Pool 1 in accordance
>with policies set by the community.
>
> ARIN is not and, IMHO, should not be responsible for
>managing pool 2. This should be left to the people and
>organizations who actually run routers.


Then start thinking about how you want to restructure ARIN's process
to facilitate route filtering and management by third parties because
with ARIN's current process, it and the other RIRs are the only ones
in a position to prevent a tragedy-of-the-commons style routing
explosion, whether that's a task ARIN should be doing 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 michael.dillon at bt.com  Tue Feb 23 05:48:42 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Tue, 23 Feb 2010 10:48:42 -0000
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C49745805432A84@E03MVZ2-UKDY.domain1.systemhost.net>


> One additional thought:  there's no hard and fast rule as to 
> which has to come first: the RFC or the policy. An obvious 
> objection to the RFC is that the RIRs haven't requested it. 
> Having a policy in place for what to do with the numbers 
> might help "grease the skids" for an RFC.

In this case there is. We don't know what /16 block will
be set aside for this use. That is the IETF's job, and in
doing that, they could make any number of other changes
to a proposal.

We really should not waste more time discussing this,
because if folks really want to do it, they can write
an Internet draft and take it to the IETF.

--Michael Dillon


From kkargel at polartel.com  Tue Feb 23 11:30:20 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 23 Feb 2010 10:30:20 -0600
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <4B83305A.7020409@ibctech.ca>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at>	<4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
	<11099.1266885507@marajade.sandelman.ca>
	<71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>
	<4B83305A.7020409@ibctech.ca>
Message-ID: <8695009A81378E48879980039EEDAD28876D41A0@MAIL1.polartel.local>

> 
> On 2010.02.22 19:59, Owen DeLong wrote:
> > I cannot speak for the entire AC, however:
> 
> > I'm all for relaxing the policies for routable space. I'm opposed
> > to replacing them with a policy which was put in place under the
> > guise of creating "non-routable" space.
> >
> > Making assignments for various things out of "a block reserved for
> > that purpose" essentially creates an artificial class system.
> 
> Then there should be no distinction between 'private' and 'public', and
> there should be no difference in policy requirements for acquiring either.
> 
> imho, if this is the case, then the entire discussion of "Non-connected
> networks" is futile, isn't it?
> 
> I mean, if you already know that the path of least resistance is already
> going to be allowed, why bother creating policy?
> 
> Steve
> _______________________________________________

This is my point exactly in all of this.  To my way of thinking you should be able to apply for and receive a block of IPv6 because you have some need for it.  Think of that block as containing both routed and non-routed space and 'wow', you get to decide for yourself how much you want to route globally and how much you don't want to route, then you adjust your advertisements and firewalls accordingly.  

You get the space, you can route it or not route it, you set the borders, and you can change the borders whenever you want.

So long as you keep your contact information current and pay your fees your assignment remains valid, whether you actually route it or not.

I see no reason for setting aside special non-routed space in the pool when you can already use your assigned space and you don't have to route it.

If we did create a separate pool for some reason, then IMHO it depletes the pool the same as any other reason and should have the same requirements.

So yes, as you said "the entire discussion of "Non-connected networks" is futile"




From kkargel at polartel.com  Tue Feb 23 11:31:31 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 23 Feb 2010 10:31:31 -0600
Subject: [arin-ppml] Policy for connected vs. non-connected networks
In-Reply-To: <4B833492.1000704@ibctech.ca>
References: <63F2A808-CF62-4722-B9B3-DCA15130FCA2@delong.com>
	<4B833492.1000704@ibctech.ca>
Message-ID: <8695009A81378E48879980039EEDAD28876D41A1@MAIL1.polartel.local>


> If this is the case, then I propose that all (currently available global
> unique) IP(v6) space be merged into one, and that all current and
> proposed policies that deal with 'non-connected' or otherwise 'private'
> IP space be abolished, and no distinction shall be made between the two.
> 
> One policy for all, no matter what.
> 
> Steve


I concur and second your proposal

Kevin


From marla.azinger at frontiercorp.com  Tue Feb 23 11:33:25 2010
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Tue, 23 Feb 2010 11:33:25 -0500
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <4B83305A.7020409@ibctech.ca>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at>	<4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
	<11099.1266885507@marajade.sandelman.ca>
	<71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>
	<4B83305A.7020409@ibctech.ca>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048529C0CB5@ROCH-EXCH1.corp.pvt>

Creating policy that wont be followed by networks makes the publishing organization look ineffective.  

Writing policy that isn't part of an organizations charter shouldn't be supported.  

Writing BCP where it belongs should be supported.

Cheers
Marla

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steve Bertrand
Sent: Monday, February 22, 2010 5:33 PM
To: Owen DeLong
Cc: 'arin-ppml at arin.net'
Subject: Re: [arin-ppml] IPv6 Multihomed networks

On 2010.02.22 19:59, Owen DeLong wrote:
> I cannot speak for the entire AC, however:

> I'm all for relaxing the policies for routable space. I'm opposed to 
> replacing them with a policy which was put in place under the guise of 
> creating "non-routable" space.
> 
> Making assignments for various things out of "a block reserved for 
> that purpose" essentially creates an artificial class system.

Then there should be no distinction between 'private' and 'public', and there should be no difference in policy requirements for acquiring either.

imho, if this is the case, then the entire discussion of "Non-connected networks" is futile, isn't it?

I mean, if you already know that the path of least resistance is already going to be allowed, why bother creating policy?

Steve
_______________________________________________
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 marla.azinger at frontiercorp.com  Tue Feb 23 11:37:03 2010
From: marla.azinger at frontiercorp.com (Azinger, Marla)
Date: Tue, 23 Feb 2010 11:37:03 -0500
Subject: [arin-ppml] Policy for connected vs. non-connected networks
In-Reply-To: <8695009A81378E48879980039EEDAD28876D41A1@MAIL1.polartel.local>
References: <63F2A808-CF62-4722-B9B3-DCA15130FCA2@delong.com>
	<4B833492.1000704@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D41A1@MAIL1.polartel.local>
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048529C0CC8@ROCH-EXCH1.corp.pvt>

Removing a form of class addressing would be a good move.

Managing IP Addresses for contiguous growth would be a good move. 

Cheers
Marla

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
Sent: Tuesday, February 23, 2010 8:32 AM
To: 'Steve Bertrand'; 'Owen DeLong'
Cc: 'arin ppml'
Subject: Re: [arin-ppml] Policy for connected vs. non-connected networks


> If this is the case, then I propose that all (currently available 
> global
> unique) IP(v6) space be merged into one, and that all current and 
> proposed policies that deal with 'non-connected' or otherwise 'private'
> IP space be abolished, and no distinction shall be made between the two.
> 
> One policy for all, no matter what.
> 
> Steve


I concur and second your proposal

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 farmer at umn.edu  Tue Feb 23 12:09:04 2010
From: farmer at umn.edu (David Farmer)
Date: Tue, 23 Feb 2010 11:09:04 -0600
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <8695009A81378E48879980039EEDAD28876D41A0@MAIL1.polartel.local>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>	<4B82F096.1030007@matthew.at>	<4B82FDDC.8080706@umn.edu>	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>	<11099.1266885507@marajade.sandelman.ca>	<71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>	<4B83305A.7020409@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D41A0@MAIL1.polartel.local>
Message-ID: <4B840BB0.5060506@umn.edu>

Kevin Kargel wrote:
>> On 2010.02.22 19:59, Owen DeLong wrote:
>>> I cannot speak for the entire AC, however:
>>> I'm all for relaxing the policies for routable space. I'm opposed
>>> to replacing them with a policy which was put in place under the
>>> guise of creating "non-routable" space.
>>>
>>> Making assignments for various things out of "a block reserved for
>>> that purpose" essentially creates an artificial class system.
>> Then there should be no distinction between 'private' and 'public', and
>> there should be no difference in policy requirements for acquiring either.
>>
>> imho, if this is the case, then the entire discussion of "Non-connected
>> networks" is futile, isn't it?
>>
>> I mean, if you already know that the path of least resistance is already
>> going to be allowed, why bother creating policy?
>>
>> Steve
>> _______________________________________________
> 
> This is my point exactly in all of this.  To my way of thinking you should be able to apply for and receive a block of IPv6 because you have some need for it.  

I agree, but I believe it is not unreasonable for you to explain that 
need to some extent to ARIN.  I don't want to make it a burden, but some 
checks and balances are usually a good thing.

> Think of that block as containing both routed and non-routed space and 'wow', you get to decide for yourself how much you want to route globally and how much you don't want to route, then you adjust your advertisements and firewalls accordingly.  
>
> You get the space, you can route it or not route it, you set the borders, and you can change the borders whenever you want. 
>
> So long as you keep your contact information current and pay your fees your assignment remains valid, whether you actually route it or not.
> 
> I see no reason for setting aside special non-routed space in the pool when you can already use your assigned space and you don't have to route it.
> 
> If we did create a separate pool for some reason, then IMHO it depletes the pool the same as any other reason and should have the same requirements.

I mostly agree with this, and if I put on my "I believe in RPKI" hat on 
then no problem.  But, if RPKI doesn't happen, then this non-routed 
space could create abuse problems, and make a place for bad guys to make 
a home. So I think this has been an important discussion.

> So yes, as you said "the entire discussion of "Non-connected networks" is futile"

I'll just say that I don't think this discussion has been futile at all, 
  I believe it may be heading us toward a consensus.  And, if we finally 
get to a consensus then I believe it has been a very productive discussion.

I have no illusions that PP#101, PP#106 or PP#107 will end up as policy 
as they are currently written.  Sometimes the important thing is to put 
things in front of people and let them take their shots at them.

So please keep shooting at them.

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


From kkargel at polartel.com  Tue Feb 23 12:17:31 2010
From: kkargel at polartel.com (Kevin Kargel)
Date: Tue, 23 Feb 2010 11:17:31 -0600
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <4B840BB0.5060506@umn.edu>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at>	<4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
	<11099.1266885507@marajade.sandelman.ca>
	<71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>
	<4B83305A.7020409@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D41A0@MAIL1.polartel.local>
	<4B840BB0.5060506@umn.edu>
Message-ID: <8695009A81378E48879980039EEDAD28876D41A4@MAIL1.polartel.local>


> I'll just say that I don't think this discussion has been futile at all,
>   I believe it may be heading us toward a consensus.  And, if we finally
> get to a consensus then I believe it has been a very productive
> discussion.
> 
> I have no illusions that PP#101, PP#106 or PP#107 will end up as policy
> as they are currently written.  Sometimes the important thing is to put
> things in front of people and let them take their shots at them.
> 
> So please keep shooting at them.
> 
That was bad quoting on my part earlier..  I also believe that the discussion has had great merit.  I laud and appreciate all the work and thought that has gone in to all the proposals being discussed.


From terry.l.davis at boeing.com  Tue Feb 23 12:20:31 2010
From: terry.l.davis at boeing.com (Davis, Terry L)
Date: Tue, 23 Feb 2010 09:20:31 -0800
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <4B83305A.7020409@ibctech.ca>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.s
	ystemhost.net>	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@m
	atthew.at>	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>	<4
	B82F096.1030007@matthew.at><4B82FDDC.8080706@umn.edu>	<8695009A81378E488799
	80039EEDAD28876D418C@MAIL1.polartel.local>	<11099.1266885507@marajade.sande
	lman.ca><71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>
	<4B83305A.7020409@ibctech.ca>
Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF551547BB3C@XCH-NW-05V.nw.nos.boeing.com>

Steve

I fully agree; there should be no differences between public and private or routed and non-routed.  

- If I were a startup initially operating single homed and then grew into a large company with true "business continuity requirements" (or became identified as "critical infrastructure" with potential legislated reliability reqs), would I then have to re-address my entire company to be dual-homed?

- Likewise if as initially planned ICAO (International Civil Aviation Organization), begins operating the next generation global "air traffic control network" as an IPv6 closed network, and then years later unseen technical issues or just changes in the Internet infrastructure requires them to become routed, would you suggest that we try to then re-number their entire global IPv6 "air traffic control network" to become routable?  (Which would honestly be both politically and technically impossible once it was globally deployed!) 

One set of rules for all seems like the only way to go forward.

Take care
Terry
 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steve Bertrand
> Sent: Monday, February 22, 2010 5:33 PM
> To: Owen DeLong
> Cc: 'arin-ppml at arin.net'
> Subject: Re: [arin-ppml] IPv6 Multihomed networks
> 
> On 2010.02.22 19:59, Owen DeLong wrote:
> > I cannot speak for the entire AC, however:
> 
> > I'm all for relaxing the policies for routable space. I'm opposed
> > to replacing them with a policy which was put in place under the
> > guise of creating "non-routable" space.
> > 
> > Making assignments for various things out of "a block reserved for
> > that purpose" essentially creates an artificial class system. 
> 
> Then there should be no distinction between 'private' and 
> 'public', and
> there should be no difference in policy requirements for 
> acquiring either.
> 
> imho, if this is the case, then the entire discussion of 
> "Non-connected
> networks" is futile, isn't it?
> 
> I mean, if you already know that the path of least resistance 
> is already
> going to be allowed, why bother creating policy?
> 
> Steve
> _______________________________________________
> 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 mcr at sandelman.ca  Tue Feb 23 14:43:22 2010
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 23 Feb 2010 14:43:22 -0500
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <8695009A81378E48879980039EEDAD28876D41A0@MAIL1.polartel.local> 
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<24397.1266865884@marajade.sandelman.ca>
	<4B82DB16.8010105@matthew.at>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>
	<4B82F096.1030007@matthew.at> <4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
	<11099.1266885507@marajade.sandelman.ca>
	<71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>
	<4B83305A.7020409@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D41A0@MAIL1.polartel.local>
Message-ID: <23747.1266954202@marajade.sandelman.ca>


For those that feel that ARIN can never keep unconnected networks from
being routed globally, I wonder if you'd take the time to read the SIDR
work from IETF.

Consider what would happen if ARIN were to issue non-connected network
space, and bind it's use to a specific (dummy) ASN.  Once secure, the
public ("Internet") BGP system would never accept an announcement from
anyone attempting to announce that prefix from another ASN.

If some group of enterprises needed to do (I)BGP on their non-connected
networks (such as for VPN use), they would either create an exception to
SBGP, or they would introduce a second SIDR root CA into their routers.
(This is commonly done in S/MIME email system and HTTPS systems in many
enterprises)

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 




From scottleibrand at gmail.com  Tue Feb 23 14:48:14 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 23 Feb 2010 11:48:14 -0800
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <23747.1266954202@marajade.sandelman.ca>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>	<24397.1266865884@marajade.sandelman.ca>	<4B82DB16.8010105@matthew.at>	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com>	<4B82F096.1030007@matthew.at>
	<4B82FDDC.8080706@umn.edu>	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>	<11099.1266885507@marajade.sandelman.ca>	<71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com>	<4B83305A.7020409@ibctech.ca>	<8695009A81378E48879980039EEDAD28876D41A0@MAIL1.polartel.local>
	<23747.1266954202@marajade.sandelman.ca>
Message-ID: <4B8430FE.2080505@gmail.com>

I think most people understand that a SIDR/rPKI system would  make this 
problem go away.  The big question is when such a system will ever be 
deployed, and whether policy can safely assume it will be soon enough.   
How foggy is your crystal ball on that subject?  :-)

-Scott

On Tue 2/23/2010 11:43 AM, Michael Richardson wrote:
> For those that feel that ARIN can never keep unconnected networks from
> being routed globally, I wonder if you'd take the time to read the SIDR
> work from IETF.
>
> Consider what would happen if ARIN were to issue non-connected network
> space, and bind it's use to a specific (dummy) ASN.  Once secure, the
> public ("Internet") BGP system would never accept an announcement from
> anyone attempting to announce that prefix from another ASN.
>
> If some group of enterprises needed to do (I)BGP on their non-connected
> networks (such as for VPN use), they would either create an exception to
> SBGP, or they would introduce a second SIDR root CA into their routers.
> (This is commonly done in S/MIME email system and HTTPS systems in many
> enterprises)
>
>    


From info at arin.net  Tue Feb 23 15:23:29 2010
From: info at arin.net (Member Services)
Date: Tue, 23 Feb 2010 15:23:29 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - February 2010
Message-ID: <4B843941.2070209@arin.net>

In accordance with the ARIN Policy Development Process (PDP), the ARIN
Advisory Council (AC) held a meeting on 18 February and made decisions
about several policy proposals.

The AC selected the following proposals as draft policies for adoption
discussion online and at the April Public Policy Meeting in Toronto.
Each draft policy will be posted shortly to the PPML.

   107. Rework of IPv6 assignment criteria
   106. Simplified IPv6 policy
   105. Simplified M&A transfer policy
   102. Reduce and Simplify IPv4 Initial Allocations
   101. Multihomed initial allocation criteria

The AC accepted the following proposals on to the AC's docket for
development and evaluation.

   109. Standardize IP Reassignment Registration Requirements

The AC abandoned proposal "108. Eliminate the term license in the NRPM",
so that ARIN Counsel and staff may develop an administrative change with
the appropriate language. Per existing practice, such a change will be
sent to the ARIN AC for their review prior to action by the ARIN Board
of Trustees.

The PDP states, ?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.? The abandonment of proposal 108 may be petitioned.
Proposal 109 may be petitioned because it was not selected for adoption
discussion. The original versions of proposals 101, 102, 105, 106 and
107 may also be petitioned (if the original text is preferred over the
resulting draft policy text). The purpose of a petition would be to
change the proposal into a draft policy for discussion on the Public
Policy Mailing List and at the April meeting. The deadline to begin a
petition is 2 March 2010.

For more information on starting and participating in petitions, see PDP
Petitions at: https://www.arin.net/policy/pdp_petitions.html

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 info at arin.net  Tue Feb 23 15:23:46 2010
From: info at arin.net (Member Services)
Date: Tue, 23 Feb 2010 15:23:46 -0500
Subject: [arin-ppml] Draft Policy 2010-4: Rework of IPv6 allocation criteria
Message-ID: <4B843952.3080708@arin.net>

Draft Policy 2010-4
Rework of IPv6 allocation criteria

On 18 February 2010 the ARIN Advisory Council (AC) selected "Rework of
IPv6 allocation criteria" as a draft policy for adoption discussion on
the PPML and at the Public Policy Meeting in Toronto in April.

The draft was developed by the AC from policy proposal "101. Multihomed
initial allocation criteria". Per the Policy Development Process the AC
submitted text to ARIN for a staff and legal assessment prior to its
selection as a draft policy. Below the draft policy is the ARIN
staff and legal assessment, followed by the text that was submitted by
the AC.

Draft Policy 2010-4 is below and can be found at:
https://www.arin.net/policy/proposals/2010_4.htm

You are encouraged to discuss Draft Policy 2010-4 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-4
Rework of IPv6 allocation criteria

Version/Date: 23 February 2010

Policy statement:

Delete section 6.4.3. Minimum Allocation.

Modify the following sections;

6.5.1 Initial allocations for ISPs and LIRs

6.5.1.1. Initial allocation size

Organizations that meet at least one of the following criteria are
eligible to receive a minimum allocation of /32. Requests for larger
allocations, reasonably justified with supporting documentation, will be
evaluated based on the number of existing users and the extent of the
organization's infrastructure.

6.5.1.2. Criteria for initial allocation to ISPs

Organizations may justify an initial allocation for the purpose of
assigning addresses to other organizations or customers that it will
provide IPv6 Internet connectivity to, with an intent to provide global
reachability for the allocation within 12 months, by meeting one of the
following additional criteria:

a. Having a previously justified IPv4 ISP allocation from ARIN or one of
its predecessor registries, or;

b. Currently being IPv6 Multihomed or immediately becoming IPv6
Multihomed and using an assigned valid global AS number, or;

c. By providing a reasonable plan detailing assignments to other
organizations or customers for one, two and five year periods, with a
minimum of 50 assignments within 5 years.

6.5.1.3. Criteria for initial allocation to other LIRs

Organizations may justify an initial allocation for the purpose of
assigning addresses to other organizations or customers that it will
provide IPv6 based network connectivity services to, not necessarily
Internet connected, by meeting one of the following additional criteria:

a. Having a previously justified IPv4 ISP allocation from ARIN or one of
its predecessor registries, or;

b. By providing a reasonable technical justification, indicating why an
allocation is necessary, including the intended purposes for the
allocation, and describing the network infrastructure the allocation
will be used to support. Justification must include a plan detailing
assignments to other organizations or customers for one, two and five
year periods, with a minimum of 50 assignments within 5 years.

Rationale:

This proposal provides a complete rework of the IPv6 allocation criteria
while maintaining many of the basic concepts contained in the current
policies. The order of the subsections of 6.5.1 are rearranged moving
the initial allocation size to 6.5.1.1. This will facilitate adding
future criteria without additional renumbering the current policies.

The initial allocation criteria include the following general concepts:

? The need for an allocation is only justified by the need to assign
resource to customers, either internal or external.
? When the need to provide Internet connectivity is use to justify
resources it is implied the resources should be advertised to the
Internet, within some reasonable time frame after they are received.
? IPv4 resources may be use to justify the need for IPv6 resources.
? An ISP may justify independent resource by being Multihomed or
planning to assign IPv6 resource to some minimum number of customers.
? It should be possible to justify an IPv6 allocation for more than just
classical ISPs, such as non-connected networks or other types of LIRs.
But additional justification should be required, describing the purpose
and network infrastructure the allocation will be supporting.

Finally, section 6.4.3 Minimum Allocation, is deleted as it is
incomplete and redundant anyway.

Timetable for implementation: immediate


#####


STAFF ASSESSMENT

Proposal:  Rework of IPv6 allocation criteria

Proposal Version (Date): 5 Jan 2010

Date of Assessment:  12 Feb 2010


1. Proposal Summary (Staff Understanding)

ARIN staff understands this policy replaces existing IPv6 Allocation
Policy text with new, relaxed criteria in which an ISP must qualify for
one out of the three qualifying criteria; have an existing IPv4
allocation OR be multi-home OR have a detailed plan for assigning
address space to 50 customers within 5 years.  It introduces a separate
category for a LIR, which is defined as an organization that provides
IPv6 assignments to at least 50 customers, but not necessarily for the
purposes of providing internet transit.

2. Comments

A.	ARIN Staff Comments

?	This policy provides very clear direction for ISPs requesting IPv6
address space stating that they must ?assign addresses to other
organizations or customers that it will provide IPv6 Internet
connectivity to, with an intent to provide global reachability for the
allocation within 12 months?.  This distinction should help clarify the
role of the ISP in relation to this policy.
?	Since 6.5.1.3b does not specify whether ?other organizations or
customers? must be external, it seems likely that this policy will open
up allocation policy to enterprise customers (who presently receive
assignments under the End-user policies). Currently the larger
enterprise businesses we see typically define their operating divisions
and departments as 'customers'.
?	The new ISP and LIR qualification criteria lower the bar to receiving
a /32, which should significantly increase the number of allocations
ARIN makes each year.
?	6.5.1.3 states that a LIR can qualify for an allocation if it will be
?assigning addresses to other organizations or customers that it will
provide IPv6 based network connectivity services to, not necessarily
Internet connected?.  The words ?network based connectivity services?
are somewhat confusing. Staff interprets this to mean that a LIR will
not necessarily be providing Internet connectivity to its customers, but
we are seeking clarification on this point.


B.	ARIN General Counsel

?This proposal poses no significant legal issues.?

3. Resource Impact

This policy would have minimal resource impact.  It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:

?	Changes to guidelines
?	May require new template
?	Staff training


4. Proposal Text

Delete section 6.4.3. Minimum Allocation.
Modify the following sections;
6.5.1 Initial allocations for ISPs and LIRs
6.5.1.1. Initial allocation size
Organizations that meet at least one of the following criteria are
eligible to receive a minimum allocation of /32. Requests for larger
allocations, reasonably justified with supporting documentation, will be
evaluated based on the number of existing users and the extent of the
organization's infrastructure.
6.5.1.2. Criteria for initial allocation to ISPs
Organizations may justify an initial allocation for the purpose of
assigning addresses to other organizations or customers that it will
provide IPv6 Internet connectivity to, with an intent to provide global
reachability for the allocation within 12 months, by meeting one of the
following additional criteria:
a. Having a previously justified IPv4 ISP allocation from ARIN or one of
its predecessor registries, or;
b. Currently being IPv6 Multihomed or immediately becoming IPv6
Multihomed and using an assigned valid global AS number, or;
c. By providing a reasonable plan detailing assignments to other
organizations or customers for one, two and five year periods, with a
minimum of 50 assignments within 5 years.
6.5.1.3. Criteria for initial allocation to other LIRs
Organizations may justify an initial allocation for the purpose of
assigning addresses to other organizations or customers that it will
provide IPv6 based network connectivity services to, not necessarily
Internet connected, by meeting one of the following additional criteria:
a. Having a previously justified IPv4 ISP allocation from ARIN or one of
its predecessor registries, or;
b. By providing a reasonable technical justification, indicating why an
allocation is necessary, including the intended purposes for the
allocation, and describing the network infrastructure the allocation
will be used to support. Justification must include a plan detailing
assignments to other organizations or customers for one, two and five
year periods, with a minimum of 50 assignments within 5 years.


Rationale:
This proposal provides a complete rework of the IPv6 allocation criteria
while maintaining many of the basic concepts contained in the current
policies. The order of the subsections of 6.5.1 are rearranged moving
the initial allocation size to 6.5.1.1. This will facilitate adding
future criteria without additional renumbering the current policies.
The initial allocation criteria include the following general concepts;
?	The need for an allocation is only justified by the need to assign
resource to customers, either internal or external.
?	When the need to provide Internet connectivity is use to justify
resources it is implied the resources should be advertised to the
Internet, within some reasonable time frame after they are received.
?	IPv4 resources may be use to justify the need for IPv6 resources.
?	An ISP may justify independent resource by being Multihomed or
planning to assign IPv6 resource to some minimum number of customers.
?	It should be possible to justify an IPv6 allocation for more than just
classical ISPs, such as non-connected networks or other types of LIRs.
But additional justification should be required, describing the purpose
and network infrastructure the allocation will be supporting.

Finally, section 6.4.3 Minimum Allocation, is deleted as it is
incomplete and redundant anyway.





From info at arin.net  Tue Feb 23 15:24:12 2010
From: info at arin.net (Member Services)
Date: Tue, 23 Feb 2010 15:24:12 -0500
Subject: [arin-ppml] Draft Policy 2010-6: Simplified M&A transfer policy
Message-ID: <4B84396C.5000009@arin.net>

Draft Policy 2010-6
Simplified M&A transfer policy

On 18 February 2010 the ARIN Advisory Council (AC) selected "Simplified
M&A transfer policy" as a draft policy for adoption discussion on the
PPML and at the Public Policy Meeting in Toronto in April.

The draft was developed by the AC from policy proposal "105. Simplified
M&A transfer policy". Per the Policy Development Process the AC
submitted text to ARIN for a staff and legal assessment prior to its
selection as a draft policy. Below the draft policy is the ARIN staff
and legal assessment, followed by the text that was submitted by
the AC.

Draft Policy 2010-6 is below and can be found at:
https://www.arin.net/policy/proposals/2010_6.htm

You are encouraged to discuss Draft Policy 2010-6 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-6
Simplified M&A transfer policy

Version/Date: 23 February 2010

Policy statement:

Replace section 8.2 with:

8.2. Mergers and Acquisitions

ARIN will consider requests for the transfer of number resources in the
case of mergers and acquisitions upon receipt of evidence that the new
entity has acquired assets that used the transferred resources from the
current registrant. ARIN will maintain an up-to-date list of acceptable
types of documentation.

In the event that number resources of the combined organizations are no
longer justified under ARIN policy at the time ARIN becomes aware of the
transaction, through a transfer request or otherwise, ARIN will work
with the resource holder(s) to return, aggregate, or reclaim resources
as appropriate via the processes outlined in current ARIN policy (for
example, sections 4.6, 4.7, or 12 of the NRPM).

Add "In addition to transfers under section 8.2, " at the beginning of
section 8.3. Transfers to Specified Recipients.

Rationale:

This policy proposal: attempts to simplify the M&A transfer section of
the NRPM; eliminates the ambiguity discussed at the ARIN Public Policy
Meeting (PPM) in Dearborn by clarifying that transfers can occur under
either 8.2 or 8.3 independently; and attempts to address the concerns
raised in the staff policy implementation report at the Dearborn PPM
(https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PDF/thursday/policy_exp_report.pdf)

The idea here is to simply say that ARIN will allow M&A transfers, and
to require the return of any number resources for which there is no
longer a justified need after the acquisition. Preferably that would
happen voluntarily under the policies of NRPM 4.6 (Amnesty), but it also
leaves the door open for ARIN to revoke space under NRPM 12 (Resource
Review) if necessary. By implication, future needs that would qualify
the organization for an allocation/assignment would likewise justify
keeping transferred space. In particular, see the language of NRPM
section 12, paragraphs 4 and 4a.

This policy also should dramatically increase the completion rate for
transfer requests, as the evaluation of whether space is efficiently
utilized after the transfer can occur in parallel, completely
independently of the transfer request, and can continue even if the
transfer request is abandoned.

The bulleted lists of acceptable documentation removed from the NRPM
should be maintained by ARIN elsewhere on the website, such as at
https://www.arin.net/resources/request/transfers.html

FAQ:

Q1: What about legacy resources?

A1: Resources subject to the legacy RSA are exempt from a number of ARIN
policies, such as usage justification. However, the recipient of
transferred resources must sign a standard RSA covering the received
resources. At that point, the resources lose their legacy status and
become subject to all ARIN policies, including section 12.

Q2: I'm not sure how NRPM 4.7 will come into play with this policy. Is
the aggregation policy actually applicable here? I understand how 4.6
would work, but just not making the connection with 4.7.

A2: If the organization is returning pieces of space, or, wants to
return multiple disparate chunks and get a single aggregate in the
process, that shouldn't be precluded. NRPM section 4.7 facilitates that.

Timetable for implementation: Immediate


#####


STAFF ASSESSMENT

Proposal: Simplified M&A transfer policy

Proposal Version (Date): 22 Dec 2009

Date of Assessment: 12 Feb 2010

1.	Proposal Summary (Staff Understanding)

ARIN staff understands that this proposal clarifies that a transfer
request can take place either at the time of the actual M&A activity, or
anytime after as long as the proper documentation is provided.  If the
number resources being transferred are not being utilized in accordance
with current ARIN policies, the proposal requires ARIN staff to work
with the requesting organization to return or aggregate the resources as
appropriate, using sections 4.6, 4.7, and 12 of the NRPM.

2. Comments

A.	ARIN Staff Comments

?	This proposal simplifies the M&A transfer criteria and clarifies
several things that may not be apparent with the existing policy.  It
better clarifies that 8.3 transfers are independent of 8.2 transfers and
it clearly states that ARIN will consider transfers after the actual M&A
has occurred as long as the proper documentation is supplied.

?	The proposal adds new, more directive criteria that says if staff sees
that the resources being transferred are not justified under any
existing ARIN policy,  staff must work with the recipient organization
to return, aggregate or reclaim the resources.  Based on staff
experience with M&A transfers, it is possible that these more stringent
requirements could deter organizations with v4 resources from initiating
transfers, thus ensuring that the WHOIS data remains stale and out of
date.  Past experience with M&A transfers has shown us that when we ask
for detailed utilization information and/or ask for unused or
under-utilized address space back, many organizations will simply
abandon their transfers.

B.	ARIN General Counsel

?This proposal poses no significant legal issues.?

3. Resource Impact

?	This policy would have moderate resource impact.  It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees.
?	The significant impact will be felt in the actual application of the
policy due to the fact that ARIN receives many transfer requests where
large blocks of IPv4 addresses are either completely unused or
significantly underused. In turn, staff would have to initiate dozens of
new audits per month as a result of completed transfers.  These audits
and their follow up activity are labor intensive and time consuming,
which will impact staff workload and could necessitate the hiring of
additional staff.

The following would be needed in order to implement:

?	Changes to guidelines
?	Staff training

4. Proposal Text

Replace section 8.2 with:
8.2. Mergers and Acquisitions
ARIN will consider requests for the transfer of number resources in the
case of mergers and acquisitions upon receipt of evidence that the new
entity has acquired assets that used the transferred resources from the
current registrant. ARIN will maintain an up-to-date list of acceptable
types of documentation.

In the event that number resources of the combined organizations are no
longer justified under ARIN policy at the time ARIN becomes aware of the
transaction, through a transfer request or otherwise, ARIN will work
with the resource holder(s) to return, aggregate, or reclaim resources
as appropriate via the processes outlined in current ARIN policy (for
example, sections 4.6, 4.7, or 12 of the NRPM).

Add "In addition to transfers under section 8.2, " at the beginning of
section 8.3. Transfers to Specified Recipients.

Rationale:
This policy proposal: attempts to simplify the M&A transfer section of
the NRPM; eliminates the ambiguity discussed at the ARIN Public Policy
Meeting (PPM) in Dearborn by clarifying that transfers can occur under
either 8.2 or 8.3 independently; and attempts to address the concerns
raised in the staff policy implementation report at the Dearborn PPM
(https://www.arin.net/participate/meetings/reports/ARIN_XXIV/PDF/thursday/policy_exp_report.pdf 



)
The idea here is to simply say that ARIN will allow M&A transfers, and
to require the return of any number resources for which there is no
longer a justified need after the acquisition. Preferably that would
happen voluntarily under the policies of NRPM 4.6 (Amnesty), but it also
leaves the door open for ARIN to revoke space under NRPM 12 (Resource
Review) if necessary. By implication, future needs that would qualify
the organization for an allocation/assignment would likewise justify
keeping transferred space. In particular, see the language of NRPM
section 12, paragraphs 4 and 4a.
This policy also should dramatically increase the completion rate for
transfer requests, as the evaluation of whether space is efficiently
utilized after the transfer can occur in parallel, completely
independently of the transfer request, and can continue even if the
transfer request is abandoned.
The bulleted lists of acceptable documentation removed from the NRPM
should be maintained by ARIN elsewhere on the website, such as at
https://www.arin.net/resources/request/transfers.html
FAQ:
Q1: What about legacy resources?
A1: Resources subject to the legacy RSA are exempt from a number of ARIN
policies, such as usage justification. However, the recipient of
transferred resources must sign a standard RSA covering the received
resources. At that point, the resources lose their legacy status and
become subject to all ARIN policies, including section 12.
Q2: I'm not sure how NRPM 4.7 will come into play with this policy. Is
the aggregation policy actually applicable here? I understand how 4.6
would work, but just not making the connection with 4.7.
A2: If the organization is returning pieces of space, or, wants to
return multiple disparate chunks and get a single aggregate in the
process, that shouldn't be precluded. NRPM section 4.7 facilitates that.






From info at arin.net  Tue Feb 23 15:24:24 2010
From: info at arin.net (Member Services)
Date: Tue, 23 Feb 2010 15:24:24 -0500
Subject: [arin-ppml] Draft Policy 2010-7: Simplified IPv6 policy
Message-ID: <4B843978.9090802@arin.net>

Draft Policy 2010-7
Simplified IPv6 policy

On 18 February 2010 the ARIN Advisory Council (AC) selected "Simplified
IPv6 policy " as a draft policy for adoption discussion on the PPML and
at the Public Policy Meeting in Toronto in April.

The draft was developed by the AC from policy proposal "106. Simplified
IPv6 policy". Per the Policy Development Process the AC submitted text
to ARIN for a staff and legal assessment prior to its selection as a
draft policy. Below the draft policy is the ARIN staff and legal
assessment, followed by the text that was submitted by the AC.

Draft Policy 2010-7 is below and can be found at:
https://www.arin.net/policy/proposals/2010_7.htm

You are encouraged to discuss Draft Policy 2010-7 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-7
Simplified IPv6 policy

Version/Date: 23 February 2010

Policy statement:

Delete 6.1 Introduction - This is all historical.

Leave 6.3 as is (renumber to 6.1) - These still accurately reflect the
Goals we want our policy to follow.

Delete 6.4.2 - 6.4.4 - These principles don't seem worthy of elevation
to special status. 6.4.1 is handled in a separate Draft Policy.

Replace 6.5 - Policies for allocations and assignments with text below
(renumber to 6.2). This seems to be where most of the changes and
simplification are needed.

Delete 6.7 Appendix A: HD-Ratio - The numbers from this table were used
to determine the thresholds in 6.2 below, so this section is confusing
and no longer needed.

Delete 6.9 IPv6 Reassignments policy - This is redundant and covered
better elsewhere.

Move 6.10 into 6.2.3.2 below

Replacement text:

2.12. Critical Infrastructure Providers

Critical infrastructure providers of the Internet include public
exchange points, core DNS service providers (e.g. ICANN-sanctioned root,
gTLD, and ccTLD operators) as well as the RIRs and IANA.

4.4. Micro-allocation

ARIN will make IPv4 micro-allocations to Critical Infrastructure
Providers per section 2.8. These allocations will be no longer than a
/24. Multiple allocations may be granted in certain situations.

4.4.1. Allocation and assignment from specific blocks

Exchange point allocations MUST be allocated from specific blocks
reserved only for this purpose. All other micro-allocations WILL be
allocated out of other blocks reserved for micro-allocation purposes.
ARIN will make a list of these blocks publicly available.

4.4.2. Exchange point requirements

Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of
two total), ASN, and contact information. ISPs and other organizations
receiving these micro-allocations will be charged under the ISP fee
schedule, while end-users will be charged under the fee schedule for
end-users. This policy does not preclude exchange point operators from
requesting address space under other policies.

6.2. Policies for IPv6 allocations and assignments

6.2.1. Allocations and assignments

To meet the goal of Fairness, ARIN makes both allocations and
assignments according to common criteria. Allocations are made to LIRs,
and assignments to certain end users.

6.2.2. Assignments from LIRs/ISPs

End-users are assigned an end site assignment from their LIR or ISP. The
exact size of the assignment is a local decision for the LIR or ISP to
make, using a minimum value of a /64 (when only one subnet is
anticipated for the end site) up to the normal maximum of /48, except in
cases of extra large end sites where a larger assignment can be justified.

The following guidelines may be useful (but they are only guidelines):

     * /64 when it is known that one and only one subnet is needed
     * /56 for small sites, those expected to need only a few subnets
over the next 5 years.
     * /48 for larger sites

For end sites to whom reverse DNS will be delegated, the LIR/ISP should
consider making an assignment on a nibble (4-bit) boundary to simplify
reverse lookup delegation.

6.2.3. Allocations and assignments from ARIN

6.2.3.1 Goals

To balance the goals of Aggregation, Conservation, Fairness, and
Minimized Overhead, ARIN normally issues IPv6 addresses only in the
discrete sizes of /48, /40, /32, /28, /24, or larger. Each organization
or discrete network may qualify for one allocation or assignment of each
size.

6.2.3.1.1 Allocation and assignment from specific blocks

Each allocation/assignment size will be made out of separate blocks
reserved for that purpose. Additionally, non-routed assignments for
internal infrastructure, and assignments to Critical Infrastructure
Providers per section 2.8, will each be made out of separate blocks
reserved for those purposes. ARIN will make a list of these blocks
publicly available.

6.2.3.2 X-Small (/48)

To qualify for a /48 allocation or assignment, an organization must:

     * Be Multihomed per section 2.7, and qualify for an ASN per section
5; or
     * Serve at least 1000 hosts; or
     * Demonstrate efficient utilization of all direct IPv4 assignments
and allocations, each of which must be covered by any current ARIN RSA; or
     * Require a non-routed block for internal infrastructure; or
     * Be a Critical Infrastructure Provider per section 2.8.

6.2.3.3 Small (/40)

To qualify for a /40 allocation or assignment, an organization must:

     * Have two or more Multihomed sites, each of which would qualify
for a /48; or
     * Serve at least 2000 hosts; or
     * Be an LIR.

6.2.3.4 Medium (/32)

To qualify for a /32 allocation or assignment, an organization must:

     * Have 100 or more sites, each of which would qualify for a /48; or
     * Be an existing, known LIR; or
     * Have a plan to provide IPv6 connectivity to other organizations
and assign at least 100 end-site assignments to those organizations
within 5 years.

6.2.3.5 Large (/28)

To qualify for a /28, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 25,000 /48s, based on
current network infrastructure and customer base.

6.2.3.6 X-Large (/24)

To qualify for a /24, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 330,000 /48s, based
on current network infrastructure and customer base.

6.2.3.7 XX-Large (larger than /24)

Allocations or assignments larger than /24 may be made only in
exceptional cases, to organizations that demonstrate the need to make
assignments and/or reallocations equal to at least 4,500,000 /48s, based
on current network infrastructure and customer base. If approved, the
allocation prefix length will be based on the number of /24s justified
(at 4,500,000 /48s each), rounded up to the next whole CIDR prefix.
Subsequent XX-Large assignments may be made if justified using the same
criteria.

6.3. Registration (Copied from NRPM 6.5.5)

When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register assignment information in a
database, accessible by RIRs as appropriate (information registered by
ARIN may be replaced by a distributed database for registering address
management information in future). Information is registered in units of
assigned /56 networks. When more than a /56 is assigned to an
organization, the assigning organization is responsible for ensuring
that the address space is registered in an ARIN database.

6.3.1. Residential Customer Privacy (Copied from NRPM 6.5.5.1)

To maintain the privacy of their residential customers, an organization
with downstream residential customers may substitute that organization's
name for the customer's name, e.g. 'Private Customer - XYZ Network', and
the customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.

6.3.2. Reverse lookup (Copied from NRPM 6.5.6)

When ARIN delegates IPv6 address space to an organization, it also
delegates the responsibility to manage the reverse lookup zone that
corresponds to the allocated IPv6 address space. Each organization
should properly manage its reverse lookup zone. When making an address
assignment, the organization must delegate to an assignee organization,
upon request, the responsibility to manage the reverse lookup zone that
corresponds to the assigned address.


Rationale:

This policy proposal attempts to simplify IPv6 policy in a number of ways.

For example, it:

     * Deletes a number of historical sections and items that duplicate
text elsewhere in the NRPM.

     * Removes the HD-ratio, instead incorporating values calculated
from it as the basis for qualification criteria.

It also replaces & rewrites section 6.5 "Policies for allocations and
assignments" entirely. This rewrite:

     * Eliminates the different criteria for allocations (ISPs) vs.
assignments (end users) and replaces them with a single common set of
criteria for both classes of users. The allocation vs. assignment
distinction itself is preserved, as it still forms a useful basis for a
cost-recovery fee structure, and for other parts of the NRPM (such as
whois policy).

     * Creates a size-class-based system for allocating IPv6 address
blocks.

This has a number of advantages over the existing policy:

     * Allows for safe filtering of traffic-engineering (TE)
more-specific route announcements.

     * In exchange (since PA more-specifics are expected to be
filterable), allows any multihomed organization to get an assignment
from ARIN. The smaller number of such PI assignments (compared to TE
more-specifics) should mean that such assignments will largely be
accepted across the DFZ.

     * Expands the use of discrete blocks from which all allocations
will be of identical prefix length and categorization. This will enable
safer and easier TE filtering, as mentioned above.

     * Expands the availability of non-routed blocks for internal
infrastructure. Since routable blocks are available to any multihomed
organization, there is no longer a need to restrict the availability of
blocks from the non-routable pool.

     * Makes allocations available to any LIR.

Note: In the event of an M&A transfer per section 8.2 that would result
in more than one block of a given size class being held by the combined
organization, the organization should be encouraged to renumber into a
single larger block and return the smaller block(s) when feasible.
However, as long as the organization doesn't require any additional
resources, this policy does not force them to make any changes. OTOH, if
they request a larger block and still hold two or more smaller blocks,
they would be required to return the smaller block as a condition for
receiving the larger one.

Related non-policy suggestion: in order to provide a small incentive for
organizations to renumber and return out of smaller unneeded blocks, the
ARIN fee schedule could be modified such that fees are assessed,
according to the ARIN fee schedule, for each size block issued, rather
than based on the total quantity of space held.

FAQs:

Q1: How did you come up with the thresholds?

A1: /48: Many of the criteria for a /48 were copied from existing
policy. The notable exception is that any Multihomed network that
qualifies for an ASN can also get a /48. /40: Since we don't give out
multiple /48s (except in the case of MDN), anyone outgrowing a /48 needs
a /40. Hence, the /40 requirements are 2x the /48 requirements. In
addition, LIRs who don't qualify for a /32 can get a /40, since they
need to be able to assign /48s. /32: Some of these requirements were
inherited from existing policy. The existing 200 sites requirement was
reduced to 100, and made to apply to assignments as well as allocations.
/28: Since we don't give out multiple /32s (except in the case of MDN),
anyone outgrowing a /32 needs a /28. The /28 requirements are based on
the current HD-ratio-based requirement for a /32 (6,183,533 /56s)
converted to /48s (24154) and rounded up to 25,000. /24+: Similarly, the
requirements for a /24 are based on the HD-ratio requirement for a /28,
and the requirement for more than one /24 are based on the HD-ratio
requirement for a /24.

Q2: What about timeframes for meeting the allocation criteria?

A2: All requests are based on current usage, so no timeframes are
involved. For example, if an ISP has a /32 and is applying for a /28,
they will be required to demonstrate that they have already assigned
25,000 /48s. Since there are 64k /48s in a /32, there is no longer any
need to make predictions about future assignments.

Q3: The proposal says "Each organization or discrete network may qualify
for one allocation or assignment of each size". It is fairly clear how
staff would evaluate whether a network qualifies for a given block size,
if it's the first block, but it is not clear how it would work if the
network already has a block assigned or allocated to it.

For instance, suppose a network has 50 sites. They qualify for a /40. A
year later they come back, have 150 sites, and want a /32. Do they
qualify for a /32, because they have more than 100 sites, or is some
consideration given to how the existing /40 has been used? It seems like
the former would be the logical interpretation, since the policy doesn't
mention anything about consideration of existing blocks, and says you
can have one of each block size.

A3: Correct. If you qualify for a larger block, you also qualify for one
of each smaller size.


Timetable for implementation: Immediate (as soon as practical).


#####


STAFF ASSESSMENT

Proposal: Simplified IPv6 Policy

Proposal Version (Date): 01 February 2010

Date of Assessment:  16 February 2010


1. Proposal Summary (Staff Understanding)

ARIN staff understands this policy would allow a network (whether ISP or
end-user) to qualify for one each of the following prefix lengths: /48,
/40, /32, /28, and /24 (with anything larger being issued in /24 units).
  Qualification is based on a number of factors including multi-homing,
host count, number of sites, and number of /48s projected to be used.
Each organization or discrete network can qualify for one block of each
size.  Each block would be issued from a specific range reserved only
for that block size.

2. Comments

A.	ARIN Staff Comments

?	In section 6.2.3.1, the policy proposal notes: "and must pay fees
according to ARIN's fee schedule [1] for each size issued." This text
should be removed, as it is not policy text. Matters relating to fees
are outside the NRPM's purview and are typically covered under the ARIN
fee schedule https://www.arin.net/fees/fee_schedule.html.
?	The policy provides no mechanism for a large network to get a 6th
network block if it efficiently utilizes its first 5 blocks. While this
likely won't be an issue for a few years, it bears consideration for
future policy development.
?	The policy says to move current NRPM sections 6.9 and 6.10 into
6.2.3.2 and provides replacement text; however, staff cannot see where
6.9 is covered.  In further review of 6.9, it appears that this is
redundant text which is already covered in NRPM section 6.5.4 so we
suggest removing 6.9 from the policy text altogether.


B.	ARIN General Counsel

               "At this time counsel has no significant legal comments.?


3. Resource Impact

This policy would have minimal resource impact.  It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:

?	New guidelines
?	A new IPv6 request form
?	Staff training



4. Proposal Text

Delete 6.1 Introduction - This is all historical.
Leave 6.3 as is (renumber to 6.1) - I think these still accurately
reflect the Goals we want our policy to follow.
Delete 6.4.2 - 6.4.4 - These principles don't seem worthy of elevation
to special status. 6.4.1 is handled in a separate Draft Policy.
Replace 6.5 - Policies for allocations and assignments with text below
(renumber to 6.2) This seems to be where most of the changes and
simplification are needed.
Delete 6.7 Appendix A: HD-Ratio - The numbers from this table were used
to determine the thresholds in 6.2 below, so this section is confusing
and no longer needed.
Move 6.9 and 6.10 into 6.2.3.2 below
Replacement text:
2.12. Critical Infrastructure Providers
Critical infrastructure providers of the Internet include public
exchange points, core DNS service providers (e.g. ICANN-sanctioned root,
gTLD, and ccTLD operators) as well as the RIRs and IANA.
4.4. Micro-allocation
ARIN will make IPv4 micro-allocations to Critical Infrastructure
Providers per section 2.8. These allocations will be no longer than a
/24. Multiple allocations may be granted in certain situations.
4.4.1. Allocation and assignment from specific blocks
Exchange point allocations MUST be allocated from specific blocks
reserved only for this purpose. All other micro-allocations WILL be
allocated out of other blocks reserved for micro-allocation purposes.
ARIN will make a list of these blocks publicly available.
4.4.2. Exchange point requirements
Exchange point operators must provide justification for the allocation,
including: connection policy, location, other participants (minimum of
two total), ASN, and contact information. ISPs and other organizations
receiving these micro-allocations will be charged under the ISP fee
schedule, while end-users will be charged under the fee schedule for
end-users. This policy does not preclude exchange point operators from
requesting address space under other policies.
6.2. Policies for IPv6 allocations and assignments
6.2.1. Allocations and assignments
To meet the goal of Fairness, ARIN makes both allocations and
assignments according to common criteria. Allocations are made to LIRs,
and assignments to certain end users.
6.2.2. Assignments from LIRs/ISPs
End-users are assigned an end site assignment from their LIR or ISP. The
exact size of the assignment is a local decision for the LIR or ISP to
make, using a minimum value of a /64 (when only one subnet is
anticipated for the end site) up to the normal maximum of /48, except in
cases of extra large end sites where a larger assignment can be justified.
The following guidelines may be useful (but they are only guidelines):
  *   /64 when it is known that one and only one subnet is needed
  *   /56 for small sites, those expected to need only a few subnets
over the next 5 years.
   *   /48 for larger sites
For end sites to whom reverse DNS will be delegated, the LIR/ISP should
consider making an assignment on a nibble (4-bit) boundary to simplify
reverse lookup delegation.
6.2.3. Allocations and assignments from ARIN
6.2.3.1 Goals
To balance the goals of Aggregation, Conservation, Fairness, and
Minimized Overhead, ARIN normally issues IPv6 addresses only in the
discrete sizes of /48, /40, /32, /28, or /24 or larger. Each
organization or discrete network may qualify for one allocation or
assignment of each size, and must pay fees according to ARIN's fee
schedule [1] <https://www.arin.net/fees/fee_schedule.html >  for each
size issued.
6.2.3.1.1 Allocation and assignment from specific blocks
Each allocation/assignment size will be made out of separate blocks
reserved for that purpose. Additionally, non-routed assignments for
internal infrastructure, and assignments to Critical Infrastructure
Providers per section 2.8, will each be made out of separate blocks
reserved for those purposes. ARIN will make a list of these blocks
publicly available.
6.2.3.2 X-Small (/48)
To qualify for a /48 allocation or assignment, an organization must:
  *   Be Multihomed per section 2.7, and qualify for an ASN per section
5; or
  *   Serve at least 1000 hosts; or
  *   Demonstrate efficient utilization of all direct IPv4 assignments
and allocations, each of which must be covered by any current ARIN RSA; or
  *   Require a non-routed block for internal infrastructure; or
  *   Be a Critical Infrastructure Provider per section 2.8.
6.2.3.3 Small (/40)
To qualify for a /40 allocation or assignment, an organization must:
  *   Have two or more Multihomed sites, each of which would qualify for
a /48; or
   *   Serve at least 2000 hosts; or
  *   Be an LIR.
  6.2.3.4 Medium (/32)
  To qualify for a /32 allocation or assignment, an organization must:
   *   Have 100 or more sites, each of which would qualify for a /48; or
  *   Be an existing, known LIR; or
  *   Have a plan to provide IPv6 connectivity to other organizations
and assign at least 100 end-site assignments to those organizations
within 5 years.
6.2.3.5 Large (/28)
To qualify for a /28, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 25,000 /48s, based on
current network infrastructure and customer base.
6.2.3.6 X-Large (/24)
To qualify for a /24, an organization must demonstrate the need to make
assignments and/or reallocations equal to at least 330,000 /48s, based
on current network infrastructure and customer base.
6.2.3.7 XX-Large (larger than /24)
Allocations or assignments larger than /24 may be made only in
exceptional cases, to organizations that demonstrate the need to make
assignments and/or reallocations equal to at least 4,500,000 /48s, based
on current network infrastructure and customer base. If approved, the
allocation prefix length will be based on the number of /24s justified
(at 4,500,000 /48s each).
6.3. Registration (Copied from NRPM 6.5.5)
When an organization holding an IPv6 address allocation makes IPv6
address assignments, it must register assignment information in a
database, accessible by RIRs as appropriate (information registered by
ARIN may be replaced by a distributed database for registering address
management information in future). Information is registered in units of
assigned /56 networks. When more than a /56 is assigned to an
organization, the assigning organization is responsible for ensuring
that the address space is registered in an ARIN database.
6.3.1. Residential Customer Privacy (Copied from NRPM 6.5.5.1)
To maintain the privacy of their residential customers, an organization
with downstream residential customers may substitute that organization's
name for the customer's name, e.g. 'Private Customer - XYZ Network', and
the customer's street address may read 'Private Residence'. Each private
downstream residential reassignment must have accurate upstream Abuse
and Technical POCs visible on the WHOIS record for that block.
6.3.2. Reverse lookup (Copied from NRPM 6.5.6)
When ARIN delegates IPv6 address space to an organization, it also
delegates the responsibility to manage the reverse lookup zone that
corresponds to the allocated IPv6 address space. Each organization
should properly manage its reverse lookup zone. When making an address
assignment, the organization must delegate to an assignee organization,
upon request, the responsibility to manage the reverse lookup zone that
corresponds to the assigned address.


Rationale:
This policy proposal attempts to simplify IPv6 policy in a number of ways.
For example, it:
  *   Deletes a number of historical sections and items that duplicate
text elsewhere in the NRPM.
   *   Removes the HD-ratio, instead incorporating values calculated
from it as the basis for qualification criteria.
It also replaces & rewrites section 6.5 "Policies for allocations and
assignments" entirely. This rewrite:
  *   Eliminates the different criteria for allocations (ISPs) vs.
assignments (end users) and replaces them with a single common set of
criteria for both classes of users. The allocation vs. assignment
distinction itself is preserved, as it still forms a useful basis for a
cost-recovery fee structure, and for other parts of the NRPM (such as
whois policy).
  *   Creates a size-class-based system for allocating IPv6 address blocks.
This has a number of advantages over the existing policy:
     *   Allows for safe filtering of traffic-engineering (TE)
more-specific route announcements.
     *   In exchange (since PA more-specifics are expected to be
filterable), allows any multihomed organization to get an assignment
from ARIN. The smaller number of such PI assignments (compared to TE
more-specifics) should mean that such assignments will largely be
accepted across the DFZ.
     *   Expands the use of discrete blocks from which all allocations
will be of identical prefix length and categorization. This will enable
safer and easier TE filtering, as mentioned above.
     *   Expands the availability of non-routed blocks for internal
infrastructure. Since routable blocks are available to any multihomed
organization, there is no longer a need to restrict the availability of
blocks from the non-routable pool.
     *   Makes allocations available to any LIR.
Note: In the event of an M&A transfer per section 8.2 that would result
in more than one block of a given size class being held by the combined
organization, the organization should be encouraged to renumber into a
single larger block and return the smaller block(s) when feasible.
However, as long as the organization doesn't require any additional
resources, this policy does not force them to make any changes. OTOH, if
they request a larger block and still hold two or more smaller blocks,
they would be required to return the smaller block as a condition for
receiving the larger one.
FAQs:
Q1: How did you come up with the thresholds?
A1: /48: Many of the criteria for a /48 were copied from existing
policy. The notable exception is that any Multihomed network that
qualifies for an ASN can also get a /48. /40: Since we don't give out
multiple /48s (except in the case of MDN), anyone outgrowing a /48 needs
a /40. Hence, the /40 requirements are 2x the /48 requirements. In
addition, LIRs who don't qualify for a /32 can get a /40, since they
need to be able to assign /48s. /32: Some of these requirements were
inherited from existing policy. The existing 200 sites requirement was
reduced to 100, and made to apply to assignments as well as allocations.
/28: Since we don't give out multiple /32s (except in the case of MDN),
anyone outgrowing a /32 needs a /28. The /28 requirements are based on
the current HD-ratio-based requirement for a /32 (6,183,533 /56s)
converted to /48s (24154) and rounded up to 25,000. /24+: Similarly, the
requirements for a /24 are based on the HD-ratio requirement for a /28,
and the requirement for more than one /24 are based on the HD-ratio
requirement for a /24.
Q2: What about timeframes for meeting the allocation criteria?
A2: All requests are based on current usage, so no timeframes are
involved. For example, if an ISP has a /32 and is applying for a /28,
they will be required to demonstrate that they have already assigned
25,000 /48s. Since there are 64k /48s in a /32, there is no longer any
need to make predictions about future assignments.
Q3: The proposal says "Each organization or discrete network may qualify
for one allocation or assignment of each size". It is fairly clear how
staff would evaluate whether a network qualifies for a given block size,
if it's the first block, but it is not clear how it would work if the
network already has a block assigned or allocated to it.
For instance, suppose a network has 50 sites. They qualify for a /40. A
year later they come back, have 150 sites, and want a /32. Do they
qualify for a /32, because they have more than 100 sites, or is some
consideration given to how the existing /40 has been used? It seems like
the former would be the logical interpretation, since the policy doesn't
mention anything about consideration of existing blocks, and says you
can have one of each block size.
A3: Correct. If you qualify for a larger block, you also qualify for one
of each smaller size.







From info at arin.net  Tue Feb 23 15:24:00 2010
From: info at arin.net (Member Services)
Date: Tue, 23 Feb 2010 15:24:00 -0500
Subject: [arin-ppml] Draft Policy 2010-5: Reduce and Simplify IPv4 Initial
	Allocations
Message-ID: <4B843960.40309@arin.net>

Draft Policy 2010-5
Reduce and Simplify IPv4 Initial Allocations

On 18 February 2010 the ARIN Advisory Council (AC) selected "Reduce and
Simplify IPv4 Initial Allocations" as a draft policy for adoption
discussion on the PPML and at the Public Policy Meeting in Toronto in April.

The draft was developed by the AC from policy proposal "102. Reduce and
Simplify IPv4 Initial Allocations". Per the Policy Development Process
the AC submitted text to ARIN for a staff and legal assessment prior to
its selection as a draft policy. Below the draft policy is the ARIN
staff and legal assessment, followed by the text that was submitted by
the AC.

Draft Policy 2010-5 is below and can be found at:
https://www.arin.net/policy/proposals/2010_5.htm

You are encouraged to discuss Draft Policy 2010-5 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-5
Reduce and Simplify IPv4 Initial Allocations

Version/Date: 23 February 2010

Policy statement:

Modify section 4.2.1.5. Minimum allocation:

In general, ARIN allocates IP address prefixes no longer than /23 to
ISPs. If allocations smaller than /23 are needed, ISPs should request
address space from their upstream provider. When prefixes are assigned
which are longer than /20, they will be from a block reserved for that
purpose whenever that is feasible.

And

Replace the contents of section 4.2.2. Initial allocation to ISPs:

4.2.2.1. Use of /24

The efficient utilization of an entire previously allocated /24 or
equivalent from their upstream ISP.

4.2.2.2. Efficient utilization

Demonstrate efficient use of IP address space allocations by providing
appropriate documentation, including assignment histories, showing their
efficient use. ISPs must provide reassignment information on the entire
previously allocated block(s) via SWIP or RWHOIS server for /29 or
larger blocks. For blocks smaller than /29 and for internal space, ISPs
should provide utilization data either via SWIP or RWHOIS server or by
using the table format described in Section 4.2.3.7.5.

4.2.2.3. Three months

Provide detailed information showing specifically how the initial
allocation will be utilized within three months.

4.2.2.4. Renumber and return

ISPs receiving an initial allocation smaller than /20 must agree that
the newly requested IP address space will be used to renumber out of the
current addresses which will be returned to the assigning organization
within 12 months. ISPs receiving an initial allocation equal to or
larger than /20 may wish to renumber out of their previously allocated
space. In this case, an ISP must use the new prefix to renumber out of
that previously allocated block of address space and must return the
space to its upstream provider.

4.2.2.5. Replacement initial allocation

Any ISP which has received an initial allocation, or previous
replacement initial allocation, smaller than /20 who wishes to receive
additional address space must request a replacement initial allocation.
To receive a replacement initial allocation, an ISP must agree to
renumber out of and return the existing allocation in it's entirety
within 12 months of receiving a new allocation and provide justification
for the new allocation as described in section 4.2.4. Multihomed
organizations holding a /22 or a /21 at the time of policy adoption are
exempt from having to renumber and return for a period of 12 months
after this policy is adopted.

Rationale:

This policy proposal fundamentally changes and simplifies the initial
IPv4 allocations to ISPs by doing the following:

1) Makes moot whether the requesting ISP is multihomed or not, with this
policy change all initial ISPs request under the same minimums.

2) Lowers the minimums, making it easier for smaller ISPs to qualify for
direct allocations from ARIN.

3) Reduces fragmentation of the allocated IPv4 pool by forcing smaller
ISPs who do qualify under the minimum to return the small allocation
when they outgrow it. Note particularly that this does not "change the
bar" for ISPs who have already received small allocations, as they will
have not agreed to return those smaller allocations when they get larger
allocations.

4) Indirectly encourages the adoption of IPv6 as the ISPs that now
qualify for numbering under this policy change will be considered an LIR
and thus satisfy one of the IPv6 requirements in section 6.5.1.1

This policy proposal idea grew out of Proposal 98 and 100 and the
discussions surrounding those proposals as well as many discussions on
the ppml and on arin-discuss mailing lists.

For starters, it's well known that while transit networks have the
ability to filter IPv4 BGP advertisements, few to none filter anything
larger than a /24 (any who do filter /24 or larger have a default route
to fall back on), and a /24 (for perhaps no better reason than it
happens to be a "class C") has become the de-facto standard minimum. As
a result, assigning blocks smaller than a /22 (the current minimum under
4.2.2) isn't going to break anything.

Secondly, the primary motivator for denying smaller ISPs an initial
allocation from ARIN is to slow the growth of the DFZ, due to concerns
that growth of the so-called "IPv4 global routing table" would exceed
memory requirements in routers operated by transit networks. This is why
Section 4.2.2 was split into multihomed and non-multihomed in the first
place, to help "raise the bar" and prevent a land rush. Section 4.2.2.1
makes it so that only really large ISPs qualify for an initial
allocation, Section 4.2.2.2 makes it so that only ISPs with the
financial ability to bring in multiple feeds can qualify. Basically,
your either big and poor or small and rich - whereas the typical "garage
operator" ISP would be small and poor.

Our belief is that while this may have worked a decade ago, it's a moot
issue now. For one thing, nothing prevents orgs that obtain larger
allocations from splitting their advertisements. For example an org that
has a /22 and 2 feeds, one larger than the other, might choose to
advertise 2 /23's so they can prepend one of the /23's towards the
smaller feed, so as to reduce traffic. Orgs that have distributed NOCS
and even larger allocations have also done this for traffic flow
reasons. There is no real guarantee than an org getting a contiguous
block will actually advertise it under a single route entry, so it seems
somewhat hypocritical to deny smaller ISPs an initial allocation because
of the reason that small allocations clog up the so-called "global route
table" when larger ISPs can and sometimes do clog it up by subnetting.

The Internet landscape has changed tremendously, it is much more
expensive now for "garage operators" to initiate operations, and the ISP
industry has had a lot of consolidation. These factors are much more of
a deterrent to small operators getting started and wanting an initial
allocation. And, with small operators, labor is costly and renumbering
out of an upstream-assigned IPv4 block is a big barrier as well.

We feel that allowing smaller ISPs to qualify now for IPv4 will have a
number of benefits:

1) It's possible that post-IPv4 runout, financial pressure to justify
assignments will develop among transit networks as the "market rate" of
IPv4 rises. That may lead to smaller ISPs who don't have their own
assignments to be pressured to shrink operations (or be pushed out
completely), by upstreams eager to sell IPv4 blocks on the transfer market.

2) Sometimes an issue is helped more by being "nibbled to death by
ducks". If a large number of small ISPs were to obtain IPv4 and follow
up by obtaining IPv6 at the same time, the cumulative effect of many
small operators calling their upstreams and pressuring their upstreams
to supply native IPv6 routing might be much stronger - and might cause
more of them to get on the ball with IPv6 deployments.

3) Small IPv4 subnets that a /23 or /22 allocation can be made from will
be increasingly available to ARIN from reclamation efforts, thus
allocating small subnets that the RIR generates from these efforts to
legitimate ISPs will help to prevent "squatting" on them from spammers
and other network criminals, without consuming "virgin" blocks in the
free pool. It might even be possible for ARIN to use portions of the
"old swamp" (ie: 192.5.0.0/16, 192.12.0.0/16, 192.16.0.0/16, etc.) for this.

Timetable for implementation: immediate


#####


STAFF ASSESSMENT

Proposal: Reduce and Simplify IPv4 Initial Allocations

Proposal Version (Date): 05 February 2010

Date of Assessment:  17 February 2010

1.	Proposal Summary (Staff Understanding)

Staff understands this policy shifts the IPv4 minimum allocation size to
a /23 and removes the requirement to be multi-homed. It allows ISPs to
request blocks of /23, /22, or /21 from ARIN with a 12-month renumbering
requirement, and to request blocks of /20 or larger with optional
renumbering. Finally, it introduces the idea that an ISP must renumber
out of an ARIN-issued /23, /22, or /21 if it wishes to request
additional addresses from ARIN.

2. Comments

A.	ARIN Staff Comments

?	4.2.2.4 states: "ISPs receiving an initial allocation equal to or
larger than /20 may wish to renumber out of their previously allocated
space. In this case, an ISP must use the new prefix to renumber out of
that previously allocated block of address space and must return the
space to its upstream provider." This is not declarative policy text and
does not provide definitive direction to the community on how to qualify
for IPv4 resources or to the staff on how to assess requests for IPv4
resources.  If this isn?t a policy requirement, it should be removed
from the policy text and perhaps placed in a best practices guide.
?	4.2.2.5 has confusing uses of the word "initial". The section is
clearly intended to apply to any direct allocation longer than a /20,
including 2nd, 3rd, and nth replacement allocations. But it uses
"initial" allocation too many times. For clarity, staff suggests
removing the word "initial" from both the title and all instances beyond
the first usage of the word.
?	The policy lays out numerous renumbering requirements and timeframes,
however it does not specify any repercussions for non-compliance,
leaving the ARIN staff on its own to determine the course of action.
Staff experience has shown us that adherence to renumbering requirements
in existing policies has often been problematic for some organizations.
When a company does not adhere to their renumbering commitments, it
forces ARIN to make a judgment call that could potentially impact an
organization?s business and productivity.

B.	ARIN General Counsel

                    "At this time counsel has no significant legal
comments.?


3. Resource Impact

This policy would have a moderate resource impact.  It is estimated that
implementation would occur within 3 - 6 months following ratification by
the ARIN Board of Trustees. The following would be needed in order to
implement:

?	New software or tools to effectively track the status of multiple
instances of renumbering requirements
?	Construction of a detailed implementation plan to include how to work
with customers who fail to meet the renumbering requirements
?	New guidelines
?	Staff training


4. Proposal Text

Modify section 4.2.1.5. Minimum allocation:
In general, ARIN allocates IP address prefixes no longer than /23 to
ISPs. If allocations smaller than /23 are needed, ISPs should request
address space from their upstream provider. When prefixes are assigned
which are longer than /20, they will be from a block reserved for that
purpose whenever that is feasible.
And
Replace the contents of section 4.2.2. Initial allocation to ISPs:
4.2.2.1. Use of /24
The efficient utilization of an entire previously allocated /24 or
equivalent from their upstream ISP.
4.2.2.2. Efficient utilization
Demonstrate efficient use of IP address space allocations by providing
appropriate documentation, including assignment histories, showing their
efficient use. ISPs must provide reassignment information on the entire
previously allocated block(s) via SWIP or RWHOIS server for /29 or
larger blocks. For blocks smaller than /29 and for internal space, ISPs
should provide utilization data either via SWIP or RWHOIS server or by
using the table format described in Section 4.2.3.7.5.
4.2.2.3. Three months
Provide detailed information showing specifically how the initial
allocation will be utilized within three months.
4.2.2.4. Renumber and return
ISPs receiving an initial allocation smaller than /20 must agree that
the newly requested IP address space will be used to renumber out of the
current addresses which will be returned to the assigning organization
within 12 months. ISPs receiving an initial allocation equal to or
larger than /20 may wish to renumber out of their previously allocated
space. In this case, an ISP must use the new prefix to renumber out of
that previously allocated block of address space and must return the
space to its upstream provider.
4.2.2.5. Replacement initial allocation
Any ISP which has received an initial allocation, or previous
replacement initial allocation, smaller than /20 who wishes to receive
additional address space must request a replacement initial allocation.
To receive a replacement initial allocation, an ISP must agree to
renumber out of and return the existing allocation in it's entirety
within 12 months of receiving a new allocation and provide justification
for the new allocation as described in section 4.2.4. Multihomed
organizations holding a /22 or a /21 at the time of policy adoption are
exempt from having to renumber and return for a period of 12 months
after this policy is adopted.


Rationale:
This policy proposal fundamentally changes and simplifies the initial
IPv4 allocations to ISPs by doing the following:
1) Makes moot whether the requesting ISP is multihomed or not, with this
policy change all initial ISPs request under the same minimums.
2) Lowers the minimums, making it easier for smaller ISPs to qualify for
direct allocations from ARIN.
3) Reduces fragmentation of the allocated IPv4 pool by forcing smaller
ISPs who do qualify under the minimum to return the small allocation
when they outgrow it. Note particularly that this does not "change the
bar" for ISPs who have already received small allocations, as they will
have not agreed to return those smaller allocations when they get larger
allocations.
4) Indirectly encourages the adoption of IPv6 as the ISPs that now
qualify for numbering under this policy change will be considered an LIR
and thus satisfy one of the IPv6 requirements in section 6.5.1.1
This policy proposal idea grew out of Proposal 98 and 100 and the
discussions surrounding those proposals as well as many discussions on
the ppml and on arin-discuss mailing lists.
For starters, it's well known that while transit networks have the
ability to filter IPv4 BGP advertisements, few to none filter anything
larger than a /24 (any who do filter /24 or larger have a default route
to fall back on), and a /24 (for perhaps no better reason than it
happens to be a "class C") has become the de-facto standard minimum. As
a result, assigning blocks smaller than a /22 (the current minimum under
4.2.2) isn't going to break anything.
Secondly, the primary motivator for denying smaller ISPs an initial
allocation from ARIN is to slow the growth of the DFZ, due to concerns
that growth of the so-called "IPv4 global routing table" would exceed
memory requirements in routers operated by transit networks. This is why
Section 4.2.2 was split into multihomed and non-multihomed in the first
place, to help "raise the bar" and prevent a land rush. Section 4.2.2.1
makes it so that only really large ISPs qualify for an initial
allocation, Section 4.2.2.2 makes it so that only ISPs with the
financial ability to bring in multiple feeds can qualify. Basically,
your either big and poor or small and rich - whereas the typical "garage
operator" ISP would be small and poor.
Our belief is that while this may have worked a decade ago, it's a moot
issue now. For one thing, nothing prevents orgs that obtain larger
allocations from splitting their advertisements. For example an org that
has a /22 and 2 feeds, one larger than the other, might choose to
advertise 2 /23's so they can prepend one of the /23's towards the
smaller feed, so as to reduce traffic. Orgs that have distributed NOCS
and even larger allocations have also done this for traffic flow
reasons. There is no real guarantee than an org getting a contiguous
block will actually advertise it under a single route entry, so it seems
somewhat hypocritical to deny smaller ISPs an initial allocation because
of the reason that small allocations clog up the so-called "global route
table" when larger ISPs can and sometimes do clog it up by subnetting.
The Internet landscape has changed tremendously, it is much more
expensive now for "garage operators" to initiate operations, and the ISP
industry has had a lot of consolidation. These factors are much more of
a deterrent to small operators getting started and wanting an initial
allocation. And, with small operators, labor is costly and renumbering
out of an upstream-assigned IPv4 block is a big barrier as well.
We feel that allowing smaller ISPs to qualify now for IPv4 will have a
number of benefits:
1) It's possible that post-IPv4 runout, financial pressure to justify
assignments will develop among transit networks as the "market rate" of
IPv4 rises. That may lead to smaller ISPs who don't have their own
assignments to be pressured to shrink operations (or be pushed out
completely), by upstreams eager to sell IPv4 blocks on the transfer market.
2) Sometimes an issue is helped more by being "nibbled to death by
ducks". If a large number of small ISPs were to obtain IPv4 and follow
up by obtaining IPv6 at the same time, the cumulative effect of many
small operators calling their upstreams and pressuring their upstreams
to supply native IPv6 routing might be much stronger - and might cause
more of them to get on the ball with IPv6 deployments.
3) Small IPv4 subnets that a /23 or /22 allocation can be made from will
be increasingly available to ARIN from reclamation efforts, thus
allocating small subnets that the RIR generates from these efforts to
legitimate ISPs will help to prevent "squatting" on them from spammers
and other network criminals, without consuming "virgin" blocks in the
free pool. It might even be possible for ARIN to use portions of the
"old swamp" (ie: 192.5.0.0/16, 192.12.0.0/16, 192.16.0.0/16, etc.) for this.






From info at arin.net  Tue Feb 23 15:24:35 2010
From: info at arin.net (Member Services)
Date: Tue, 23 Feb 2010 15:24:35 -0500
Subject: [arin-ppml] Draft Policy 2010-8: Rework of IPv6 assignment criteria
Message-ID: <4B843983.2060902@arin.net>

Draft Policy 2010-8
Rework of IPv6 assignment criteria

On 18 February 2010 the ARIN Advisory Council (AC) selected "Rework of
IPv6 assignment criteria" as a draft policy for adoption discussion on
the PPML and at the Public Policy Meeting in Toronto in April.

The draft was developed by the AC from policy proposal "107. Rework of
IPv6 assignment criteria". Per the Policy Development Process the AC
submitted text to ARIN for a staff and legal assessment prior to its
selection as a draft policy. Below the draft policy is the ARIN staff
and legal assessment, followed by the text that was submitted by the AC.

Draft Policy 2010-8 is below and can be found at:
https://www.arin.net/policy/proposals/2010_8.htm

You are encouraged to discuss Draft Policy 2010-8 on the PPML prior to
the April Public Policy Meeting. Both the discussion on the list and
at the meeting will be used by the ARIN Advisory Council to determine
the community consensus for adopting this as policy.

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

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy 2010-8
Rework of IPv6 assignment criteria

Version/Date: 23 February 2010

Policy statement:

6.5.8. Initial assignments

6.5.8.1. Initial assignment size

Organizations that meet at least one of the following criteria are
eligible to receive a minimum assignment of /48. Requests for larger
initial assignments, reasonably justified with supporting documentation,
will be evaluated based on the number of sites and the number of subnets
needed to support a site.

Organizations may request up to a /48 for each site in their network,
with the overall allocation rounded up to the next whole prefix only as
necessary. A subnet plan demonstrating a utilization of 33,689 or more
subnets within a site is necessary to justify an additional /48 for any
individual site, beyond this the 0.94 HD-Ratio metric of the number of
subnets is used.

All assignments shall be made from distinctly identified prefixes, with
each assignment receiving a reservation for growth of at least a /44.
Such reservations are not guaranteed and ARIN, at its discretion, may
assign them to other organizations at any time.

Note: Organizations with multiple sites are encouraged to consider the
use /56s for smaller satellite sites.

6.5.8.2. Criteria for initial assignment to Internet connected end-users

Organizations may justify an initial assignment for connecting their own
network to the IPv6 Internet, with an intent to provide global
reachability for the assignment within 12 months, and for addressing
devices directly attached to their network infrastructure, by meeting
one of the following additional criteria:

a. Having a previously justified IPv4 end-user assignment from ARIN or
one of its predecessor registries, or;

b. Currently being IPv6 Multihomed or immediately becoming IPv6
Multihomed and using an assigned valid global AS number, or;

c. By providing a reasonable technical justification indicating why
other IPv6 addresses from an ISP or other LIR are unsuitable and a plan
detailing the utilization of sites and subnets for one, two and five
year periods.

Examples of justifications for why addresses from an ISP or other LIR
may be unsuitable include, but are not limited to:

? An organization that operates infrastructure critical to life safety
or the functioning of society, has justification based on the fact that
renumbering would have a broader than expected impact than simply the
number of hosts involved. These would include; hospitals, fire fighting,
police, emergency response, power or energy distribution, water or waste
treatment, traffic management and control, etc?
? Regardless of the number of hosts involved, an organization has
justification if renumbering would affect 1000 or more individuals
either internal or external to the organization.

6.5.8.3 Criteria for initial assignment to non-connected networks

Organizations may justify an initial assignment for operating their own
non-connected IPv6 network and for addressing devices directly attached
to their network infrastructure, by meeting one of the following
additional criteria:

a. Having a previously justified IPv4 end-users assignment from ARIN or
one of its predecessor registries, or;

b. By providing a reasonable technical justification indicating why an
assignment for a non-connected networks is necessary, including the
intended purpose for the assignment, and describing the network
infrastructure the assignment will be used to support. Justification
must include why Unique Local IPv6 Unicast Addresses (ULA) is unsuitable
and a plan detailing the utilization of sites and subnets for one, two
and five year periods.

Examples of justifications for why ULA may be unsuitable include, but
are not limited to:

? The need for authoritative delegation of reverse DNS, including
documentation way this is necessary.
? The need for documented uniqueness, beyond the statistical uniqueness
provided by ULA, including documentation way this is necessary.
? A documented need to connect with other networks connected to or not
connected to the Internet

NOTE: Organizations are encouraged to consider the use of ULA, for
non-connected networks, see RFC 4193 for details.

6.5.8.4 Criteria for initial assignment to Community Networks

Organizations may justify an initial assignment for operating a
Community Network by documenting that they meet the criteria specified
in section 2.11. A Community Network is considered a single site and a
larger initial assignment may only be justified based on the number of
subnets necessary to serve the community in question.

6.5.9. Subsequent assignments

Subsequent assignments may be made when the need for additional sites or
subnets are justified with reasonable supporting documentation. When
possible, subsequent assignments will be made from an adjacent address
block.

Organizations may request up to a /48 for each site in their network,
with the overall allocation rounded up to the next whole prefix only as
necessary. A subnet plan demonstrating a utilization of 33,689 or more
subnets within a site is necessary to justify an additional /48 for any
individual site, beyond this the 0.94 HD-Ratio metric of the number of
subnets is used.

Note: Organizations with multiple sites are encouraged to consider the
use /56s for smaller satellite sites.

Delete current 6.5.9 Community Network Assignments as it is incorporated
in 6.5.8.4.

Rationale:

This proposal provides a complete rework of the IPv6 end-user assignment
criteria, removing the dependency on IPv4 policy, while maintaining many
of the basic concepts contained in the current policies. The order of
the subsections of 6.5.8 was rearranged moving the initial assignment
size to 6.5.8.1 and subsequent assignments to 6.5.9. This will
facilitate adding future criteria without additional renumbering of
current policies.

The initial assignment criteria include the following general concepts:

? When Internet connectivity is use to justify resources it is implied
the resources should be advertised to the Internet, within some
reasonable time frame after they are received.
? IPv4 resources may be use to justify the need for IPv6 resources. ?
Internet multihoming is sufficient justification for an end-user
assignment in and of itself.
? Other Internet connected end-users must justify why an ISP or LIR
assignment is not sufficient for their needs.
? Non-connected networks must describe the purpose and network
infrastructure the assignment will be supporting, including why ULA is
not sufficient for their needs.
? Organizations with multiple sites are allowed to request a /48 for
each site, with a suggestion to use /56s for smaller sites.
? While HD-Ratio is not completely eliminated it really only applies to
situations that an individual site of an organization needs more that a /48.
? Community networks are assumed to justify an assignment in and of
themselves, but they should be considered a single site, otherwise they
should get an ISP allocation.

Timetable for implementation: Immediate


#####


STAFF ASSESSMENT

Proposal: Rework of IPv6 assignment criteria
Proposal Version (Date): 1 Feb 2010

Date of Assessment:  12 Feb 2010


1.	Proposal Summary (Staff Understanding)

ARIN staff understands this policy establishes fresh criteria for
end-users requesting /48 and larger assignments for their networks based
on the number of sites and number of subnets needed per site.  It allows
almost all requestors to receive a /48 for a site by meeting one of the
following three criteria: have an IPv4 end user assignment OR be
multi-homed OR provide technical justification why upstream space will
not suffice and a plan detailing utilization for one, two, and five
years out. In addition, it allows non-connected (private) networks to
get an IPv6 assignment from ARIN.  Finally, it lowers the threshold for
community networks by removing the existing criteria for an initial
assignment.

2. Comments

A. ARIN Staff Comments

?	The policy adds very specific criteria for assigning a site more than
a /48. Having this specific criteria lay out such clear rules makes it
easier for both requesters and ARIN staff to understand and provides the
type of necessary details that have been missing from the current
policy.  (Staff understands that this policy allows an organization to
define what a site is.)
?	6.5.8.2 relaxes the current qualification criteria for a /48 per site
and opens up the policy to pretty much everyone. This should
significantly increase the number of assignments ARIN makes each year.

	B. ARIN General Counsel

?This proposal poses no significant legal issues.?


3. Resource Impact

This policy would have minimal resource impact.  It is estimated that
implementation would occur within 3 months after ratification by the
ARIN Board of Trustees. The following would be needed in order to implement:

?	Changes to guidelines
?	May require new template
?	Staff training


4. Proposal Text

6.5.8. Initial assignments
6.5.8.1. Initial assignment size
Organizations that meet at least one of the following criteria are
eligible to receive a minimum assignment of /48. Requests for larger
initial assignments, reasonably justified with supporting documentation,
will be evaluated based on the number of sites and the number of subnets
needed to support a site.
Organizations may request up to a /48 for each site in their network,
with the overall allocation rounded up to the next whole prefix only as
necessary. A subnet plan demonstrating a utilization of 33,689 or more
subnets within a site is necessary to justify an additional /48 for any
individual site, beyond this the 0.94 HD-Ratio metric of the number of
subnets is used.
All assignments shall be made from distinctly identified prefixes, with
each assignment receiving a reservation for growth of at least a /44.
Such reservations are not guaranteed and ARIN, at its discretion, may
assign them to other organizations at any time.
Note: Organizations with multiple sites are encouraged to consider the
use /56s for smaller satellite sites.
6.5.8.2. Criteria for initial assignment to Internet connected end-users
Organizations may justify an initial assignment for connecting their own
network to the IPv6 Internet, with an intent to provide global
reachability for the assignment within 12 months, and for addressing
devices directly attached to their network infrastructure, by meeting
one of the following additional criteria:
a. Having a previously justified IPv4 end-user assignment from ARIN or
one of its predecessor registries, or;
b. Currently being IPv6 Multihomed or immediately becoming IPv6
Multihomed and using an assigned valid global AS number, or;
c. By providing a reasonable technical justification indicating why
other IPv6 addresses from an ISP or other LIR are unsuitable and a plan
detailing the utilization of sites and subnets for one, two and five
year periods.
Examples of justifications for why addresses from an ISP or other LIR
may be unsuitable include, but are not limited to:
?	An organization that operates infrastructure critical to life safety
or the functioning of society, has justification based on the fact that
renumbering would have a broader than expected impact than simply the
number of hosts involved. These would include; hospitals, fire
fighting, police, emergency response, power or energy distribution,
water or waste treatment, traffic management and control, etc...
?	Regardless of the number of hosts involved, an organization has
justification if renumbering would affect 1000 or more individuals
either internal or external to the organization.
6.5.8.3 Criteria for initial assignment to non-connected networks
Organizations may justify an initial assignment for operating their own
non-connected IPv6 network and for addressing devices directly attached
to their network infrastructure, by meeting one of the following
additional criteria:
a. Having a previously justified IPv4 end-users assignment from ARIN or
one of its predecessor registries, or;
b. By providing a reasonable technical justification indicating why an
assignment for a non-connected networks is necessary, including the
intended purpose for the assignment, and describing the network
infrastructure the assignment will be used to support. Justification
must include why Unique Local IPv6 Unicast Addresses (ULA) is unsuitable
and a plan detailing the utilization of sites and subnets for one, two
and five year periods.
Examples of justifications for why ULA may be unsuitable include, but
are not limited to:
?	The need for authoritative delegation of reverse DNS, including
documentation way this is necessary.
?	The need for documented uniqueness, beyond the statistical uniqueness
provided by ULA, including documentation way this is necessary.
?	A documented need to connect with other networks connected to or not
connected to the Internet
NOTE: Organizations are encouraged to consider the use of ULA, for
non-connected networks, see RFC 4193 for details.
6.5.8.4 Criteria for initial assignment to Community Networks
Organizations may justify an initial assignment for operating a
Community Network by documenting that they meet the criteria specified
in section 2.11. A Community Network is considered a single site and a
larger initial assignment may only be justified based on the number of
subnets necessary to serve the community in question.
6.5.9. Subsequent assignments
Subsequent assignments may be made when the need for additional sites or
subnets are justified with reasonable supporting documentation. When
possible, subsequent assignments will be made from an adjacent address
block.
Organizations may request up to a /48 for each site in their network,
with the overall allocation rounded up to the next whole prefix only as
necessary. A subnet plan demonstrating a utilization of 33,689 or more
subnets within a site is necessary to justify an additional /48 for any
individual site, beyond this the 0.94 HD-Ratio metric of the number of
subnets is used.
Note: Organizations with multiple sites are encouraged to consider the
use /56s for smaller satellite sites.
Delete current 6.5.9 Community Network Assignments as it is incorporated
in 6.5.8.4.


Rationale:
This proposal provides a complete rework of the IPv6 end-user assignment
criteria, removing the dependency on IPv4 policy, while maintaining many
of the basic concepts contained in the current policies. The order of
the subsections of 6.5.8 was rearranged moving the initial assignment
size to 6.5.8.1 and subsequent assignments to 6.5.9. This will
facilitate adding future criteria without additional renumbering of
current policies.
The initial assignment criteria include the following general concepts:
?	When Internet connectivity is use to justify resources it is implied
the resources should be advertised to the Internet, within some
reasonable time frame after they are received.
?	IPv4 resources may be use to justify the need for IPv6 resources.
?	Internet multihoming is sufficient justification for an end-user
assignment in and of itself.
?	Other Internet connected end-users must justify why an ISP or LIR
assignment is not sufficient for their needs.
?	Non-connected networks must describe the purpose and network
infrastructure the assignment will be supporting, including why ULA is
not sufficient for their needs.
?	Organizations with multiple sites are allowed to request a /48 for
each site, with a suggestion to use /56s for smaller sites.
?	While HD-Ratio is not completely eliminated it really only applies to
situations that an individual site of an organization needs more that a /48.
?	Community networks are assumed to justify an assignment in and of
themselves, but they should be considered a single site, otherwise they
should get an ISP allocation.






From bill at herrin.us  Tue Feb 23 16:52:35 2010
From: bill at herrin.us (William Herrin)
Date: Tue, 23 Feb 2010 16:52:35 -0500
Subject: [arin-ppml] IPv6 Multihomed networks
In-Reply-To: <23747.1266954202@marajade.sandelman.ca>
References: <28E139F46D45AF49A31950F88C4974580543267E@E03MVZ2-UKDY.domain1.systemhost.net>
	<3c3e3fca1002221215l60a07576q41b2a058225447e0@mail.gmail.com> 
	<4B82F096.1030007@matthew.at> <4B82FDDC.8080706@umn.edu>
	<8695009A81378E48879980039EEDAD28876D418C@MAIL1.polartel.local>
	<11099.1266885507@marajade.sandelman.ca>
	<71057B2E-C042-45B8-900B-30A5104EA4CB@delong.com> 
	<4B83305A.7020409@ibctech.ca>
	<8695009A81378E48879980039EEDAD28876D41A0@MAIL1.polartel.local>
	<23747.1266954202@marajade.sandelman.ca>
Message-ID: <3c3e3fca1002231352j266d54d5y426df6eaf2f0489e@mail.gmail.com>

On Tue, Feb 23, 2010 at 2:43 PM, Michael Richardson <mcr at sandelman.ca> wrote:
> For those that feel that ARIN can never keep unconnected networks from
> being routed globally, I wonder if you'd take the time to read the SIDR
> work from IETF.
>
> Consider what would happen if ARIN were to issue non-connected network
> space, and bind it's use to a specific (dummy) ASN. ?Once secure, the
> public ("Internet") BGP system would never accept an announcement from
> anyone attempting to announce that prefix from another ASN.

Hi Michael,

That could work, in this particular case if not the more general case.
It's a bit of a hack.

Do you have a decent overview document for SIDR? Perusing the drafts,
I couldn't make heads or tails of how authority delegation for who
signs the ROA is supposed to work.

I think I'd also like to see SIDR deployed before writing ARIN policy
against it. I think it's worth discussing the kinds of policy
structures SIDR could enable but I don't think it has developed quite
to the point where we should hold our breaths and wait for 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 farmer at umn.edu  Tue Feb 23 19:55:45 2010
From: farmer at umn.edu (David Farmer)
Date: Tue, 23 Feb 2010 18:55:45 -0600
Subject: [arin-ppml] Draft Policy 2010-8: Rework of IPv6 assignment
	criteria
In-Reply-To: <4B843983.2060902@arin.net>
References: <4B843983.2060902@arin.net>
Message-ID: <4B847911.10909@umn.edu>

In on an off-line discussion, concerns were raised about rewriting the 
Community Networks Policy so soon after this policy was adopted. 
Therefore, in a final edit of this draft policy prior to Toronto, I 
propose to remove 6.5.8.4 and move the current Community Networks policy 
as-is from 6.5.9 to 6.5.10.  This move is necessary to make room for 
section 6.5.9 Subsequent assignments from this policy to immediately 
follow section 6.5.8. Initial assignments.

If there are other changes that you believe should be made to this text 
prior to the Toronto meeting please let me know.  The text will be 
frozen in early April prior to the meeting, so we have a little time, 
but I would rather not wait until the last minute.

Thanks

Member Services wrote:
> Draft Policy 2010-8
> Rework of IPv6 assignment criteria
> 
> On 18 February 2010 the ARIN Advisory Council (AC) selected "Rework of
> IPv6 assignment criteria" as a draft policy for adoption discussion on
> the PPML and at the Public Policy Meeting in Toronto in April.
> 
> The draft was developed by the AC from policy proposal "107. Rework of
> IPv6 assignment criteria". Per the Policy Development Process the AC
> submitted text to ARIN for a staff and legal assessment prior to its
> selection as a draft policy. Below the draft policy is the ARIN staff
> and legal assessment, followed by the text that was submitted by the AC.
> 
> Draft Policy 2010-8 is below and can be found at:
> https://www.arin.net/policy/proposals/2010_8.htm
> 
> You are encouraged to discuss Draft Policy 2010-8 on the PPML prior to
> the April Public Policy Meeting. Both the discussion on the list and
> at the meeting will be used by the ARIN Advisory Council to determine
> the community consensus for adopting this as policy.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> Regards,
> 
> Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy 2010-8
> Rework of IPv6 assignment criteria
> 
> Version/Date: 23 February 2010
> 
> Policy statement:
> 
> 6.5.8. Initial assignments
> 
> 6.5.8.1. Initial assignment size
> 
> Organizations that meet at least one of the following criteria are
> eligible to receive a minimum assignment of /48. Requests for larger
> initial assignments, reasonably justified with supporting documentation,
> will be evaluated based on the number of sites and the number of subnets
> needed to support a site.
> 
> Organizations may request up to a /48 for each site in their network,
> with the overall allocation rounded up to the next whole prefix only as
> necessary. A subnet plan demonstrating a utilization of 33,689 or more
> subnets within a site is necessary to justify an additional /48 for any
> individual site, beyond this the 0.94 HD-Ratio metric of the number of
> subnets is used.
> 
> All assignments shall be made from distinctly identified prefixes, with
> each assignment receiving a reservation for growth of at least a /44.
> Such reservations are not guaranteed and ARIN, at its discretion, may
> assign them to other organizations at any time.
> 
> Note: Organizations with multiple sites are encouraged to consider the
> use /56s for smaller satellite sites.
> 
> 6.5.8.2. Criteria for initial assignment to Internet connected end-users
> 
> Organizations may justify an initial assignment for connecting their own
> network to the IPv6 Internet, with an intent to provide global
> reachability for the assignment within 12 months, and for addressing
> devices directly attached to their network infrastructure, by meeting
> one of the following additional criteria:
> 
> a. Having a previously justified IPv4 end-user assignment from ARIN or
> one of its predecessor registries, or;
> 
> b. Currently being IPv6 Multihomed or immediately becoming IPv6
> Multihomed and using an assigned valid global AS number, or;
> 
> c. By providing a reasonable technical justification indicating why
> other IPv6 addresses from an ISP or other LIR are unsuitable and a plan
> detailing the utilization of sites and subnets for one, two and five
> year periods.
> 
> Examples of justifications for why addresses from an ISP or other LIR
> may be unsuitable include, but are not limited to:
> 
> ? An organization that operates infrastructure critical to life safety
> or the functioning of society, has justification based on the fact that
> renumbering would have a broader than expected impact than simply the
> number of hosts involved. These would include; hospitals, fire fighting,
> police, emergency response, power or energy distribution, water or waste
> treatment, traffic management and control, etc?
> ? Regardless of the number of hosts involved, an organization has
> justification if renumbering would affect 1000 or more individuals
> either internal or external to the organization.
> 
> 6.5.8.3 Criteria for initial assignment to non-connected networks
> 
> Organizations may justify an initial assignment for operating their own
> non-connected IPv6 network and for addressing devices directly attached
> to their network infrastructure, by meeting one of the following
> additional criteria:
> 
> a. Having a previously justified IPv4 end-users assignment from ARIN or
> one of its predecessor registries, or;
> 
> b. By providing a reasonable technical justification indicating why an
> assignment for a non-connected networks is necessary, including the
> intended purpose for the assignment, and describing the network
> infrastructure the assignment will be used to support. Justification
> must include why Unique Local IPv6 Unicast Addresses (ULA) is unsuitable
> and a plan detailing the utilization of sites and subnets for one, two
> and five year periods.
> 
> Examples of justifications for why ULA may be unsuitable include, but
> are not limited to:
> 
> ? The need for authoritative delegation of reverse DNS, including
> documentation way this is necessary.
> ? The need for documented uniqueness, beyond the statistical uniqueness
> provided by ULA, including documentation way this is necessary.
> ? A documented need to connect with other networks connected to or not
> connected to the Internet
> 
> NOTE: Organizations are encouraged to consider the use of ULA, for
> non-connected networks, see RFC 4193 for details.
> 
> 6.5.8.4 Criteria for initial assignment to Community Networks
> 
> Organizations may justify an initial assignment for operating a
> Community Network by documenting that they meet the criteria specified
> in section 2.11. A Community Network is considered a single site and a
> larger initial assignment may only be justified based on the number of
> subnets necessary to serve the community in question.
> 
> 6.5.9. Subsequent assignments
> 
> Subsequent assignments may be made when the need for additional sites or
> subnets are justified with reasonable supporting documentation. When
> possible, subsequent assignments will be made from an adjacent address
> block.
> 
> Organizations may request up to a /48 for each site in their network,
> with the overall allocation rounded up to the next whole prefix only as
> necessary. A subnet plan demonstrating a utilization of 33,689 or more
> subnets within a site is necessary to justify an additional /48 for any
> individual site, beyond this the 0.94 HD-Ratio metric of the number of
> subnets is used.
> 
> Note: Organizations with multiple sites are encouraged to consider the
> use /56s for smaller satellite sites.
> 
> Delete current 6.5.9 Community Network Assignments as it is incorporated
> in 6.5.8.4.
> 
> Rationale:
> 
> This proposal provides a complete rework of the IPv6 end-user assignment
> criteria, removing the dependency on IPv4 policy, while maintaining many
> of the basic concepts contained in the current policies. The order of
> the subsections of 6.5.8 was rearranged moving the initial assignment
> size to 6.5.8.1 and subsequent assignments to 6.5.9. This will
> facilitate adding future criteria without additional renumbering of
> current policies.
> 
> The initial assignment criteria include the following general concepts:
> 
> ? When Internet connectivity is use to justify resources it is implied
> the resources should be advertised to the Internet, within some
> reasonable time frame after they are received.
> ? IPv4 resources may be use to justify the need for IPv6 resources. ?
> Internet multihoming is sufficient justification for an end-user
> assignment in and of itself.
> ? Other Internet connected end-users must justify why an ISP or LIR
> assignment is not sufficient for their needs.
> ? Non-connected networks must describe the purpose and network
> infrastructure the assignment will be supporting, including why ULA is
> not sufficient for their needs.
> ? Organizations with multiple sites are allowed to request a /48 for
> each site, with a suggestion to use /56s for smaller sites.
> ? While HD-Ratio is not completely eliminated it really only applies to
> situations that an individual site of an organization needs more that a 
> /48.
> ? Community networks are assumed to justify an assignment in and of
> themselves, but they should be considered a single site, otherwise they
> should get an ISP allocation.
> 
> Timetable for implementation: Immediate
> 
> 
> #####
> 
> 
> STAFF ASSESSMENT
> 
> Proposal: Rework of IPv6 assignment criteria
> Proposal Version (Date): 1 Feb 2010
> 
> Date of Assessment:  12 Feb 2010
> 
> 
> 1.    Proposal Summary (Staff Understanding)
> 
> ARIN staff understands this policy establishes fresh criteria for
> end-users requesting /48 and larger assignments for their networks based
> on the number of sites and number of subnets needed per site.  It allows
> almost all requestors to receive a /48 for a site by meeting one of the
> following three criteria: have an IPv4 end user assignment OR be
> multi-homed OR provide technical justification why upstream space will
> not suffice and a plan detailing utilization for one, two, and five
> years out. In addition, it allows non-connected (private) networks to
> get an IPv6 assignment from ARIN.  Finally, it lowers the threshold for
> community networks by removing the existing criteria for an initial
> assignment.
> 
> 2. Comments
> 
> A. ARIN Staff Comments
> 
> ?    The policy adds very specific criteria for assigning a site more than
> a /48. Having this specific criteria lay out such clear rules makes it
> easier for both requesters and ARIN staff to understand and provides the
> type of necessary details that have been missing from the current
> policy.  (Staff understands that this policy allows an organization to
> define what a site is.)
> ?    6.5.8.2 relaxes the current qualification criteria for a /48 per site
> and opens up the policy to pretty much everyone. This should
> significantly increase the number of assignments ARIN makes each year.
> 
>     B. ARIN General Counsel
> 
> ?This proposal poses no significant legal issues.?
> 
> 
> 3. Resource Impact
> 
> This policy would have minimal resource impact.  It is estimated that
> implementation would occur within 3 months after ratification by the
> ARIN Board of Trustees. The following would be needed in order to 
> implement:
> 
> ?    Changes to guidelines
> ?    May require new template
> ?    Staff training
> 
> 
> 4. Proposal Text
> 
> 6.5.8. Initial assignments
> 6.5.8.1. Initial assignment size
> Organizations that meet at least one of the following criteria are
> eligible to receive a minimum assignment of /48. Requests for larger
> initial assignments, reasonably justified with supporting documentation,
> will be evaluated based on the number of sites and the number of subnets
> needed to support a site.
> Organizations may request up to a /48 for each site in their network,
> with the overall allocation rounded up to the next whole prefix only as
> necessary. A subnet plan demonstrating a utilization of 33,689 or more
> subnets within a site is necessary to justify an additional /48 for any
> individual site, beyond this the 0.94 HD-Ratio metric of the number of
> subnets is used.
> All assignments shall be made from distinctly identified prefixes, with
> each assignment receiving a reservation for growth of at least a /44.
> Such reservations are not guaranteed and ARIN, at its discretion, may
> assign them to other organizations at any time.
> Note: Organizations with multiple sites are encouraged to consider the
> use /56s for smaller satellite sites.
> 6.5.8.2. Criteria for initial assignment to Internet connected end-users
> Organizations may justify an initial assignment for connecting their own
> network to the IPv6 Internet, with an intent to provide global
> reachability for the assignment within 12 months, and for addressing
> devices directly attached to their network infrastructure, by meeting
> one of the following additional criteria:
> a. Having a previously justified IPv4 end-user assignment from ARIN or
> one of its predecessor registries, or;
> b. Currently being IPv6 Multihomed or immediately becoming IPv6
> Multihomed and using an assigned valid global AS number, or;
> c. By providing a reasonable technical justification indicating why
> other IPv6 addresses from an ISP or other LIR are unsuitable and a plan
> detailing the utilization of sites and subnets for one, two and five
> year periods.
> Examples of justifications for why addresses from an ISP or other LIR
> may be unsuitable include, but are not limited to:
> ?    An organization that operates infrastructure critical to life safety
> or the functioning of society, has justification based on the fact that
> renumbering would have a broader than expected impact than simply the
> number of hosts involved. These would include; hospitals, fire
> fighting, police, emergency response, power or energy distribution,
> water or waste treatment, traffic management and control, etc...
> ?    Regardless of the number of hosts involved, an organization has
> justification if renumbering would affect 1000 or more individuals
> either internal or external to the organization.
> 6.5.8.3 Criteria for initial assignment to non-connected networks
> Organizations may justify an initial assignment for operating their own
> non-connected IPv6 network and for addressing devices directly attached
> to their network infrastructure, by meeting one of the following
> additional criteria:
> a. Having a previously justified IPv4 end-users assignment from ARIN or
> one of its predecessor registries, or;
> b. By providing a reasonable technical justification indicating why an
> assignment for a non-connected networks is necessary, including the
> intended purpose for the assignment, and describing the network
> infrastructure the assignment will be used to support. Justification
> must include why Unique Local IPv6 Unicast Addresses (ULA) is unsuitable
> and a plan detailing the utilization of sites and subnets for one, two
> and five year periods.
> Examples of justifications for why ULA may be unsuitable include, but
> are not limited to:
> ?    The need for authoritative delegation of reverse DNS, including
> documentation way this is necessary.
> ?    The need for documented uniqueness, beyond the statistical uniqueness
> provided by ULA, including documentation way this is necessary.
> ?    A documented need to connect with other networks connected to or not
> connected to the Internet
> NOTE: Organizations are encouraged to consider the use of ULA, for
> non-connected networks, see RFC 4193 for details.
> 6.5.8.4 Criteria for initial assignment to Community Networks
> Organizations may justify an initial assignment for operating a
> Community Network by documenting that they meet the criteria specified
> in section 2.11. A Community Network is considered a single site and a
> larger initial assignment may only be justified based on the number of
> subnets necessary to serve the community in question.
> 6.5.9. Subsequent assignments
> Subsequent assignments may be made when the need for additional sites or
> subnets are justified with reasonable supporting documentation. When
> possible, subsequent assignments will be made from an adjacent address
> block.
> Organizations may request up to a /48 for each site in their network,
> with the overall allocation rounded up to the next whole prefix only as
> necessary. A subnet plan demonstrating a utilization of 33,689 or more
> subnets within a site is necessary to justify an additional /48 for any
> individual site, beyond this the 0.94 HD-Ratio metric of the number of
> subnets is used.
> Note: Organizations with multiple sites are encouraged to consider the
> use /56s for smaller satellite sites.
> Delete current 6.5.9 Community Network Assignments as it is incorporated
> in 6.5.8.4.
> 
> 
> Rationale:
> This proposal provides a complete rework of the IPv6 end-user assignment
> criteria, removing the dependency on IPv4 policy, while maintaining many
> of the basic concepts contained in the current policies. The order of
> the subsections of 6.5.8 was rearranged moving the initial assignment
> size to 6.5.8.1 and subsequent assignments to 6.5.9. This will
> facilitate adding future criteria without additional renumbering of
> current policies.
> The initial assignment criteria include the following general concepts:
> ?    When Internet connectivity is use to justify resources it is implied
> the resources should be advertised to the Internet, within some
> reasonable time frame after they are received.
> ?    IPv4 resources may be use to justify the need for IPv6 resources.
> ?    Internet multihoming is sufficient justification for an end-user
> assignment in and of itself.
> ?    Other Internet connected end-users must justify why an ISP or LIR
> assignment is not sufficient for their needs.
> ?    Non-connected networks must describe the purpose and network
> infrastructure the assignment will be supporting, including why ULA is
> not sufficient for their needs.
> ?    Organizations with multiple sites are allowed to request a /48 for
> each site, with a suggestion to use /56s for smaller sites.
> ?    While HD-Ratio is not completely eliminated it really only applies to
> situations that an individual site of an organization needs more that a 
> /48.
> ?    Community networks are assumed to justify an assignment in and of
> themselves, but they should be considered a single site, otherwise they
> should get an ISP allocation.
> 
> 
> 
> 
> _______________________________________________
> 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
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================


From vixie at isc.org  Wed Feb 24 01:14:57 2010
From: vixie at isc.org (Paul Vixie)
Date: Wed, 24 Feb 2010 06:14:57 +0000
Subject: [arin-ppml] IPv6 Non-connected networks
In-Reply-To: <28E139F46D45AF49A31950F88C497458054324FC@E03MVZ2-UKDY.domain1.systemhost.net>
	(michael dillon's message of "Mon\, 22 Feb 2010 15\:26\:58 -0000")
References: <75cb24521002220705l1283decy46be540b23be810@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054324FC@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <g3d3zv40ta.fsf@nsa.vix.com>

michael.dillon at bt.com writes:

> ULA random (FD00::/8) does not provide the uniqueness guarantee.  There
> is another kind of ULA set aside for assignments to organizations that
> would provide a uniqueness guarantee.
>
> The problem is that the IETF has not yet figured out how to manage
> assignments of FC00::/8.
>
> As far as I know, there isn't currently an active Internet draft on this
> topic.

i never submitted <http://nsa.vix.com/~vixie/ula-global.txt> because it
would take a global RIR policy push and i wasn't up for the travel.
-- 
Paul Vixie, KI6YSY
Chairman, ARIN BoT



From steve at ibctech.ca  Wed Feb 24 20:07:24 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Wed, 24 Feb 2010 20:07:24 -0500
Subject: [arin-ppml] Clarification on "a block designated for that purpose"
Message-ID: <4B85CD4C.70109@ibctech.ca>

Although I haven't had a chance to thoroughly read the Staff Assessments
within the recent Draft Policies, I just want to make something clear.

When I came up with 'a block designated/reserved for that purpose', I
was not attempting to segregate the IP space into another classful
environment.

I clearly understand that ARIN is not, or will not be in a position to
create/modify routing policy, nor do I (at this time) think that they
should be.

My engineering hat says this:

- extreme influx of traffic from x:x::/x
- my automation software senses this, and looks up the origin
- it's an ARIN allocation, and it falls within the 'special IX' space
- we weight the traffic differently, and allow it for an extended period

- same situation, but from a /48 within ARIN assigned PA space
- same auto tools identify that there is no SWIP
- it might be an attack
- route is [sink|black] holed, and ops are notified

- same situation again, from a non-connected network
- all space in this regard is known via ARIN, because it is from a block
reserved for the purpose
- route filters sink immediately, notify ops, and take necessary steps
to shut them down

- whether custom or [insert very expensive network] software, if the
space is going to be segregated in ANY regard, it is in the best
interest of the entire community to be able to have a safe understanding
of the identity of what that IP address is, and what its purpose is.

Operations hat:

- private /48? block all
- single-homed /48? block dirty feed, and notify community of bad provider
- leaky IX? make proper contact
- advertising someone else's space? heh

My point is, is that having ALL IP space alloc'd/assigned out of blocks
reserved for that purpose is for `informational purposes'.

I'm not trying to imply a new classful strategy. Classful was a
technological issue that was implemented in hardware/software. What I've
been hoping for was a policy-based strategy, that would give each and
everyone the opportunity to adhere to it, or not.

There are no restrictions. Again... I'm not asking for ARIN to create a
"boundary" here. As an engineer/operator, I just would find it easier
that if the IP space was to be segregated, that it be segregated in a
way that it be documented publicly, so that ops *could* make
routing/forwarding decisions on the documentation if they *chose* to.

Steve

ps. the v6 was an example. Having the same _documented_ segregation for
v4 would be just as fantastic.



From michael.dillon at bt.com  Thu Feb 25 04:04:41 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Thu, 25 Feb 2010 09:04:41 -0000
Subject: [arin-ppml] Clarification on "a block designated for that
	purpose"
In-Reply-To: <4B85CD4C.70109@ibctech.ca>
Message-ID: <28E139F46D45AF49A31950F88C497458054841E6@E03MVZ2-UKDY.domain1.systemhost.net>

> When I came up with 'a block designated/reserved for that 
> purpose', I was not attempting to segregate the IP space into 
> another classful environment.

Why not? Classes are good. Classes simplify things. That is
why the designers of IPv6 use a loosely classful model.
People are under the mistaken impression that classful
networking is bade because of the history of IPv4. But
IPv4 classes were not bad, they were too small and too
rigid. In IPv6, the classes are much larger and very
unlikely to be too small. And in IPv6 we have only
designated about 1/8th of the space so there is even
room for additional classes so we don't have the 
rigidity problem.

Note that IPv4 today is still classful. We don't have 
Class A, B and C any more, but we still have class D
multicast and RFC 1918, and a few other special use
classes.

It is a GOOD thing if ARIN applies classful thinking
and uses a designated block for address allocations
which providers will likely want to treat AS A CLASS
and apply the same policy towards them. 

> - it's an ARIN allocation, and it falls within the 'special IX' space
> - we weight the traffic differently, and allow it for an 
> extended period

That is a class of address. If the special IX space was
a list of 379 scattered allocations ranging from /24 to
/19, you would do more work than if it was all from a
single ARIN /15 block. The CLASS exists regardless of
whether ARIN does the sensible thing or not.

> - whether custom or [insert very expensive network] software, 
> if the space is going to be segregated in ANY regard, it is 
> in the best interest of the entire community to be able to 
> have a safe understanding of the identity of what that IP 
> address is, and what its purpose is.

Indeed. Network operators do CLASSify addresses and apply
special behaviors according to the CLASS. Since ARIN
serves the community, ARIN should model allocations according
the the CLASSful activities of operators, where that is
possible.

> My point is, is that having ALL IP space alloc'd/assigned out 
> of blocks reserved for that purpose is for `informational purposes'.

Yes, for CLASSification purposes.

> I'm not trying to imply a new classful strategy.

Of course not. The classful strategy already exists and was
implemented by network operators. ARIN is simply coming into
alignment with what network operators already do because it
it benefits the network.

> There are no restrictions. Again... I'm not asking for ARIN 
> to create a "boundary" here.

Sure you are. Otherwise you would ignore this issue entirely
and work with someone like Cymru to set up a registry to
track all the special case blocks.

> As an engineer/operator, I just 
> would find it easier that if the IP space was to be 
> segregated, that it be segregated in a way that it be 
> documented publicly, so that ops *could* make 
> routing/forwarding decisions on the documentation if they *chose* to.

I agree with you that this is a good thing.
Classes are good, and subclasses like this are within the
scope of ARIN's charter. We may not determine network operations
activity, but we have always tried to fit in with it as
long as it was consistent with the public interest.

When ARIN started, network operators used classful filtering
on incoming BGP announcements since they knew that ARIN's minimum
ISP allocation on certain /8s, was /19. ARIN had defined the class
and operators leveraged that information. 

--Michael Dillon


From steve at ibctech.ca  Thu Feb 25 18:35:50 2010
From: steve at ibctech.ca (Steve Bertrand)
Date: Thu, 25 Feb 2010 18:35:50 -0500
Subject: [arin-ppml] Clarification on "a block designated for
	that	purpose"
In-Reply-To: <28E139F46D45AF49A31950F88C497458054841E6@E03MVZ2-UKDY.domain1.systemhost.net>
References: <28E139F46D45AF49A31950F88C497458054841E6@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <4B870956.4010308@ibctech.ca>

On 2010.02.25 04:04, michael.dillon at bt.com wrote:
>> When I came up with 'a block designated/reserved for that 
>> purpose', I was not attempting to segregate the IP space into 
>> another classful environment.

> Note that IPv4 today is still classful. We don't have 
> Class A, B and C any more, but we still have class D
> multicast and RFC 1918, and a few other special use
> classes.

These are 'hard' classes (ie. classes that require major vendor overhaul
and operational learning curves and expenses to get over). I guess I
agree with you that what I'd like to see is creating a _form_ of class.

> It is a GOOD thing if ARIN applies classful thinking
> and uses a designated block for address allocations
> which providers will likely want to treat AS A CLASS
> and apply the same policy towards them.

Agreed. A 'soft' class system. One founded on policy and documentation,
that can be changed if the policy is changed. One where network people
and business policy makers can form their own internal policies around
if they choose to, but there will be no ill-effects if they don't.

>> - it's an ARIN allocation, and it falls within the 'special IX' space
>> - we weight the traffic differently, and allow it for an 
>> extended period

> That is a class of address. If the special IX space was
> a list of 379 scattered allocations ranging from /24 to
> /19, you would do more work than if it was all from a
> single ARIN /15 block. The CLASS exists regardless of
> whether ARIN does the sensible thing or not.

Exactly. Easier for reporting, easier for filtering/PBR etc, but
requires no operational changes/impact for those who might not need/want
to do traffic 'classification' within their network.

>> There are no restrictions. Again... I'm not asking for ARIN 
>> to create a "boundary" here.
> 
> Sure you are. Otherwise you would ignore this issue entirely
> and work with someone like Cymru to set up a registry to
> track all the special case blocks.

That's a thought, but wouldn't it be easier if we did the documentation
this time around since we have the chance, and let Team Cymru focus on
their new projects? ;)

fwiw, I believe that ALL blocks are "special case". ie. it's a special
case if I need single-homed PA, another special case if I need a
multi-homed /48, ISP /32, IX, infrastructure etc, and I'm hoping that
its not too late to configure a documentation system for it.

>> As an engineer/operator, I just 
>> would find it easier that if the IP space was to be 
>> segregated, that it be segregated in a way that it be 
>> documented publicly, so that ops *could* make 
>> routing/forwarding decisions on the documentation if they *chose* to.
> 
> I agree with you that this is a good thing.
> Classes are good, and subclasses like this are within the
> scope of ARIN's charter. We may not determine network operations
> activity, but we have always tried to fit in with it as
> long as it was consistent with the public interest.
> 
> When ARIN started, network operators used classful filtering
> on incoming BGP announcements since they knew that ARIN's minimum
> ISP allocation on certain /8s, was /19. ARIN had defined the class
> and operators leveraged that information.

We have another chance to use leverage again then. With the relatively
few v6 blocks currently allocated/assigned by ARIN, with documentation,
ops could once again be able to identify not only the minimum/maximum
_size_ of the prefix from the block, but also what its _purpose_ is (or
supposed to be).

What prompted my OP was a few off-list comments/discussions that I had.
Some were saying that I was trying to create "classes", and some "classful".

The terminology got me until I read your response. I would like to see
'classes of networks' (documentation only), but not 'classful networks'
(ie hard boundaries).

Steve


From michael.dillon at bt.com  Fri Feb 26 03:32:15 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 26 Feb 2010 08:32:15 -0000
Subject: [arin-ppml] Clarification on "a block designated for
	that	purpose"
In-Reply-To: <4B870956.4010308@ibctech.ca>
Message-ID: <28E139F46D45AF49A31950F88C497458054F27FF@E03MVZ2-UKDY.domain1.systemhost.net>


> What prompted my OP was a few off-list comments/discussions 
> that I had.
> Some were saying that I was trying to create "classes", and 
> some "classful".

I suspected as much. I am opposed to the kind of knee jerk
reaction because it means that the people saying these 
things either don't know anything about IPv6 or else they
simply haven't taken the time to really think about the
topic.

> The terminology got me until I read your response. I would 
> like to see 'classes of networks' (documentation only), but 
> not 'classful networks'
> (ie hard boundaries).

Even hard boundaries would not be a bad thing if they are
boundaries around a very large numberspace with room to
breathe. For instance the /64 boundary is becoming harder
as some vendors are finding it beneficial to build a maximum
/64 prefix length into their hardware.

Also, when you have thousands of ISPs basing their filters
on some kind of ARIN classification of an address range,
to most people, that makes it just as hard as the class A
boundary was before CIDR.

Networking is not Democrats versus Republicans stuff or
commies versus capitalist running dogs. Anything that is
bad in the IPv4 world is only bad because of the context
that it is in, and in the IPv6 world, the context has
changed so radically, that you really have to evaluate
things from scratch before pronouncing something as bad
or good.

--Michael Dillon


From rudi.daniel at gmail.com  Fri Feb 26 11:55:08 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Fri, 26 Feb 2010 12:55:08 -0400
Subject: [arin-ppml] RIPE/ITU
Message-ID: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>

Although I am indeed thankful to the ITU for keeping us poor and
under privileged developing countries well stocked in IPv6 numbers, I would
much prefer that ARIN consider structural modifications to allow for sub
regional registries under present structure: As in the case of a region like
the Caribbean which has such completely different demographics that the bulk
of the ARIN Region and therefore allow the ITU to interact not only in IPv6
but also in IPv4 (not mentioned in the attachment).

The recent HipCar project currently being undertaken in the Caribbean region
is another very important initiative by the ITU in garnering the support of
business and Governments in a region where she has always had a good degree
of control and support.

I would be interested in the views of the community because this may be a
complex issue and I really do not know the views of the larger community out
there.


--Forwarded Message Attachment--
From: ncc at ripe.net
To: ncc-announce at ripe.net
Date: Thu, 25 Feb 2010 17:20:18 +0100
Subject: [Admin] [members-discuss] [ncc-announce] RIPE NCC Position On The
   ITU IPv6 Group

Dear Colleagues,

As you may be aware, the International Telecommunication Union's (ITU)
Telecommunication Standardization Bureau (TSB) has convened an ITU
IPv6 Group, the first meeting of which will be held on 15-16 March
2010 in Geneva, Switzerland. Information on this group is available at:
http://www.itu.int/ITU-T/othergroups/ipv6/

Among the group's Terms of Reference are the following:

  * To draft a global policy proposal for the reservation of a large
IPv6 block, taking into consideration the future needs of developing
countries (as outlined in paragraph 23 of ITU document C09/29).

  * To further study possible methodologies and related
implementation mechanisms to ensure 'equitable access' to IPv6
resource by countries.

  * To further study the possibility for ITU to become another
Internet Registry, and propose policies and procedures for ITU to
manage a reserved IPv6 block.

  * To further study the feasibility and advisability of implementing
the CIR [Country Internet Registry] model for those countries who
would request national allocations.

The ITU IPv6 Group is open to ITU Member States and Sector Members of
ITU-T and ITU-D. RIRs that are not members have also been extended an
invitation to participate.

IPv6 address policy is clearly of critical importance to the RIPE NCC
membership, and the unsympathetic implementation of any of the Terms
of Reference stated above would have serious impact on the global IP
address distribution environment.

Members of RIPE NCC staff will be participating in this meeting of the
ITU IPv6 Group to represent the interests of our members and community.

The position of the RIPE NCC is based on support for smooth and
reliable working of the Internet globally, and for the bottom-up, open
policy development process that allows for all stakeholders, including
business, government and the technical community, to participate.

Some of the issues addressed in the Terms of Reference listed above
are a cause for concern because they could directly affect the RIPE
NCC operations as a Regional Internet Registry (RIR). Therefore, the
RIPE NCC position on the Terms of Reference is as follows:

* The needs of developing economies in IP address policy are
important. Network operators in these economies have fair and equal
access to IPv6 resources from the Regional Internet Registries (RIRs),
and to the Policy Development Processes in their RIR and globally.
Each of the RIRs has been allocated an equal block of IPv6 to
distribute to networks in their region. (eg. AfriNIC has been
allocated the same sized block of IPv6 as the RIPE NCC).

* IPv6 allocations made by RIRs to date amount to the equivalent of
500 times the size of the entire IPv4 address pool, allocated to
networks in over 150 economies.

* If a significant sector in the Internet community feels that the
"reservation of a large IPv6 block" for "the future needs of
developing countries" is warranted, the open, bottom-up Policy
Development Processes (PDPs) of the RIRs provide an appropriate forum
in which to argue that case and develop such a policy.

* The RIRs, as the recognised stewards of Internet Number Resources,
are working, individually, jointly, and with invited experts, to
engage the ITU membership. We have closely followed discussions in the
ITU to date. The RIPE NCC does not believe that there are any problems
that would be solved by the shift to a country-based allocation system
or the installation of the ITU as an Internet Registry.

The purpose of this email is to ensure that all RIPE NCC members are
informed of the RIPE NCC's participation in this ITU IPv6 Group, and
our position. If you have any comments or questions regarding this
information, please send an email to <ncc at ripe.net>.

Kind regards,

Axel Pawlik
Managing Director
RIPE NCC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100226/5322c2a5/attachment.htm>

From michael.dillon at bt.com  Fri Feb 26 12:09:31 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Fri, 26 Feb 2010 17:09:31 -0000
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>


> Although I am indeed thankful to the ITU for keeping us poor 
> and under privileged developing countries well stocked in 
> IPv6 numbers, I would much prefer that ARIN consider 
> structural modifications to allow for sub regional registries 
> under present structure

You might want to look into APNIC's NIR model which is exactly
that, and then make a formal proposal. I wouldn't expect you
to simply copy APNIC, but in making a proposal, I think you
should understand the alternatives. Also, I believe RIPE has
done something similar for the Russia and the ex-USSR countries,
partly because of the economic gap and partly because of legal
restrictions on signing contracts with foreign organizations.

This is a good idea, and as a side effect, if you get all
the Caribbean networking people talking around the same
table on a regular basis, you will be able to react faster
and in a more coordinated fashion when disaster strikes.
Like the next hurricane, and the one after that...

I don't see any connection between what you are suggesting
and the ITU's activities, and it is probably best if ARIN
considers your sub-registry proposal on its own merits.

--Michael Dillon



From jcurran at arin.net  Fri Feb 26 13:26:53 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 26 Feb 2010 13:26:53 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
Message-ID: <D939AA47-FB2E-422A-ABA9-55557BF8B204@arin.net>

Rudolph -

  Michael Dillon's response is right on target:  ARIN is more than willing to
consider proposals for structuring the management of registry services that
make sense for any geography, and this can follow what happened in the
APNIC and RIPE regions or can be a fully new region such as the creation
of LACNIC & AfriNIC from ARIN some years ago.  ARIN has done significant
outreach in the Caribbean region with this message but the most important
point is that the determination be led by the actual users of numbering
resources (e.g. ISPs, businesses, non-profits, educational organizations) in
the region and not imposed by arbitrary third-party organization from above.

/John

John Curran
President and CEO
ARIN

Begin forwarded message:
From: michael.dillon at bt.com<mailto:michael.dillon at bt.com>
Date: February 26, 2010 11:09:31 AM CST
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] RIPE/ITU


Although I am indeed thankful to the ITU for keeping us poor
and under privileged developing countries well stocked in
IPv6 numbers, I would much prefer that ARIN consider
structural modifications to allow for sub regional registries
under present structure

You might want to look into APNIC's NIR model which is exactly
that, and then make a formal proposal. I wouldn't expect you
to simply copy APNIC, but in making a proposal, I think you
should understand the alternatives. Also, I believe RIPE has
done something similar for the Russia and the ex-USSR countries,
partly because of the economic gap and partly because of legal
restrictions on signing contracts with foreign organizations.

This is a good idea, and as a side effect, if you get all
the Caribbean networking people talking around the same
table on a regular basis, you will be able to react faster
and in a more coordinated fashion when disaster strikes.
Like the next hurricane, and the one after that...

I don't see any connection between what you are suggesting
and the ITU's activities, and it is probably best if ARIN
considers your sub-registry proposal on its own merits.

--Michael Dillon

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

From dogwallah at gmail.com  Fri Feb 26 13:22:20 2010
From: dogwallah at gmail.com (McTim)
Date: Fri, 26 Feb 2010 21:22:20 +0300
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
Message-ID: <f65fb55e1002261022q557bbb07l93ac3bff5d223316@mail.gmail.com>

hello Rudolph,

I think this is largely a solution in search of a problem.

You can read my full thoughts on this at
http://www.circleid.com/posts/country_internet_registries_one_african_perspective/

-- 
Cheers,

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


On Fri, Feb 26, 2010 at 7:55 PM, Rudolph Daniel <rudi.daniel at gmail.com>wrote:

> Although I am indeed thankful to the ITU for keeping us poor and
> under privileged developing countries well stocked in IPv6 numbers, I would
> much prefer that ARIN consider structural modifications to allow for sub
> regional registries under present structure: As in the case of a region like
> the Caribbean which has such completely different demographics that the bulk
> of the ARIN Region and therefore allow the ITU to interact not only in IPv6
> but also in IPv4 (not mentioned in the attachment).
>
> The recent HipCar project currently being undertaken in the Caribbean
> region is another very important initiative by the ITU in garnering the
> support of business and Governments in a region where she has always had a
> good degree of control and support.
>
> I would be interested in the views of the community because this may be a
> complex issue and I really do not know the views of the larger community out
> there.
>




>
>
> --Forwarded Message Attachment--
> From: ncc at ripe.net
> To: ncc-announce at ripe.net
> Date: Thu, 25 Feb 2010 17:20:18 +0100
> Subject: [Admin] [members-discuss] [ncc-announce] RIPE NCC Position On The
>      ITU IPv6 Group
>
> Dear Colleagues,
>
> As you may be aware, the International Telecommunication Union's (ITU)
> Telecommunication Standardization Bureau (TSB) has convened an ITU
> IPv6 Group, the first meeting of which will be held on 15-16 March
> 2010 in Geneva, Switzerland. Information on this group is available at:
> http://www.itu.int/ITU-T/othergroups/ipv6/
>
> Among the group's Terms of Reference are the following:
>
>   * To draft a global policy proposal for the reservation of a large
> IPv6 block, taking into consideration the future needs of developing
> countries (as outlined in paragraph 23 of ITU document C09/29).
>
>   * To further study possible methodologies and related
> implementation mechanisms to ensure 'equitable access' to IPv6
> resource by countries.
>
>   * To further study the possibility for ITU to become another
> Internet Registry, and propose policies and procedures for ITU to
> manage a reserved IPv6 block.
>
>   * To further study the feasibility and advisability of implementing
> the CIR [Country Internet Registry] model for those countries who
> would request national allocations.
>
> The ITU IPv6 Group is open to ITU Member States and Sector Members of
> ITU-T and ITU-D. RIRs that are not members have also been extended an
> invitation to participate.
>
> IPv6 address policy is clearly of critical importance to the RIPE NCC
> membership, and the unsympathetic implementation of any of the Terms
> of Reference stated above would have serious impact on the global IP
> address distribution environment.
>
> Members of RIPE NCC staff will be participating in this meeting of the
> ITU IPv6 Group to represent the interests of our members and community.
>
> The position of the RIPE NCC is based on support for smooth and
> reliable working of the Internet globally, and for the bottom-up, open
> policy development process that allows for all stakeholders, including
> business, government and the technical community, to participate.
>
> Some of the issues addressed in the Terms of Reference listed above
> are a cause for concern because they could directly affect the RIPE
> NCC operations as a Regional Internet Registry (RIR). Therefore, the
> RIPE NCC position on the Terms of Reference is as follows:
>
> * The needs of developing economies in IP address policy are
> important. Network operators in these economies have fair and equal
> access to IPv6 resources from the Regional Internet Registries (RIRs),
> and to the Policy Development Processes in their RIR and globally.
> Each of the RIRs has been allocated an equal block of IPv6 to
> distribute to networks in their region. (eg. AfriNIC has been
> allocated the same sized block of IPv6 as the RIPE NCC).
>
> * IPv6 allocations made by RIRs to date amount to the equivalent of
> 500 times the size of the entire IPv4 address pool, allocated to
> networks in over 150 economies.
>
> * If a significant sector in the Internet community feels that the
> "reservation of a large IPv6 block" for "the future needs of
> developing countries" is warranted, the open, bottom-up Policy
> Development Processes (PDPs) of the RIRs provide an appropriate forum
> in which to argue that case and develop such a policy.
>
> * The RIRs, as the recognised stewards of Internet Number Resources,
> are working, individually, jointly, and with invited experts, to
> engage the ITU membership. We have closely followed discussions in the
> ITU to date. The RIPE NCC does not believe that there are any problems
> that would be solved by the shift to a country-based allocation system
> or the installation of the ITU as an Internet Registry.
>
> The purpose of this email is to ensure that all RIPE NCC members are
> informed of the RIPE NCC's participation in this ITU IPv6 Group, and
> our position. If you have any comments or questions regarding this
> information, please send an email to <ncc at ripe.net>.
>
> Kind regards,
>
> Axel Pawlik
> Managing Director
> RIPE NCC
>
>
>
> _______________________________________________
> 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/20100226/8fd62c1e/attachment.htm>

From rudi.daniel at gmail.com  Fri Feb 26 13:34:12 2010
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Fri, 26 Feb 2010 14:34:12 -0400
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <f65fb55e1002261022q557bbb07l93ac3bff5d223316@mail.gmail.com>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<f65fb55e1002261022q557bbb07l93ac3bff5d223316@mail.gmail.com>
Message-ID: <8aeeaff61002261034j214d587ene12c30f8ef4d559a@mail.gmail.com>

Hi McTim

Indeed that is what I would hope to be the case, and it is still the case
that my small region, is still dominated by the influence of that body which
(may) possibly have an effect on regional infrastructure policy
initiatives.
RD

On Fri, Feb 26, 2010 at 2:22 PM, McTim <dogwallah at gmail.com> wrote:

> hello Rudolph,
>
> I think this is largely a solution in search of a problem.
>
> You can read my full thoughts on this at
> http://www.circleid.com/posts/country_internet_registries_one_african_perspective/
>
> --
> Cheers,
>
> McTim
> "A name indicates what we seek. An address indicates where it is. A route
> indicates how we get there."  Jon Postel
>
>
> On Fri, Feb 26, 2010 at 7:55 PM, Rudolph Daniel <rudi.daniel at gmail.com>wrote:
>
>> Although I am indeed thankful to the ITU for keeping us poor and
>> under privileged developing countries well stocked in IPv6 numbers, I would
>> much prefer that ARIN consider structural modifications to allow for sub
>> regional registries under present structure: As in the case of a region like
>> the Caribbean which has such completely different demographics that the bulk
>> of the ARIN Region and therefore allow the ITU to interact not only in IPv6
>> but also in IPv4 (not mentioned in the attachment).
>>
>> The recent HipCar project currently being undertaken in the Caribbean
>> region is another very important initiative by the ITU in garnering the
>> support of business and Governments in a region where she has always had a
>> good degree of control and support.
>>
>> I would be interested in the views of the community because this may be a
>> complex issue and I really do not know the views of the larger community out
>> there.
>>
>
>
>
>
>>
>>
>> --Forwarded Message Attachment--
>> From: ncc at ripe.net
>> To: ncc-announce at ripe.net
>> Date: Thu, 25 Feb 2010 17:20:18 +0100
>> Subject: [Admin] [members-discuss] [ncc-announce] RIPE NCC Position On The
>>      ITU IPv6 Group
>>
>> Dear Colleagues,
>>
>> As you may be aware, the International Telecommunication Union's (ITU)
>> Telecommunication Standardization Bureau (TSB) has convened an ITU
>> IPv6 Group, the first meeting of which will be held on 15-16 March
>> 2010 in Geneva, Switzerland. Information on this group is available at:
>> http://www.itu.int/ITU-T/othergroups/ipv6/
>>
>> Among the group's Terms of Reference are the following:
>>
>>   * To draft a global policy proposal for the reservation of a large
>> IPv6 block, taking into consideration the future needs of developing
>> countries (as outlined in paragraph 23 of ITU document C09/29).
>>
>>   * To further study possible methodologies and related
>> implementation mechanisms to ensure 'equitable access' to IPv6
>> resource by countries.
>>
>>   * To further study the possibility for ITU to become another
>> Internet Registry, and propose policies and procedures for ITU to
>> manage a reserved IPv6 block.
>>
>>   * To further study the feasibility and advisability of implementing
>> the CIR [Country Internet Registry] model for those countries who
>> would request national allocations.
>>
>> The ITU IPv6 Group is open to ITU Member States and Sector Members of
>> ITU-T and ITU-D. RIRs that are not members have also been extended an
>> invitation to participate.
>>
>> IPv6 address policy is clearly of critical importance to the RIPE NCC
>> membership, and the unsympathetic implementation of any of the Terms
>> of Reference stated above would have serious impact on the global IP
>> address distribution environment.
>>
>> Members of RIPE NCC staff will be participating in this meeting of the
>> ITU IPv6 Group to represent the interests of our members and community.
>>
>> The position of the RIPE NCC is based on support for smooth and
>> reliable working of the Internet globally, and for the bottom-up, open
>> policy development process that allows for all stakeholders, including
>> business, government and the technical community, to participate.
>>
>> Some of the issues addressed in the Terms of Reference listed above
>> are a cause for concern because they could directly affect the RIPE
>> NCC operations as a Regional Internet Registry (RIR). Therefore, the
>> RIPE NCC position on the Terms of Reference is as follows:
>>
>> * The needs of developing economies in IP address policy are
>> important. Network operators in these economies have fair and equal
>> access to IPv6 resources from the Regional Internet Registries (RIRs),
>> and to the Policy Development Processes in their RIR and globally.
>> Each of the RIRs has been allocated an equal block of IPv6 to
>> distribute to networks in their region. (eg. AfriNIC has been
>> allocated the same sized block of IPv6 as the RIPE NCC).
>>
>> * IPv6 allocations made by RIRs to date amount to the equivalent of
>> 500 times the size of the entire IPv4 address pool, allocated to
>> networks in over 150 economies.
>>
>> * If a significant sector in the Internet community feels that the
>> "reservation of a large IPv6 block" for "the future needs of
>> developing countries" is warranted, the open, bottom-up Policy
>> Development Processes (PDPs) of the RIRs provide an appropriate forum
>> in which to argue that case and develop such a policy.
>>
>> * The RIRs, as the recognised stewards of Internet Number Resources,
>> are working, individually, jointly, and with invited experts, to
>> engage the ITU membership. We have closely followed discussions in the
>> ITU to date. The RIPE NCC does not believe that there are any problems
>> that would be solved by the shift to a country-based allocation system
>> or the installation of the ITU as an Internet Registry.
>>
>> The purpose of this email is to ensure that all RIPE NCC members are
>> informed of the RIPE NCC's participation in this ITU IPv6 Group, and
>> our position. If you have any comments or questions regarding this
>> information, please send an email to <ncc at ripe.net>.
>>
>> Kind regards,
>>
>> Axel Pawlik
>> Managing Director
>> RIPE NCC
>>
>>
>>
>> _______________________________________________
>> 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.
>>
>
>
>
>
>


-- 
Rudi Daniel
e Business Consultant
http://www.svgpso.org
http://oecstimes.wordpress.com
?The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts.? - Bertrand
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100226/46d1edea/attachment.htm>

From mueller at syr.edu  Fri Feb 26 17:15:47 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Fri, 26 Feb 2010 17:15:47 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>


> -----Original Message-----
> You might want to look into APNIC's NIR model which is exactly
> that, and then make a formal proposal. 

My understanding is that the people at APNIC are not exactly delighted with the NIR model; it was a concession to some of the same political pressures that are now leading to the call for CIRs. Indeed, it is a bit inconsistent for this community to argue against the Ramadass proposal for CIRs and then propose NIRs instead. I prefer McTim's approach of supporting the principle that addresses should be allocated to users (ASs) and not to governments or other entities who want to interpose themselves as intermediaries. 

If it comes down to a choice between NIRs and CIRs, then the only relevant difference is whether the RIRs retain a monopoly on higher-level allocations or not. I think that's a weak position to be in. Here we need to frankly realize that the issues are fundamentally political. 

Note that the ITU proposal for CIRs does not propose to make them exclusive, but rather proposes that an ITU-mediated CIR be an additional option. If one supports competing ISPs, why not alternative address registries? One cannot argue against this option on the grounds that we don't have enough ipv6 addresses to make it viable; we do. One cannot argue against it on the grounds that it messes up the efficiency of routing, because new, RIR-sanctioned NIRs or new RIRs carved out of existing ones would have basically the same effects on routing. 

The only way to viably challenge this proposal is to face squarely the political issues and question whether states who gain control of ip addresses will truly allow competitive alternatives, or instead try to leverage their control of the resource to gain more control over internet supply and usage, or to favor incumbent, national champion network operators.

One can also try to question the need for this proposal (solution in search of a problem). There is merit in this argument, but the issue is not quite as simple as it may seem. Developing countries aware of the landrush for ipv4 addresses that took place in the early stages of the internet's development have a legitimate reason to worry about whether history will repeat itself. An inherent feature of needs-based allocations is that developed economies will be able to show "need" well before undeveloped ones. The ITU is basically arguing for a system of reservations that guarantees each nation-state a substantial chunk of address resources just in case that happens. Naturally enough, given its basis in an intergovernmental organization, the ITU considers nation-states the appropriate stewards for these reservations. 

If setting aside address block reservations were the ONLY price we had to pay to assuage these political concerns, I would say, "do it." But other prices could be extracted - as I explained above, linking ip address allocations to the nation state system so closely could have serious political and regulatory repercussions. That price is not worth paying. 

--MM

From stephen at sprunk.org  Fri Feb 26 17:44:56 2010
From: stephen at sprunk.org (Stephen Sprunk)
Date: Fri, 26 Feb 2010 16:44:56 -0600
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4B884EE8.5030208@sprunk.org>

On 26 Feb 2010 16:15, Milton L Mueller wrote:
> Note that the ITU proposal for CIRs does not propose to make them
> exclusive, but rather proposes that an ITU-mediated CIR be an
> additional option. If one supports competing ISPs, why not alternative
> address registries? One cannot argue against this option on the
> grounds that we don't have enough ipv6 addresses to make it viable; we
> do. One cannot argue against it on the grounds that it messes up the
> efficiency of routing, because new, RIR-sanctioned NIRs or new RIRs
> carved out of existing ones would have basically the same effects on
> routing.

The difference between NIRs and CIRs is that NIRs are still required to
follow the policies developed by their parent RIR, whereas CIRs could in
theory do anything they want, e.g. giving PI addresses to any entity
that pays some nominal fee.  The resulting explosion of prefixes in the
DFZ from such a policy could cause a global meltdown.  More likely, it
would cause ISPs to filter the CIR blocks to protect themselves, which
would almost certainly result in government regulations that ISPs must
accept routes from the relevant CIR, which could in turn cause
country-specific meltdowns.  Worse, some governments might use the
availability of CIR blocks to ban the use of RIR/NIR blocks.  The end
result: the current global reachability (except to Verizon) that
everyone with RIR/NIR blocks enjoys today would not be available in the
future--something that many governments (and thus the ITU) want to
happen anyway but is undoubtedly bad for consumers, bad for the entire
industry, and bad for freedom (as in beer) globally.

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/pkcs7-signature
Size: 3646 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100226/9f060219/attachment.p7s>

From dogwallah at gmail.com  Fri Feb 26 17:50:37 2010
From: dogwallah at gmail.com (McTim)
Date: Sat, 27 Feb 2010 01:50:37 +0300
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> 
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <f65fb55e1002261450k7def36eena741a851b68ffdf1@mail.gmail.com>

Hi Milton,

On Sat, Feb 27, 2010 at 1:15 AM, Milton L Mueller <mueller at syr.edu> wrote:
>
> > -----Original Message-----
> > You might want to look into APNIC's NIR model which is exactly
> > that, and then make a formal proposal.
>
> My understanding is that the people at APNIC are not exactly delighted with the NIR model;

My understanding is that the people who make up the APNIC community
are not exactly delighted with the NIR model, and the model is being
phased out as not viable.

>
> it was a concession to some of the same political pressures that are now leading to the call for CIRs. Indeed, it is a bit inconsistent for this community to argue against the Ramadass proposal for CIRs and then propose NIRs instead.

agreed, but the community hasn't endorsed this idea AFAICS.

>
> I prefer McTim's approach of supporting the principle that addresses should be allocated to users (ASs) and not to governments or other entities who want to interpose themselves as intermediaries.
>
> If it comes down to a choice between NIRs and CIRs, then the only relevant difference is whether the RIRs retain a monopoly on higher-level allocations or not. I think that's a weak position to be in. Here we need to frankly realize that the issues are fundamentally political.
>
> Note that the ITU proposal for CIRs does not propose to make them exclusive, but rather proposes that an ITU-mediated CIR be an additional option. If one supports competing ISPs, why not alternative address registries?

RFC2050

"Service areas will be of continental dimensions."

In addition there are various other reasons outlined in the Circleid
post I sent earlier.

>
> One cannot argue against this option on the grounds that we don't have enough ipv6 addresses to make it viable; we do. One cannot argue against it on the grounds that it messes up the efficiency of routing,

You can actually.

>because new, RIR-sanctioned NIRs or new RIRs carved out of existing ones would have basically the same effects on routing.

perhaps, or perhaps not, depending on the policies they adopt.

>
> The only way to viably challenge this proposal is to face squarely the political issues and question whether states who gain control of ip addresses will truly allow competitive alternatives, or instead try to leverage their control of the resource to gain more control over internet supply and usage, or to favor incumbent, national champion network operators.


or to boost government revenue, or use IP address revenue to feather
individual nests, or not develop policies in an open, transparent
manner, etc, etc.


>
> One can also try to question the need for this proposal (solution in search of a problem). There is merit in this argument, but the issue is not quite as simple as it may seem. Developing countries aware of the landrush for ipv4 addresses that took place in the early stages of the internet's development have a legitimate reason to worry about whether history will repeat itself. An inherent feature of needs-based allocations is that developed economies will be able to show "need" well before undeveloped ones. The ITU is basically arguing for a system of reservations that guarantees each nation-state a substantial chunk of address resources just in case that happens. Naturally enough, given its basis in an intergovernmental organization, the ITU considers nation-states the appropriate stewards for these reservations.


Speaking of "reservations" I am under the impression that it is the
IETF that instructs the IANA to reserve IP blocks.  If this is
correct, then the ITU and the RIR policy lists are not the correct
fora to discuss this proposal.  The ITU should write a draft RFC and
submit it to the IETF.  Perhaps I am mistaken.

>
> If setting aside address block reservations were the ONLY price we had to pay to assuage these political concerns, I would say, "do it." But other prices could be extracted - as I explained above, linking ip address allocations to the nation state system so closely could have serious political and regulatory repercussions. That price is not worth paying.


I hope you plan to say this to the ITU in March!


--
Cheers,

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


From jcurran at arin.net  Fri Feb 26 17:52:34 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 26 Feb 2010 17:52:34 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>

On Feb 26, 2010, at 4:15 PM, Milton L Mueller wrote:
> ...
> Note that the ITU proposal for CIRs does not propose to make them exclusive, but rather proposes that an ITU-mediated CIR be an additional option. If one supports competing ISPs, why not alternative address registries? One cannot argue against this option on the grounds that we don't have enough ipv6 addresses to make it viable; we do. One cannot argue against it on the grounds that it messes up the efficiency of routing, because new, RIR-sanctioned NIRs or new RIRs carved out of existing ones would have basically the same effects on routing. 

Milton - Is there an "ITU proposal" for CIRs?  I'm not certain that I've 
actually seen such a proposal, and while I'm aware of both your and the
NAV6 ITU-funded studies, neither appears to contain an actual ITU CIR 
proposal.  Could you point us to such a document, so that the community 
can review and actually assess the operational impacts of it?

> One can also try to question the need for this proposal (solution in search of a problem). There is merit in this argument, but the issue is not quite as simple as it may seem. Developing countries aware of the landrush for ipv4 addresses that took place in the early stages of the internet's development have a legitimate reason to worry about whether history will repeat itself. An inherent feature of needs-based allocations is that developed economies will be able to show "need" well before undeveloped ones. The ITU is basically arguing for a system of reservations that guarantees each nation-state a substantial chunk of address resources just in case that happens. Naturally enough, given its basis in an intergovernmental organization, the ITU considers nation-states the appropriate stewards for these reservations. 

Is it asserted that the current policies for IPv6 allocation will create
a similar situation as occurred for IPv4?  I believe that it was your own
paper ("Economic Factors in the Allocation of IPv6 Addresses") which quotes 
Thomas Narten indicating that we're on track to use 1% of the IPv6 space 
in the next 50 years, correct?

> If setting aside address block reservations were the ONLY price we had to pay to assuage these political concerns, I would say, "do it." But other prices could be extracted - as I explained above, linking ip address allocations to the nation state system so closely could have serious political and regulatory repercussions. That price is not worth paying. 

I'm not certain that your paper was as clear on these negative aspects of 
the approach as you state above ("That price is not worth paying"). In fact,
fact, your paper is a document exhibit to the ITU IPv6 workshop meeting 
<http://www.itu.int/md/T09-IPV6-100315/sum/en> and it states that the ITU
has a constructive role to play, assuming "that the ITU is allocated a /12
in the IPv6 address space to act as an alternative IP address registry" Is
there a more up to date version of the paper that we should be referencing?

/John

John Curran
President and CEO
ARIN



From fm-lists at st-kilda.org  Fri Feb 26 18:02:55 2010
From: fm-lists at st-kilda.org (Fearghas McKay)
Date: Fri, 26 Feb 2010 23:02:55 +0000
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
Message-ID: <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>


On 26 Feb 2010, at 22:52, John Curran wrote:

> Milton - Is there an "ITU proposal" for CIRs?  I'm not certain that  
> I've
> actually seen such a proposal, and while I'm aware of both your and  
> the
> NAV6 ITU-funded studies, neither appears to contain an actual ITU CIR
> proposal.  Could you point us to such a document, so that the  
> community
> can review and actually assess the operational impacts of it?


from the first post in the thread.

http://www.itu.int/ITU-T/othergroups/ipv6/

suggests:
-=-=-
Terms of Reference
	? To draft a global policy proposal for the reservation of a large  
IPv6 block, taking into consideration the future needs of developing  
countries, as outlined in paragraph 23 of C09/29.
	? To further study possible methodologies and related implementation  
mechanisms to ensure ?equitable access? to IPv6 resource by countries.
	? To further study the possibility for ITU to become another Internet  
Registry, and propose policies and procedures for ITU to manage a  
reserved IPv6 block.
	? To further study the feasibility and advisability of implementing  
the CIR model for those countries who would request national  
allocations.
	? To assist in the implementation of the project called for by  
Resolution 64, taking into account the needs at regional and national  
level in terms of capacity building and allocation policies.
	? To report to ITU Council 2010.
-=-=-

	f

From jcurran at arin.net  Fri Feb 26 18:53:38 2010
From: jcurran at arin.net (John Curran)
Date: Fri, 26 Feb 2010 18:53:38 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>
Message-ID: <E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>

On Feb 26, 2010, at 5:02 PM, Fearghas McKay wrote:
> ...
> http://www.itu.int/ITU-T/othergroups/ipv6/
> 
> suggests:
> -=-=-
> Terms of Reference
>   ? To draft a global policy proposal for the reservation of a large IPv6 block, taking into consideration the future needs of developing countries, as outlined in paragraph 23 of C09/29.
>   ? To further study possible methodologies and related implementation mechanisms to ensure ?equitable access? to IPv6 resource by countries.
>   ? To further study the possibility for ITU to become another Internet Registry, and propose policies and procedures for ITU to manage a reserved IPv6 block.
>   ? To further study the feasibility and advisability of implementing the CIR model for those countries who would request national allocations.
>   ? To assist in the implementation of the project called for by Resolution 64, taking into account the needs at regional and national level in terms of capacity building and allocation policies.
>   ? To report to ITU Council 2010.

Milton refers to "the ITU proposal for CIRs", whereas the terms of 
reference to the ITU IPV6 working group meeting (of which I am an 
invited expert) call for *drafting* such a proposal.  Since Milton 
references "the ITU proposal" as if it was already specified, and 
his paper is indeed a listed working group meeting document, perhaps 
he's aware of an actual ITU CIR proposal which will be forthcoming 
to the rest of us soon?

Of course, the differences in approach between the ITU and the RIR
community should be very apparent just from this ITU IPv6 meeting  
announcement.  The idea that a closed (ITU members + invited guests
who are to "represent" the Regional Internet Registries) working 
group could "draft a global policy proposal" which would then be 
seen as sufficiently complete to allow assessment of the various
implementation details almost presumes that one has already given 
up on any form of community-based policy; note specifically that 
ARIN's Policy Development Process states: "Policy proposals may 
be submitted by anyone in the global Internet community except 
for members of the ARIN Board of Trustees or the ARIN staff" 
exactly to prevent assumptions such as this from occurring...

While invited and going to Geneva for the working group meeting, 
my most important contribution regarding that initial item in 
the terms of reference is to invite the participants of the ITU 
IPv6 working group to ARIN's Public Policy Meetings and this 
mailing list so that any actual CIR proposal is made before this 
community, discussed publicly on its merits, and otherwise follows 
ARIN's Policy Development Process as required.

/John

John Curran
President and CEO
ARIN





From Skeeve at eintellego.net  Fri Feb 26 20:37:27 2010
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Sat, 27 Feb 2010 12:37:27 +1100
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
Message-ID: <292AF25E62B8894C921B893B53A19D973974B77CBC@BUSINESSEX.business.ad>

Re the Caribbean, is it being suggested that LACNIC is not doing its job for that region?

...Skeeve

--
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
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?


> -----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: Saturday, 27 February 2010 4:10 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] RIPE/ITU
> 
> 
> > Although I am indeed thankful to the ITU for keeping us poor
> > and under privileged developing countries well stocked in
> > IPv6 numbers, I would much prefer that ARIN consider
> > structural modifications to allow for sub regional registries
> > under present structure
> 
> You might want to look into APNIC's NIR model which is exactly
> that, and then make a formal proposal. I wouldn't expect you
> to simply copy APNIC, but in making a proposal, I think you
> should understand the alternatives. Also, I believe RIPE has
> done something similar for the Russia and the ex-USSR countries,
> partly because of the economic gap and partly because of legal
> restrictions on signing contracts with foreign organizations.
> 
> This is a good idea, and as a side effect, if you get all
> the Caribbean networking people talking around the same
> table on a regular basis, you will be able to react faster
> and in a more coordinated fashion when disaster strikes.
> Like the next hurricane, and the one after that...
> 
> I don't see any connection between what you are suggesting
> and the ITU's activities, and it is probably best if ARIN
> considers your sub-registry proposal on its own merits.
> 
> --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 owen at delong.com  Fri Feb 26 20:38:30 2010
From: owen at delong.com (Owen DeLong)
Date: Fri, 26 Feb 2010 17:38:30 -0800
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <44445021-9752-4B71-B7EA-DB462D85C844@delong.com>


On Feb 26, 2010, at 2:15 PM, Milton L Mueller wrote:

> 
>> -----Original Message-----
>> You might want to look into APNIC's NIR model which is exactly
>> that, and then make a formal proposal. 
> 
> My understanding is that the people at APNIC are not exactly delighted with the NIR model; it was a concession to some of the same political pressures that are now leading to the call for CIRs. Indeed, it is a bit inconsistent for this community to argue against the Ramadass proposal for CIRs and then propose NIRs instead. I prefer McTim's approach of supporting the principle that addresses should be allocated to users (ASs) and not to governments or other entities who want to interpose themselves as intermediaries. 
> 
> If it comes down to a choice between NIRs and CIRs, then the only relevant difference is whether the RIRs retain a monopoly on higher-level allocations or not. I think that's a weak position to be in. Here we need to frankly realize that the issues are fundamentally political. 
> 
> Note that the ITU proposal for CIRs does not propose to make them exclusive, but rather proposes that an ITU-mediated CIR be an additional option. If one supports competing ISPs, why not alternative address registries? One cannot argue against this option on the grounds that we don't have enough ipv6 addresses to make it viable; we do. One cannot argue against it on the grounds that it messes up the efficiency of routing, because new, RIR-sanctioned NIRs or new RIRs carved out of existing ones would have basically the same effects on routing. 
> 
Hey, I know... How about competing national laws in the same country... Each citizen gets to choose which congress and which senate and which... 

Oh, wait, that's pretty dumb and I'm willing to bet most governments are unwilling to give up their monopolies on the creation of national laws.

The difference between ITU CIRs vs. APNIC NIRs is that APNIC NIRs still participate in the APNIC policy process and are still subject to APNIC policies.

I have no problem with the ITU having CIRs, so long as those CIRs are subjugate to and agree to abide by the RIR policies set by the community
process in their respective regions.  Absent that, CIRs vs. LIRs seem like a really good way to subvert the public policy process currently in place
and replace it with a land-rush amongst the various countries to try and grab as much IPv6 space as they can.

Under the current RIR model, I have trouble imagining a scenario where any developing nation has difficulty getting the address space they need.
Under likely ITU models, this may or may not be the same.

Under the current RIR model, I have trouble imagining a scenario where any developed nation has difficulty getting the address space they need.
Under likely ITU models, I can foresee significant issues in this area.

Owen



From Skeeve at eintellego.net  Fri Feb 26 20:43:05 2010
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Sat, 27 Feb 2010 12:43:05 +1100
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <f65fb55e1002261450k7def36eena741a851b68ffdf1@mail.gmail.com>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<f65fb55e1002261450k7def36eena741a851b68ffdf1@mail.gmail.com>
Message-ID: <292AF25E62B8894C921B893B53A19D973974B77CBD@BUSINESSEX.business.ad>

Do you have any reference to where the APNIC community is suggesting phasing out the NIR model?

...Skeeve

--
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
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of McTim
> Sent: Saturday, 27 February 2010 9:51 AM
> To: Milton L Mueller
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] RIPE/ITU
> 
> Hi Milton,
> 
> On Sat, Feb 27, 2010 at 1:15 AM, Milton L Mueller <mueller at syr.edu>
> wrote:
> >
> > > -----Original Message-----
> > > You might want to look into APNIC's NIR model which is exactly
> > > that, and then make a formal proposal.
> >
> > My understanding is that the people at APNIC are not exactly
> delighted with the NIR model;
> 
> My understanding is that the people who make up the APNIC community
> are not exactly delighted with the NIR model, and the model is being
> phased out as not viable.
> 
> >
> > it was a concession to some of the same political pressures that are
> now leading to the call for CIRs. Indeed, it is a bit inconsistent for
> this community to argue against the Ramadass proposal for CIRs and then
> propose NIRs instead.
> 
> agreed, but the community hasn't endorsed this idea AFAICS.
> 
> >
> > I prefer McTim's approach of supporting the principle that addresses
> should be allocated to users (ASs) and not to governments or other
> entities who want to interpose themselves as intermediaries.
> >
> > If it comes down to a choice between NIRs and CIRs, then the only
> relevant difference is whether the RIRs retain a monopoly on higher-
> level allocations or not. I think that's a weak position to be in. Here
> we need to frankly realize that the issues are fundamentally political.
> >
> > Note that the ITU proposal for CIRs does not propose to make them
> exclusive, but rather proposes that an ITU-mediated CIR be an
> additional option. If one supports competing ISPs, why not alternative
> address registries?
> 
> RFC2050
> 
> "Service areas will be of continental dimensions."
> 
> In addition there are various other reasons outlined in the Circleid
> post I sent earlier.
> 
> >
> > One cannot argue against this option on the grounds that we don't
> have enough ipv6 addresses to make it viable; we do. One cannot argue
> against it on the grounds that it messes up the efficiency of routing,
> 
> You can actually.
> 
> >because new, RIR-sanctioned NIRs or new RIRs carved out of existing
> ones would have basically the same effects on routing.
> 
> perhaps, or perhaps not, depending on the policies they adopt.
> 
> >
> > The only way to viably challenge this proposal is to face squarely
> the political issues and question whether states who gain control of ip
> addresses will truly allow competitive alternatives, or instead try to
> leverage their control of the resource to gain more control over
> internet supply and usage, or to favor incumbent, national champion
> network operators.
> 
> 
> or to boost government revenue, or use IP address revenue to feather
> individual nests, or not develop policies in an open, transparent
> manner, etc, etc.
> 
> 
> >
> > One can also try to question the need for this proposal (solution in
> search of a problem). There is merit in this argument, but the issue is
> not quite as simple as it may seem. Developing countries aware of the
> landrush for ipv4 addresses that took place in the early stages of the
> internet's development have a legitimate reason to worry about whether
> history will repeat itself. An inherent feature of needs-based
> allocations is that developed economies will be able to show "need"
> well before undeveloped ones. The ITU is basically arguing for a system
> of reservations that guarantees each nation-state a substantial chunk
> of address resources just in case that happens. Naturally enough, given
> its basis in an intergovernmental organization, the ITU considers
> nation-states the appropriate stewards for these reservations.
> 
> 
> Speaking of "reservations" I am under the impression that it is the
> IETF that instructs the IANA to reserve IP blocks.  If this is
> correct, then the ITU and the RIR policy lists are not the correct
> fora to discuss this proposal.  The ITU should write a draft RFC and
> submit it to the IETF.  Perhaps I am mistaken.
> 
> >
> > If setting aside address block reservations were the ONLY price we
> had to pay to assuage these political concerns, I would say, "do it."
> But other prices could be extracted - as I explained above, linking ip
> address allocations to the nation state system so closely could have
> serious political and regulatory repercussions. That price is not worth
> paying.
> 
> 
> I hope you plan to say this to the ITU in March!
> 
> 
> --
> Cheers,
> 
> McTim
> "A name indicates what we seek. An address indicates where it is. A
> route indicates how we get there." ?Jon Postel
> _______________________________________________
> 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 Skeeve at eintellego.net  Fri Feb 26 20:45:43 2010
From: Skeeve at eintellego.net (Skeeve Stevens)
Date: Sat, 27 Feb 2010 12:45:43 +1100
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <58E881F4-EE3C-4556-98BE-05CA63C9F982@gmail.com>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<292AF25E62B8894C921B893B53A19D973974B77CBC@BUSINESSEX.business.ad>
	<58E881F4-EE3C-4556-98BE-05CA63C9F982@gmail.com>
Message-ID: <292AF25E62B8894C921B893B53A19D973974B77CBE@BUSINESSEX.business.ad>

That is a little confusing.... So counties in that region can choose which RIR they want to deal with?

--
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
www.linkedin.com/in/skeeve ; facebook.com/eintellego
--
NOC, NOC, who's there?


> -----Original Message-----
> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
> Sent: Saturday, 27 February 2010 12:41 PM
> To: Skeeve Stevens
> Cc: michael.dillon at bt.com; arin-ppml at arin.net
> Subject: Re: [arin-ppml] RIPE/ITU
> 
> Keep in mind that the English-speaking Caribbean is served by ARIN
> rather than LACNIC.
> 
> Scott
> 
> On Feb 26, 2010, at 5:37 PM, Skeeve Stevens <Skeeve at eintellego.net>
> wrote:
> 
> > Re the Caribbean, is it being suggested that LACNIC is not doing its
> > job for that region?
> >
> > ...Skeeve
> >
> > --
> > 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
> > www.linkedin.com/in/skeeve ; facebook.com/eintellego
> > --
> > NOC, NOC, who's there?
> >
> >
> >> -----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: Saturday, 27 February 2010 4:10 AM
> >> To: arin-ppml at arin.net
> >> Subject: Re: [arin-ppml] RIPE/ITU
> >>
> >>
> >>> Although I am indeed thankful to the ITU for keeping us poor
> >>> and under privileged developing countries well stocked in
> >>> IPv6 numbers, I would much prefer that ARIN consider
> >>> structural modifications to allow for sub regional registries
> >>> under present structure
> >>
> >> You might want to look into APNIC's NIR model which is exactly
> >> that, and then make a formal proposal. I wouldn't expect you
> >> to simply copy APNIC, but in making a proposal, I think you
> >> should understand the alternatives. Also, I believe RIPE has
> >> done something similar for the Russia and the ex-USSR countries,
> >> partly because of the economic gap and partly because of legal
> >> restrictions on signing contracts with foreign organizations.
> >>
> >> This is a good idea, and as a side effect, if you get all
> >> the Caribbean networking people talking around the same
> >> table on a regular basis, you will be able to react faster
> >> and in a more coordinated fashion when disaster strikes.
> >> Like the next hurricane, and the one after that...
> >>
> >> I don't see any connection between what you are suggesting
> >> and the ITU's activities, and it is probably best if ARIN
> >> considers your sub-registry proposal on its own merits.
> >>
> >> --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 scottleibrand at gmail.com  Fri Feb 26 20:51:17 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 26 Feb 2010 17:51:17 -0800
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <292AF25E62B8894C921B893B53A19D973974B77CBE@BUSINESSEX.business.ad>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<292AF25E62B8894C921B893B53A19D973974B77CBC@BUSINESSEX.business.ad>
	<58E881F4-EE3C-4556-98BE-05CA63C9F982@gmail.com>
	<292AF25E62B8894C921B893B53A19D973974B77CBE@BUSINESSEX.business.ad>
Message-ID: <89B5298D-3CA4-48D0-BA53-5C88C6B8EB6B@gmail.com>

The geographic scope of LACNIC was decided, mostly based on common  
languages etc., when LACNIC was first established. It hasn't changed  
since.  Those regions that didn't become part of LACNIC's region  
stayed with ARIN.

Scott

On Feb 26, 2010, at 5:45 PM, Skeeve Stevens <Skeeve at eintellego.net>  
wrote:

> That is a little confusing.... So counties in that region can choose  
> which RIR they want to deal with?
>
> --
> 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
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
>
>
>> -----Original Message-----
>> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
>> Sent: Saturday, 27 February 2010 12:41 PM
>> To: Skeeve Stevens
>> Cc: michael.dillon at bt.com; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] RIPE/ITU
>>
>> Keep in mind that the English-speaking Caribbean is served by ARIN
>> rather than LACNIC.
>>
>> Scott
>>
>> On Feb 26, 2010, at 5:37 PM, Skeeve Stevens <Skeeve at eintellego.net>
>> wrote:
>>
>>> Re the Caribbean, is it being suggested that LACNIC is not doing its
>>> job for that region?
>>>
>>> ...Skeeve
>>>
>>> --
>>> 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
>>> www.linkedin.com/in/skeeve ; facebook.com/eintellego
>>> --
>>> NOC, NOC, who's there?
>>>
>>>
>>>> -----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: Saturday, 27 February 2010 4:10 AM
>>>> To: arin-ppml at arin.net
>>>> Subject: Re: [arin-ppml] RIPE/ITU
>>>>
>>>>
>>>>> Although I am indeed thankful to the ITU for keeping us poor
>>>>> and under privileged developing countries well stocked in
>>>>> IPv6 numbers, I would much prefer that ARIN consider
>>>>> structural modifications to allow for sub regional registries
>>>>> under present structure
>>>>
>>>> You might want to look into APNIC's NIR model which is exactly
>>>> that, and then make a formal proposal. I wouldn't expect you
>>>> to simply copy APNIC, but in making a proposal, I think you
>>>> should understand the alternatives. Also, I believe RIPE has
>>>> done something similar for the Russia and the ex-USSR countries,
>>>> partly because of the economic gap and partly because of legal
>>>> restrictions on signing contracts with foreign organizations.
>>>>
>>>> This is a good idea, and as a side effect, if you get all
>>>> the Caribbean networking people talking around the same
>>>> table on a regular basis, you will be able to react faster
>>>> and in a more coordinated fashion when disaster strikes.
>>>> Like the next hurricane, and the one after that...
>>>>
>>>> I don't see any connection between what you are suggesting
>>>> and the ITU's activities, and it is probably best if ARIN
>>>> considers your sub-registry proposal on its own merits.
>>>>
>>>> --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 scottleibrand at gmail.com  Fri Feb 26 20:40:37 2010
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 26 Feb 2010 17:40:37 -0800
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <292AF25E62B8894C921B893B53A19D973974B77CBC@BUSINESSEX.business.ad>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<292AF25E62B8894C921B893B53A19D973974B77CBC@BUSINESSEX.business.ad>
Message-ID: <58E881F4-EE3C-4556-98BE-05CA63C9F982@gmail.com>

Keep in mind that the English-speaking Caribbean is served by ARIN  
rather than LACNIC.

Scott

On Feb 26, 2010, at 5:37 PM, Skeeve Stevens <Skeeve at eintellego.net>  
wrote:

> Re the Caribbean, is it being suggested that LACNIC is not doing its  
> job for that region?
>
> ...Skeeve
>
> --
> 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
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
>
>
>> -----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: Saturday, 27 February 2010 4:10 AM
>> To: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] RIPE/ITU
>>
>>
>>> Although I am indeed thankful to the ITU for keeping us poor
>>> and under privileged developing countries well stocked in
>>> IPv6 numbers, I would much prefer that ARIN consider
>>> structural modifications to allow for sub regional registries
>>> under present structure
>>
>> You might want to look into APNIC's NIR model which is exactly
>> that, and then make a formal proposal. I wouldn't expect you
>> to simply copy APNIC, but in making a proposal, I think you
>> should understand the alternatives. Also, I believe RIPE has
>> done something similar for the Russia and the ex-USSR countries,
>> partly because of the economic gap and partly because of legal
>> restrictions on signing contracts with foreign organizations.
>>
>> This is a good idea, and as a side effect, if you get all
>> the Caribbean networking people talking around the same
>> table on a regular basis, you will be able to react faster
>> and in a more coordinated fashion when disaster strikes.
>> Like the next hurricane, and the one after that...
>>
>> I don't see any connection between what you are suggesting
>> and the ITU's activities, and it is probably best if ARIN
>> considers your sub-registry proposal on its own merits.
>>
>> --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 mueller at syr.edu  Sat Feb 27 00:33:20 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sat, 27 Feb 2010 00:33:20 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>,
	<E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>

Stop fretting, John. I am not part of a vast ITU conspiracy. We have two docs on the table: one is the study proposal for CIRs prepared by prof. Ramadass, the other is the Terms of Reference McKay cites which clearly indicates that this is the direction some in Geneva would like to go. Ok, if you want to be picky we cannot say there is an "ITU proposal" yet, but its pretty clear what direction certain people there would like to move. I am suggesting that we engage in that discussion seriously. 

My study said that the ITU "could play a constructive role" by helping to work out a legal framework for TABLs.Aside from the fact that that does not seem to be the direction they want to move in, is it your implication that ITU has _no_ constructive role to play in this space?  

--MM

_______________________________________
From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of John Curran [jcurran at arin.net]
Milton refers to "the ITU proposal for CIRs", whereas the terms of
reference to the ITU IPV6 working group meeting (of which I am an
invited expert) call for *drafting* such a proposal.  Since Milton
references "the ITU proposal" as if it was already specified, and
his paper is indeed a listed working group meeting document, perhaps
he's aware of an actual ITU CIR proposal which will be forthcoming
to the rest of us soon?

Of course, the differences in approach between the ITU and the RIR
community should be very apparent just from this ITU IPv6 meeting
announcement.  The idea that a closed (ITU members + invited guests
who are to "represent" the Regional Internet Registries) working
group could "draft a global policy proposal" which would then be
seen as sufficiently complete to allow assessment of the various
implementation details almost presumes that one has already given
up on any form of community-based policy; note specifically that
ARIN's Policy Development Process states: "Policy proposals may
be submitted by anyone in the global Internet community except
for members of the ARIN Board of Trustees or the ARIN staff"
exactly to prevent assumptions such as this from occurring...

While invited and going to Geneva for the working group meeting,
my most important contribution regarding that initial item in
the terms of reference is to invite the participants of the ITU
IPv6 working group to ARIN's Public Policy Meetings and this
mailing list so that any actual CIR proposal is made before this
community, discussed publicly on its merits, and otherwise follows
ARIN's Policy Development Process as required.

/John

John Curran
President and CEO
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 dogwallah at gmail.com  Sat Feb 27 00:35:23 2010
From: dogwallah at gmail.com (McTim)
Date: Sat, 27 Feb 2010 08:35:23 +0300
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <292AF25E62B8894C921B893B53A19D973974B77CBD@BUSINESSEX.business.ad>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com> 
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu> 
	<f65fb55e1002261450k7def36eena741a851b68ffdf1@mail.gmail.com> 
	<292AF25E62B8894C921B893B53A19D973974B77CBD@BUSINESSEX.business.ad>
Message-ID: <f65fb55e1002262135r3c7b2618s98a8fd5da5153db1@mail.gmail.com>

Hi,

On Sat, Feb 27, 2010 at 4:43 AM, Skeeve Stevens <Skeeve at eintellego.net> wrote:
> Do you have any reference to where the APNIC community is suggesting phasing out the NIR model?

I don't this recollection is based on private conversations over the
last 5 years.

Now that I am thinking about it, perhaps "phasing out" is too strong a
term, I think that what they have decided is more like "no more new
NIRs".

-- 
Cheers,

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





>
> ...Skeeve
>
> --
> 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
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of McTim
>> Sent: Saturday, 27 February 2010 9:51 AM
>> To: Milton L Mueller
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] RIPE/ITU
>>
>> Hi Milton,
>>
>> On Sat, Feb 27, 2010 at 1:15 AM, Milton L Mueller <mueller at syr.edu>
>> wrote:
>> >
>> > > -----Original Message-----
>> > > You might want to look into APNIC's NIR model which is exactly
>> > > that, and then make a formal proposal.
>> >
>> > My understanding is that the people at APNIC are not exactly
>> delighted with the NIR model;
>>
>> My understanding is that the people who make up the APNIC community
>> are not exactly delighted with the NIR model, and the model is being
>> phased out as not viable.
>>
>> >
>> > it was a concession to some of the same political pressures that are
>> now leading to the call for CIRs. Indeed, it is a bit inconsistent for
>> this community to argue against the Ramadass proposal for CIRs and then
>> propose NIRs instead.
>>
>> agreed, but the community hasn't endorsed this idea AFAICS.
>>
>> >
>> > I prefer McTim's approach of supporting the principle that addresses
>> should be allocated to users (ASs) and not to governments or other
>> entities who want to interpose themselves as intermediaries.
>> >
>> > If it comes down to a choice between NIRs and CIRs, then the only
>> relevant difference is whether the RIRs retain a monopoly on higher-
>> level allocations or not. I think that's a weak position to be in. Here
>> we need to frankly realize that the issues are fundamentally political.
>> >
>> > Note that the ITU proposal for CIRs does not propose to make them
>> exclusive, but rather proposes that an ITU-mediated CIR be an
>> additional option. If one supports competing ISPs, why not alternative
>> address registries?
>>
>> RFC2050
>>
>> "Service areas will be of continental dimensions."
>>
>> In addition there are various other reasons outlined in the Circleid
>> post I sent earlier.
>>
>> >
>> > One cannot argue against this option on the grounds that we don't
>> have enough ipv6 addresses to make it viable; we do. One cannot argue
>> against it on the grounds that it messes up the efficiency of routing,
>>
>> You can actually.
>>
>> >because new, RIR-sanctioned NIRs or new RIRs carved out of existing
>> ones would have basically the same effects on routing.
>>
>> perhaps, or perhaps not, depending on the policies they adopt.
>>
>> >
>> > The only way to viably challenge this proposal is to face squarely
>> the political issues and question whether states who gain control of ip
>> addresses will truly allow competitive alternatives, or instead try to
>> leverage their control of the resource to gain more control over
>> internet supply and usage, or to favor incumbent, national champion
>> network operators.
>>
>>
>> or to boost government revenue, or use IP address revenue to feather
>> individual nests, or not develop policies in an open, transparent
>> manner, etc, etc.
>>
>>
>> >
>> > One can also try to question the need for this proposal (solution in
>> search of a problem). There is merit in this argument, but the issue is
>> not quite as simple as it may seem. Developing countries aware of the
>> landrush for ipv4 addresses that took place in the early stages of the
>> internet's development have a legitimate reason to worry about whether
>> history will repeat itself. An inherent feature of needs-based
>> allocations is that developed economies will be able to show "need"
>> well before undeveloped ones. The ITU is basically arguing for a system
>> of reservations that guarantees each nation-state a substantial chunk
>> of address resources just in case that happens. Naturally enough, given
>> its basis in an intergovernmental organization, the ITU considers
>> nation-states the appropriate stewards for these reservations.
>>
>>
>> Speaking of "reservations" I am under the impression that it is the
>> IETF that instructs the IANA to reserve IP blocks. ?If this is
>> correct, then the ITU and the RIR policy lists are not the correct
>> fora to discuss this proposal. ?The ITU should write a draft RFC and
>> submit it to the IETF. ?Perhaps I am mistaken.
>>
>> >
>> > If setting aside address block reservations were the ONLY price we
>> had to pay to assuage these political concerns, I would say, "do it."
>> But other prices could be extracted - as I explained above, linking ip
>> address allocations to the nation state system so closely could have
>> serious political and regulatory repercussions. That price is not worth
>> paying.
>>
>>
>> I hope you plan to say this to the ITU in March!
>>
>>
>> --
>> Cheers,
>>
>> McTim
>> "A name indicates what we seek. An address indicates where it is. A
>> route indicates how we get there." ?Jon Postel
>> _______________________________________________
>> 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  Sat Feb 27 00:36:29 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sat, 27 Feb 2010 00:36:29 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <f65fb55e1002262135r3c7b2618s98a8fd5da5153db1@mail.gmail.com>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<f65fb55e1002261450k7def36eena741a851b68ffdf1@mail.gmail.com>
	<292AF25E62B8894C921B893B53A19D973974B77CBD@BUSINESSEX.business.ad>,
	<f65fb55e1002262135r3c7b2618s98a8fd5da5153db1@mail.gmail.com>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C79C6CE0@SUEX07-MBX-04.ad.syr.edu>

This conforms to my experience and information, too. Although I do recall seeing documentation - either records of APNIC meeting discussions or some kind of policy document, but I don't have time to look it up. 
--MM
________________________________________
From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of McTim [dogwallah at gmail.com]

On Sat, Feb 27, 2010 at 4:43 AM, Skeeve Stevens <Skeeve at eintellego.net> wrote:
> Do you have any reference to where the APNIC community is suggesting phasing out the NIR model?

I don't this recollection is based on private conversations over the
last 5 years.

Now that I am thinking about it, perhaps "phasing out" is too strong a
term, I think that what they have decided is more like "no more new
NIRs".



From maem at nic.ad.jp  Sat Feb 27 01:55:03 2010
From: maem at nic.ad.jp (MAEMURA Akinori)
Date: Sat, 27 Feb 2010 15:55:03 +0900
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6CE0@SUEX07-MBX-04.ad.syr.edu>
References: <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<f65fb55e1002261450k7def36eena741a851b68ffdf1@mail.gmail.com>
	<292AF25E62B8894C921B893B53A19D973974B77CBD@BUSINESSEX.business.ad>
	<f65fb55e1002262135r3c7b2618s98a8fd5da5153db1@mail.gmail.com>
	<75822E125BCB994F8446858C4B19F0D701C79C6CE0@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <201002271555.ABJ39089.BNNF@nic.ad.jp>

Milton, McTim and all,

I agree that the NIR scheme has some disadvantages.  the 
major one is complexiety.  An NIR need to deploy a similar 
mechanism of an Internet Registry including the registry 
system and policy development process, which should be 
synchronized to RIR's one.  Someone possibly might feel not 
comfortable.

However, NIRs are working very well to serve non English 
speaking community to deliver IP resources and include it 
into the global policy scheme, which should justify an
additional cost for the complexiety as shown above.

The NIR scheme is not phasing out, APNIC does accept 
applications of forming an NIR.


Just for making sure.

Best,
Akinori - JPNIC and APNIC EC, but in my personal capacity


In message <75822E125BCB994F8446858C4B19F0D701C79C6CE0 at SUEX07-MBX-04.ad.syr.edu>
   "Re: [arin-ppml] RIPE/ITU"
   "Milton L Mueller <mueller at syr.edu>" wrote:

| This conforms to my experience and information, too. Although I do recall
| seeing documentation - either records of APNIC meeting discussions or
| some kind of policy document, but I don't have time to look it up. 
| --MM
| ________________________________________
| From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of McTim [dogwallah at gmail.com]
| 
| On Sat, Feb 27, 2010 at 4:43 AM, Skeeve Stevens <Skeeve at eintellego.net> wrote:
| > Do you have any reference to where the APNIC community is suggesting
|   phasing out the NIR model?
| 
| I don't this recollection is based on private conversations over the
| last 5 years.
| 
| Now that I am thinking about it, perhaps "phasing out" is too strong a
| term, I think that what they have decided is more like "no more new
| NIRs".
| 
| _______________________________________________
| 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 ocl at gih.com  Sat Feb 27 03:59:01 2010
From: ocl at gih.com (Olivier MJ Crepin-Leblond)
Date: Sat, 27 Feb 2010 09:59:01 +0100
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>,
	<E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <4B88DED5.8010800@gih.com>

Milton,

Le 27/02/2010 06:33, Milton L Mueller a ?crit :
> Stop fretting, John. I am not part of a vast ITU conspiracy. We have two docs on the table: one is the study proposal for CIRs prepared by prof. Ramadass, the other is the Terms of Reference McKay cites which clearly indicates that this is the direction some in Geneva would like to go. Ok, if you want to be picky we cannot say there is an "ITU proposal" yet, but its pretty clear what direction certain people there would like to move. I am suggesting that we engage in that discussion seriously.

I'd like to find out if this is the direction that the ITU *really* want
to go in, or whether it is the direction which a minority number of
members at ITU wish to push ITU into by being as vocal as possible in
public forums.
"There is no publicity as bad publicity" (
http://en.wikipedia.org/wiki/Succ%C3%A8s_de_scandale )

Is it clear that all ITU members wish to like to move in this direction?

Kind regards,

Olivier

-- 
Olivier MJ Cr?pin-Leblond, PhD
http://www.gih.com/ocl.html



From michael.dillon at bt.com  Sat Feb 27 05:53:58 2010
From: michael.dillon at bt.com (michael.dillon at bt.com)
Date: Sat, 27 Feb 2010 10:53:58 -0000
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <f65fb55e1002261022q557bbb07l93ac3bff5d223316@mail.gmail.com>
Message-ID: <28E139F46D45AF49A31950F88C497458054F30C6@E03MVZ2-UKDY.domain1.systemhost.net>


> I think this is largely a solution in search of a problem.

That doesn't mean that the Caribbean folks should not try
something. 

Different regions have different problems and the nature of
problems changes over time. So the fact that APNIC NIRs faded
away doesn't say anything about the Caribbean. As for the 
ITU stuff, I think that it is best ignored because it is
another thing entirely. NIRs came from the users. LACNIC
and AfriNIC breakoff came from the users. If the Caribbean
users can find a good reason for a sub-registry, then let's
hear their ideas.

And let's not muddy the waters by mixing this bottom up
proposal with the grand scheme of the ITU.

--Michael Dillon


From pwilson at apnic.net  Sat Feb 27 07:04:28 2010
From: pwilson at apnic.net (Paul Wilson)
Date: Sat, 27 Feb 2010 22:04:28 +1000
Subject: [arin-ppml] RIPE/ITU
Message-ID: <74104705B8BBFFBDC099B655@as-paul-l-1813.local>

Speaking for APNIC staff, we not aware that anyone is suggesting or 
discussing a phase-out of NIRs in the APNIC region; and I don't know where 
that perception has come from.  Quite the opposite is true in fact.  The 
APNIC EC (the Executive Council, our governing body) recently gave its 
in-principle approval to a proposal to establish an NIR in India, and I 
fully expect that more NIRs will be formed in future.

As for Milton's suggestion of dissatisfaction with the APNIC NIR model, 
this is also a misconception.  It is true that the model has a long history 
and has undergone a number of changes, but today's configuration is the 
result of community policymaking which has ensured that the APNIC NIRs can 
function well in technical and operational terms.  Having achieved that 
outcome some years ago, any remaining dissatisfaction with the model was 
related primarily to the membership fee structure for NIRs, which was 
recently changed after long discussions which are well documented.

Paul Wilson
APNIC


--On 27 February 2010 12:43:05 PM +1100 Skeeve Stevens 
<Skeeve at eintellego.net> wrote:

> Do you have any reference to where the APNIC community is suggesting
> phasing out the NIR model?
>
> ...Skeeve
>
> --
> 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
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of McTim
>> Sent: Saturday, 27 February 2010 9:51 AM
>> To: Milton L Mueller
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] RIPE/ITU
>>
>> Hi Milton,
>>
>> On Sat, Feb 27, 2010 at 1:15 AM, Milton L Mueller <mueller at syr.edu>
>> wrote:
>> >
>> > > -----Original Message-----
>> > > You might want to look into APNIC's NIR model which is exactly
>> > > that, and then make a formal proposal.
>> >
>> > My understanding is that the people at APNIC are not exactly
>> delighted with the NIR model;
>>
>> My understanding is that the people who make up the APNIC community
>> are not exactly delighted with the NIR model, and the model is being
>> phased out as not viable.
>>
>> >
>> > it was a concession to some of the same political pressures that are
>> now leading to the call for CIRs. Indeed, it is a bit inconsistent for
>> this community to argue against the Ramadass proposal for CIRs and then
>> propose NIRs instead.
>>
>> agreed, but the community hasn't endorsed this idea AFAICS.
>>
>> >
>> > I prefer McTim's approach of supporting the principle that addresses
>> should be allocated to users (ASs) and not to governments or other
>> entities who want to interpose themselves as intermediaries.
>> >
>> > If it comes down to a choice between NIRs and CIRs, then the only
>> relevant difference is whether the RIRs retain a monopoly on higher-
>> level allocations or not. I think that's a weak position to be in. Here
>> we need to frankly realize that the issues are fundamentally political.
>> >
>> > Note that the ITU proposal for CIRs does not propose to make them
>> exclusive, but rather proposes that an ITU-mediated CIR be an
>> additional option. If one supports competing ISPs, why not alternative
>> address registries?
>>
>> RFC2050
>>
>> "Service areas will be of continental dimensions."
>>
>> In addition there are various other reasons outlined in the Circleid
>> post I sent earlier.
>>
>> >
>> > One cannot argue against this option on the grounds that we don't
>> have enough ipv6 addresses to make it viable; we do. One cannot argue
>> against it on the grounds that it messes up the efficiency of routing,
>>
>> You can actually.
>>
>> > because new, RIR-sanctioned NIRs or new RIRs carved out of existing
>> ones would have basically the same effects on routing.
>>
>> perhaps, or perhaps not, depending on the policies they adopt.
>>
>> >
>> > The only way to viably challenge this proposal is to face squarely
>> the political issues and question whether states who gain control of ip
>> addresses will truly allow competitive alternatives, or instead try to
>> leverage their control of the resource to gain more control over
>> internet supply and usage, or to favor incumbent, national champion
>> network operators.
>>
>>
>> or to boost government revenue, or use IP address revenue to feather
>> individual nests, or not develop policies in an open, transparent
>> manner, etc, etc.
>>
>>
>> >
>> > One can also try to question the need for this proposal (solution in
>> search of a problem). There is merit in this argument, but the issue is
>> not quite as simple as it may seem. Developing countries aware of the
>> landrush for ipv4 addresses that took place in the early stages of the
>> internet's development have a legitimate reason to worry about whether
>> history will repeat itself. An inherent feature of needs-based
>> allocations is that developed economies will be able to show "need"
>> well before undeveloped ones. The ITU is basically arguing for a system
>> of reservations that guarantees each nation-state a substantial chunk
>> of address resources just in case that happens. Naturally enough, given
>> its basis in an intergovernmental organization, the ITU considers
>> nation-states the appropriate stewards for these reservations.
>>
>>
>> Speaking of "reservations" I am under the impression that it is the
>> IETF that instructs the IANA to reserve IP blocks.  If this is
>> correct, then the ITU and the RIR policy lists are not the correct
>> fora to discuss this proposal.  The ITU should write a draft RFC and
>> submit it to the IETF.  Perhaps I am mistaken.
>>
>> >
>> > If setting aside address block reservations were the ONLY price we
>> had to pay to assuage these political concerns, I would say, "do it."
>> But other prices could be extracted - as I explained above, linking ip
>> address allocations to the nation state system so closely could have
>> serious political and regulatory repercussions. That price is not worth
>> paying.
>>
>>
>> I hope you plan to say this to the ITU in March!
>>
>>
>> --
>> Cheers,
>>
>> McTim
>> "A name indicates what we seek. An address indicates where it is. A
>> route indicates how we get there." ?Jon Postel
>> _______________________________________________
>> 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.
>



________________________________________________________________________
Paul Wilson, Director-General, APNIC                      <dg at apnic.net>
http://www.apnic.net                            ph/fx +61 7 3858 3100/99
 


From pwilson at apnic.net  Sat Feb 27 07:05:46 2010
From: pwilson at apnic.net (Paul Wilson)
Date: Sat, 27 Feb 2010 22:05:46 +1000
Subject: [arin-ppml] RIPE/ITU
Message-ID: <4637A90D729F40809726C46D@as-paul-l-1813.local>

Speaking for APNIC staff, we not aware that anyone is suggesting or 
discussing a phase-out of NIRs in the APNIC region; and I don't know where 
that perception has come from.  Quite the opposite is true in fact.  The 
APNIC EC (the Executive Council, our Governing body) recently gave its 
in-principle approval to a proposal to establish an NIR in India, and I 
fully expect that more NIRs will be formed in future.

As for Milton's suggestion of dissatisfaction with the APNIC NIR model, 
this is also a misconception.  It is true that the model has a long history 
and has undergone a number of changes, but today's configuration is the 
result of community policymaking which has ensured that the APNIC NIRs can 
function well in technical and operational terms.  Having achieved that 
outcome some years ago, any remaining dissatisfaction with the model was 
related primarily to the membership fee structure for NIRs, which was 
recently changed after long discussions which are well documented.

Paul Wilson
APNIC


--On 27 February 2010 12:43:05 PM +1100 Skeeve Stevens 
<Skeeve at eintellego.net> wrote:

> Do you have any reference to where the APNIC community is suggesting
> phasing out the NIR model?
>
> ...Skeeve
>
> --
> 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
> www.linkedin.com/in/skeeve ; facebook.com/eintellego
> --
> NOC, NOC, who's there?
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of McTim
>> Sent: Saturday, 27 February 2010 9:51 AM
>> To: Milton L Mueller
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] RIPE/ITU
>>
>> Hi Milton,
>>
>> On Sat, Feb 27, 2010 at 1:15 AM, Milton L Mueller <mueller at syr.edu>
>> wrote:
>> >
>> > > -----Original Message-----
>> > > You might want to look into APNIC's NIR model which is exactly
>> > > that, and then make a formal proposal.
>> >
>> > My understanding is that the people at APNIC are not exactly
>> delighted with the NIR model;
>>
>> My understanding is that the people who make up the APNIC community
>> are not exactly delighted with the NIR model, and the model is being
>> phased out as not viable.
>>
>> >
>> > it was a concession to some of the same political pressures that are
>> now leading to the call for CIRs. Indeed, it is a bit inconsistent for
>> this community to argue against the Ramadass proposal for CIRs and then
>> propose NIRs instead.
>>
>> agreed, but the community hasn't endorsed this idea AFAICS.
>>
>> >
>> > I prefer McTim's approach of supporting the principle that addresses
>> should be allocated to users (ASs) and not to governments or other
>> entities who want to interpose themselves as intermediaries.
>> >
>> > If it comes down to a choice between NIRs and CIRs, then the only
>> relevant difference is whether the RIRs retain a monopoly on higher-
>> level allocations or not. I think that's a weak position to be in. Here
>> we need to frankly realize that the issues are fundamentally political.
>> >
>> > Note that the ITU proposal for CIRs does not propose to make them
>> exclusive, but rather proposes that an ITU-mediated CIR be an
>> additional option. If one supports competing ISPs, why not alternative
>> address registries?
>>
>> RFC2050
>>
>> "Service areas will be of continental dimensions."
>>
>> In addition there are various other reasons outlined in the Circleid
>> post I sent earlier.
>>
>> >
>> > One cannot argue against this option on the grounds that we don't
>> have enough ipv6 addresses to make it viable; we do. One cannot argue
>> against it on the grounds that it messes up the efficiency of routing,
>>
>> You can actually.
>>
>> > because new, RIR-sanctioned NIRs or new RIRs carved out of existing
>> ones would have basically the same effects on routing.
>>
>> perhaps, or perhaps not, depending on the policies they adopt.
>>
>> >
>> > The only way to viably challenge this proposal is to face squarely
>> the political issues and question whether states who gain control of ip
>> addresses will truly allow competitive alternatives, or instead try to
>> leverage their control of the resource to gain more control over
>> internet supply and usage, or to favor incumbent, national champion
>> network operators.
>>
>>
>> or to boost government revenue, or use IP address revenue to feather
>> individual nests, or not develop policies in an open, transparent
>> manner, etc, etc.
>>
>>
>> >
>> > One can also try to question the need for this proposal (solution in
>> search of a problem). There is merit in this argument, but the issue is
>> not quite as simple as it may seem. Developing countries aware of the
>> landrush for ipv4 addresses that took place in the early stages of the
>> internet's development have a legitimate reason to worry about whether
>> history will repeat itself. An inherent feature of needs-based
>> allocations is that developed economies will be able to show "need"
>> well before undeveloped ones. The ITU is basically arguing for a system
>> of reservations that guarantees each nation-state a substantial chunk
>> of address resources just in case that happens. Naturally enough, given
>> its basis in an intergovernmental organization, the ITU considers
>> nation-states the appropriate stewards for these reservations.
>>
>>
>> Speaking of "reservations" I am under the impression that it is the
>> IETF that instructs the IANA to reserve IP blocks.  If this is
>> correct, then the ITU and the RIR policy lists are not the correct
>> fora to discuss this proposal.  The ITU should write a draft RFC and
>> submit it to the IETF.  Perhaps I am mistaken.
>>
>> >
>> > If setting aside address block reservations were the ONLY price we
>> had to pay to assuage these political concerns, I would say, "do it."
>> But other prices could be extracted - as I explained above, linking ip
>> address allocations to the nation state system so closely could have
>> serious political and regulatory repercussions. That price is not worth
>> paying.
>>
>>
>> I hope you plan to say this to the ITU in March!
>>
>>
>> --
>> Cheers,
>>
>> McTim
>> "A name indicates what we seek. An address indicates where it is. A
>> route indicates how we get there." ?Jon Postel
>> _______________________________________________
>> 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.
>



________________________________________________________________________
Paul Wilson, Director-General, APNIC                      <dg at apnic.net>
http://www.apnic.net                            ph/fx +61 7 3858 3100/99
 


From jcurran at arin.net  Sat Feb 27 07:39:29 2010
From: jcurran at arin.net (John Curran)
Date: Sat, 27 Feb 2010 07:39:29 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>,
	<E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net>

On Feb 26, 2010, at 11:33 PM, Milton L Mueller wrote:
> 
> Stop fretting, John. I am not part of a vast ITU conspiracy. We have two docs on the table: one is the study proposal for CIRs prepared by prof. Ramadass, the other is the Terms of Reference McKay cites which clearly indicates that this is the direction some in Geneva would like to go. Ok, if you want to be picky we cannot say there is an "ITU proposal" yet, but its pretty clear what direction certain people there would like to move. I am suggesting that we engage in that discussion seriously. 
> 
> My study said that the ITU "could play a constructive role" by helping to work out a legal framework for TABLs. Aside from the fact that that does not seem to be the direction they want to move in, is it your implication that ITU has _no_ constructive role to play in this space?  

Milton - 
 
Given that there are already existing forums in each region which enjoy 
participation from organizations of all types (including governments, 
businesses, and civil society) one could certainly imagine that the ITU 
could play a constructive role by participating in these open forums. 

That would allow us to conduct global dialogue on the actual issues, 
rather than forcing much of the community having to guess about "who" 
would like to move in "what" direction and "why"...  Was having the 
ITU participate in open, multi-stakeholder policy dialogue the type 
of constructive role you were advocating for in the study, or were
you suggesting that their existing model for global dialogue (e.g.
the closed, invite-only IT IPv6 meeting in Geneva) be the appropriate
forum?  As you've advocated for their involvement, it would be good
for the community to understand why and in what form you feel this 
involvement should take place. 

/John





From internetplumber at gmail.com  Sat Feb 27 08:52:55 2010
From: internetplumber at gmail.com (Rob Evans)
Date: Sat, 27 Feb 2010 13:52:55 +0000
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <4B88DED5.8010800@gih.com>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>
	<E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>
	<4B88DED5.8010800@gih.com>
Message-ID: <9a8fa98b1002270552s2cc9fdd1vdd9e3a4e74798394@mail.gmail.com>

> I'd like to find out if this is the direction that the ITU *really* want
> to go in, or whether it is the direction which a minority number of
> members at ITU wish to push ITU into by being as vocal as possible in
> public forums.

I suspect, or at least hope, this will become more evident from the
March meeting.

Rob


From baptista at publicroot.org  Sat Feb 27 10:20:08 2010
From: baptista at publicroot.org (Joe Baptista)
Date: Sat, 27 Feb 2010 10:20:08 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>
	<E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <874c02a21002270720x4f583400me419d8c31888bbc6@mail.gmail.com>

On Sat, Feb 27, 2010 at 12:33 AM, Milton L Mueller <mueller at syr.edu> wrote:

> Stop fretting, John. I am not part of a vast ITU conspiracy.


Thats true. But you are a hired gun. I've had experience with that.

In any case my two cents in all this is - now that countries have discovered
the value of IPv? the MLM (multi-level marketing) monopoly at
ARIN/IANA/APNIC/RIPE/etc might come to a close.

This is a fight I consider entertaining enough to watch. The ITU is a fools
paradise of myopic bureaucracy. They were offered the opportunity of getting
involved in the Internet back in the 80's and they turned it down. I'm not
confident they know what they are doing. But at least the MLM monopoly would
be broken.

regards
joe baptista




> We have two docs on the table: one is the study proposal for CIRs prepared
> by prof. Ramadass, the other is the Terms of Reference McKay cites which
> clearly indicates that this is the direction some in Geneva would like to
> go. Ok, if you want to be picky we cannot say there is an "ITU proposal"
> yet, but its pretty clear what direction certain people there would like to
> move. I am suggesting that we engage in that discussion seriously.
>
> My study said that the ITU "could play a constructive role" by helping to
> work out a legal framework for TABLs.Aside from the fact that that does not
> seem to be the direction they want to move in, is it your implication that
> ITU has _no_ constructive role to play in this space?
>
> --MM
>
> _______________________________________
> From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of
> John Curran [jcurran at arin.net]
> Milton refers to "the ITU proposal for CIRs", whereas the terms of
> reference to the ITU IPV6 working group meeting (of which I am an
> invited expert) call for *drafting* such a proposal.  Since Milton
> references "the ITU proposal" as if it was already specified, and
> his paper is indeed a listed working group meeting document, perhaps
> he's aware of an actual ITU CIR proposal which will be forthcoming
> to the rest of us soon?
>
> Of course, the differences in approach between the ITU and the RIR
> community should be very apparent just from this ITU IPv6 meeting
> announcement.  The idea that a closed (ITU members + invited guests
> who are to "represent" the Regional Internet Registries) working
> group could "draft a global policy proposal" which would then be
> seen as sufficiently complete to allow assessment of the various
> implementation details almost presumes that one has already given
> up on any form of community-based policy; note specifically that
> ARIN's Policy Development Process states: "Policy proposals may
> be submitted by anyone in the global Internet community except
> for members of the ARIN Board of Trustees or the ARIN staff"
> exactly to prevent assumptions such as this from occurring...
>
> While invited and going to Geneva for the working group meeting,
> my most important contribution regarding that initial item in
> the terms of reference is to invite the participants of the ITU
> IPv6 working group to ARIN's Public Policy Meetings and this
> mailing list so that any actual CIR proposal is made before this
> community, discussed publicly on its merits, and otherwise follows
> ARIN's Policy Development Process as required.
>
> /John
>
> John Curran
> President and CEO
> 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.
> _______________________________________________
> 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.
>



-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

Personal: http://baptista.cynikal.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100227/fc159e32/attachment.htm>

From jcurran at arin.net  Sat Feb 27 11:18:46 2010
From: jcurran at arin.net (John Curran)
Date: Sat, 27 Feb 2010 11:18:46 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <874c02a21002270720x4f583400me419d8c31888bbc6@mail.gmail.com>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>
	<E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>
	<874c02a21002270720x4f583400me419d8c31888bbc6@mail.gmail.com>
Message-ID: <B2C7A92C-66D6-49FC-8EBA-7BF9EC9CE8E6@arin.net>

On Feb 27, 2010, at 9:20 AM, Joe Baptista wrote:
> In any case my two cents in all this is - now that countries have discovered the value of IPv? the MLM (multi-level marketing) monopoly at ARIN/IANA/APNIC/RIPE/etc might come to a close.
> 
> This is a fight I consider entertaining enough to watch. The ITU is a fools paradise of myopic bureaucracy. They were offered the opportunity of getting involved in the Internet back in the 80's and they turned it down. I'm not confident they know what they are doing. But at least the MLM monopoly would be broken.


Joe - 

The multi-level assignment model of (IANA, Regional Registries, 
Local Registries/ISPs, end organizations) is indeed unitary in nature.   
This was established quite intentionally in order to provide uniqueness, 
conservation, and hierarchy to the address allocation process.   Without 
extensive automation, it's not obvious how one would have multiple 
competing registries in this space and still meet any of the requirements 
handed down by community, particularly with respect to IPv4.  

Under IPv6, there's certainly a vast abundance of space, which means 
that if the principles of conservation and hierarchy were to be thrown 
out by the community, one could look at a number of alternatives.  
What benefits do you want to accomplish, and have you considered
the impacts (e.g. routing) of changing the framework as you suggest?

/John





From mueller at syr.edu  Sat Feb 27 17:40:53 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sat, 27 Feb 2010 17:40:53 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>,
	<E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>,
	<612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu>

John, 
I don't advocate for the ITU. This kind of "spin," which attempts to polarize the debate, is not helpful. Those tactics just reinforce the conclusion that this whole thing is just a power struggle between two large institutions over turf. Which, at this point, it basically is: http://blog.internetgovernance.org/blog/_archives/2009/11/20/4385849.html  

There's a growing community of scholars and academic analysts who are beginning to look seriously at address policy and internet governance. These folks _will_ be interested in a debate over the role of national governments vs. private sector, transnational self-regulatory agencies; and they _will_be interested discussions of the role of markets and commons in address governance, conservation, aggregation and other policy principles. But the good and influential ones are _not_ going to be interested in being loyalists for your little organization or for the ITU. They're going to look at both ITU and the RIRs and ICANN critically and objectively as institutional players in the arena. If you're not used to that kind of scrutiny -- get used to it, more is coming.  

If what you have said in this thread is an indication of your strategy and tactics for the Geneva meeting, I'd respectfully suggest a trip back to the drawing board. Your plan, apparently, is to tell the ITU and its member states to come to _your_ meetings, to your home field, to participate in _your_ game. Good luck with that. Looks to me as if you're going to one of their meetings..... 

As I said earlier, in an attempt to be helpful, try to articulate and take a position on the real political and policy issues. Don't try to force policy analysts and critics into your own manichean worldview of a bipolar struggle with the ITU. Keep the focus on policies and the public interest. Try to articulate principles. Paul Wilson's intervention, which tells us that NIRs are OK if the RIRs create them but an abomination of the ITU does, is a perfect example of what NOT to do. 

ICANN, ARIN and the RIRs have all kinds of invitation-only meetings to discuss policy, and you know it. For example, RIPE holds invitation-only meetings wth governmental stakeholders and some with law enforcement agencies. 
Real decisions at RIRs are made by dues-paying members, which is the case also at ITU. 

That being said, I do think the ITU processes are less open than ICANN's and RIRs, and (like dozens of other civil society participants) have openly and repeatedly said so all throughout WSIS up to the present day. I have supported a nongovernmental model for critical internet resource governance in reams and reams of my writing. If you see me as an enemy in this particular debate I feel really sorry for you, for I wonder who your friends are and how many of them there are (who are not on the payrolls of the RIRs). 

--MM

________________________________________
From: John Curran [jcurran at arin.net]
Sent: Saturday, February 27, 2010 7:39 AM
To: Milton L Mueller
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] RIPE/ITU

On Feb 26, 2010, at 11:33 PM, Milton L Mueller wrote:
>
> Stop fretting, John. I am not part of a vast ITU conspiracy. We have two docs on the table: one is the study proposal for CIRs prepared by prof. Ramadass, the other is the Terms of Reference McKay cites which clearly indicates that this is the direction some in Geneva would like to go. Ok, if you want to be picky we cannot say there is an "ITU proposal" yet, but its pretty clear what direction certain people there would like to move. I am suggesting that we engage in that discussion seriously.
>
> My study said that the ITU "could play a constructive role" by helping to work out a legal framework for TABLs. Aside from the fact that that does not seem to be the direction they want to move in, is it your implication that ITU has _no_ constructive role to play in this space?

Milton -

Given that there are already existing forums in each region which enjoy
participation from organizations of all types (including governments,
businesses, and civil society) one could certainly imagine that the ITU
could play a constructive role by participating in these open forums.

That would allow us to conduct global dialogue on the actual issues,
rather than forcing much of the community having to guess about "who"
would like to move in "what" direction and "why"...  Was having the
ITU participate in open, multi-stakeholder policy dialogue the type
of constructive role you were advocating for in the study, or were
you suggesting that their existing model for global dialogue (e.g.
the closed, invite-only IT IPv6 meeting in Geneva) be the appropriate
forum?  As you've advocated for their involvement, it would be good
for the community to understand why and in what form you feel this
involvement should take place.

/John





From jcurran at arin.net  Sat Feb 27 19:16:23 2010
From: jcurran at arin.net (John Curran)
Date: Sat, 27 Feb 2010 19:16:23 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>,
	<E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>,
	<612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <73F74491-3325-41D3-800D-0A662A446157@arin.net>

On Feb 27, 2010, at 4:40 PM, Milton L Mueller wrote:
> 
> If what you have said in this thread is an indication of your strategy and tactics for the Geneva meeting, I'd respectfully suggest a trip back to the drawing board. Your plan, apparently, is to tell the ITU and its member states to come to _your_ meetings, to your home field, to participate in _your_ game. Good luck with that. Looks to me as if you're going to one of their meetings..... 

Milton - 
 
Actually, any open forum would be welcome as a location to have these 
discussions, so that the community impacted by them could actually 
participate.  I'll take ARIN, ICANN, IGF, ISOC, or a place to be named 
later, as long as the community at large can participate.

This is not a question of politics or strategy; it's a simple matter 
of openness and multi-stakeholderism which I thought you and the 
Internet Governance Project <internetgovernance.org> took to be an 
essential principle.

> ICANN, ARIN and the RIRs have all kinds of invitation-only meetings to discuss policy, and you know it. For example, RIPE holds invitation-only meetings wth governmental stakeholders and some with law enforcement agencies. 
> Real decisions at RIRs are made by dues-paying members, which is the case also at ITU.

I'm sorry regarding your understanding of ARIN processes, but I am happy 
to clarify them for you.  ARIN's policies are suggested and shaped by the 
community by discussion on this very mailing list. The recommendation to 
advance a draft policy comes from the ARIN Advisory Council, which is made 
up of folks elected at large and which do not even have to be dues-paying 
ARIN members.  The Internet number resource policy is the essential rules
by which ARIN does its mission, and no dues-paying members hold control
over their formation.

ARIN holds informational meetings with different groups, including the 
government & law enforcement community. This year, will add another pre-
meeting informational session with interested hosting organizations, see: 
<https://www.arin.net/participate/meetings/ARIN-XXV/premeeting.html#hosting>
for specifics. These are informational meetings setup to explain the way 
the ARIN policy process works & review the draft policies under discussion, 
so that these folks can feel comfortable that they're up to speed to join
in the same public policy process. Any suggestions of policy changes are 
directed to the same public policy process everyone else follows which is 
documented here: <https://www.arin.net/policy/pdp.html>  FYI - I'm happy 
to hold additional informational sessions, so that if you wanted to get
a group of academic policy advocates or economists together before ARIN's 
next meeting, please let me know.  Part of being open is making new parties 
feel welcome, including preparing tailored information as necessary.

> That being said, I do think the ITU processes are less open than ICANN's and RIRs, and (like dozens of other civil society participants) have openly and repeatedly said so all throughout WSIS up to the present day. I have supported a nongovernmental model for critical internet resource governance in reams and reams of my writing. If you see me as an enemy in this particular debate I feel really sorry for you, for I wonder who your friends are and how many of them there are (who are not on the payrolls of the RIRs). 

For clarity, your study stated that there's a role for the ITU, and given 
your involvement with the Internet Governance Project (IGP) and their 
underlying principles, it seemed necessary to ask exactly what role you're 
advocating for the ITU in this discussion.  If you think that they should
hold open, multi-stakeholder discussions of this issue, that didn't exactly
come through in your paper.  As it is, your paper is cited as support for
why the ITU needs to have a closed, invitation-only IPv6 working group on
this topic.  I am simply asking if that was your intention by recommending 
their involvement, since the recommendation seems so contrary both to the 
other IGP work as well your own astute comments on repercussions which 
started this discussion:

>   "If setting aside address block reservations were the ONLY price we had to pay to assuage these political concerns, I would say, "do it." But other prices could be extracted - as I explained above, linking ip address allocations to the nation state system so closely could have serious political and regulatory repercussions. That price is not worth paying. "

(hence, one's almost left wondering if the study advocating for an 
 "ITU role" was written by some other Milton Mueller...)

As this discussion is no longer directly on Internet numbering resource 
policy, I recommend that we take this to private email shortly so that 
folks may continue work on ARIN number resource policy development.

/John

John Curran
President and CEO
ARIN





From mysidia at gmail.com  Sun Feb 28 05:11:23 2010
From: mysidia at gmail.com (James Hess)
Date: Sun, 28 Feb 2010 04:11:23 -0600
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
Message-ID: <6eb799ab1002280211x54a41aebqb7b6e925609ca84a@mail.gmail.com>

On Fri, Feb 26, 2010 at 4:15 PM, Milton L Mueller <mueller at syr.edu> wrote:
>> -----Original Message-----
> Note that the ITU proposal for CIRs does not propose to make them exclusive, but rather proposes that an ITU-mediated CIR be an additional option. If one supports competing ISPs, why not alternative address registries? One cannot argue against this option on the grounds that we don't have enough ipv6 addresses to make it viable; we do. One cannot argue against it on the grounds that it messes up the efficiency of routing, because new, RIR-sanctioned NIRs or new RIRs carved out of existing ones would have basically the same effects on routing.
>
As I understand the  NIRs  didn't  receive their own  blocks of
addresses, or get any blocks that were distinctly theirs,
automatically, to do with as they please.   And the NIRs only approve
allocation to users within their region,  the addresses are truly
still allocated by RIR.

The ITU  proposal  implies a breakdown of hierarchical addressing,
which would have profound negative impact on the efficiency of
routing,   if it were to be implemented,  in terms of fragmentation,
number of prefixes, and

Since it then becomes impossible to aggregate at the RIR level and
keep out-of-region routing announcements out of your table, when there
are hundreds of countries applying for and receiving  new additional
allocations  interspersed throughout an ITU assignment.,...


It is not as if the  choice to create  RIRs    instead of  assigning
IP blocks to countries in the first place,  was some arbitrary policy
decision or a   "division of resources"  decision .

Allocating  fixed  sized  blocks to countries  "CIRs" is a polar
opposite to efficient utilization of  IP address space  and
needs-based allocation.


There ought to be some sort of justification criteria that needs to be
met for the creation of new IP address registries,  including respect
for the IPv6 addressing model and hierarchical addressing.

Just like there needs to be justification criteria for the creation of
new LIRs....


Basically it sounds as if  the ITU  wants to  just ignore the IP
addressing model, and get a big  block to do their own thing.     That
 might be fine  if their "alternative"  were to  cleanly   preserve
the hierarchical  properties of IP addressing, and weren't excessively
wasteful.

But it appears that  of the proposal (A) it is excessively wasteful, and
(B)  they really want to break things....


--
-J


From proclus at gnu-darwin.org  Sun Feb 28 23:15:48 2010
From: proclus at gnu-darwin.org (proclus at gnu-darwin.org)
Date: Sun, 28 Feb 2010 23:15:48 -0500 (EST)
Subject: [arin-ppml] radical mormons
Message-ID: <20100301041548.C1FBED5C0D5@gnu-darwin.org>


Those of you who have been following mormonism on the web
for many years will probably recognize The Radical Mormon
publication.  This was likely the first attempt to make
a web portal for latter-day saint people, and this pioneering
effort helped to inspire many other sites to do likewise.  
Radical set itself apart as a place where devout and sincere
LDS and mormons could intelligently discuss controversial
doctrines in a positive light, at a time when the anti-mormon
forces were very powerful on the web.  The publication has been
active off and on ever since that time.  If you are not
familiar with it, you might want to have a look at it.  This
site broke new ground at the time that it was started in 1999.

http://proclus.tripod.com/radical/

For those who are already familiar with The Radical Mormon,
you might be interested to know that the editors and 
contributors have recently started work on some historical
information regarding the publication, which provides many
links to related websites.  You can have an advance look, 
and see as it evolves.  

http://proclus.tripod.com/radical/editor.html

Some of you may even like to contribute something; help us
fix broken links, contribute a news item, editorial, or
personal story.  If you were a part of the activity that
spawned The Radical Mormon, you might like to submit your
link for inclusion on our contributors page.

Regards,
proclus
http://www.gnu-darwin.org/



From mueller at syr.edu  Sun Feb 28 23:46:35 2010
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 28 Feb 2010 23:46:35 -0500
Subject: [arin-ppml] RIPE/ITU
In-Reply-To: <73F74491-3325-41D3-800D-0A662A446157@arin.net>
References: <8aeeaff61002260855i2700a7c3mf7bde0363ac7aa5a@mail.gmail.com>
	<28E139F46D45AF49A31950F88C497458054F3021@E03MVZ2-UKDY.domain1.systemhost.net>
	<75822E125BCB994F8446858C4B19F0D701C7AB38D1@SUEX07-MBX-04.ad.syr.edu>
	<70F6BD77-A0D0-4EEC-A456-91A65E84DE6E@arin.net>
	<45AC65CC-B108-4EBA-A1B7-54041270EA80@st-kilda.org>,
	<E67E2EF3-DDA5-40D6-8F2F-00B62B476D8A@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CDF@SUEX07-MBX-04.ad.syr.edu>,
	<612DEFE6-81C5-4C28-97FC-6CB326D5BA14@arin.net>
	<75822E125BCB994F8446858C4B19F0D701C79C6CE9@SUEX07-MBX-04.ad.syr.edu>
	<73F74491-3325-41D3-800D-0A662A446157@arin.net>
Message-ID: <75822E125BCB994F8446858C4B19F0D701C78E5CFD@SUEX07-MBX-04.ad.syr.edu>

> ...your paper is cited as support for
> why the ITU needs to have a closed, invitation-only 
> IPv6 working group on this topic.

Really? Since my study did not propose the CIR model and presumed the continued existence of the RIRs, that would be quite interesting. I am unaware of any such citations. Show me where they are. If they do exist, they only prove that other people, as well as you, can reference academic studies without regard to their content as part of a political game.

> I am simply asking if that was your intention by 
> recommending their involvement, since the 
> recommendation seems so contrary both to the 
> other IGP work as well your own astute comments 
> on repercussions which started this discussion:

As I've said, it's all about the policies. If the ITU or anyone else wants to discuss and promote more reasonable policies I'm all for it. ITU can serve as a useful countervailing force to the RIR monopoly, just as it has with ICANN. 

--MM



From baptista at publicroot.org  Sun Feb 28 23:57:34 2010
From: baptista at publicroot.org (Joe Baptista)
Date: Sun, 28 Feb 2010 23:57:34 -0500
Subject: [arin-ppml] radical mormons
In-Reply-To: <20100301041548.C1FBED5C0D5@gnu-darwin.org>
References: <20100301041548.C1FBED5C0D5@gnu-darwin.org>
Message-ID: <874c02a21002282057h41ba80e6r8ada1e9c754d8175@mail.gmail.com>

This may be off topic for this list. John can probably speak to that.

joe

On Sun, Feb 28, 2010 at 11:15 PM, <proclus at gnu-darwin.org> wrote:

>
> Those of you who have been following mormonism on the web
> for many years will probably recognize The Radical Mormon
> publication.  This was likely the first attempt to make
> a web portal for latter-day saint people, and this pioneering
> effort helped to inspire many other sites to do likewise.
> Radical set itself apart as a place where devout and sincere
> LDS and mormons could intelligently discuss controversial
> doctrines in a positive light, at a time when the anti-mormon
> forces were very powerful on the web.  The publication has been
> active off and on ever since that time.  If you are not
> familiar with it, you might want to have a look at it.  This
> site broke new ground at the time that it was started in 1999.
>
> http://proclus.tripod.com/radical/
>
> For those who are already familiar with The Radical Mormon,
> you might be interested to know that the editors and
> contributors have recently started work on some historical
> information regarding the publication, which provides many
> links to related websites.  You can have an advance look,
> and see as it evolves.
>
> http://proclus.tripod.com/radical/editor.html
>
> Some of you may even like to contribute something; help us
> fix broken links, contribute a news item, editorial, or
> personal story.  If you were a part of the activity that
> spawned The Radical Mormon, you might like to submit your
> link for inclusion on our contributors page.
>
> Regards,
> proclus
> http://www.gnu-darwin.org/
>
> _______________________________________________
> 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/20100228/d515f186/attachment.htm>

From michel at arneill-py.sacramento.ca.us  Sun Feb 28 23:58:06 2010
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Sun, 28 Feb 2010 20:58:06 -0800
Subject: [arin-ppml] radical mormons
In-Reply-To: <20100301041548.C1FBED5C0D5@gnu-darwin.org>
References: <20100301041548.C1FBED5C0D5@gnu-darwin.org>
Message-ID: <471D76419F9EF642962323D13DF1DF690117E3@newserver.arneill-py.local>

Although there is always the risk of a joe-job, and after necessary
header verifications have occurred, I recommend that ARIN takes the
necessary measures to get these spammers off the Internet. 

Included, but not limited to: having their web page at tripod.com and
the tripod.com associated account cancelled; contacting the registrar
for gnu-darwin.org (dotster) to can the domain; contacting dyndns.org to
delete the account; contacting tummy.com and have them delete the
proclus account (apparently the spam came from 66.35.48.51); contacting
Comcast do cancel the account currently using 68.50.230.183 as of 8:41
pm PST feb 28 2010.

Someone from Comcast reading this? Pulling the plug on that account
would give you brownie points....without his home ISP he can't do much.

Spam is not nice, but if we start to tolerate it on this list we might
as well go back to the papyrus script. Although there are limits to what
we can collectively do to curb spam, let's consider making an example of
people stupid enough to spam this list.

Michel.


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of proclus at gnu-darwin.org
Sent: Sunday, February 28, 2010 8:16 PM
To: ARIN-PPML at arin.net
Subject: [arin-ppml] radical mormons


Those of you who have been following mormonism on the web
for many years will probably recognize The Radical Mormon
publication.  This was likely the first attempt to make
a web portal for latter-day saint people, and this pioneering
effort helped to inspire many other sites to do likewise.  
Radical set itself apart as a place where devout and sincere
LDS and mormons could intelligently discuss controversial
doctrines in a positive light, at a time when the anti-mormon
forces were very powerful on the web.  The publication has been
active off and on ever since that time.  If you are not
familiar with it, you might want to have a look at it.  This
site broke new ground at the time that it was started in 1999.

http://proclus.tripod.com/radical/

For those who are already familiar with The Radical Mormon,
you might be interested to know that the editors and 
contributors have recently started work on some historical
information regarding the publication, which provides many
links to related websites.  You can have an advance look, 
and see as it evolves.  

http://proclus.tripod.com/radical/editor.html

Some of you may even like to contribute something; help us
fix broken links, contribute a news item, editorial, or
personal story.  If you were a part of the activity that
spawned The Radical Mormon, you might like to submit your
link for inclusion on our contributors page.

Regards,
proclus
http://www.gnu-darwin.org/

_______________________________________________
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.