From ras at e-gerbil.net  Sat Oct  1 01:11:04 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sat, 1 Oct 2011 00:11:04 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <393C370D-93D0-425B-BDFF-9DB916B52307@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<3ACA6282-FE1E-473C-A352-77AFF263332D@delong.com>
	<20110929211048.GR49464@gerbil.cluepon.net>
	<47735537-C06C-4BD9-82C4-1B521F5104F1@arin.net>
	<20110930215833.GJ49464@gerbil.cluepon.net>
	<8D4BE984-E6AF-4781-A3B7-DB76D31276BE@arin.net>
	<20111001022043.GK49464@gerbil.cluepon.net>
	<393C370D-93D0-425B-BDFF-9DB916B52307@arin.net>
Message-ID: <20111001051104.GN49464@gerbil.cluepon.net>

On Sat, Oct 01, 2011 at 03:15:20AM +0000, John Curran wrote:
> 
> I did not say that it has no effect on aggregation.  I said that the 
> point of the policy is not to improve aggregation; the policy exists 
> to allow organizations to readily obtain address space as a single 
> organization under criteria applicable when there are multiple 
> discrete networks for a compelling reason.
...
> I'd recommend either redefining "multiple discrete networks" to have a 
> clear technical definition in the policy, or refining the existing 
> examples so one of them directly meets your specific needs (e.g. 
> removal of the term "autonomous" or changing it to an AS reference 
> instead.)

Ok, let me see if I can summarize this.

You're saying that if someone has a compelling reason for running 
multiple discrete networks, it means that they are incapable of 
announcing their single allocation as an aggregate, and therefore need 
the MDN policy to provide multiple blocks which they CAN announce as 
aggregates.

You then go on to say that if someone benefits from the aggregation 
being provided in the previous statement, since aggregation is not an 
intended effect of the policy they therefore don't qualify to use it.

Do you not see the circular logic here? I feel like I need to flowchart 
this or something. :)

Let's think about this:

* There is already an existing policy which enumates a very specific 
  list of example "compelling reasons" for running multiple discrete 
  networks.

* One assumes that if you can exactly match an example from the list of 
  "compelling reason" included in there policy, you therefore do infact 
  have a compelling reason for running them.

* Thus, your compelling reason is THE EXAMPLE THAT YOU MATCHED FROM THE 
  LIST OF COMPELLING REASONS, not the aggregation benefits that may 
  come as a result.

Is there something else that I'm missing? I could at least understand 
and correct it if there was something specific like "I don't think you 
meet compelling reason X", but I'm having a really hard time arguing the 
simple chain of logic above any clearer than I already have.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From jcurran at arin.net  Sat Oct  1 08:17:36 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 1 Oct 2011 12:17:36 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111001051104.GN49464@gerbil.cluepon.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<3ACA6282-FE1E-473C-A352-77AFF263332D@delong.com>
	<20110929211048.GR49464@gerbil.cluepon.net>
	<47735537-C06C-4BD9-82C4-1B521F5104F1@arin.net>
	<20110930215833.GJ49464@gerbil.cluepon.net>
	<8D4BE984-E6AF-4781-A3B7-DB76D31276BE@arin.net>
	<20111001022043.GK49464@gerbil.cluepon.net>
	<393C370D-93D0-425B-BDFF-9DB916B52307@arin.net>
	<20111001051104.GN49464@gerbil.cluepon.net>
Message-ID: <1D9E6B30-E4FC-49DC-8D58-DBB9417731E8@arin.net>

On Oct 1, 2011, at 1:11 AM, Richard A Steenbergen wrote:

> On Sat, Oct 01, 2011 at 03:15:20AM +0000, John Curran wrote:
>> 
>> I did not say that it has no effect on aggregation.  I said that the 
>> point of the policy is not to improve aggregation; the policy exists 
>> to allow organizations to readily obtain address space as a single 
>> organization under criteria applicable when there are multiple 
>> discrete networks for a compelling reason.
> ...
>> I'd recommend either redefining "multiple discrete networks" to have a 
>> clear technical definition in the policy, or refining the existing 
>> examples so one of them directly meets your specific needs (e.g. 
>> removal of the term "autonomous" or changing it to an AS reference 
>> instead.)
> 
> Ok, let me see if I can summarize this.
> 
> You're saying that if someone has a compelling reason for running 
> multiple discrete networks, it means that they are incapable of 
> announcing their single allocation as an aggregate, and therefore need 
> the MDN policy to provide multiple blocks which they CAN announce as 
> aggregates.

Incorrect. If an organization has a compelling reason (along the lines
of the provided examples) for creating multiple discrete networks and
desires to request new or additional address space under a single 
Organization ID, then it can request space under the MDN criteria.

> You then go on to say that if someone benefits from the aggregation 
> being provided in the previous statement, since aggregation is not an 
> intended effect of the policy they therefore don't qualify to use it.

Incorrect. You have repeatedly asserted that position (that intended 
effect of the policy is aggregation) whereas I have had to clarify each
time that aggregation effects are side-effects of the policy, rather 
than criteria for qualification or disqualification of its use.  

Thanks,
/John

John Curran
President and CEO
ARIN




From mysidia at gmail.com  Sat Oct  1 08:58:54 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 1 Oct 2011 07:58:54 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
Message-ID: <CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>

On Thu, Sep 29, 2011 at 3:02 PM, John Curran <jcurran at arin.net> wrote:
> On Sep 29, 2011, at 9:59 PM, Richard A Steenbergen <ras at e-gerbil.net> wrote:
>> I'd very much like to see something done about this, either through the
> For avoidance of doubt, I suggested to Richard that he raise this matter on the PPML or at the Open Policy Hour in Philly, so that the community could consider if policy changes are needed in this area.

I do not see a change required in the MDN policy.  ARIN staff should
apply the policy as written not make a determination that the
applicant "Doesn't NEED" to use a certain policy;  if the applicant
WANTs to apply the policy, when they meet the stated criteria for the
policy, and their application of the policy is reasonable, they should
be allowed to do so.

If the MDN policy is available, and the applicant meets all the
criteria in the MDN policy, the applicant should be eligible to the
allocation of discrete networks under the policy,
specifically:

'"well yes technically I could always just break up my single ARIN
allocation into a bunch of individual /24s for use by each discrete
network" '

Is not a valid reasoning to refuse to apply the MDN policy;  the MDN
policy doesn't contain any statement that allows ARIN staff to refuse
to apply it for that reason alone.

A valid reasoning for refusing to apply the MDN policy would be one of
the following:

1. The organization is actually a group or consortium of multiple entities.
2. The organization does not have a satisfactorily compelling criteria
for creating multiple discrete networks.
3. The organization has failed to keep detailed records for each
discrete network or won't agree to do so on receiving their initial
allocation.
4. The organization fails to demonstrate utilization of 50% or more of
the last block allocated and the aggregate sum of all blocks.
5. The organization has existing blocks for one of the networks that
is not 80% utilized at that location
6.  The organization has not asked ARIN to apply the MDN policy for
their application.


> FYI,
> /John
--
-JH


From jcurran at arin.net  Sat Oct  1 09:11:52 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 1 Oct 2011 13:11:52 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
Message-ID: <DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>

On Oct 1, 2011, at 8:58 AM, Jimmy Hess wrote:

> I do not see a change required in the MDN policy.  ARIN staff should
> apply the policy as written not make a determination that the
> applicant "Doesn't NEED" to use a certain policy;  if the applicant
> WANTs to apply the policy, when they meet the stated criteria for the
> policy, and their application of the policy is reasonable, they should
> be allowed to do so.

Agreed, and this is the case.

> If the MDN policy is available, and the applicant meets all the
> criteria in the MDN policy, the applicant should be eligible to the
> allocation of discrete networks under the policy,
> specifically:
> 
> '"well yes technically I could always just break up my single ARIN
> allocation into a bunch of individual /24s for use by each discrete
> network" '
> 
> Is not a valid reasoning to refuse to apply the MDN policy;  the MDN
> policy doesn't contain any statement that allows ARIN staff to refuse
> to apply it for that reason alone.

Also agreed.

> A valid reasoning for refusing to apply the MDN policy would be one of
> the following:
> 
> 1. The organization is actually a group or consortium of multiple entities.
> 2. The organization does not have a satisfactorily compelling criteria
> for creating multiple discrete networks.
> ...

Reason #2 is the difficulty, whereas ARIN staff has to effectively make a 
judgement of the "compelling" criteria based on 3 illustrative examples.  
I recommend that the policy be so that there is a clear technical definition 
of "discrete network" is added to the policy, and further that any organization 
which has multiple "discrete networks" would qualify for use of the policy, 
regardless of the compelling or otherwise reasoning behind their architectural
decision.

Thanks!
/John

John Curran
President and CEO
ARIN



From ras at e-gerbil.net  Sat Oct  1 11:29:55 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sat, 1 Oct 2011 10:29:55 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
Message-ID: <20111001152955.GP49464@gerbil.cluepon.net>

On Sat, Oct 01, 2011 at 01:11:52PM +0000, John Curran wrote:
> 
> Reason #2 is the difficulty, whereas ARIN staff has to effectively 
> make a judgement of the "compelling" criteria based on 3 illustrative 
> examples.  I recommend that the policy be so that there is a clear 
> technical definition of "discrete network" is added to the policy, and 
> further that any organization which has multiple "discrete networks" 
> would qualify for use of the policy, regardless of the compelling or 
> otherwise reasoning behind their architectural decision.

Ok so, your current position is that matching an example from the 
specifically defined list of example compelling reasons is not a 
compelling reason, because of an exclusionary rule which doesn't exist 
anywhere in the policy (namely that you can't possibly solve the problem 
with deaggregation) that you're making up on the spot? A policy which, 
furthermore, would exclude nearly every MDN applicant if it was actually 
applied to anyone else. Can you explain how this is anything other than 
a blatant refusal to honor the policy as written?

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From jcurran at arin.net  Sat Oct  1 12:13:41 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 1 Oct 2011 16:13:41 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111001152955.GP49464@gerbil.cluepon.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
Message-ID: <0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>

On Oct 1, 2011, at 11:29 AM, Richard A Steenbergen wrote:

> On Sat, Oct 01, 2011 at 01:11:52PM +0000, John Curran wrote:
>> 
>> Reason #2 is the difficulty, whereas ARIN staff has to effectively 
>> make a judgement of the "compelling" criteria based on 3 illustrative 
>> examples.  I recommend that the policy be so that there is a clear 
>> technical definition of "discrete network" is added to the policy, and 
>> further that any organization which has multiple "discrete networks" 
>> would qualify for use of the policy, regardless of the compelling or 
>> otherwise reasoning behind their architectural decision.
> 
> Ok so, your current position is that matching an example from the 
> specifically defined list of example compelling reasons is not a 
> compelling reason, because of an exclusionary rule which doesn't exist 
> anywhere in the policy (namely that you can't possibly solve the problem 
> with deaggregation) that you're making up on the spot? 

Incorrect.  If an organization can demonstrate a compelling need 
for multiple discrete networks (along the lines of the examples),
it can make use of the MDN policy. This is as the policy requires.

Refining the examples is also an option for improving the clarity
of the policy, but that still leaves ARIN staff having to make a 
judgement call regarding what constitutes "compelling criteria."
I believe that the more certain outcome would be to change the 
policy to specifically include a clear technical definition of 
what constitutes "multiple discrete networks" in the policy text.

Richard - Can you propose an appropriate definition of 
"multiple discrete networks" that could be added to the 
policy?

Thanks!
/John

John Curran
President and CEO
ARIN




From mysidia at gmail.com  Sat Oct  1 14:59:58 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 1 Oct 2011 13:59:58 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111001152955.GP49464@gerbil.cluepon.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
Message-ID: <CAAAwwbUh_bBkOK9gmBN_OO5A-dCD3c17OcQUq4QFM6GwfYb=6Q@mail.gmail.com>

On Sat, Oct 1, 2011 at 10:29 AM, Richard A Steenbergen <ras at e-gerbil.net> wrote:
> On Sat, Oct 01, 2011 at 01:11:52PM +0000, John Curran wrote:
> specifically defined list of example compelling reasons is not a
> compelling reason, because of an exclusionary rule which doesn't exist
> anywhere in the policy (namely that you can't possibly solve the problem

Something needs to determine if there is a compelling reason.
The most obvious would be a business need for discrete networks
created by a technical
requirement.

I don't think it's necessarily reasonable/possible to codify every
feasible situation
in which multiple discrete networks are called for.

This is an engineering decision which should be handled based on sound
technical merits.
Since ARIN staffs'  job is to examine the application, not to review
technical decisions,

Perhaps what ARIN should do is provide an option for an "independent
technical review"
of the merits for an organization operating discrete networks, instead
of one network;
where the applicant would be required to find a "reviewer"  mutually
agreed upon by
ARIN and the applicant,   who would then be required to perform a
review, and submit their
findings directly to ARIN,  keeping them confidential from the applicant.

Then instead of staff making an arbitrary judgement call;  they would
be relying on the integrity
of the reviewer.      "Independent"  would imply  the reviewer has no
relationship with the applicant.

--
-JH


From ras at e-gerbil.net  Sat Oct  1 15:26:21 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sat, 1 Oct 2011 14:26:21 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
Message-ID: <20111001192621.GQ49464@gerbil.cluepon.net>

On Sat, Oct 01, 2011 at 04:13:41PM +0000, John Curran wrote:
> > 
> > Ok so, your current position is that matching an example from the 
> > specifically defined list of example compelling reasons is not a 
> > compelling reason, because of an exclusionary rule which doesn't exist 
> > anywhere in the policy (namely that you can't possibly solve the problem 
> > with deaggregation) that you're making up on the spot? 
> 
> Incorrect.  If an organization can demonstrate a compelling need 
> for multiple discrete networks (along the lines of the examples),
> it can make use of the MDN policy. This is as the policy requires.

That would be fine, but how does one go about doing that? I would assume 
that one would demonstrate how their situation matches one of the 
examples in the policy, which I've already shown, but so far that hasn't 
been good enough for you. After that is done, you then come back to add 
a rule which doesn't exist in the policy that says "if you can possibly 
implement this with deaggregation instead, you don't have a compelling 
need". This language simply doesn't exist, and for good reason, because 
it would exclude almost everyone from using the MDN policy.

I have yet to see you argue anything about how a specific situation 
doesn't match one of the example compelling needs. If you did, I could 
easily explain how it does (as I tried to do in a previous e-mail, 
talking about the "geographic distance and network diversity" example), 
but that HASN'T been your objection so far, all you've had is this made 
up rule about "aggregation".

Can you please address this point? Where in the policy does it say that 
if you can solve the problem with deaggregation you don't have a 
compelling reason? If it doesn't, what is your basis for claiming that 
someone who matches on of the example compelling reasons doesn't have a 
compelling reason? Or is the arguement about the matching itself? Please 
pick one so I can figure out where your objection is and explain the 
confusion.

> Refining the examples is also an option for improving the clarity
> of the policy, but that still leaves ARIN staff having to make a 
> judgement call regarding what constitutes "compelling criteria."
> I believe that the more certain outcome would be to change the 
> policy to specifically include a clear technical definition of 
> what constitutes "multiple discrete networks" in the policy text.
> 
> Richard - Can you propose an appropriate definition of 
> "multiple discrete networks" that could be added to the 
> policy?

I would say that a discrete network is one which must implement a unique 
routing policy which is distinct from and other network, and multiple 
means there is more than one of them. There are a variety of technical 
and political reasons why someone might have a compelling reason to do 
this, such as the 3 examples specifically listed in the policy already 
(political/legal issues, geographic distance or network diversity 
needs, and discontiguous networks).

But how does this help you with ANY of the issues above?

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From jcurran at arin.net  Sat Oct  1 17:06:58 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 1 Oct 2011 21:06:58 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111001192621.GQ49464@gerbil.cluepon.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
Message-ID: <46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>

On Oct 1, 2011, at 3:26 PM, Richard A Steenbergen wrote:

>> Richard - Can you propose an appropriate definition of 
>> "multiple discrete networks" that could be added to the 
>> policy?
> 
> I would say that a discrete network is one which must implement a unique 
> routing policy which is distinct from and other network, and multiple 
> means there is more than one of them.

Looking at the proposed definition:

   Multiple = more than one network.   

This is fine; no further elaboration needed.

   Discrete = "one which must implement a unique routing policy"
               (distinct from the other networks)

How does ARIN staff determine that the network "must implement a 
unique routing policy"?  

As written, I see that this can be read as either [A] "the requestor 
must clearly show that the network is configured with routing policy 
which is unique from the others" or [B] "the requestor must show that 
the network cannot function correctly without a routing policy which 
is unique from the others"  Which of the above ([A], [B]) did you 
intend?

Thanks,
/John

John Curran
President and CEO
ARIN




From jcurran at arin.net  Sat Oct  1 17:50:12 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 1 Oct 2011 21:50:12 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAAAwwbUh_bBkOK9gmBN_OO5A-dCD3c17OcQUq4QFM6GwfYb=6Q@mail.gmail.com>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<CAAAwwbUh_bBkOK9gmBN_OO5A-dCD3c17OcQUq4QFM6GwfYb=6Q@mail.gmail.com>
Message-ID: <3547B323-F1DA-4F70-87DB-6F28E6517CD7@arin.net>

On Oct 1, 2011, at 2:59 PM, Jimmy Hess wrote:
> 
> Something needs to determine if there is a compelling reason.
> The most obvious would be a business need for discrete networks
> created by a technical requirement.
> 
> I don't think it's necessarily reasonable/possible to codify every
> feasible situation in which multiple discrete networks are called for.
> 
> This is an engineering decision which should be handled based on sound
> technical merits.

Presumably any organization which decided to deploy multiple discrete 
networks had sound technical merits to do so, so the existence of them 
under some clear definition suffices as proof of the "compelling need". 
If this is what the community wants, then a very simple change to policy 
is needed, and the administration of the policy becomes quite routine.

> Since ARIN staffs'  job is to examine the application, not to review
> technical decisions,
> Perhaps what ARIN should do is provide an option for an "independent
> technical review"
> of the merits for an organization operating discrete networks, instead
> of one network;
> where the applicant would be required to find a "reviewer"  mutually
> agreed upon by
> ARIN and the applicant,   who would then be required to perform a
> review, and submit their
> findings directly to ARIN,  keeping them confidential from the applicant.
> 
> Then instead of staff making an arbitrary judgement call;  they would
> be relying on the integrity
> of the reviewer.      "Independent"  would imply  the reviewer has no
> relationship with the applicant.

Interesting suggestion.  If the policy requires a judgement call, moving
it to a third-party doesn't change to potential for disagreement of views
between those evaluating and the requestor (and an rejected applicant need 
only reapply and seek a different reviewer)  I think there's some merit to
the approach (e.g. a panel of reviewers for appeals?) but there's a lot of
details (non-disclosures, competitive information, etc) that would need to 
be considered.

Elimination of relative judgement situations in the policy would be a far
easier solution, but it's worth thinking of various alternatives should the
policy remain as-is.

Thanks!
/John

John Curran
President and CEO
ARIN



From ras at e-gerbil.net  Sat Oct  1 18:15:38 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sat, 1 Oct 2011 17:15:38 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
Message-ID: <20111001221538.GR49464@gerbil.cluepon.net>

On Sat, Oct 01, 2011 at 09:06:58PM +0000, John Curran wrote:
> 
> Looking at the proposed definition:
> 
>    Multiple = more than one network.   
> 
> This is fine; no further elaboration needed.
> 
>    Discrete = "one which must implement a unique routing policy"
>                (distinct from the other networks)
> 
> How does ARIN staff determine that the network "must implement a 
> unique routing policy"?  

If they meet one of the existing examples for compelling reasons to use 
multiple discrete networks? I kinda figured that part was a given. :)

> As written, I see that this can be read as either [A] "the requestor 
> must clearly show that the network is configured with routing policy 
> which is unique from the others" or [B] "the requestor must show that 
> the network cannot function correctly without a routing policy which 
> is unique from the others" Which of the above ([A], [B]) did you 
> intend?

I'd say both, but again I think the policy already says this. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From JOHN at egh.com  Sat Oct  1 18:40:11 2011
From: JOHN at egh.com (John Santos)
Date: Sat, 1 Oct 2011 18:40:11 -0400
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111001192621.GQ49464@gerbil.cluepon.net>
Message-ID: <1111001182049.58216B-100000@Ives.egh.com>



I've been watching this, back and forth, with no particular concern, one 
way or the other, but now I'm confused.

Richard, are you talking about an initial assignment or allocation, or
an additional one?  Originally, I thought it was for additional space,
but now it sounds like you are talking about an initial assignment.

If initial, what difference does it make if ARIN hands out N blocks,
each of the size that one of your networks requires, or a single block
equal to the sum of the sizes?   You can parcel the individual blocks
out of the single assignment any way you want, and will be announcing
N routes, either way.  It might be advantageous to ARIN to do the 
deaggregating for you, though, since that way they might be able to
utiliize some smaller fragments, but if the discrete networks are really 
independent, it shouldn't matter to you, one way or the other.

If you are talking about expanding an existing network, I thought the
rule was the network running out of space had two be at least 80%
utilized and the aggregate had to be at least 50%.  Are saying this is the
case and they are telling you to deagregate one of the lesser-used 
networks and route some of the subnets to the 80% network?  Or are
you at less than 50%?   In the latter case, you were initially 
overallocated, and they are attempting to correct that.


On Sat, 1 Oct 2011, Richard A Steenbergen wrote:

> On Sat, Oct 01, 2011 at 04:13:41PM +0000, John Curran wrote:

[lots of stuff, back and forth]

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539



From jcurran at arin.net  Sat Oct  1 18:45:32 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 1 Oct 2011 22:45:32 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111001221538.GR49464@gerbil.cluepon.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
Message-ID: <B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>

On Oct 1, 2011, at 6:15 PM, Richard A Steenbergen wrote:

> On Sat, Oct 01, 2011 at 09:06:58PM +0000, John Curran wrote:
>> 
>> Looking at the proposed definition:
>> 
>>   Multiple = more than one network.   
>> 
>> This is fine; no further elaboration needed.
>> 
>>   Discrete = "one which must implement a unique routing policy"
>>               (distinct from the other networks)
>> 
>> How does ARIN staff determine that the network "must implement a 
>> unique routing policy"?  
> 
> If they meet one of the existing examples for compelling reasons to use 
> multiple discrete networks? I kinda figured that part was a given. :)

Richard - Hopefully, we don't need examples of compelling reasons if
a clear technical definition of "discrete networks" is added (as it 
would remove the requirement for judgement of "compelling reason")

>> As written, I see that this can be read as either [A] "the requestor 
>> must clearly show that the network is configured with routing policy 
>> which is unique from the others" or [B] "the requestor must show that 
>> the network cannot function correctly without a routing policy which 
>> is unique from the others" Which of the above ([A], [B]) did you 
>> intend?
> 
> I'd say both, but again I think the policy already says this. :)

[A] is a simple matter of fact, i.e. show networks with unique routing
policies.

[B] still requires judgement, i.e. explain why the networks must have 
unique routing policies in order for the networks to operate "correctly".  
It is clearer than present policy since it would have a clear definition
that equates discrete networks as networks with unique routing policies, 
but wouldn't eliminate the need for judging whether or not the use of 
those unique routing polices was truly necessary.

Using [A], if a definition of "Multiple Discrete Networks" is added to 
read: "Multiple networks are networks with unique routing policies",
then the criteria could be greatly simplified to simply show presence
of multiple discrete networks.

Note: I have no idea whether the community wants either change, 
but suggest you propose either one, should it better meet your 
needs.    Details on submitting a policy proposal are here: 
https://www.arin.net/policy/pdp_appendix_b.html

Thanks!
/John

John Curran
President and CEO
ARIN



From ras at e-gerbil.net  Sat Oct  1 19:05:32 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sat, 1 Oct 2011 18:05:32 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
Message-ID: <20111001230532.GS49464@gerbil.cluepon.net>

On Sat, Oct 01, 2011 at 10:45:32PM +0000, John Curran wrote:
> > If they meet one of the existing examples for compelling reasons to use 
> > multiple discrete networks? I kinda figured that part was a given. :)
> 
> Richard - Hopefully, we don't need examples of compelling reasons if
> a clear technical definition of "discrete networks" is added (as it 
> would remove the requirement for judgement of "compelling reason")

Er, yes you do... Discrete networks is a state, not a reason. The 
current policy says you need to demonstrate a) that you are using them 
(the same A you were talking about in your other question) and b) that 
you have a compelling reason to run them (the same B). Nothing in the 
definition of discrete network affects this in any way!

> [B] still requires judgement, i.e. explain why the networks must have 
> unique routing policies in order for the networks to operate 
> "correctly".  It is clearer than present policy since it would have a 
> clear definition that equates discrete networks as networks with 
> unique routing policies, but wouldn't eliminate the need for judging 
> whether or not the use of those unique routing polices was truly 
> necessary.
 
Correct, B is a judgement call. Fortunately there is a specific list of 
example compelling reasons already in the policy, so it is the job of 
the applicant to show that they meet one of those examples.

Is THIS now the point of contention? It seem like we're just running 
around in circls through a series of non sequitur objections. I'd really 
like to arrive at a concrete objection that I can actually argue, before 
we get to "arin doesn't really know what the meaning of the word is is" 
or something. :)

> Note: I have no idea whether the community wants either change, but 
> suggest you propose either one, should it better meet your needs.  
> Details on submitting a policy proposal are here: 
> https://www.arin.net/policy/pdp_appendix_b.html

Again, I'm not proposing any changes, I'm suggesting that you are 
massively confused about the meaning of the perfectly good words which 
are already in place. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From jcurran at arin.net  Sat Oct  1 20:07:43 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 2 Oct 2011 00:07:43 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111001230532.GS49464@gerbil.cluepon.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
Message-ID: <0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>

On Oct 1, 2011, at 7:05 PM, Richard A Steenbergen wrote:

> On Sat, Oct 01, 2011 at 10:45:32PM +0000, John Curran wrote:
>> Richard - Hopefully, we don't need examples of compelling reasons if
>> a clear technical definition of "discrete networks" is added (as it 
>> would remove the requirement for judgement of "compelling reason")
> 
> Er, yes you do... Discrete networks is a state, not a reason.

Correct.  I was pointing out that if the policy is changed to 
simply require a well-defined "state" then no examples would be 
needed.  If the policy is only changed to equate "discrete" 
networks to "networks with unique routing policies", then there
would still need to judgement regarding whether there was a
compelling need for the networks to have unique routing policies.

> The current policy says you need to demonstrate a) that you are using them 
> (the same A you were talking about in your other question) and b) that 
> you have a compelling reason to run them (the same B).  Nothing in the 
> definition of discrete network affects this in any way!

The current policy says "multiple discrete networks" not "networks 
with unique routing policies"  You've asserted that they are the 
same and that is not the case accordingly to the current policy.

Networks that cannot readily reallocate their existing allocations 
(for compelling reasons such as those shown in the examples, e.g.
regulatory restrictions on interconnection, geographic restrictions, 
being discontiguous or those that are autonomous by nature) have been 
judged to be "discrete networks".  Organizations that acknowledge
that they can readily reallocate their existing allocations across
interconnected network infrastructure have been determined NOT to
have "multiple discrete networks", even if such reallocation would 
result in a routing impact.

> Correct, B is a judgement call. Fortunately there is a specific list of 
> example compelling reasons already in the policy, so it is the job of 
> the applicant to show that they meet one of those examples.

Agreed.  I'd prefer policy that is defined on a clear factual state as 
opposed to judgement calls, since there it makes for more predictable
outcomes for applicants. However, we will continue to administer per the 
examples in the existing policy text, even if requires judgement calls 
to be made with regard to what constitutes "multiple discrete networks."

Thanks!
/John

John Curran
President and CEO
ARIN




From owen at delong.com  Sun Oct  2 01:08:26 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 1 Oct 2011 22:08:26 -0700
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111001051104.GN49464@gerbil.cluepon.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<3ACA6282-FE1E-473C-A352-77AFF263332D@delong.com>
	<20110929211048.GR49464@gerbil.cluepon.net>
	<47735537-C06C-4BD9-82C4-1B521F5104F1@arin.net>
	<20110930215833.GJ49464@gerbil.cluepon.net>
	<8D4BE984-E6AF-4781-A3B7-DB76D31276BE@arin.net>
	<20111001022043.GK49464@gerbil.cluepon.net>
	<393C370D-93D0-425B-BDFF-9DB916B52307@arin.net>
	<20111001051104.GN49464@gerbil.cluepon.net>
Message-ID: <5BA4EA87-EF23-4951-BA69-4AA44F9D4B2D@delong.com>


On Sep 30, 2011, at 10:11 PM, Richard A Steenbergen wrote:

> On Sat, Oct 01, 2011 at 03:15:20AM +0000, John Curran wrote:
>> 
>> I did not say that it has no effect on aggregation.  I said that the 
>> point of the policy is not to improve aggregation; the policy exists 
>> to allow organizations to readily obtain address space as a single 
>> organization under criteria applicable when there are multiple 
>> discrete networks for a compelling reason.
> ...
>> I'd recommend either redefining "multiple discrete networks" to have a 
>> clear technical definition in the policy, or refining the existing 
>> examples so one of them directly meets your specific needs (e.g. 
>> removal of the term "autonomous" or changing it to an AS reference 
>> instead.)
> 
> Ok, let me see if I can summarize this.
> 
> You're saying that if someone has a compelling reason for running 
> multiple discrete networks, it means that they are incapable of 
> announcing their single allocation as an aggregate, and therefore need 
> the MDN policy to provide multiple blocks which they CAN announce as 
> aggregates.
> 
I believe that if MDN allocations are aggregable, that is a chance coincidence
and not a specific effect that ARIN strives for. Perhaps this is where you
are misunderstanding the situation in assuming that ARIN always issues
aggergable blocks to MDNs?

> You then go on to say that if someone benefits from the aggregation 
> being provided in the previous statement, since aggregation is not an 
> intended effect of the policy they therefore don't qualify to use it.
> 

Since your first statement doesn't accurately reflect the situation, this
statement is a fundamentally flawed conclusion as a result.

> Do you not see the circular logic here? I feel like I need to flowchart 
> this or something. :)
> 

I don't see it as circular, though I could sort of see that if your initial
assumption had been correct.

Owen



From owen at delong.com  Sun Oct  2 01:14:00 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 1 Oct 2011 22:14:00 -0700
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
Message-ID: <2BA07195-4F2C-4F67-AAB6-EECEA4E89F11@delong.com>

If the networks can be announced in an aggregate, then, they are
not discrete in the meaning of the policy.

Owen

On Oct 1, 2011, at 5:58 AM, Jimmy Hess wrote:

> On Thu, Sep 29, 2011 at 3:02 PM, John Curran <jcurran at arin.net> wrote:
>> On Sep 29, 2011, at 9:59 PM, Richard A Steenbergen <ras at e-gerbil.net> wrote:
>>> I'd very much like to see something done about this, either through the
>> For avoidance of doubt, I suggested to Richard that he raise this matter on the PPML or at the Open Policy Hour in Philly, so that the community could consider if policy changes are needed in this area.
> 
> I do not see a change required in the MDN policy.  ARIN staff should
> apply the policy as written not make a determination that the
> applicant "Doesn't NEED" to use a certain policy;  if the applicant
> WANTs to apply the policy, when they meet the stated criteria for the
> policy, and their application of the policy is reasonable, they should
> be allowed to do so.
> 
> If the MDN policy is available, and the applicant meets all the
> criteria in the MDN policy, the applicant should be eligible to the
> allocation of discrete networks under the policy,
> specifically:
> 
> '"well yes technically I could always just break up my single ARIN
> allocation into a bunch of individual /24s for use by each discrete
> network" '
> 
> Is not a valid reasoning to refuse to apply the MDN policy;  the MDN
> policy doesn't contain any statement that allows ARIN staff to refuse
> to apply it for that reason alone.
> 
> A valid reasoning for refusing to apply the MDN policy would be one of
> the following:
> 
> 1. The organization is actually a group or consortium of multiple entities.
> 2. The organization does not have a satisfactorily compelling criteria
> for creating multiple discrete networks.
> 3. The organization has failed to keep detailed records for each
> discrete network or won't agree to do so on receiving their initial
> allocation.
> 4. The organization fails to demonstrate utilization of 50% or more of
> the last block allocated and the aggregate sum of all blocks.
> 5. The organization has existing blocks for one of the networks that
> is not 80% utilized at that location
> 6.  The organization has not asked ARIN to apply the MDN policy for
> their application.
> 
> 
>> FYI,
>> /John
> --
> -JH
> _______________________________________________
> 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  Sun Oct  2 01:29:41 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 1 Oct 2011 22:29:41 -0700
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
Message-ID: <62E31486-99E8-4DF6-8250-5CE1529C3C74@delong.com>


On Oct 1, 2011, at 2:06 PM, John Curran wrote:

> On Oct 1, 2011, at 3:26 PM, Richard A Steenbergen wrote:
> 
>>> Richard - Can you propose an appropriate definition of 
>>> "multiple discrete networks" that could be added to the 
>>> policy?
>> 
>> I would say that a discrete network is one which must implement a unique 
>> routing policy which is distinct from and other network, and multiple 
>> means there is more than one of them.
> 
> Looking at the proposed definition:
> 
>   Multiple = more than one network.   
> 
> This is fine; no further elaboration needed.
> 
>   Discrete = "one which must implement a unique routing policy"
>               (distinct from the other networks)
> 
> How does ARIN staff determine that the network "must implement a 
> unique routing policy"?  
> 
> As written, I see that this can be read as either [A] "the requestor 
> must clearly show that the network is configured with routing policy 
> which is unique from the others" or [B] "the requestor must show that 
> the network cannot function correctly without a routing policy which 
> is unique from the others"  Which of the above ([A], [B]) did you 
> intend?
> 

FWIW, B is more in line with the original intent of the policy as I recall.

I would also support B as the more correct approach, since applying
the MDN criteria to networks in situation A would cause unnecessary
disaggregation.

Owen



From mysidia at gmail.com  Sun Oct  2 12:59:16 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 2 Oct 2011 11:59:16 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <2BA07195-4F2C-4F67-AAB6-EECEA4E89F11@delong.com>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<2BA07195-4F2C-4F67-AAB6-EECEA4E89F11@delong.com>
Message-ID: <CAAAwwbWyLFd9oB7kDWBFOXt_EKQ5Ta7nOvkw5Km0By2KSRsBSg@mail.gmail.com>

On Sun, Oct 2, 2011 at 12:14 AM, Owen DeLong <owen at delong.com> wrote:
> If the networks can be announced in an aggregate, then, they are
> not discrete in the meaning of the policy.

I would say networks are not discrete if they  _ARE_ announced as an aggregate.
Networks that are not announced as an aggregate but could be are still discrete.

The question to the operator should be in that case...  do you have a
compelling reason that they are not announced  as an aggregate?

If the networks are not interconnected,   then  that would be a reason
they should not be announced as an aggregate.    The  operator  should
then have a compelling reason that they haven't built a tunnel or
interconnected the  two networks.

If purchasing an additional link to connect the two networks is an
option, perhaps they should be denied the option of utilizing the MDN
policy.

> Owen
--
-JH


From ras at e-gerbil.net  Sun Oct  2 17:02:24 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sun, 2 Oct 2011 16:02:24 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
References: <CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
Message-ID: <20111002210224.GT49464@gerbil.cluepon.net>

On Sun, Oct 02, 2011 at 12:07:43AM +0000, John Curran wrote:
> 
> Correct.  I was pointing out that if the policy is changed to simply 
> require a well-defined "state" then no examples would be needed.  If 
> the policy is only changed to equate "discrete" networks to "networks 
> with unique routing policies", then there would still need to 
> judgement regarding whether there was a compelling need for the 
> networks to have unique routing policies.

Uhm... How could you possibly propose to change the definition of a 
discrete network to eliminate the need to justify using them? These two 
things have absolutely nothing to do with each other, this is a total 
non sequitur.

> The current policy says "multiple discrete networks" not "networks 
> with unique routing policies" You've asserted that they are the same 
> and that is not the case accordingly to the current policy.

You asked for an explicit definition and I gave you a perfectly sensible 
one. Are you now claiming that this policy can't be applied because 
nobody knows what a discrete network is? Why not, I guess it's the only 
possible argument left which hasn't already been defeated.

I suppose we could start with the context provided by the policy itself, 
which says:

> Some organizations have requirements for multiple discrete networks 
> that need individual address allocations. Discrete networks must often 
> have separate unique globally routable address space and will often 
> grow at different rates. In order for organizations with multiple 
> discrete networks to request additional address space under a single 
> maintainer ID, the organization must use the following criteria:

So far we know that whatever they are, they must often have separate 
unique global routable address space, and will often grow at different 
rates. Any why might an organization need separate unique globally 
routable address space which can grow at a different rate? The ONLY 
benefit to this would be if they are required to implement unique 
routing policies for each discrete network, and thus require unique 
globally routable address space to do so. If you have another 
explanation, I'm all ears. Otherwise, I'm going to say that this acts as 
the basis for defining what they are, multiple networks which must 
implement unique routing policies.

The policy then goes on to say that you need to have a good reason for 
doing so:

> The organization must have compelling criteria for creating discrete 
> networks. Examples:
> * regulatory restrictions for data transmission
> * geographic distance and diversity between networks
> * autonomous multi-homed discrete networks

These three specific examples are all reasons why one may need to 
implement unique routing policies. One assumes that if you situation can 
be shown to match one of the example "compelling reasons" for doing 
this, and if you have a need for separate unique globally routable 
address space which grows at different rates, you would infact be able 
to use the $%^&ing policy that says these exact words!

> Networks that cannot readily reallocate their existing allocations 
> (for compelling reasons such as those shown in the examples, e.g. 
> regulatory restrictions on interconnection, geographic restrictions, 
> being discontiguous or those that are autonomous by nature) have been 
> judged to be "discrete networks".  Organizations that acknowledge that 
> they can readily reallocate their existing allocations across 
> interconnected network infrastructure have been determined NOT to have 
> "multiple discrete networks", even if such reallocation would result 
> in a routing impact.

Again, you're adding an exclusion which DOES NOT EXIST IN THE POLICY. 
The policy doesn't say ANYTHING about this, but what it does do is list 
some problems, state some requirements, and then provide a solution. If 
your problem matches the example problems, and you have a good reason to 
do it which matches the requirements, then how does ARIN possibly 
justify adding random new exclusions which don't exist in the policy?

Or, let me try another approach. If this is really the position you want 
to take, I hearby call on ARIN to apply the (newly invented) rules 
consistently, and stop giving out allocations under the multiple 
discrete network policy to anyone who could potentially solve their need 
to implement unique routing policies with deaggregation. I believe this 
will exclude almost everyone, including the #1 example "intended user" 
that keeps getting cited, someone with two or more physically 
discontiguous networks. Unless they have some other random situation, 
like not being able to work swip because of a bizaare corporate 
structure as you've been trying to point out in the past, they should 
clearly be able to solve this with deaggregation and thus no longer 
qualify. Does that seem sensible to you?

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From ras at e-gerbil.net  Sun Oct  2 17:12:57 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sun, 2 Oct 2011 16:12:57 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <5BA4EA87-EF23-4951-BA69-4AA44F9D4B2D@delong.com>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<3ACA6282-FE1E-473C-A352-77AFF263332D@delong.com>
	<20110929211048.GR49464@gerbil.cluepon.net>
	<47735537-C06C-4BD9-82C4-1B521F5104F1@arin.net>
	<20110930215833.GJ49464@gerbil.cluepon.net>
	<8D4BE984-E6AF-4781-A3B7-DB76D31276BE@arin.net>
	<20111001022043.GK49464@gerbil.cluepon.net>
	<393C370D-93D0-425B-BDFF-9DB916B52307@arin.net>
	<20111001051104.GN49464@gerbil.cluepon.net>
	<5BA4EA87-EF23-4951-BA69-4AA44F9D4B2D@delong.com>
Message-ID: <20111002211257.GU49464@gerbil.cluepon.net>

On Sat, Oct 01, 2011 at 10:08:26PM -0700, Owen DeLong wrote:
> 
> > You're saying that if someone has a compelling reason for running 
> > multiple discrete networks, it means that they are incapable of 
> > announcing their single allocation as an aggregate, and therefore need 
> > the MDN policy to provide multiple blocks which they CAN announce as 
> > aggregates.
>
> I believe that if MDN allocations are aggregable, that is a chance 
> coincidence and not a specific effect that ARIN strives for. Perhaps 
> this is where you are misunderstanding the situation in assuming that 
> ARIN always issues aggergable blocks to MDNs?

I was specifically referencing something John said earlier, but ok lets 
assume for the moment that your statement is entirely true (as I'm not 
particularly interested in trying to figure out the specific effects 
that ARIN strives for, just in how to get them to stop making excuses 
for not honoring the policy as written :P).

If you have a need which matches the one the policy specifically says it 
is trying to address (the need for unique globally routable address 
space which grows at different rates), and you match the example 
compelling reasons for this, and you match all of the other requirements 
as stated in the policy, what possible justification is there for 
excluding users of the policy who DO happen to obtain aggregation 
benefits as well?

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From jcurran at arin.net  Sun Oct  2 17:18:33 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 2 Oct 2011 21:18:33 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111002210224.GT49464@gerbil.cluepon.net>
References: <CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
Message-ID: <24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>

On Oct 2, 2011, at 5:02 PM, Richard A Steenbergen wrote:

>> The current policy says "multiple discrete networks" not "networks 
>> with unique routing policies" You've asserted that they are the same 
>> and that is not the case accordingly to the current policy.
> 
> You asked for an explicit definition and I gave you a perfectly sensible 
> one.

Richard - 

If you'd like that definition used, then I suggest submission into 
the policy process.

>> Networks that cannot readily reallocate their existing allocations 
>> (for compelling reasons such as those shown in the examples, e.g. 
>> regulatory restrictions on interconnection, geographic restrictions, 
>> being discontiguous or those that are autonomous by nature) have been 
>> judged to be "discrete networks".  Organizations that acknowledge that 
>> they can readily reallocate their existing allocations across 
>> interconnected network infrastructure have been determined NOT to have 
>> "multiple discrete networks", even if such reallocation would result 
>> in a routing impact.
> 
> Again, you're adding an exclusion which DOES NOT EXIST IN THE POLICY. 
> The policy doesn't say ANYTHING about this ...

Alas, the policy makes clear that there must be a compelling need.

Thanks,
/John

John Curran
President and CEO
ARIN





From ras at e-gerbil.net  Sun Oct  2 17:20:32 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sun, 2 Oct 2011 16:20:32 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAAAwwbWyLFd9oB7kDWBFOXt_EKQ5Ta7nOvkw5Km0By2KSRsBSg@mail.gmail.com>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<2BA07195-4F2C-4F67-AAB6-EECEA4E89F11@delong.com>
	<CAAAwwbWyLFd9oB7kDWBFOXt_EKQ5Ta7nOvkw5Km0By2KSRsBSg@mail.gmail.com>
Message-ID: <20111002212031.GV49464@gerbil.cluepon.net>

On Sun, Oct 02, 2011 at 11:59:16AM -0500, Jimmy Hess wrote:
> The question to the operator should be in that case...  do you have a 
> compelling reason that they are not announced as an aggregate?

Please see my previous email about this, one of the compelling reasons 
listed in the policy specifically addresses why an operator might need 
to not announce it as an aggregate. :)

http://lists.arin.net/pipermail/arin-ppml/2011-September/023251.html

> Lets consider the example "geographic distance and diversity between 
> networks", which is specifically listed as a compelling reason. The 
> geographic diversity angle seems simple enough, if a network has (for 
> example) a presence in Miami and a presence in Seattle, it could be 
> quite sensible for them to operate these two regions as discrete 
> networks in order to ensure optimal routing. Similarly, it would be 
> quite reasonable to assume that they may need/want diverse transit 
> providers in each region (e.g. buy from someone in Seattle who doesn't 
> have a presence in Miami, and vice versa), which would also require 
> operating as discrete networks.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From ras at e-gerbil.net  Sun Oct  2 17:38:15 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sun, 2 Oct 2011 16:38:15 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
References: <20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
Message-ID: <20111002213815.GW49464@gerbil.cluepon.net>

On Sun, Oct 02, 2011 at 09:18:33PM +0000, John Curran wrote:
> 
> Alas, the policy makes clear that there must be a compelling need.

For the record, the policy says absolutely nothing about a compelling 
need. It lists some examples of why some organizations require multiple 
discrete networks, says that you need to prove a compelling reason for 
doing it, and has a states a bunch of of other requirements which must 
be met to use the policy. If all of these line up, I fail to understand 
how you can exclude an organization based on a requirement which DOESN'T 
exist in the policy. You've also refused to address the point that if 
this rule was actually applied anywhere else, it would exclude almost 
every other applicant.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From mysidia at gmail.com  Sun Oct  2 17:39:23 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 2 Oct 2011 16:39:23 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
Message-ID: <CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>

n Sat, Oct 1, 2011 at 7:07 PM, John Curran <jcurran at arin.net> wrote:
[snip]
> that they can readily reallocate their existing allocations across
> interconnected network infrastructure have been determined NOT to
> have "multiple discrete networks", even if such reallocation would
> result in a routing impact.

The determination is flawwed.   First of all, it's not mentioned in
the policy that
"networks that are capable of readily reallocating their existing
allocations across interconnected
network infrastructure with routing impact"    are to be considered
non-discrete.

If the applicant can determine that their networks are discrete based
on the criteria
for operating discrete networks, then their networks are discrete,
regardless of the
technical possibility of reallocating existing allocations.

Second,   just because it's technically feasible for "existing
allocations to be reallocated"
across interconnected network infrastructure,  does not mean it would
be appropriate
to do so.  There may be a performance or cost impact that causes this
to be extremely
problematic.     There may be a reliability impact with regards to the
operator's network
design, and survivability requirements,   there might be legal issues, etc.


Third....    there's really no such thing as a network that would not
be able to readily reallocate their existing allocations  with routing
impact.

"Build a tunnel"    (with routing impact), and any discrete network becomes
interconnected,  as long as both networks have indirect connectivity.

--
-JH


From jcurran at arin.net  Sun Oct  2 17:51:13 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 2 Oct 2011 21:51:13 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111002211257.GU49464@gerbil.cluepon.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<3ACA6282-FE1E-473C-A352-77AFF263332D@delong.com>
	<20110929211048.GR49464@gerbil.cluepon.net>
	<47735537-C06C-4BD9-82C4-1B521F5104F1@arin.net>
	<20110930215833.GJ49464@gerbil.cluepon.net>
	<8D4BE984-E6AF-4781-A3B7-DB76D31276BE@arin.net>
	<20111001022043.GK49464@gerbil.cluepon.net>
	<393C370D-93D0-425B-BDFF-9DB916B52307@arin.net>
	<20111001051104.GN49464@gerbil.cluepon.net>
	<5BA4EA87-EF23-4951-BA69-4AA44F9D4B2D@delong.com>
	<20111002211257.GU49464@gerbil.cluepon.net>
Message-ID: <2506369E-3808-45C2-91B2-840B6F73C658@arin.net>

On Oct 2, 2011, at 5:12 PM, Richard A Steenbergen wrote:

> I was specifically referencing something John said earlier, but ok lets 
> assume for the moment that your statement is entirely true (as I'm not 
> particularly interested in trying to figure out the specific effects 
> that ARIN strives for, just in how to get them to stop making excuses 
> for not honoring the policy as written :P).

Richard - 

ARIN implements the policy as written, but it is true that the
implementation does not match your desired use of the policy. 

You have said: 

    "The problem is that ARIN doesn't believe "promoting 
     routing aggregation on the Internet" is a stated goal
     of this policy,"

    "At the end of the day, I can't think of anything else 
     that is actually being accomplished by this policy 
     EXCEPT maintaining reasonable aggregation for 
     aggregation purposes."

Both of these statements have been shown to be incorrect; the goal 
of the policy has never been the avoidance of deaggregation - the
policy was proposed to provide an acceptable mechanism for those
organization which had multiple discrete networks growing at 
different rates and were making use of multiple maintainer ids as 
a workaround. These organizations frequently had compelling reasons 
that precluded them readily sharing a single address pool among 
their multiple networks, and hence the examples of compelling 
reasons listed in the policy.

You have repeatedly suggested that maintaining reasonable route
aggregation should be considering a goal of the policy and hence 
a compelling reason for maintaining multiple discrete networks.
That may desirable, but IT DOES NOT MATCH THE PRESENT POLICY, and 
hence my suggestion that you propose a policy change on the PPML 
mailing list; e.g. you might propose the addition of an example
for "maintaining routing aggregation" and then the policy would 
likely function just as you desire.   Note - I do not know if 
this would be considered desirable by the community, but that 
would be quickly be revealed via the policy development process.

Thanks,
/John

John Curran
President and CEO
ARIN



From jcurran at arin.net  Sun Oct  2 17:57:57 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 2 Oct 2011 21:57:57 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
Message-ID: <18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>

On Oct 2, 2011, at 5:39 PM, Jimmy Hess wrote:

> n Sat, Oct 1, 2011 at 7:07 PM, John Curran <jcurran at arin.net> wrote:
> [snip]
>> that they can readily reallocate their existing allocations across
>> interconnected network infrastructure have been determined NOT to
>> have "multiple discrete networks", even if such reallocation would
>> result in a routing impact.
> 
> The determination is flawwed.   First of all, it's not mentioned in
> the policy that
> "networks that are capable of readily reallocating their existing
> allocations across interconnected
> network infrastructure with routing impact"    are to be considered
> non-discrete.

Jimmy - Read the policy text. There is no definition of a _discrete_
network contained therein.  It's fairly easy to distinguish some
discrete networks from the examples, but it is not clear at all 
how interconnected network infrastructure qualifies as "discrete".

> If the applicant can determine that their networks are discrete based
> on the criteria
> for operating discrete networks, then their networks are discrete,
> regardless of the
> technical possibility of reallocating existing allocations.

Correct, as I note above.

> Second,   just because it's technically feasible for "existing
> allocations to be reallocated"
> across interconnected network infrastructure,  does not mean it would
> be appropriate
> to do so.  There may be a performance or cost impact that causes this
> to be extremely
> problematic.     There may be a reliability impact with regards to the
> operator's network
> design, and survivability requirements,   there might be legal issues, etc.

Exactly, and we ask exactly those type of questions searching for a
compelling need for their treatment of their interconnected network 
infrastructure as "multiple discrete networks".

Thanks,
/John

John Curran
President and CEO
ARIN



From kevinb at thewire.ca  Sun Oct  2 22:32:18 2011
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Mon, 3 Oct 2011 02:32:18 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
	<18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>
Message-ID: <7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>

John,

I've been following this thread and a couple questions come to mind.

1) In the case of a dispute between ARIN and a member what recourse mechanism is there?
2) How many times has this policy been accepted/rejected in the past 2 years? 

If I had  a scenario like this:

Toronto
Diverse Paths

Calgary
Diverse Paths

Would the MDN policy apply? If I decided later on to add an interconnection to move certain traffic
between the cities would the MDN policy still apply?

Kevin Blumberg
T 416.214.9473 x31
F 416.862.9473
kevinb at thewire.ca  

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran
Sent: Sunday, October 02, 2011 5:58 PM
To: Jimmy Hess
Cc: arin-ppml at arin.net List
Subject: Re: [arin-ppml] ARIN Multiple Discrete Networks Policy

On Oct 2, 2011, at 5:39 PM, Jimmy Hess wrote:

> n Sat, Oct 1, 2011 at 7:07 PM, John Curran <jcurran at arin.net> wrote:
> [snip]
>> that they can readily reallocate their existing allocations across 
>> interconnected network infrastructure have been determined NOT to 
>> have "multiple discrete networks", even if such reallocation would 
>> result in a routing impact.
> 
> The determination is flawwed.   First of all, it's not mentioned in
> the policy that
> "networks that are capable of readily reallocating their existing 
> allocations across interconnected
> network infrastructure with routing impact"    are to be considered
> non-discrete.

Jimmy - Read the policy text. There is no definition of a _discrete_ network contained therein.  It's fairly easy to distinguish some discrete networks from the examples, but it is not clear at all how interconnected network infrastructure qualifies as "discrete".

> If the applicant can determine that their networks are discrete based 
> on the criteria for operating discrete networks, then their networks 
> are discrete, regardless of the technical possibility of reallocating 
> existing allocations.

Correct, as I note above.

> Second,   just because it's technically feasible for "existing
> allocations to be reallocated"
> across interconnected network infrastructure,  does not mean it would 
> be appropriate to do so.  There may be a performance or cost impact 
> that causes this to be extremely
> problematic.     There may be a reliability impact with regards to the
> operator's network
> design, and survivability requirements,   there might be legal issues, etc.

Exactly, and we ask exactly those type of questions searching for a compelling need for their treatment of their interconnected network infrastructure as "multiple discrete networks".

Thanks,
/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 jcurran at arin.net  Sun Oct  2 23:35:50 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Oct 2011 03:35:50 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
	<18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>
	<7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>
Message-ID: <507CAF29-9D57-4FB7-B957-3B3E4BB8035B@arin.net>

On Oct 2, 2011, at 10:32 PM, Kevin Blumberg wrote:

> John,
> 
> I've been following this thread and a couple questions come to mind.
> 
> 1) In the case of a dispute between ARIN and a member what recourse mechanism is there?

The member first gets to ask for a review by the Chief Operating Officer.
THe COO confirms that the request was handled consistent with all other
requests received under the same policy section.  If the request is still
denied, the member can appeal.

First portion of the appeal is done by the CEO (me) and consists of the
same process followed by the COO, but additionally involves reviewing the
procedures used to process the request to see if they correctly implement
language and intent.  If this does not resolve the situation, then the
member has the option of formal arbitration per their RSA agreement.
<https://www.arin.net/resources/resource_requests/appeal_process.html>

> 2) How many times has this policy been accepted/rejected in the past 2 years? 

I do not know the stats offhand, but can obtain them.

> If I had  a scenario like this:
> 
> Toronto
> Diverse Paths
> 
> Calgary
> Diverse Paths
> 
> Would the MDN policy apply? If I decided later on to add an interconnection to move certain traffic
> between the cities would the MDN policy still apply?

Hypothetical situations generally need a lot more information, 
but I will endeavor to do so with the information supplied - 

If you have two completely separate networks, then the MDN 
determination of compelling reason for them being discrete is
trivial and you would be approved.  If you dded a backbone 
between them, then you would be asked whether you can readily 
reallocate the space to the network that is running low and 
needs more.  If you indicated that you could do that (because 
of the interconnection via your backbone), and have no compelling 
reason for running discrete networks then you would be informed 
that you do not qualify under the MDN policy.

That's generally how it would be handled; obviously, an actual
answer is based on the details of any specific request.

Thanks!
/John

John Curran
President and CEO
ARIN



From owen at delong.com  Mon Oct  3 03:00:30 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Oct 2011 00:00:30 -0700
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAAAwwbWyLFd9oB7kDWBFOXt_EKQ5Ta7nOvkw5Km0By2KSRsBSg@mail.gmail.com>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<2BA07195-4F2C-4F67-AAB6-EECEA4E89F11@delong.com>
	<CAAAwwbWyLFd9oB7kDWBFOXt_EKQ5Ta7nOvkw5Km0By2KSRsBSg@mail.gmail.com>
Message-ID: <CD6E5ECC-BC9B-429E-A2DB-9FE44214B191@delong.com>


On Oct 2, 2011, at 9:59 AM, Jimmy Hess wrote:

> On Sun, Oct 2, 2011 at 12:14 AM, Owen DeLong <owen at delong.com> wrote:
>> If the networks can be announced in an aggregate, then, they are
>> not discrete in the meaning of the policy.
> 
> I would say networks are not discrete if they  _ARE_ announced as an aggregate.
> Networks that are not announced as an aggregate but could be are still discrete.
> 
> The question to the operator should be in that case...  do you have a
> compelling reason that they are not announced  as an aggregate?
> 

Now we're getting into subtle flavors of the difference between can and cannot.

If there's a compelling reason not to announce them as an aggregate, they are
discrete. If there is not a compelling reason, then, they are not discrete.

> If the networks are not interconnected,   then  that would be a reason
> they should not be announced as an aggregate.    The  operator  should
> then have a compelling reason that they haven't built a tunnel or
> interconnected the  two networks.
> 

Even with a tunnel, it's still compelling IMHO. I can't imagine a scenario
where I'd want to accept traffic for network B at site A only to ship it across
a tunnel to site B. Basically discrete networks are networks which are either
A: Not connected by an interior backbone
or B: Connected by an interior backbone that is insufficient for passing the
	level of traffic expected to be received via the internet.

If the two networks can share a common routing policy, then, they are not
discrete.

> If purchasing an additional link to connect the two networks is an
> option, perhaps they should be denied the option of utilizing the MDN
> policy.

I disagree. This would constitute ARIN wading into the business decisions
and inflicting cost structures on organizations which are, IMHO, not
within the purview of ARIN policy.

Owen



From owen at delong.com  Mon Oct  3 03:10:06 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Oct 2011 00:10:06 -0700
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111002213815.GW49464@gerbil.cluepon.net>
References: <20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
Message-ID: <0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>


On Oct 2, 2011, at 2:38 PM, Richard A Steenbergen wrote:

> On Sun, Oct 02, 2011 at 09:18:33PM +0000, John Curran wrote:
>> 
>> Alas, the policy makes clear that there must be a compelling need.
> 
> For the record, the policy says absolutely nothing about a compelling 
> need. It lists some examples of why some organizations require multiple 

Um... Here's the policy:

4.5. Multiple Discrete Networks

Organizations with multiple discrete networks desiring to request new or additional address space under a single Organization ID must meet the following criteria:
The organization shall be a single entity and not a consortium of smaller independent entities.
The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include:
Regulatory restrictions for data transmission,
Geographic distance and diversity between networks,
Autonomous multihomed discrete networks.
The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation.
When applying for additional internet address registrations from ARIN, the organization must demonstrate utilization greater than 50% of both the last block allocated and the aggregate sum of all blocks allocated from ARIN to that organization. If an organization is unable to satisfy this 50% minimum utilization criteria, the organization may alternatively qualify for additional internet address registrations by having all unallocated blocks of addresses smaller than ARIN's current minimum allocation size.
The organization may not allocate additional address space to a location until each of that location's address blocks are 80% utilized.
The organization should notify ARIN at the time of the request their desire to apply this policy to their account.


I've added just a little emphasis and increased the font size of 4.5.2 in the hopes that it will allow you to see the part of the policy you apparently failed to read.


> discrete networks, says that you need to prove a compelling reason for 
> doing it, and has a states a bunch of of other requirements which must 
> be met to use the policy. If all of these line up, I fail to understand 

Admittedly, it uses the word criteria instead of reason, but, I think picking
apart the synonyms really isn't necessary. The meaning seems relatively
clear to me and it indicates that you need a compelling reason (criteria)
for not giving the networks a common routing policy.

> how you can exclude an organization based on a requirement which DOESN'T 
> exist in the policy. You've also refused to address the point that if 
> this rule was actually applied anywhere else, it would exclude almost 
> every other applicant.
> 

Since the requirement does exist in the policy, QED, the rest is specious.

Owen

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

From owen at delong.com  Mon Oct  3 03:18:14 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Oct 2011 00:18:14 -0700
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
	<18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>
	<7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>
Message-ID: <BA0B16DF-92A3-4466-B3BE-8951A44D25FE@delong.com>


On Oct 2, 2011, at 7:32 PM, Kevin Blumberg wrote:

> John,
> 
> I've been following this thread and a couple questions come to mind.
> 
> 1) In the case of a dispute between ARIN and a member what recourse mechanism is there?
> 2) How many times has this policy been accepted/rejected in the past 2 years? 
> 
> If I had  a scenario like this:
> 
> Toronto
> Diverse Paths
> 
> Calgary
> Diverse Paths
> 
> Would the MDN policy apply? If I decided later on to add an interconnection to move certain traffic
> between the cities would the MDN policy still apply?
> 

In my experience using this policy:

1.	Yes.
2.	Yes, if the interconnect was not of sufficient bandwidth to carry the full
	internet-derived load from A to B or vice versa.

Owen

> Kevin Blumberg
> T 416.214.9473 x31
> F 416.862.9473
> kevinb at thewire.ca  
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran
> Sent: Sunday, October 02, 2011 5:58 PM
> To: Jimmy Hess
> Cc: arin-ppml at arin.net List
> Subject: Re: [arin-ppml] ARIN Multiple Discrete Networks Policy
> 
> On Oct 2, 2011, at 5:39 PM, Jimmy Hess wrote:
> 
>> n Sat, Oct 1, 2011 at 7:07 PM, John Curran <jcurran at arin.net> wrote:
>> [snip]
>>> that they can readily reallocate their existing allocations across 
>>> interconnected network infrastructure have been determined NOT to 
>>> have "multiple discrete networks", even if such reallocation would 
>>> result in a routing impact.
>> 
>> The determination is flawwed.   First of all, it's not mentioned in
>> the policy that
>> "networks that are capable of readily reallocating their existing 
>> allocations across interconnected
>> network infrastructure with routing impact"    are to be considered
>> non-discrete.
> 
> Jimmy - Read the policy text. There is no definition of a _discrete_ network contained therein.  It's fairly easy to distinguish some discrete networks from the examples, but it is not clear at all how interconnected network infrastructure qualifies as "discrete".
> 
>> If the applicant can determine that their networks are discrete based 
>> on the criteria for operating discrete networks, then their networks 
>> are discrete, regardless of the technical possibility of reallocating 
>> existing allocations.
> 
> Correct, as I note above.
> 
>> Second,   just because it's technically feasible for "existing
>> allocations to be reallocated"
>> across interconnected network infrastructure,  does not mean it would 
>> be appropriate to do so.  There may be a performance or cost impact 
>> that causes this to be extremely
>> problematic.     There may be a reliability impact with regards to the
>> operator's network
>> design, and survivability requirements,   there might be legal issues, etc.
> 
> Exactly, and we ask exactly those type of questions searching for a compelling need for their treatment of their interconnected network infrastructure as "multiple discrete networks".
> 
> Thanks,
> /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.



From mysidia at gmail.com  Mon Oct  3 07:40:03 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 3 Oct 2011 06:40:03 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
References: <20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
Message-ID: <CAAAwwbX4sQvxJd=siQjrL-Mrp68f=b=bZwP7UjiZbgeKS92JEg@mail.gmail.com>

>On Mon, Oct 3, 2011 at 2:10 AM, Owen DeLong <owen at delong.com> wrote:

>>> On Oct 2, 2011, at 2:38 PM, Richard A Steenbergen wrote:
>>> On Sun, Oct 02, 2011 at 09:18:33PM +0000, John Curran wrote:
>>> Alas, the policy makes clear that there must be a compelling need.
>>For the record, the policy says absolutely nothing about a compelling
>>need. It lists some examples of why some organizations require multiple
>Um... Here's the policy:

It can be stated that   "must be compelling need"
is different from  "must have compelling criteria"
The policy actually says "must have compelling criteria".

That may sound the same, or look subtly different,  but for the
applicant it can be a big difference whether they actually have to
"NEED"  to use discrete networks, or you just have a very good reason
to.

--
-JH


From ras at e-gerbil.net  Mon Oct  3 08:56:53 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 3 Oct 2011 07:56:53 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
References: <20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
Message-ID: <20111003125653.GA49464@gerbil.cluepon.net>

On Mon, Oct 03, 2011 at 12:10:06AM -0700, Owen DeLong wrote:
> Admittedly, it uses the word criteria instead of reason, but, I think 
> picking apart the synonyms really isn't necessary. The meaning seems 
> relatively clear to me and it indicates that you need a compelling 
> reason (criteria) for not giving the networks a common routing policy.

Owen, please read what I said again, I think we're actually in complete 
agreement here.

So far what you've said is:

a) You need a compelling reason to operate multiple discrete networks.
b) The policy defines some examples compelling reasons for this.
c) Not having a common routing policy equates to discrete networks.

I couldn't agree more with any of the above.

What John is saying is that, in addition to the compelling REASON 
criteria of the policy, there is also a phantom compelling NEED 
criteria. This shifts the burdon of proof from "show us that you have a 
good reason for doing this" to "show us that you have an absolutely NEED 
to do this", language which doesn't exist in the policy at all. He then 
goes on to say that there is no definition equating having unique 
routing policies with "discrete networks", and therefore he gets to make 
up any definition for "discrete network" that he likes, and the 
definition he uses just happens to include this non-existant compelling 
NEED logic.

You're absolutely right, the meaning of the policy is QUITE clear and we 
both have the same interpretation of it. The problem is that ARIN does 
not agree.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From jcurran at arin.net  Mon Oct  3 09:27:03 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Oct 2011 13:27:03 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111003125653.GA49464@gerbil.cluepon.net>
References: <20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
Message-ID: <1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>

On Oct 3, 2011, at 8:56 AM, Richard A Steenbergen wrote:

> a) You need a compelling reason to operate multiple discrete networks.

Yes.

> b) The policy defines some examples compelling reasons for this.

Yes.

> c) Not having a common routing policy equates to discrete networks.

That is not expressed in the policy.  Having "Autonomous multihomed 
discrete networks" certainly is delineated as an example.  

> What John is saying is that, in addition to the compelling REASON 
> criteria of the policy, there is also a phantom compelling NEED 
> criteria.

Incorrect.   You need a compelling reason, and there's no policy 
language that denotes lack of common routing policy as a compelling
reason for discrete networks.

> This shifts the burdon of proof from "show us that you have a 
> good reason for doing this" to "show us that you have an absolutely NEED 
> to do this", language which doesn't exist in the policy at all.

Incorrect. Show us that you have a _compelling reason_ for doing this.

That's not "absolute need", but it is certainly a high standard than
some "good reason" as you assert above.

If you'd like to add an example for "lack of common routing policy"
(which would match your earlier incorrect assertion about this being
the very goal of the policy), then feel free to submit an appropriate
policy proposal.

Thanks!
/John

John Curran
President and CEO
ARIN



From ras at e-gerbil.net  Mon Oct  3 10:31:24 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 3 Oct 2011 09:31:24 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
References: <20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
Message-ID: <20111003143124.GB49464@gerbil.cluepon.net>

On Mon, Oct 03, 2011 at 01:27:03PM +0000, John Curran wrote:
> > What John is saying is that, in addition to the compelling REASON 
> > criteria of the policy, there is also a phantom compelling NEED 
> > criteria.
> 
> Incorrect.  You need a compelling reason, and there's no policy 
> language that denotes lack of common routing policy as a compelling 
> reason for discrete networks.

Ok, that's not what you just said a few e-mails ago, but anyways... Lack 
of common routing policy is not a compelling reason for a discrete 
network, it is THE DEFINITION of a discrete network.

> Incorrect. Show us that you have a _compelling reason_ for doing this.
> 
> That's not "absolute need", but it is certainly a high standard than 
> some "good reason" as you assert above.

Again, not what you JUST SAID a few emails ago, but lets run with it... 
I DO have a compelling reason, and it just so happens to line up 
perfectly with one of the example compelling reasons provided in the 
policy... Is *THIS* now the part that you're disputing? I'd really love 
to figure out what your actual objection is, but every time you seem to 
make one and I prove it wrong you seem to make another one. If this is 
your objection, I'd be more than happy to disprove it (again), but lets 
be clear about it before I waste a lot of time typing. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From owen at delong.com  Mon Oct  3 10:44:26 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Oct 2011 07:44:26 -0700
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111003125653.GA49464@gerbil.cluepon.net>
References: <20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
Message-ID: <2C8C02FC-4C3E-4B63-BEE3-8D3CDBAF2762@delong.com>


On Oct 3, 2011, at 5:56 AM, Richard A Steenbergen wrote:

> On Mon, Oct 03, 2011 at 12:10:06AM -0700, Owen DeLong wrote:
>> Admittedly, it uses the word criteria instead of reason, but, I think 
>> picking apart the synonyms really isn't necessary. The meaning seems 
>> relatively clear to me and it indicates that you need a compelling 
>> reason (criteria) for not giving the networks a common routing policy.
> 
> Owen, please read what I said again, I think we're actually in complete 
> agreement here.
> 
> So far what you've said is:
> 
> a) You need a compelling reason to operate multiple discrete networks.
> b) The policy defines some examples compelling reasons for this.
> c) Not having a common routing policy equates to discrete networks.
> 
> I couldn't agree more with any of the above.
> 
> What John is saying is that, in addition to the compelling REASON 
> criteria of the policy, there is also a phantom compelling NEED 
> criteria. This shifts the burdon of proof from "show us that you have a 
> good reason for doing this" to "show us that you have an absolutely NEED 
> to do this", language which doesn't exist in the policy at all. He then 

Nope... I'm saying that criteria equates to NEED in the policy and in the
policy intent.

You're saying that it does not. That's where I agree with John and where
you and I appear to disagree.

> goes on to say that there is no definition equating having unique 
> routing policies with "discrete networks", and therefore he gets to make 
> up any definition for "discrete network" that he likes, and the 
> definition he uses just happens to include this non-existant compelling 
> NEED logic.
> 

Correct. The examples in the policy are intended to equate the actual
NEED for distinct routing policies as criteria rather than the mere use
of distinct routing policies.

> You're absolutely right, the meaning of the policy is QUITE clear and we 
> both have the same interpretation of it. The problem is that ARIN does 
> not agree.
> 

Apparently not since you just reinterpreted it differently than I did.

However, I will submit a proposal to correct this discrepancy. Thank
you for bringing the issue to my attention.

Owen


From jcurran at arin.net  Mon Oct  3 10:47:46 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Oct 2011 14:47:46 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111003143124.GB49464@gerbil.cluepon.net>
References: <20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
	<20111003143124.GB49464@gerbil.cluepon.net>
Message-ID: <CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>

On Oct 3, 2011, at 10:31 AM, Richard A Steenbergen wrote:

> I DO have a compelling reason, and it just so happens to line up 
> perfectly with one of the example compelling reasons provided in the 
> policy... 

Richard - 
 
In your request to ARIN, you did claim a compelling reason based on one
the examples in the policy.  As noted in ARIN's response, it was ARIN's
determination that you failed to demonstrate how your claimed reason 
were compelling criteria for creating discrete networks.  You have the 
option of appeal as noted in that communication (and on this list 
recently)  I also referred you to the PPML mailing list so that you 
could explore the option of developing a policy change that would 
better meet your expectations.

Thanks!
/John

John Curran
President and CEO
ARIN








From ras at e-gerbil.net  Mon Oct  3 11:28:28 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 3 Oct 2011 10:28:28 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <2C8C02FC-4C3E-4B63-BEE3-8D3CDBAF2762@delong.com>
References: <20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<2C8C02FC-4C3E-4B63-BEE3-8D3CDBAF2762@delong.com>
Message-ID: <20111003152828.GD49464@gerbil.cluepon.net>

On Mon, Oct 03, 2011 at 07:44:26AM -0700, Owen DeLong wrote:
> 
> Nope... I'm saying that criteria equates to NEED in the policy and in 
> the policy intent.
> 
> You're saying that it does not. That's where I agree with John and 
> where you and I appear to disagree.

Do you or do you not believe that meeting the criteria established by 
the policy as an example of a compelling reason equates to 
justification for using the policy?

> Apparently not since you just reinterpreted it differently than I did.
> 
> However, I will submit a proposal to correct this discrepancy. Thank 
> you for bringing the issue to my attention.

I'm not sure how that's possible, considering:

1) I suggested a definition of discrete network based on the applicants 
requirement to implement unique routing policies.

2) John said that this isn't the definition at all, and that his 
definition also adds "and that you can't possibly work around it any 
other way, such as with deaggregation".

3) You then proposed a policy to change the definition of a discrete 
network to exactly what I said in 1).

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From ras at e-gerbil.net  Mon Oct  3 12:11:45 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 3 Oct 2011 11:11:45 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>
References: <20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
	<20111003143124.GB49464@gerbil.cluepon.net>
	<CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>
Message-ID: <20111003161145.GE49464@gerbil.cluepon.net>

On Mon, Oct 03, 2011 at 02:47:46PM +0000, John Curran wrote:
>  
> In your request to ARIN, you did claim a compelling reason based on 
> one the examples in the policy.  As noted in ARIN's response, it was 
> ARIN's determination that you failed to demonstrate how your claimed 
> reason were compelling criteria for creating discrete networks.  You 
> have the option of appeal as noted in that communication (and on this 
> list recently) I also referred you to the PPML mailing list so that 
> you could explore the option of developing a policy change that would 
> better meet your expectations.

Actually that's not what you said at all (that would have been a MUCH 
easier argument to have than all of this other nonsense that has been 
going on :P), but ok lets go with it.

There are three example compelling reasons cited in the policy:

* regulatory restrictions for data transmission
* geographic distance and diversity between networks
* autonomous multi-homed discrete networks

I am claiming "geographic distance and diversity between networks" as a 
compelling reason to implement unique routing policies.

I have a network with a bunch of POPs, and they span very large 
geographic distances. In fact, the North American portion spans nearly 
the entire extent of the region the ARIN serves. Large geographic 
distances create several challanges, such as high latency, and large 
costs associated with the transport of data across these distances. 
Thus, it is important for a network which spans large geographic 
distances to ensure traffic gets routed optimally, and at the lowest 
cost (i.e. with the least amount of data transported across these large 
distances possible, by making your transit provider haul and deliver 
traffic to the correct location). To do this, implementing unique 
routing policies across each discrete network is required.

Further, when a network spans these great geographic distances, 
diversity between networks becomes a problem. For example, it may not be 
possible to find the same transit provider at all points, or you may 
need to buy from a transit provider who specifically services region X. 
In order to implement diversity between networks, unique routing 
policies across each discrete network is required.

Now, what part of that seems like it doesn't match the example 
compelling reason? Or, if you think that it doesn't, can you please 
provide an example of something that does? Personally I can't think of a 
better match for this example.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From info at arin.net  Mon Oct  3 12:31:42 2011
From: info at arin.net (ARIN)
Date: Mon, 03 Oct 2011 12:31:42 -0400
Subject: [arin-ppml] ARIN-prop-158 Clarify Multiple Discreet Networks Policy
Message-ID: <4E89E36E.9020109@arin.net>

ARIN-prop-158 Clarify Multiple Discreet Networks Policy

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

The ARIN Advisory Council (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.

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,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

## * ##

ARIN-prop-158 Clarify Multiple Discreet Networks Policy

Proposal Originator: Owen DeLong

Proposal Version: 1.0

Date: 3 October 2011

Proposal type: modify

Policy term: permanent

Policy statement:

Modify section 4.5 of the NRPM as follows:

Replace 4.5.2 with: The organization must have a compelling need to 
create discrete networks.

Insert new 4.5.3: Discrete networks are separate networks which have 
cannot usefully share a common routing policy.
Examples might include networks with any of the following characteristics:

Move 4.5.2 a, b, and c into new 4.5.3.

Renumber existing 4.5.3 et. seq. to accommodate new 4.5.3 (4.5.3->4.5.4, 
etc.).

Rationale:

Recent discussions on the PPML have shown that while ARIN is correctly 
applying the policy as intended, there are those which interpret the 
existing wording differently.

This proposal seeks to clarify the meaning in line with the current and 
intended application of the policy.

Timetable for implementation: Immediate



From jcurran at arin.net  Mon Oct  3 12:56:51 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Oct 2011 16:56:51 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111003161145.GE49464@gerbil.cluepon.net>
References: <20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
	<20111003143124.GB49464@gerbil.cluepon.net>
	<CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>
	<20111003161145.GE49464@gerbil.cluepon.net>
Message-ID: <CEC5ED5D-5EF8-46BA-8514-663A3264F09E@arin.net>

On Oct 3, 2011, at 12:11 PM, Richard A Steenbergen wrote:

> I am claiming "geographic distance and diversity between networks" as a 
> compelling reason to implement unique routing policies.

Do you have a compelling reason to implement _discrete_ networks
or simply unique routing policies?  You have again equated the
two, despite lack of any policy language which supports that.

As written, the policy doesn't provide any basis for consideration 
of the routing as a basis for _discrete networks_. There is a basis 
for viewing regulatory restrictions for data transmission, geographic 
distance and diversity requirements, and autonomous multihomed 
discrete networks as being compelling reasons for discrete networks:

Regulatory restrictions for data transmission:
  "While I do have what appears to be a single network, I've already
   allocated address blocks to my POPs which I cannot rearrange and 
   I cannot transit traffic between these two sets of POP due to 
   regulatory restrictions... Hence, we consider those two sets of 
   POPs to be discrete networks."

Geographic distance and diversity requirements:
  "While I do have what appears to be a single network, I've already
   allocated address blocks to my POPs which I cannot rearrange and 
   I cannot transit traffic between these two sets of POP due to 
   the geographic distance and latency would result, and/or the lack
   of redundancy in the my services that would result... Hence, we
   consider those two sets of POPs to be discrete networks."

Autonomous multihomed discrete networks:
  "While I do have what appears to be a single network, I've already
   allocated address blocks to my POPs which I cannot rearrange and 
   I cannot transit traffic between these two sets of POP due to 
   those POPS belonging to another autonomous business unit which 
   coordinates with us for purposes of getting space but we do not
   have the ability to make use of their infrastructure. Hence, we
   consider those two sets of POPs to be discrete networks."

*These are all COMPELLING REASONS for treating the infrastructure as 
having _discrete networks_ precisely because they preclude the use of 
network routing to make the existing allocation serve all of the POPs.*

If you can make use of your existing address allocations to meet your 
needs, only with some routing impact as a result, you lack a compelling 
reason to have your infrastructure treated as _discrete networks_.  If
you do not like this implementation of the MDN policy, feel free to 
submit a change to policy to match your desired outcome.

/John

John Curran
President and CEO
ARIN



From jcurran at arin.net  Mon Oct  3 13:05:34 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Oct 2011 17:05:34 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <507CAF29-9D57-4FB7-B957-3B3E4BB8035B@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
	<18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>
	<7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>
	<507CAF29-9D57-4FB7-B957-3B3E4BB8035B@arin.net>
Message-ID: <20EB77B2-A94D-4D08-BF3B-2E41D8C565D0@arin.net>

On Oct 2, 2011, at 11:35 PM, John Curran wrote:

> On Oct 2, 2011, at 10:32 PM, Kevin Blumberg wrote:
> 
>> 2) How many times has this policy been accepted/rejected in the past 2 years? 
> 
> I do not know the stats offhand, but can obtain them.

Kevin - 

It turns out that rejections are very hard to measure (e.g. Applicant
applied, was turned down, reapplied, got told it needed to be amended, 
then reapplied with changes and approved - Is that 3 requests, 2 denied
and 1 approved, or is that 1 approved and 0 rejections?)

We need to more consideration about how to usefully collect that 
information, but in the meantime I can provide statistics on the 
accepted MDN requests (and in context against all approved address 
requests):


Statistics on use of the MDN policy

In the past year (10/1/2010 -> 9/30/2011):

We've had 63 total requests approved under MDN:

          44 v4 requests approved under MDN
          19 v6 requests approved under MDN

This is out of a total number of IPv4/IPv6 address
request approvals in the same period of:

          872  v4 requests approved
          1134 v6 requests approved 

44 of 872 v4 approvals means MDN was approx 5% of total
19 of 1,134 v6 approvals meansMDN was approx 2% of total

FYI,
/John

John Curran
President and CEO
ARIN



From kevinb at thewire.ca  Mon Oct  3 13:16:42 2011
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Mon, 3 Oct 2011 17:16:42 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20EB77B2-A94D-4D08-BF3B-2E41D8C565D0@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
	<18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>
	<7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>
	<507CAF29-9D57-4FB7-B957-3B3E4BB8035B@arin.net>
	<20EB77B2-A94D-4D08-BF3B-2E41D8C565D0@arin.net>
Message-ID: <7E7773B523E82C478734E793E58F69E7F9E559@SBS2011.thewireinc.local>

John,

Are those approvals for members that had existing MDN space and required additional space or requests to move under the MDN policy?

As for the rejections I was more interested in the total number of people rejected on initial request to be under the MDN policy that did not
complete later on. 

Thanks,

Kevin Blumberg
T 416.214.9473 x31
F 416.862.9473
kevinb at thewire.ca






> -----Original Message-----
> From: John Curran [mailto:jcurran at arin.net]
> Sent: Monday, October 03, 2011 1:06 PM
> To: Kevin Blumberg
> Cc: arin-ppml at arin.net List
> Subject: Re: [arin-ppml] ARIN Multiple Discrete Networks Policy
> 
> On Oct 2, 2011, at 11:35 PM, John Curran wrote:
> 
> > On Oct 2, 2011, at 10:32 PM, Kevin Blumberg wrote:
> >
> >> 2) How many times has this policy been accepted/rejected in the past 2
> years?
> >
> > I do not know the stats offhand, but can obtain them.
> 
> Kevin -
> 
> It turns out that rejections are very hard to measure (e.g. Applicant applied,
> was turned down, reapplied, got told it needed to be amended, then
> reapplied with changes and approved - Is that 3 requests, 2 denied and 1
> approved, or is that 1 approved and 0 rejections?)
> 
> We need to more consideration about how to usefully collect that
> information, but in the meantime I can provide statistics on the accepted
> MDN requests (and in context against all approved address
> requests):
> 
> 
> Statistics on use of the MDN policy
> 
> In the past year (10/1/2010 -> 9/30/2011):
> 
> We've had 63 total requests approved under MDN:
> 
>           44 v4 requests approved under MDN
>           19 v6 requests approved under MDN
> 
> This is out of a total number of IPv4/IPv6 address request approvals in the
> same period of:
> 
>           872  v4 requests approved
>           1134 v6 requests approved
> 
> 44 of 872 v4 approvals means MDN was approx 5% of total
> 19 of 1,134 v6 approvals meansMDN was approx 2% of total
> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> ARIN



From jcurran at arin.net  Mon Oct  3 13:33:29 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Oct 2011 17:33:29 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <7E7773B523E82C478734E793E58F69E7F9E559@SBS2011.thewireinc.local>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
	<18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>
	<7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>
	<507CAF29-9D57-4FB7-B957-3B3E4BB8035B@arin.net>
	<20EB77B2-A94D-4D08-BF3B-2E41D8C565D0@arin.net>
	<7E7773B523E82C478734E793E58F69E7F9E559@SBS2011.thewireinc.local>
Message-ID: <39CD7D3E-9B33-46C8-AC17-E52E2D97A60E@arin.net>

On Oct 3, 2011, at 1:16 PM, Kevin Blumberg wrote:

> John,
> 
> Are those approvals for members that had existing MDN space and required additional space or requests to move under the MDN policy?

I do not believe we've got task recording that will let us
break it down, but will check.

> As for the rejections I was more interested in the total number of people rejected on initial request to be under the MDN policy that did not
> complete later on. 

I expected as much; we need to track "rejections that become
abandoned" but then also need to realized that some come back
(immediately or later) as standard additional IPv4 ISP requests, 
so keeping it all straight is non-trivial.

FYI,
/John

John Curran
President and CEO
ARIN




From ras at e-gerbil.net  Mon Oct  3 17:00:12 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 3 Oct 2011 16:00:12 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CEC5ED5D-5EF8-46BA-8514-663A3264F09E@arin.net>
References: <20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
	<20111003143124.GB49464@gerbil.cluepon.net>
	<CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>
	<20111003161145.GE49464@gerbil.cluepon.net>
	<CEC5ED5D-5EF8-46BA-8514-663A3264F09E@arin.net>
Message-ID: <20111003210012.GJ49464@gerbil.cluepon.net>

On Mon, Oct 03, 2011 at 04:56:51PM +0000, John Curran wrote:
> 
> Do you have a compelling reason to implement _discrete_ networks
> or simply unique routing policies?  You have again equated the
> two, despite lack of any policy language which supports that.
>
> As written, the policy doesn't provide any basis for consideration of 
> the routing as a basis for _discrete networks_. There is a basis for 
> viewing regulatory restrictions for data transmission, geographic 
> distance and diversity requirements, and autonomous multihomed 
> discrete networks as being compelling reasons for discrete networks:

Annnnnnd now we go back to that other argument again, weeee....

1) So far everyone who has responded to this thread has said that a 
requirement to implement unique routing policies *IS* what defines a 
discrete network.

2) The policy itself DOES provide a link between the need for unique 
routing policies and the need to implement discrete networks, right 
here:

> Some organizations have requirements for multiple discrete networks 
> that need individual address allocations. Discrete networks must often 
> have separate unique globally routable address space and will often 
> grow at different rates.

3) Earlier we were debating the definition of a discrete network and the 
the arbitrary exclusionary rule you have added to the policy, and you 
said that your objection was to the part where we matched the compelling 
reasons for running multiple discrete networks. Now that I've shown we 
match the compelling reasons for running multiple discrete networks, 
your objection is back to the definition of discrete networks.

You're seriously trying to argue that we don't match the compelling 
reasons for implementing discrete networks, not because we don't match 
the criteria, but because what we're implementing is not a discrete 
network... And then saying that what we're implementing is not a 
discrete network because we didn't match the compelling reasons. I 
really need to get ahold of whatever you're smoking here, it must be 
worth a fortune.

I appreciate recursiveness as much as the next programmer, but you can't 
use B to prove A and A to prove B if both A and B have already been 
disproven!

> Geographic distance and diversity requirements:
>   "While I do have what appears to be a single network, I've already
>    allocated address blocks to my POPs which I cannot rearrange and 
>    I cannot transit traffic between these two sets of POP due to 
>    the geographic distance and latency would result, and/or the lack
>    of redundancy in the my services that would result... Hence, we
>    consider those two sets of POPs to be discrete networks."

What does "I've already allocated address blocks to my POPs, which I 
cannot rearrange", have to do with "geographic distance and diversity 
requirements"? Where does this language come from? What is your basis in 
the policy to support this claim? When has this claim ever been applied 
to any other MDN applicant? And for the record, that part *IS* 
completely true in my specific situation, so it's not even a blocker, 
but it's also complete nonsense too, and needs to be called out as such.

The part that I *JUST* explained was "I cannot transit traffic between 
two sets of POPs due to the geographic distance and latency which would 
result, AND the lack of redundancy in my services that would result". 
This is *PRECISELY* what I *JUST DESCRIBED*, you couldn't have said it 
any better. Do you have an argument you'd like to make about why the 
explanation I just provided does not precisely match the example you 
just gave?

> *These are all COMPELLING REASONS for treating the infrastructure as 
> having _discrete networks_ precisely because they preclude the use of 
> network routing to make the existing allocation serve all of the 
> POPs.*

They are compelling reasons *BECAUSE*... wait for it... they require you 
to implement unique routing policies... Welcome to the definition of 
discrete network!

> If you can make use of your existing address allocations to meet your 
> needs, only with some routing impact as a result, you lack a 
> compelling reason to have your infrastructure treated as _discrete 
> networks_.  If you do not like this implementation of the MDN policy, 
> feel free to submit a change to policy to match your desired outcome.

No, you have a compelling reason if you can match an example compelling 
reason from the policy. NOTHING in the policy says ANYTHING about "and 
you can't solve this any other way", and your logic to try and make this 
claim is absolutely twisted to the point of being nonsensical.

To be clear, I really don't give a $%^(* about the allocation itself. I 
*CAN* get plenty of address space by doing things the hard way, I'm just 
trying to explain how woefully confused you are in the interests of not 
creating an even bigger mess for the Internet in general.

Or is that now grounds for denying an application too? :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From jcurran at arin.net  Mon Oct  3 18:29:06 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Oct 2011 22:29:06 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111003210012.GJ49464@gerbil.cluepon.net>
References: <20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
	<20111003143124.GB49464@gerbil.cluepon.net>
	<CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>
	<20111003161145.GE49464@gerbil.cluepon.net>
	<CEC5ED5D-5EF8-46BA-8514-663A3264F09E@arin.net>
	<20111003210012.GJ49464@gerbil.cluepon.net>
Message-ID: <BBCD87C0-A836-4B0D-A473-7EB3B7A6F368@arin.net>

On Oct 3, 2011, at 5:00 PM, Richard A Steenbergen wrote:

> On Mon, Oct 03, 2011 at 04:56:51PM +0000, John Curran wrote:
>> 
>> Do you have a compelling reason to implement _discrete_ networks
>> or simply unique routing policies?  You have again equated the
>> two, despite lack of any policy language which supports that.
>> 
>> As written, the policy doesn't provide any basis for consideration of 
>> the routing as a basis for _discrete networks_. There is a basis for 
>> viewing regulatory restrictions for data transmission, geographic 
>> distance and diversity requirements, and autonomous multihomed 
>> discrete networks as being compelling reasons for discrete networks:
> 
> Annnnnnd now we go back to that other argument again, weeee....
> 
> 1) So far everyone who has responded to this thread has said that a 
> requirement to implement unique routing policies *IS* what defines a 
> discrete network.

The policy text does not reference unique routing policies.

> 2) The policy itself DOES provide a link between the need for unique 
> routing policies and the need to implement discrete networks, right 
> here:
> 
>> Some organizations have requirements for multiple discrete networks 
>> that need individual address allocations. Discrete networks must often 
>> have separate unique globally routable address space and will often 
>> grow at different rates.

Did you cut and paste the wrong section?  Please resend the section
which refers to "unique routing policies".   You quoted a section 
regarding "Separate unique 'globally routable' address space' "

> Geographic distance and diversity requirements:
>>  "While I do have what appears to be a single network, I've already
>>   allocated address blocks to my POPs which I cannot rearrange and 
>>   I cannot transit traffic between these two sets of POP due to 
>>   the geographic distance and latency would result, and/or the lack
>>   of redundancy in the my services that would result... Hence, we
>>   consider those two sets of POPs to be discrete networks."
> 
> What does "I've already allocated address blocks to my POPs, which I 
> cannot rearrange", have to do with "geographic distance and diversity 
> requirements"? Where does this language come from? What is your basis in 
> the policy to support this claim?

You need a 'compelling reason' to have your infrastructure considered
_multiple discrete networks_

> When has this claim ever been applied 
> to any other MDN applicant? And for the record, that part *IS* 
> completely true in my specific situation, so it's not even a blocker, 
> but it's also complete nonsense too, and needs to be called out as such.

Richard - If that part is completely true in your situation, then please 
reapply asap. You indicated otherwise on your last request to ARIN for 
space under the MDN policy.

>> *These are all COMPELLING REASONS for treating the infrastructure as 
>> having _discrete networks_ precisely because they preclude the use of 
>> network routing to make the existing allocation serve all of the 
>> POPs.*
> 
> They are compelling reasons *BECAUSE*... wait for it... they require you 
> to implement unique routing policies... Welcome to the definition of 
> discrete network!

Again, they are compelling reasons for treating your infrastructure as 
_multiple discrete networks_.   There is no reference to unique routing 
policies in the MDN policy.

> To be clear, I really don't give a $%^(* about the allocation itself. I 
> *CAN* get plenty of address space by doing things the hard way, I'm just 
> trying to explain how woefully confused you are in the interests of not 
> creating an even bigger mess for the Internet in general.

If that's the case, then the most constructive path would be to propose 
unequivocal text for an MDN policy change.  If you believe that "discrete
networks" are "networks that implement unique routing policies" then that
would be a fine change.   That would also result in the elimination of ARIN 
having to determine if a "compelling reason" was present at all, since with 
such a definition, since we would simply be able to ask:  "Do you have two 
or more networks with unique routing policies?", and if the applicant said 
"yes", then they would meet the MDN policy by having _multiple discrete 
networks_ per definition of _discrete network_.

Thanks!
/John

John Curran
President and CEO
ARIN






From jsw at inconcepts.biz  Mon Oct  3 18:58:31 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 3 Oct 2011 18:58:31 -0400
Subject: [arin-ppml]  ARIN Multiple Discrete Networks Policy
Message-ID: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>

> On Sat, Oct 01, 2011 at 08:17:36 EDT 2011, John Curran wrote:
> Incorrect. If an organization has a compelling reason (along the lines
> of the provided examples) for creating multiple discrete networks and
> desires to request new or additional address space under a single
> Organization ID, then it can request space under the MDN criteria.

Having re-subscribed to this list after reviewing the posts on this
thread, I'll simply reiterate my probably well-known opinion that the
biggest problem with the RIRs is they claim not to care about routing
when it's convenient for them, yet every allocation action they take
impacts routing, and many policies, in place for over a decade, were
crafted for the specific purpose of routing table efficiency.  For
example, it was common for ISPs to receive a /20 but have a /19
reserved, so they would have an allocation that was justified but also
be able to get it accepted by the SprintLink filters in place during
the mid-90s and carried on by some other networks.

There has never been any reason to reserve additional address space,
beyond what is justified by an application, except to conserve routing
table resources.  To say otherwise is idiotic.  So to say the RIRs
don't involve themselves in routing policy is the biggest,
longest-running lie in the game.  It may be a convenient lie when you
want to interpret policy just so, but the membership have taken
routing policy into consideration for a very long time.

If you want to go on pretending that this is true, go right ahead.  On
the other hand, you could make yourself the guy that acknowledges the
above truth and directs his energy into doing something constructive.
A good start would be to acknowledge that yes, RIR policy does indeed
take routing policy into consideration; and it may be a good idea to
do this in more ways.

There is a huge amount of routing table pollution that simply comes
from stupidity -- ISPs who announce every /24 out of their /19 because
they don't understand how to do it another way, those who decide this
is a good means of inbound traffic-engineering, and so on.  That could
have, and should have, been addressed by the RIRs years ago but we're
way past that point now.

I think Richard's multiple discrete networks concern is a very small
contributor to deaggregation / DFZ pollution, and it really can't
compete with pollution created by sheer stupidity; so I honestly can't
bring myself to care about this particular issue, other than to state
clearly that the MDN language should apply to the examples he
describes as it will not significantly contribute to IPv4 exhaustion
(like, say, handing Verizon Wireless 75% of a /8 years ago when there
is no possible way such allocation could have been justified) but it
does reduce routing table pollution.

The sooner RIRs get off the "we don't care about routing" company line
and realize that, in an IPv6 world, managing DFZ bloat is the only way
they can contribute anything useful, the better off we will all be.

The old thinking that vendors can ship new linecards with more FIB
capacity whenever we need them to is foolish.  Yes, they can; and then
you have to upgrade every DFZ box in your network.  More FIB
contributes substantially to power draw and heat production, which
limits router density and increases OpEx.  If you have to do that
upgrade cycle because you are out of FIB before your platforms are
otherwise functionally obsolete, you have to lay out capital dollars
and pray that you can still sell your old cards on the used market.
None of these things are good.  And yet, the way things are evolving,
the current generation of DFZ routers will probably not have
sufficient FIB for the IPv6 DFZ within a few years.

You *can* fix the stupidity problem.  In fact, when the small
multi-homed network (2002-3?) policy was implemented, ARIN allocated
these networks from special blocks in an effort to avoid having
recipients of a /22 or similar from being unable to use their
allocations.  Does ARIN guarantee that an allocation will be
globally-reachable?  No, of course not.  But ARIN absolutely does make
efforts in this area, even in the absence of specific policy language,
simply by implementing policy in a way that is sensible -- with
consideration given to routing policy.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From owen at delong.com  Mon Oct  3 19:23:13 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Oct 2011 16:23:13 -0700
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111003152828.GD49464@gerbil.cluepon.net>
References: <20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<20111002210224.GT49464@gerbil.cluepon.net>
	<24B49579-947E-4D8F-9B55-AB100EF6C8EE@arin.net>
	<20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<2C8C02FC-4C3E-4B63-BEE3-8D3CDBAF2762@delong.com>
	<20111003152828.GD49464@gerbil.cluepon.net>
Message-ID: <51F3B0E0-1779-415B-98A4-285E87A40221@delong.com>


On Oct 3, 2011, at 8:28 AM, Richard A Steenbergen wrote:

> On Mon, Oct 03, 2011 at 07:44:26AM -0700, Owen DeLong wrote:
>> 
>> Nope... I'm saying that criteria equates to NEED in the policy and in 
>> the policy intent.
>> 
>> You're saying that it does not. That's where I agree with John and 
>> where you and I appear to disagree.
> 
> Do you or do you not believe that meeting the criteria established by 
> the policy as an example of a compelling reason equates to 
> justification for using the policy?
> 

I believe that if you meet the criteria established as an example because
you cannot do otherwise. If you have adequate backbone between the
sites, I would argue they do not meet the "discrete" criteria.

>> Apparently not since you just reinterpreted it differently than I did.
>> 
>> However, I will submit a proposal to correct this discrepancy. Thank 
>> you for bringing the issue to my attention.
> 
> I'm not sure how that's possible, considering:
> 
> 1) I suggested a definition of discrete network based on the applicants 
> requirement to implement unique routing policies.
> 

Requirement being the particularly relevant word here. In your opinion,
the requirement is merely the desire to do so. In my opinion, the
requirement needs to be somewhat external either due to prohibitive
cost to run an otherwise unnecessary backbone or inability to adequately
connect the two sites.

> 2) John said that this isn't the definition at all, and that his 
> definition also adds "and that you can't possibly work around it any 
> other way, such as with deaggregation".
> 

I think this is a misunderstanding of what he actually said. I can't tell whether
your obstinance on this point is a legitimate failure to communicate or a
driven desire to mold things to your world view.  

> 3) You then proposed a policy to change the definition of a discrete 
> network to exactly what I said in 1).
> 

Not exactly how I see it.

Owen



From owen at delong.com  Mon Oct  3 19:30:40 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 3 Oct 2011 16:30:40 -0700
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20EB77B2-A94D-4D08-BF3B-2E41D8C565D0@arin.net>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
	<18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>
	<7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>
	<507CAF29-9D57-4FB7-B957-3B3E4BB8035B@arin.net>
	<20EB77B2-A94D-4D08-BF3B-2E41D8C565D0@arin.net>
Message-ID: <FFD758E5-3089-400E-8B6B-117E6D83B99D@delong.com>

Can you contrast those numbers with the number of requests that never
resulted in approval or at least have not as yet resulted in approval?

Owen

On Oct 3, 2011, at 10:05 AM, John Curran wrote:

> On Oct 2, 2011, at 11:35 PM, John Curran wrote:
> 
>> On Oct 2, 2011, at 10:32 PM, Kevin Blumberg wrote:
>> 
>>> 2) How many times has this policy been accepted/rejected in the past 2 years? 
>> 
>> I do not know the stats offhand, but can obtain them.
> 
> Kevin - 
> 
> It turns out that rejections are very hard to measure (e.g. Applicant
> applied, was turned down, reapplied, got told it needed to be amended, 
> then reapplied with changes and approved - Is that 3 requests, 2 denied
> and 1 approved, or is that 1 approved and 0 rejections?)
> 
> We need to more consideration about how to usefully collect that 
> information, but in the meantime I can provide statistics on the 
> accepted MDN requests (and in context against all approved address 
> requests):
> 
> 
> Statistics on use of the MDN policy
> 
> In the past year (10/1/2010 -> 9/30/2011):
> 
> We've had 63 total requests approved under MDN:
> 
>          44 v4 requests approved under MDN
>          19 v6 requests approved under MDN
> 
> This is out of a total number of IPv4/IPv6 address
> request approvals in the same period of:
> 
>          872  v4 requests approved
>          1134 v6 requests approved 
> 
> 44 of 872 v4 approvals means MDN was approx 5% of total
> 19 of 1,134 v6 approvals meansMDN was approx 2% of total
> 
> FYI,
> /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 jcurran at arin.net  Mon Oct  3 19:32:57 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Oct 2011 23:32:57 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
Message-ID: <3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>

On Oct 3, 2011, at 6:58 PM, Jeff Wheeler wrote:

> Having re-subscribed to this list after reviewing the posts on this
> thread, I'll simply reiterate my probably well-known opinion that the
> biggest problem with the RIRs is they claim not to care about routing
> when it's convenient for them, yet every allocation action they take
> impacts routing, and many policies, in place for over a decade, were
> crafted for the specific purpose of routing table efficiency.

Correct... If you propose policy that has ARIN taking routing 
into evaluation, we will do so.  For example, the AS policy 
in NRPM - 

>   In order to be assigned an AS Number, each requesting organization 
>   must provide ARIN with verification that it has one of the following:
>
>     ? A unique routing policy (its policy differs from its border gateway peers)
>     ? A multihomed site.

specifically has ARIN consider routing policy if that's what the 
applicant requests such to qualify.  It is true that the ARIN 
community has generally shied away from having address policy 
based on routing criteria, but if folks make address policy which 
includes routing criteria, then the ARIN staff will indeed 
implement it.  

Thanks,
/John

John Curran
President and CEO
ARIN



From jcurran at arin.net  Mon Oct  3 19:38:54 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 3 Oct 2011 23:38:54 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <FFD758E5-3089-400E-8B6B-117E6D83B99D@delong.com>
References: <20110929185919.GN49464@gerbil.cluepon.net>
	<E872EA7A-9029-475F-A15E-0B49D33AEA69@corp.arin.net>
	<CAAAwwbVTU+w_ZNZw+eSL8CwheE8bDkaAJBnV7iQXO+6an2NgMQ@mail.gmail.com>
	<DDF01FA0-EB9C-4CBD-BC15-2E9BCC594352@arin.net>
	<20111001152955.GP49464@gerbil.cluepon.net>
	<0807778D-DC9A-4EF1-A6BF-AE3C238EB8A3@arin.net>
	<20111001192621.GQ49464@gerbil.cluepon.net>
	<46C8B5B2-C5B7-4843-A3A9-B6AA8B15CEB5@arin.net>
	<20111001221538.GR49464@gerbil.cluepon.net>
	<B380AC66-6DF3-49AE-95FC-84127E25A7BE@arin.net>
	<20111001230532.GS49464@gerbil.cluepon.net>
	<0DC4B52B-8141-485A-8D3F-FF7F6058F878@arin.net>
	<CAAAwwbVBvbg2O+bwyn1AfbF6Sp=vTd6kV-+xh1p=VUkNXsm2PQ@mail.gmail.com>
	<18FBA5A3-71EB-49EC-92DE-BAE96EB48D8C@arin.net>
	<7E7773B523E82C478734E793E58F69E7F9AF28@SBS2011.thewireinc.local>
	<507CAF29-9D57-4FB7-B957-3B3E4BB8035B@arin.net>
	<20EB77B2-A94D-4D08-BF3B-2E41D8C565D0@arin.net>
	<FFD758E5-3089-400E-8B6B-117E6D83B99D@delong.com>
Message-ID: <34B7191B-E488-40D7-A5E7-B05FB6E7A01D@arin.net>

On Oct 3, 2011, at 7:30 PM, Owen DeLong wrote:

> Can you contrast those numbers with the number of requests that never
> resulted in approval or at least have not as yet resulted in approval?

Not at present, as that requires somewhere detecting and coding 
that this new request is actually chained to the prior ones that
were abandoned or declined. It's an non-trivial problem but I see
the value in trying to track this and will discuss with the team.

FYI,
/John

John Curran
President and CEO
ARIN



From jsw at inconcepts.biz  Mon Oct  3 20:13:43 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 3 Oct 2011 20:13:43 -0400
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
Message-ID: <CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>

On Mon, Oct 3, 2011 at 7:32 PM, John Curran <jcurran at arin.net> wrote:
>> ? In order to be assigned an AS Number, each requesting organization
>> ? must provide ARIN with verification that it has one of the following:
>>
>> ? ? ? A unique routing policy (its policy differs from its border gateway peers)
>> ? ? ? A multihomed site.

The "unique routing policy" language above is not necessary.  I'm not
sure it ever was.  All you have to do to get organizations the AS
numbers they legitimately need is to understand what a multihomed site
is, and that it does indeed apply to islands within enterprise
networks, those who may have private interconnections to two or more
other enterprises but no Internet connectivity, and so on.  Discrete
networks is another application where ARIN have allowed organizations
to have multiple AS numbers, and given that we aren't really in danger
of running out of ASN, this is good (other than problems with 32-bit
ASN implementations, another topic that is not necessary to rehash.)

The ASN language should not be anyone's first or primary example of
how RIR policy and inter-domain routing policy are closely related.
Sure, if you hit find and type "routing policy" into the box, that's
what you get; but I don't think either of us have such a pedestrian
view of the way things work that the "unique routing policy" provision
for ASN allocation is of any real consequence.  It should never have
been codified in the first place, but it is harmless.

> applicant requests such to qualify. ?It is true that the ARIN
> community has generally shied away from having address policy
> based on routing criteria, but if folks make address policy which
> includes routing criteria, then the ARIN staff will indeed
> implement it.

I have given several examples of how ARIN takes routing policy into
account when allocating addresses, even though the NPRM does not
direct ARIN to do so.  This is good -- ARIN has applied common sense
to these areas of policy interpretation and we benefit from it.

The problem is you, specifically, and a lot of other folks, have spent
time and energy denying that the RIRs should or do care about routing
instead of figuring out what non-obstructive, beneficial things you
can do.  I would love to read the email from John Curran that says,
"if we *did* care about routing, what could we do to reduce DFZ bloat
without getting in anyone's way?  Do we need any different policy
language, or are there things we can do today?  What kind of
applications will be affected by proposed changes?  What affect will
this have in a post-exhaustion world?"  I don't see any of that.

As long as folks continue to deny that RIRs should involve themselves
more explicitly in inter-domain routing policy, we are climbing higher
and higher up a hill, and v4 exhaustion may push us over a cliff.  I
don't think anyone wants to upgrade all of their routers because ARIN
leadership were afraid to explore what benefits (and disadvantages)
there could be from modifying policy interpretation, and from no
longer shying away from policy changes that impact routing policy.

Here is the harsh reality: IPv6 is a real danger to us because we
currently have folks de-aggregating to /48 boundaries within /32
allocations, special allocations for critical infrastructure are
poorly-understood, and most operators are afraid to filter because
there is very little guidance in this area.  With the plentiful IPv6
address space, we could have a much more efficient system, or we could
have one that is far worse than IPv4.

On the other hand, there isn't much reason for the RIRs to have a big
staff if the frequency of requests from growing ISPs changes from
several times per year to a few times per decade (if they ever need to
make a follow-up request at all.)

ARIN's primary job, for its entire lifetime, has been to be a
barrier-to-entry.  ARIN does nothing better than say "no," because
that's what we needed it to do.  In an IPv6 world we will no longer
really have that need.  Unless RIR policy gets really, really stupid
(though it is in some ways already) we will never exhaust IPv6 and
will hopefully never need to implement policies to stave that off.

What we do need is to control routing table bloat.  This should be the
primary function of RIRs in an IPv6 world, and yet they continue to
resist this job.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From ras at e-gerbil.net  Mon Oct  3 20:33:27 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 3 Oct 2011 19:33:27 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <BBCD87C0-A836-4B0D-A473-7EB3B7A6F368@arin.net>
References: <20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
	<20111003143124.GB49464@gerbil.cluepon.net>
	<CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>
	<20111003161145.GE49464@gerbil.cluepon.net>
	<CEC5ED5D-5EF8-46BA-8514-663A3264F09E@arin.net>
	<20111003210012.GJ49464@gerbil.cluepon.net>
	<BBCD87C0-A836-4B0D-A473-7EB3B7A6F368@arin.net>
Message-ID: <20111004003327.GL49464@gerbil.cluepon.net>

On Mon, Oct 03, 2011 at 10:29:06PM +0000, John Curran wrote:
>
> The policy text does not reference unique routing policies.

Even Owen, who is trying desperately to disagree with me (I'll pass on 
any particular speculations as to why :P), has stated that a discrete 
network is one which must implement unique routing policies.

Since I apparently need to cite examples from every previous e-mail 
every time now, allow me to point out his attempt to "clarify the 
current defintion":

> Insert new 4.5.3: Discrete networks are separate networks which have 
> cannot usefully share a common routing policy. Examples might include 
> networks with any of the following characteristics:

So, if a network has one of the (previously defined in the policy 
language) characteristics, and thus cannot usefully hsare a common 
routing policy, they have discrete networks AND good justification for 
running discrete networks. I'm more than happy to have this 
clarification passed as a policy change, since it's just restating how 
it "already is".

> Did you cut and paste the wrong section?  Please resend the section 
> which refers to "unique routing policies".  You quoted a section 
> regarding "Separate unique 'globally routable' address space' "

I believe I outlined how "separate unique globally routable address 
space" equates to "unique routing policies" in a previous e-mail, but 
let me know if you didn't understand it and I'll be happy to try and 
explain it again.

> > What does "I've already allocated address blocks to my POPs, which I 
> > cannot rearrange", have to do with "geographic distance and diversity 
> > requirements"? Where does this language come from? What is your basis in 
> > the policy to support this claim?
> 
> You need a 'compelling reason' to have your infrastructure considered
> _multiple discrete networks_

Uh huh... Funny, I would have thought that meeting one of the example 
"compelling reasons" listed in the policy would serve as proof that you 
have a compelling reason. Meanwhile, you seem to feel that you need to 
add new, undocumented conditions to the example "compelling reasons" in 
order to justify a compelling reason. I fail to see how this makes any 
kind of sense, or can be justified under the current policy.

> > When has this claim ever been applied 
> > to any other MDN applicant? And for the record, that part *IS* 
> > completely true in my specific situation, so it's not even a blocker, 
> > but it's also complete nonsense too, and needs to be called out as such.
> 
> Richard - If that part is completely true in your situation, then 
> please reapply asap. You indicated otherwise on your last request to 
> ARIN for space under the MDN policy.

No really I didn't, and this is the part you keep failing to understand! 
All I said was that I could potentially work around the need for this 
policy by doing something in a suboptimal way, but in the SAME WAY that 
everyone else could be too. If you think that everyone else can't do it 
too, you're confused, but fortunately the policy says NOTHING about "you 
must not be able to do this any other way". Maybe I should have just 
lied and saved myself the trouble, but I was trying to educate you on 
the practical realities of routing on the Internet. I guess no good deed 
goes unpunished, and all of that.

> If that's the case, then the most constructive path would be to 
> propose unequivocal text for an MDN policy change.  If you believe 
> that "discrete networks" are "networks that implement unique routing 
> policies" then that would be a fine change.

I believe Owen has already done this for us, and I'm happy to support 
his proposal.

> That would also result in the elimination of ARIN having to determine 
> if a "compelling reason" was present at all, since with such a 
> definition, since we would simply be able to ask: "Do you have two or 
> more networks with unique routing policies?", and if the applicant 
> said "yes", then they would meet the MDN policy by having _multiple 
> discrete networks_ per definition of _discrete network_.

*NO* it absolutely would not! The fact that you keep saying this 
indicates a clear and massive misunderstanding somewhere, which is what 
I keep trying to correct!

Having a network with a unique routing policy is a STATE OF BEING. It is 
EASY to do, all you have to do is GO CONFIGURE IT AS SUCH. This is in NO 
WAY justification for doing so, and it is certainly not justification 
for obtaining any kind of special treatment from ARIN. For that, you 
need to have a COMPELLING REASON to *BE* in that state, which the 
current policy defines (quite well too, if you would stop trying to make 
up random undocumented rules just because you think you should be :P).

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From jcurran at arin.net  Mon Oct  3 21:29:43 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 4 Oct 2011 01:29:43 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
Message-ID: <957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>

On Oct 3, 2011, at 8:13 PM, Jeff Wheeler wrote:

> The problem is you, specifically, and a lot of other folks, have spent
> time and energy denying that the RIRs should or do care about routing
> instead of figuring out what non-obstructive, beneficial things you
> can do.  I would love to read the email from John Curran that says,
> "if we *did* care about routing, what could we do to reduce DFZ bloat
> without getting in anyone's way?  Do we need any different policy
> language, or are there things we can do today?  What kind of
> applications will be affected by proposed changes?  What affect will
> this have in a post-exhaustion world?"  I don't see any of that.

Jeff - 
 
 I think you mistake the role of ARIN staff from that of the 
 community; you're not going to read an email from me making 
 suggestions because we very much want ARIN to be driven by 
 this community, as opposed to the staff's idea of how things 
 should work, and this means that if you have any ideas about 
 how to reduce DFZ bloat, or any other change, you should talk
 about it right here on PPML.
 
 You might see me asking questions to make sure that we all
 understand what is proposed, but you won't see advocacy in
 either direction with regards to a particular proposal.  
 You note "I don't see any of that" (from the CEO), and I want 
 to make plain that the reason you don't is because that is 
 intentionally how ARIN is designed.

> As long as folks continue to deny that RIRs should involve themselves
> more explicitly in inter-domain routing policy, we are climbing higher
> and higher up a hill, and v4 exhaustion may push us over a cliff.  I
> don't think anyone wants to upgrade all of their routers because ARIN
> leadership were afraid to explore what benefits (and disadvantages)
> there could be from modifying policy interpretation, and from no
> longer shying away from policy changes that impact routing policy.

 If there are changes that should be made for good reasons to protect
 the global routing table, let's hear them and let the community decide. 
 I honored that you think that I should just explore modifying things
 on my own to solve these weighty matters, but I really think that it
 takes a community to make those changes (as opposed to be based on 
 the views of one person who last had enable under ios 9.21? :-)

> What we do need is to control routing table bloat.  This should be the
> primary function of RIRs in an IPv6 world, and yet they continue to
> resist this job.

 No resistance here.  Why don't you propose some specific ideas for 
 what you think needs to be changed?

Thanks!
/John

John Curran
President and CEO
ARIN




From mysidia at gmail.com  Mon Oct  3 22:38:38 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 3 Oct 2011 21:38:38 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
Message-ID: <CAAAwwbWTZAVXytg=7=q5Ef5bE-pOtgD6pgTbMauiAC9K=2=T=Q@mail.gmail.com>

On Mon, Oct 3, 2011 at 7:13 PM, Jeff Wheeler <jsw at inconcepts.biz> wrote:
> I have given several examples of how ARIN takes routing policy into
> account when allocating addresses, even though the NPRM does not
> direct ARIN to do so. ?This is good -- ARIN has applied common sense
> to these areas of policy interpretation and we benefit from it.

ARIN does have built in things that take routing policy into account
in some manner  _when allocating addresses_.
Once you have your addresses, ARIN doesn't tell you how you can route them.

End user "Stupidity" as you refer to it, is independent of ARIN, and not related
to ARIN's mission of good stewardship of the IP address space.

There is no requirement that networks meet an  "efficient routing" criterion,
in regards to their global table announcements to continue to use their AS
number or existing addresses.

Policy for allocating new addresses wouldn't really effect an organization
that got all the addresses they needed, anyways.


So what measures would you propose ARIN should take,  where instead
ARIN currently doesn't set policy, due to excessive entanglement with
operational and technica issues  that are considered out of ARIN's scope?

--
-JH


From jsw at inconcepts.biz  Tue Oct  4 08:15:45 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Tue, 4 Oct 2011 08:15:45 -0400
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
Message-ID: <CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>

On Mon, Oct 3, 2011 at 9:29 PM, John Curran <jcurran at arin.net> wrote:
> ?I think you mistake the role of ARIN staff from that of the
> ?community; you're not going to read an email from me making

How ARIN staff interprets and implements policy has always had
significant impact.  I believe ARIN can reduce IPv6 DFZ bloat by doing
a better job of collecting the explicit intent of members receiving
allocations, by paying more attention to its routing registry.

For example, there are an increasing number of small prefixes in the
IPv6 DFZ, as ISPs are generally not sure what filtering is needed or
appropriate.  Today, this is not a severe problem, because the v6 DFZ
is small and deployment remains in its infancy.  This situation may
evolve rapidly in the next several years, to a point where allocations
being made today become a new "swamp" that could eventually be far
worse than its v4 counterpart.

I don't want to see stupidity impact the v6 DFZ because the larger
address space increases risk in this area.  There should not be
organizations with /32 allocations who are announcing /48 networks to
the DFZ, yet there are.  Some of this is certainly done with explicit
intent, but much of it is doubtlessly out of sheer stupidity.
Individual transit networks are not motivated to police their
customers' advertisements because it simply turns customers to their
competitors.  I have one down-stream customer who announces over 100
DFZ routes, yet has three RIR allocations.  This is terrible, but if I
refuse to honor those routes, they will simply go to someone else;
this is made obvious by the fact that they have other transit
providers who gladly accept the routes to get their business.  It is
not hard to imagine a future where this down-stream has even more
de-aggregates, because they can create an awful lot of /48s out of a
/32; and ISPs are not in a good position to police that.

ARIN should start by making it easy and necessary for members to
express what routes they intend to inject to the DFZ when they receive
allocations.  If your IRR was treated as a useful tool for members and
operators, instead of an afterthought (does it have any authentication
mechanism yet?), you would already be there.

I believe in the future, the ARIN membership will realize that we need
it to police routing table bloat, or the v4 tables we have today will
look small and orderly by comparison.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From jcurran at arin.net  Tue Oct  4 08:51:52 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 4 Oct 2011 12:51:52 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
	<CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
Message-ID: <6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>

On Oct 4, 2011, at 8:15 AM, Jeff Wheeler wrote:

> For example, there are an increasing number of small prefixes in the
> IPv6 DFZ, as ISPs are generally not sure what filtering is needed or
> appropriate.  Today, this is not a severe problem, because the v6 DFZ
> is small and deployment remains in its infancy.  This situation may
> evolve rapidly in the next several years, to a point where allocations
> being made today become a new "swamp" that could eventually be far
> worse than its v4 counterpart.

I concur that this is a distinct possibility.

> I don't want to see stupidity impact the v6 DFZ because the larger
> address space increases risk in this area.  There should not be
> organizations with /32 allocations who are announcing /48 networks to
> the DFZ, yet there are.  Some of this is certainly done with explicit
> intent, but much of it is doubtlessly out of sheer stupidity.
> Individual transit networks are not motivated to police their
> customers' advertisements because it simply turns customers to their
> competitors.  I have one down-stream customer who announces over 100
> DFZ routes, yet has three RIR allocations.  This is terrible, but if I
> refuse to honor those routes, they will simply go to someone else;
> this is made obvious by the fact that they have other transit
> providers who gladly accept the routes to get their business.  It is
> not hard to imagine a future where this down-stream has even more
> de-aggregates, because they can create an awful lot of /48s out of a
> /32; and ISPs are not in a good position to police that.
> 
> ARIN should start by making it easy and necessary for members to
> express what routes they intend to inject to the DFZ when they receive
> allocations.  If your IRR was treated as a useful tool for members and
> operators, instead of an afterthought (does it have any authentication
> mechanism yet?), you would already be there.

(Re: authentication, see last's weeks IRR upgrade announcement:
https://www.arin.net/announcements/2011/20110929.html)

Hmm... the ability of folks to express what routes they intend to 
announce doesn't necessarily mean you won't still see an abundance 
of announcements; you'll just see appropriate IRR entries describing 
that routing config in the IRR.

If folks want to tie address policy more tightly to declared routing
policy, that can be done.  Again, this is not something for ARIN to 
do without clear community direction in this area.

> I believe in the future, the ARIN membership will realize that we need
> it to police routing table bloat, or the v4 tables we have today will
> look small and orderly by comparison.

I highly suggest discussion of these ideas on this mailing list or in person 
at Philly (both in the hallways and at the open microphone session). ARIN 
is your organization, and to the extent the membership supports this as a
direction, it will happen.

Thanks!
/John

John Curran
President and CEO
ARIN




From hannigan at gmail.com  Tue Oct  4 09:10:47 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 4 Oct 2011 09:10:47 -0400
Subject: [arin-ppml] ARIN public policy meeting and 2011-9
Message-ID: <CAMDXq5PGGHjbC7rk01Ph9VJfQwtmJzmfS0vho28Wuo5RSc4voQ@mail.gmail.com>

I noticed that we had scheduled the discussion for ARIN 2011-9 on Thursday,
later in the day.



   - ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4
   allocation mechanisms by the
IANA<https://www.arin.net/policy/proposals/2011_9.html>

  **


I would like to suggest that we move this to Wednesday, in the 2:15 slot, so
that we can get maximum participation by both the usual suspects that are
always at ARIN meetings and the general NANOG community.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111004/37c65aa5/attachment.htm>

From jsw at inconcepts.biz  Tue Oct  4 09:33:07 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Tue, 4 Oct 2011 09:33:07 -0400
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
	<CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
	<6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>
Message-ID: <CAPWAtbJ8Y-cPd_LoTJTJMjVBDxyY-MPSsPoibj2rnqkGQ2VXTw@mail.gmail.com>

On Tue, Oct 4, 2011 at 8:51 AM, John Curran <jcurran at arin.net> wrote:
> On Oct 4, 2011, at 8:15 AM, Jeff Wheeler wrote:
>> evolve rapidly in the next several years, to a point where allocations
>> being made today become a new "swamp" that could eventually be far
>> worse than its v4 counterpart.
>
> I concur that this is a distinct possibility.

I think it is the inevitable outcome of current allocation policy and
the lack of any neutral entity that takes interest in routing table
growth.  The RIRs are not able to dictate inter-domain routing policy,
and if unease about RPKI is any indicator, most members do not want
them to be tasked with that.  This doesn't mean the RIRs shouldn't
facilitate sensible guidelines.  We should be asking them to do that.

> (Re: authentication, see last's weeks IRR upgrade announcement:
> https://www.arin.net/announcements/2011/20110929.html)

It seems that integration with the ARIN web site / registration
systems, as I believe was your goal earlier this year, did not happen?
 I think that was a perfectly good idea, but obviously you have
addressed the security concerns I raised, which is a prerequisite to
anything more useful.

> Hmm... the ability of folks to express what routes they intend to
> announce doesn't necessarily mean you won't still see an abundance
> of announcements; you'll just see appropriate IRR entries describing
> that routing config in the IRR.

This is certainly true, but you would be surprised how common it is
for inexperienced operators to leak a bunch of /24s from their new RIR
allocation simply by mistake.  Many North American networks do not use
an IRR or rely on their ISP to guess at their intent and create "proxy
objects," which is why the various IRRs in common use by ARIN-region
networks are such a mess.  It is a contributor to DFZ bloat.

If an operator really wants to inject a route to the DFZ, I don't
think I want ARIN to be in the business of stopping them.  I would
like ARIN to be in the business of making it easy for transit networks
to differentiate between intent and accidents.

> If folks want to tie address policy more tightly to declared routing
> policy, that can be done. ?Again, this is not something for ARIN to
> do without clear community direction in this area.

I really think it's too late for this to really be fixed where IPv4 is
concerned, but IPv6 DFZ is "fixable" because it isn't too bad yet, and
there is plenty of time to institute sensible policies, and for ARIN
to provide operators with useful tools, like an IRR that is easier to
use (now that it's secure.)

>> I believe in the future, the ARIN membership will realize that we need
>> it to police routing table bloat, or the v4 tables we have today will
>> look small and orderly by comparison.
>
> I highly suggest discussion of these ideas on this mailing list or in person
> at Philly (both in the hallways and at the open microphone session). ARIN
> is your organization, and to the extent the membership supports this as a
> direction, it will happen.

It may be time to revisit some old lessons that many of us take for
granted.  I received an off-list mail in response to this thread from
an operator asking how he could clean up his advertisements.  He has
common transit at many or all of his locations, and was apparently not
aware that he could use no-export functionality to avoid injecting his
de-aggregates to the DFZ.  The reality is that there are thousands of
networks being run by inexperienced people who may clean up their
advertisements if they are simply shown how.  The person asked if I
had any links to presentations or documentation that would provide him
guidance, and I am sorry to say that I had none, and simply suggested
some options to him by email.  It's understandable that he was not
aware of how he could do this better.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From jcurran at arin.net  Tue Oct  4 10:08:26 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 4 Oct 2011 14:08:26 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAPWAtbJ8Y-cPd_LoTJTJMjVBDxyY-MPSsPoibj2rnqkGQ2VXTw@mail.gmail.com>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
	<CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
	<6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>
	<CAPWAtbJ8Y-cPd_LoTJTJMjVBDxyY-MPSsPoibj2rnqkGQ2VXTw@mail.gmail.com>
Message-ID: <CC95BF4E-A921-4AD5-98B3-E186C951BD4D@arin.net>

On Oct 4, 2011, at 9:33 AM, Jeff Wheeler wrote:
> 
>> (Re: authentication, see last's weeks IRR upgrade announcement:
>> https://www.arin.net/announcements/2011/20110929.html)
> 
> It seems that integration with the ARIN web site / registration
> systems, as I believe was your goal earlier this year, did not happen?
> I think that was a perfectly good idea, but obviously you have
> addressed the security concerns I raised, which is a prerequisite to
> anything more useful.

We have to pace our development efforts, and provide incremental 
improvements in multiple areas at once (ARIN Online registration
capabilities, Online billing support, RESTful enhancements, IRR
improvements, RPKI development, etc.)  We haven't given up on 
further ARIN Online/IRR integration, but need to prioritize the
work and sometimes this means doing things next year to keep this
year's expenses within plan.

> This is certainly true, but you would be surprised how common it is
> for inexperienced operators to leak a bunch of /24s from their new RIR
> allocation simply by mistake.  Many North American networks do not use
> an IRR or rely on their ISP to guess at their intent and create "proxy
> objects," which is why the various IRRs in common use by ARIN-region
> networks are such a mess.  It is a contributor to DFZ bloat.
> 
> If an operator really wants to inject a route to the DFZ, I don't
> think I want ARIN to be in the business of stopping them.  I would
> like ARIN to be in the business of making it easy for transit networks
> to differentiate between intent and accidents.

Makes sense (and was very clearly stated - thanks)

>> If folks want to tie address policy more tightly to declared routing
>> policy, that can be done.  Again, this is not something for ARIN to
>> do without clear community direction in this area.
> 
> I really think it's too late for this to really be fixed where IPv4 is
> concerned, but IPv6 DFZ is "fixable" because it isn't too bad yet, and
> there is plenty of time to institute sensible policies, and for ARIN
> to provide operators with useful tools, like an IRR that is easier to
> use (now that it's secure.)
> 
>>> I believe in the future, the ARIN membership will realize that we need
>>> it to police routing table bloat, or the v4 tables we have today will
>>> look small and orderly by comparison.
>> 
>> I highly suggest discussion of these ideas on this mailing list or in person
>> at Philly (both in the hallways and at the open microphone session). ARIN
>> is your organization, and to the extent the membership supports this as a
>> direction, it will happen.
> 
> It may be time to revisit some old lessons that many of us take for
> granted.  I received an off-list mail in response to this thread from
> an operator asking how he could clean up his advertisements.  He has
> common transit at many or all of his locations, and was apparently not
> aware that he could use no-export functionality to avoid injecting his
> de-aggregates to the DFZ.  The reality is that there are thousands of
> networks being run by inexperienced people who may clean up their
> advertisements if they are simply shown how.  The person asked if I
> had any links to presentations or documentation that would provide him
> guidance, and I am sorry to say that I had none, and simply suggested
> some options to him by email.  It's understandable that he was not
> aware of how he could do this better.

There's a group called NANOG, and I'm certain that there's got to be 
at least a few presentations in their archives that would help...
Neither ARIN nor NANOG do extensive outreach to the new network 
operator community; i.e. we occasionally have sessions or training
which addresses such, but don't run a formal "how to get started" 
program or a help resource with the same information organized in
a central place for new service providers. If this is of interest,
to the point where the community thinks it is worth the investment,
then it can be done (either directly, or by some of the more grass
roots team out there than would need funding to make this happen)

FYI,
/John

John Curran
President and CEO
ARIN
\



From jsw at inconcepts.biz  Tue Oct  4 10:36:37 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Tue, 4 Oct 2011 10:36:37 -0400
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CC95BF4E-A921-4AD5-98B3-E186C951BD4D@arin.net>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
	<CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
	<6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>
	<CAPWAtbJ8Y-cPd_LoTJTJMjVBDxyY-MPSsPoibj2rnqkGQ2VXTw@mail.gmail.com>
	<CC95BF4E-A921-4AD5-98B3-E186C951BD4D@arin.net>
Message-ID: <CAPWAtbJTvOJMJkDiyOi27aOe2CtASzfW_d8C1MjUtK3KLD44TA@mail.gmail.com>

On Tue, Oct 4, 2011 at 10:08 AM, John Curran <jcurran at arin.net> wrote:
> We have to pace our development efforts, and provide incremental
> improvements in multiple areas at once (ARIN Online registration
> capabilities, Online billing support, RESTful enhancements, IRR
> improvements, RPKI development, etc.) ?We haven't given up on
> further ARIN Online/IRR integration, but need to prioritize the
> work and sometimes this means doing things next year to keep this
> year's expenses within plan.

It's worth mentioning that you stated the reason for ARIN needing from
March (?) until August to do something simple, like enable support for
passwords and PGP, in the ARIN IRR was that your I.T. folks intended
to integrate the IRR with other ARIN services.  I point this out
because I strongly believe that your I.T. staff is inadequate and
needs a great deal of improvement.

Not only did a simple task to address a very critical security concern
which could have been exploited by "bad guys" at any time (and still
could, while many mntners remain without passwords/etc) get ballooned
into a larger project which was to take many months, but you then
missed your projected completion date by a month or two and had to
back-peddle and do what I originally suggested: take care of the
security concern urgently, and look at a more sophisticated
integration later on.

If ARIN needs to have a larger I.T. budget to get things done, I for
one am happy to advise my clients to vote in favor of fee increases.

TCAM and tree-based look-up engines with a large memory capacity (for
DFZ routes) are expensive to operate.  They use a lot of power,
produce a lot of heat, and limit the density of routers.  The more
routes there are in the DFZ, the more money we all spend on the next
generation of routers to handle that growth.

The larger the DFZ, the more CPU is needed to converge in a reasonable
period of time (see Richard Steenbergen's many posts on this topic
lately.)  Since single-core performance is not growing much anymore,
vendors are now looking at parallel route processing, with a big R&D
expense to deliver this capability and associated performance
improvement.  IETF is producing various ideas on how to pre-populate
repair paths into the network.

There is a great deal of work going on to maintain the reliability of
the Internet as the DFZ continues to grow, but really, not much at all
is being done to constrain the DFZ in the most sensible manner -- by
reducing unnecessary routes introduced simply by mistake.

If ARIN needs to spend a million dollars to write some Perl scripts,
by all means, spend it.  When you consider the long-term cost of a
continually growing DFZ, and ever-increasing FIB memory (heat/power)
to keep up with it, there is no "greener" I.T. project that ARIN could
undertake, and none with a better cost / benefit equation to the
community, than investing in a more sensible DFZ.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From jcurran at arin.net  Tue Oct  4 11:04:18 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 4 Oct 2011 15:04:18 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAPWAtbJTvOJMJkDiyOi27aOe2CtASzfW_d8C1MjUtK3KLD44TA@mail.gmail.com>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
	<CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
	<6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>
	<CAPWAtbJ8Y-cPd_LoTJTJMjVBDxyY-MPSsPoibj2rnqkGQ2VXTw@mail.gmail.com>
	<CC95BF4E-A921-4AD5-98B3-E186C951BD4D@arin.net>
	<CAPWAtbJTvOJMJkDiyOi27aOe2CtASzfW_d8C1MjUtK3KLD44TA@mail.gmail.com>
Message-ID: <1F096BCC-6EE9-4699-8052-1B5E274EC9E2@arin.net>

On Oct 4, 2011, at 10:36 AM, Jeff Wheeler wrote:

> On Tue, Oct 4, 2011 at 10:08 AM, John Curran <jcurran at arin.net> wrote:
>> We have to pace our development efforts, and provide incremental
>> improvements in multiple areas at once (ARIN Online registration
>> capabilities, Online billing support, RESTful enhancements, IRR
>> improvements, RPKI development, etc.)  We haven't given up on
>> further ARIN Online/IRR integration, but need to prioritize the
>> work and sometimes this means doing things next year to keep this
>> year's expenses within plan.
> 
> It's worth mentioning that you stated the reason for ARIN needing from
> March (?) until August to do something simple, like enable support for
> passwords and PGP, in the ARIN IRR was that your I.T. folks intended
> to integrate the IRR with other ARIN services.  I point this out
> because I strongly believe that your I.T. staff is inadequate and
> needs a great deal of improvement.

Thanks for your perspective on this; I obviously do not agree (but
that's to be expected - If I had, I would have addressed it already)

> Not only did a simple task to address a very critical security concern
> which could have been exploited by "bad guys" at any time (and still
> could, while many mntners remain without passwords/etc) get ballooned
> into a larger project which was to take many months, but you then
> missed your projected completion date by a month or two and had to
> back-peddle and do what I originally suggested: take care of the
> security concern urgently, and look at a more sophisticated
> integration later on.

There was quite a bit of work involved behind the scenes to make
this happen (but that's likely not apparent)

> If ARIN needs to have a larger I.T. budget to get things done, I for
> one am happy to advise my clients to vote in favor of fee increases.

We've never raised fees, and that's not the general direction that
I've been given in the past by the Board.  In fact, we've lowered
them 4 (or 5?) times since ARIN's inception, and I do not believe
that such has had any impact on our services.  In fact, we've done 
more automation work in the last 2 1/2 year than we've done in the 
history of ARIN, and you can review the development achievements
here: <https://www.arin.net/features/index.html>

> TCAM and tree-based look-up engines with a large memory capacity (for
> DFZ routes) are expensive to operate.  They use a lot of power,
> produce a lot of heat, and limit the density of routers.  The more
> routes there are in the DFZ, the more money we all spend on the next
> generation of routers to handle that growth.
> 
> The larger the DFZ, the more CPU is needed to converge in a reasonable
> period of time (see Richard Steenbergen's many posts on this topic
> lately.)  Since single-core performance is not growing much anymore,
> vendors are now looking at parallel route processing, with a big R&D
> expense to deliver this capability and associated performance
> improvement.  IETF is producing various ideas on how to pre-populate
> repair paths into the network.

Acknowledged (although many of us opted for MPLS and fast reroute paths 
for similar capabilities in architecting for specific path failures in 
advance)

> There is a great deal of work going on to maintain the reliability of
> the Internet as the DFZ continues to grow, but really, not much at all
> is being done to constrain the DFZ in the most sensible manner -- by
> reducing unnecessary routes introduced simply by mistake.
> 
> If ARIN needs to spend a million dollars to write some Perl scripts,
> by all means, spend it.  When you consider the long-term cost of a
> continually growing DFZ, and ever-increasing FIB memory (heat/power)
> to keep up with it, there is no "greener" I.T. project that ARIN could
> undertake, and none with a better cost / benefit equation to the
> community, than investing in a more sensible DFZ.

Please make a concrete proposal for discussion by this community.  It
would be quite timely, since myself and the staff are presently trying
to prioritize the 2012 budget and looking forward to input here and at
the Public Policy Meeting next week.

Thanks!
/John

John Curran
President and CEO
ARIN




From susanh at arin.net  Tue Oct  4 11:37:42 2011
From: susanh at arin.net (Susan Hamlin)
Date: Tue, 4 Oct 2011 15:37:42 +0000
Subject: [arin-ppml] [arin-discuss] ARIN public policy meeting and 2011-9
In-Reply-To: <CAMDXq5PGGHjbC7rk01Ph9VJfQwtmJzmfS0vho28Wuo5RSc4voQ@mail.gmail.com>
Message-ID: <CAB09FB5.1B861%susanh@corp.arin.net>

Hello Martin,

Thank you for your suggestion to move the global policy proposal discussion to earlier in the meeting agenda in order to maximize attendee discussion.

As you may note, the policy proposal topics are grouped in several instances and we believe the placement of 2011-9 makes sense when grouped with
ARIN-2011-13: IPv4 Number Resources for Use Within Region and ARIN-2011-1: ARIN Inter-RIR Transfers, all on Thursday afternoon.

The discussion of 2011-7: Compliance Requirement was placed on Wednesday afternoon as it should be of interest to NANOG attendees since it deals with cutting off DNS. We would like operator input on this proposal too. Given that 2011-7  may enjoy lengthy discussion, it is  then difficult to move 2011-9 and have it fit in the time slot currently allotted.

It is our experience that most of the operators who stay for Wednesday afternoon  have registered for the ARIN meeting and generally stay through the end of the Public Policy portion of our meeting.
Currently there are over 80 registrants who plan to attend both the NANOG and ARIN meeting so we hope for great discussions both days of the ARIN Public Policy Meeting.


Regards,

Susan Hamlin
Director, Communications and Member Services
American Registry for Internet Numbers (ARIN)

From: Martin Hannigan <hannigan at gmail.com<mailto:hannigan at gmail.com>>
Date: Tue, 4 Oct 2011 09:10:47 -0400
To: <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>, <arin-discuss at arin.net<mailto:arin-discuss at arin.net>>
Subject: [arin-discuss] ARIN public policy meeting and 2011-9



I noticed that we had scheduled the discussion for ARIN 2011-9 on Thursday, later in the day.



  *   ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA<https://www.arin.net/policy/proposals/2011_9.html>





I would like to suggest that we move this to Wednesday, in the 2:15 slot, so that we can get maximum participation by both the usual suspects that are always at ARIN meetings and the general NANOG community.

Best,

-M<



_______________________________________________ ARIN-Discuss You are receiving this message because you are subscribed to the ARIN Discussion Mailing List (ARIN-discuss at arin.net<mailto:ARIN-discuss at arin.net>). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-discuss Please contact info at arin.net<mailto: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/20111004/c39a59b6/attachment.htm>

From hannigan at gmail.com  Tue Oct  4 12:14:03 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 4 Oct 2011 12:14:03 -0400
Subject: [arin-ppml] [arin-discuss] ARIN public policy meeting and 2011-9
In-Reply-To: <CAB09FB5.1B861%susanh@corp.arin.net>
References: <CAMDXq5PGGHjbC7rk01Ph9VJfQwtmJzmfS0vho28Wuo5RSc4voQ@mail.gmail.com>
	<CAB09FB5.1B861%susanh@corp.arin.net>
Message-ID: <CAMDXq5M-u2oyT2KHiAKPVnDMvVKEHUhepoz3ahsPdvOUCyvd7A@mail.gmail.com>

On Tue, Oct 4, 2011 at 11:37 AM, Susan Hamlin <susanh at arin.net> wrote:

>   Hello Martin,
>
>  Thank you for your suggestion to move the global policy proposal
> discussion to earlier in the meeting agenda in order to maximize attendee
> discussion.
>
>  As you may note, the policy proposal topics are grouped in several
> instances and we believe the placement of 2011-9 makes sense when grouped
> with
>  ARIN-2011-13: IPv4 Number Resources for Use Within
> Region and ARIN-2011-1: ARIN Inter-RIR Transfers, all on Thursday afternoon.
>

Thanks. I'd point out that the vast majority of cross attendees are again
"the usual suspects" and in the interest of participation, we are "powered
by participation", we may get more power for these proposals if we are
closer to NANOG. :-)

You could always consider a swap of these two items with Wednesdays two
items.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111004/97ac0850/attachment.htm>

From jsw at inconcepts.biz  Tue Oct  4 12:15:54 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Tue, 4 Oct 2011 12:15:54 -0400
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <1F096BCC-6EE9-4699-8052-1B5E274EC9E2@arin.net>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
	<CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
	<6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>
	<CAPWAtbJ8Y-cPd_LoTJTJMjVBDxyY-MPSsPoibj2rnqkGQ2VXTw@mail.gmail.com>
	<CC95BF4E-A921-4AD5-98B3-E186C951BD4D@arin.net>
	<CAPWAtbJTvOJMJkDiyOi27aOe2CtASzfW_d8C1MjUtK3KLD44TA@mail.gmail.com>
	<1F096BCC-6EE9-4699-8052-1B5E274EC9E2@arin.net>
Message-ID: <CAPWAtbL9DgmMzdPzjqBJyLO4hUN4jaY6RGgfCzM45N47OakAMg@mail.gmail.com>

On Tue, Oct 4, 2011 at 11:04 AM, John Curran <jcurran at arin.net> wrote:
> Thanks for your perspective on this; I obviously do not agree (but
> that's to be expected - If I had, I would have addressed it already)

A March until September turn-around time on enabling passwords in your
IRR doesn't indicate to you that you need more I.T. resources?  Are
you still not sure why the ARIN IRR is an important tool for
operators?

Do you know what havoc would be caused if some malicious person
decided to delete or corrupt all the unsecured data in the ARIN IRR?
There would be wide-spread network outages as transit provider
prefix-lists were updated.  A lot of clueless customers would not
understand why, and simply call their ISP for help.  ISPs would have
to roll back to the previous day's ARIN IRR data ... and could no
longer trust any data from ARIN IRR because of the numerous unsecured
mntners which could be attacked again.  This would be a lot worse than
any route leaks in the past few years, would make the news, and would
have governments questioning the competence of ARIN (steward of this
information) and asking why the ability to modify this information
wasn't simply ... protected by passwords.

It still isn't, and won't be, until a significant portion of ARIN IRR
mntners change their authentication mechanism.

The fact that it took ARIN many months to fail to integrate the IRR
into your other systems in the planned manner, *and* also took many
months to simply enable passwords, without you believing that you have
inadequate I.T. resources, should cast doubt on your understanding of
how inter-domain routing works (at minimum) and your ability to
prioritize ARIN's expenditures (time and money.)

> We've never raised fees, and that's not the general direction that

I'm not questioning that ARIN should try to be efficient.  That is
certainly good.

Having no I.T. resources to work on ways to reduce DFZ bloat, or
address IRR security problems, is not good.  You have stated that your
I.T. resources are limited and must be prioritized, and this is true
of most organizations.  But if you can do useful things for the
community with additional I.T. budget, the notion of increasing fees,
or simply not reducing fees again very soon (since ARIN operates at a
surplus), should not be off the table.

>> The larger the DFZ, the more CPU is needed to converge in a reasonable
>> period of time (see Richard Steenbergen's many posts on this topic
>
> Acknowledged (although many of us opted for MPLS and fast reroute paths
> for similar capabilities in architecting for specific path failures in
> advance)

You don't understand the difference between inter-domain convergence
issues, and intra-domain ones.  They are certainly linked, but MPLS
FRR is not a solution to DFZ bloat driving up convergence times.  It's
not like operators can simply configure FRR and not have this concern.
 Besides that, if you reboot a box, FRR helps the rest of your
network; but it does not help that box, or the customers connected to
it, recover any faster.  This is why I mention that IETF is producing
new ideas in this area which might eventually help us, vendors have
done a lot of work, etc.

I don't mean to rudely call you out for not understanding the way
things work, but if you're going to point to FRR as a technical
solution, I think you should understand what problems that technology
does and does not address.

It certainly does not address power/heat issues -- in fact it
increases them, as do all the IETF ideas in this area.  There are
undoubtedly hundreds of thousands of routers participating in the DFZ,
each of which has OpEx associated with FIB memory.  If you could add
up the electric bill for all that memory, you'd quickly find that it
out-weighs the small cost of RIRs doing more work for us to reduce
accidental introductions of new routes to the DFZ.  The capital cost
of upgrades, too, is very significant and easily eclipses the I.T.
cost of controlling DFZ bloat.

> Please make a concrete proposal for discussion by this community. ?It
> would be quite timely, since myself and the staff are presently trying
> to prioritize the 2012 budget and looking forward to input here and at
> the Public Policy Meeting next week.

If you are saying, "put up or shut up," this is well-received.  I am
not a policy-hawk, and do not understand the process for directing
ARIN to "spend time and money on reducing DFZ bloat."  How can this be
accomplished?  What would be the procedure for asking members whether
or not they want to task ARIN with this, and spend necessary time and
money to do so?

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From jcurran at arin.net  Tue Oct  4 14:29:44 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 4 Oct 2011 18:29:44 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAPWAtbL9DgmMzdPzjqBJyLO4hUN4jaY6RGgfCzM45N47OakAMg@mail.gmail.com>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
	<CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
	<6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>
	<CAPWAtbJ8Y-cPd_LoTJTJMjVBDxyY-MPSsPoibj2rnqkGQ2VXTw@mail.gmail.com>
	<CC95BF4E-A921-4AD5-98B3-E186C951BD4D@arin.net>
	<CAPWAtbJTvOJMJkDiyOi27aOe2CtASzfW_d8C1MjUtK3KLD44TA@mail.gmail.com>
	<1F096BCC-6EE9-4699-8052-1B5E274EC9E2@arin.net>
	<CAPWAtbL9DgmMzdPzjqBJyLO4hUN4jaY6RGgfCzM45N47OakAMg@mail.gmail.com>
Message-ID: <43A2D9E4-304E-4829-A8B8-529B4FB1E7FB@arin.net>


On Oct 4, 2011, at 12:15 PM, Jeff Wheeler wrote:

> On Tue, Oct 4, 2011 at 11:04 AM, John Curran <jcurran at arin.net> wrote:
>> Thanks for your perspective on this; I obviously do not agree (but
>> that's to be expected - If I had, I would have addressed it already)
> 
> A March until September turn-around time on enabling passwords in your
> IRR doesn't indicate to you that you need more I.T. resources? 

Jeff - As I noted earlier, this request was added to an existing work 
plan for a very busy year.  I'm actually quite pleased that we were 
able to add anything to the year, given the amount of work this year.

> It still isn't, and won't be, until a significant portion of ARIN IRR
> mntners change their authentication mechanism.

Correct.  What should be done in this area?

> The fact that it took ARIN many months to fail to integrate the IRR
> into your other systems in the planned manner, *and* also took many
> months to simply enable passwords, without you believing that you have
> inadequate I.T. resources, should cast doubt on your understanding of
> how inter-domain routing works (at minimum) and your ability to
> prioritize ARIN's expenditures (time and money.)

Thanks Jeff!  

>> We've never raised fees, and that's not the general direction that
> 
> I'm not questioning that ARIN should try to be efficient.  That is
> certainly good.
> 
> Having no I.T. resources to work on ways to reduce DFZ bloat, or
> address IRR security problems, is not good.  

Agreed - we have them, but they're working on an specific list of
deliverables.  Adding deliverables to the current year is always 
a challenge.

> You have stated that your
> I.T. resources are limited and must be prioritized, and this is true
> of most organizations.  But if you can do useful things for the
> community with additional I.T. budget, the notion of increasing fees,
> or simply not reducing fees again very soon (since ARIN operates at a
> surplus), should not be off the table.

Agreed.

What useful things do you want us to do to "reduce DFZ bloat"  You have
mentioned that twice but not indicated exactly what you are looking for...

>>> The larger the DFZ, the more CPU is needed to converge in a reasonable
>>> period of time (see Richard Steenbergen's many posts on this topic
>> 
>> Acknowledged (although many of us opted for MPLS and fast reroute paths
>> for similar capabilities in architecting for specific path failures in
>> advance)
> 
> You don't understand the difference between inter-domain convergence
> issues, and intra-domain ones.  They are certainly linked, but MPLS
> FRR is not a solution to DFZ bloat driving up convergence times.  It's
> not like operators can simply configure FRR and not have this concern.
> 

> Besides that, if you reboot a box, FRR helps the rest of your
> network; but it does not help that box, or the customers connected to
> it, recover any faster.  This is why I mention that IETF is producing
> new ideas in this area which might eventually help us, vendors have
> done a lot of work, etc.
> 
> I don't mean to rudely call you out for not understanding the way
> things work, but if you're going to point to FRR as a technical
> solution, I think you should understand what problems that technology
> does and does not address.

I said acknowledged your point about not having enough CPU to quickly
converge.  That actually occurs in large networks both internally and
externally: references to using FRR 'similar capabilities in architecting 
for specific path failures' is obviously for avoiding needless internal
recalcs; I did not mean to imply that it directly addresses DFZ bloat 
at all but simply that the concept of "prepopulation" is where we all 
go when we run out of enough resources to do things in a timely manner.

> 
>> Please make a concrete proposal for discussion by this community.  It
>> would be quite timely, since myself and the staff are presently trying
>> to prioritize the 2012 budget and looking forward to input here and at
>> the Public Policy Meeting next week.
> 
> If you are saying, "put up or shut up," this is well-received.  I am
> not a policy-hawk, and do not understand the process for directing
> ARIN to "spend time and money on reducing DFZ bloat."  How can this be
> accomplished?  What would be the procedure for asking members whether
> or not they want to task ARIN with this, and spend necessary time and
> money to do so?

Let's look at some options -

  - Do you want ARIN to alter the way in which it does address allocations
    so it ties to the state of someone's IRR information?  If so, that
    would be an address policy suggestion.  I have no idea how the community
    would feel about either requiring the IRR to be updated to receive or 
    maintain address space, but you've got to get from the generic statement
    "do something to reduce the DFZ bloat" to "issue/don't issue/reclaim under 
    conditions z,y,x"
  
  - If all you want is for ARIN to improve its IRR services in some manner,
    and expend more budget in this area in the future, explain the feature
    that you want to me and I'll include it in the next list of objectives.
    (If you want to do it formally, you can submit the same to the suggestion
    process - https://www.arin.net/participate/acsp/index.html

Thanks,
/John

John Curran
President and CEO
ARIN









From jsw at inconcepts.biz  Wed Oct  5 02:33:28 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Wed, 5 Oct 2011 02:33:28 -0400
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <43A2D9E4-304E-4829-A8B8-529B4FB1E7FB@arin.net>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
	<CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
	<6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>
	<CAPWAtbJ8Y-cPd_LoTJTJMjVBDxyY-MPSsPoibj2rnqkGQ2VXTw@mail.gmail.com>
	<CC95BF4E-A921-4AD5-98B3-E186C951BD4D@arin.net>
	<CAPWAtbJTvOJMJkDiyOi27aOe2CtASzfW_d8C1MjUtK3KLD44TA@mail.gmail.com>
	<1F096BCC-6EE9-4699-8052-1B5E274EC9E2@arin.net>
	<CAPWAtbL9DgmMzdPzjqBJyLO4hUN4jaY6RGgfCzM45N47OakAMg@mail.gmail.com>
	<43A2D9E4-304E-4829-A8B8-529B4FB1E7FB@arin.net>
Message-ID: <CAPWAtbJWMzS6Y1vFZcWg_JtaOu7G0K_YJXVpBXW7t=M3EBv32A@mail.gmail.com>

On Tue, Oct 4, 2011 at 2:29 PM, John Curran <jcurran at arin.net> wrote:
>> It still isn't, and won't be, until a significant portion of ARIN IRR
>> mntners change their authentication mechanism.
>
> Correct. ?What should be done in this area?

I see several options with different associated headaches.

The most obvious to me is to eliminate email authentication as a
supported choice, and replace the auth: attributes of those mntner
objects with a garbage password.  This would force those mntners to
contact ARIN (or perhaps use your web site automation?) to "reset
their password" before their objects can be modified.  This way, the
current objects will remain in the database; they cannot be
maliciously altered or erased without non-trivial efforts; but it will
create some customer support issues which will add work-load.

Another would be to simply email all the IRR users and beg them to
change their authentication, cautioning them that their IRR data may
be corrupted or erased by malicious persons if they do not take
action.  Again, support issues will happen, because many users are not
knowledgeable enough to handle this without picking up the phone.  At
least you have warned them about the potential for abuse.

I do not think it would be positive at all if ARIN, whose very
existence largely defends us from government interference in
addressing and routing policy, ended up in the newspaper because it
DID NOT PROTECT ROUTING INFORMATION WITH SOMETHING AS SIMPLE AS
PASSWORDS.  If my use of capslock disturbs you, imagine the flurry of
phone calls from clueless reporters that would happen if someone
erased half the ARIN IRR.

> What useful things do you want us to do to "reduce DFZ bloat" ?You have
> mentioned that twice but not indicated exactly what you are looking for...

A good starting point would be to have a user-friendly interface to
ARIN IRR.  MERIT RADB has one that is not bad, but it isn't quite
"point and click," which would benefit the droves of less
knowledgeable operators participating in the DFZ today.  It should be
easy to publish correct IRR information.

I would like it if ARIN had a bot that emailed the technical contact
for address spaces when new DFZ advertisements appear (for a sustained
period of time, say a week) that do not match existing IRR data.  A
friendly message with a link to click on so the operator can log in
and update their IRR records would help them maintain accurate
database entries, and as a side-effect, it would inform them of
accidental advertisements.  As you are no doubt aware, it is normal to
build a transit customer prefix-list with "le /24" for all the
relevant route: objects, which in one way makes life a bit easier; but
contributes to the accidental bloat.

Richard's posts on multiple discrete networks is another factor, but
it is one I choose not to care much about, because I think the
accident / stupidity problem is much worse.  I'm not sure Richard
agrees with me and I might be wrong -- his concern may be more
important to fix.  I think the NRPM change that you believe is
necessary to get the result he wants would probably have potential for
abuse, and so I do not know how I feel about this.

> Let's look at some options -
>
> ?- Do you want ARIN to alter the way in which it does address allocations
> ? ?so it ties to the state of someone's IRR information? ?If so, that

Yes.

I would also like members who are going to announce a /24 to the DFZ
anyway to be able to request a /24.  This should have been done a very
long time ago.  The reason is not difficult to understand -- if a
member is going to announce a /24 and they already know that's what
they are going to do, you can put them into a suitable address space
where there should generally not be any de-aggregates beyond the
nominal allocation boundary, e.g. /20.  This ALREADY HAPPENS for
2002-3 allocations but not because the network will announce a long
route to the DFZ, but because 2002-3 allows them to have a pretty
small allocation and it was the intent of the community to make it
possible to filter garbage /24s and /22s out of other chunks of the
address space.

I further would like members to be able to request de-aggregated
address space for private interconnections, backbone, etc. that they
do not want to belong to a larger aggregate DFZ announcement.  For
example, I don't want a /24 I use for certain circuits to be announced
to the DFZ at all, but I do want DNS authority for it, and require
globally unique numbers for it.  I don't have a RIR /24, I have /20s
and larger.  In order to get this behavior, I have to jump through
some technical hoops which is not always practical or even possible;
or de-aggregate a /20 and not announce the aggregate route, but
instead announce a /21, /22, a /23, and a /24.  I don't do this but I
also don't get the technical benefit of having some globally unique
numbers for interconnection without having them be globally reachable.

I would like ARIN to come out strongly against any de-aggregation at
all in ISP /32s.  If someone needs to de-aggregate, give them more
/32s!  Strongly discourage them from announcing /48s because it will
be necessary for us all to honor these /48s, meaning we cannot simply
filter everything longer than /32 from the relevant chunks of address
space.  If members do not feel like they should receive a bunch of
/32s, then choose a different size and allocate these from special
space.

If we do not do something like the above, the IPv6 DFZ will make IPv4
look great.

> ?- If all you want is for ARIN to improve its IRR services in some manner,
> ? ?and expend more budget in this area in the future, explain the feature
> ? ?that you want to me and I'll include it in the next list of objectives.
> ? ?(If you want to do it formally, you can submit the same to the suggestion
> ? ?process - https://www.arin.net/participate/acsp/index.html

As I mentioned above, I would like the ARIN IRR to be user-friendly.
I agree with your idea that it be integrated into the other ARIN
online tools, and was hoping this would indeed be implemented as you
indicated earlier this year.  I would also like the data in it to be
accurate and for rules to exist on what route: objects may be created
by what user -- I don't think I should be able to insert a route:
object with origin: AS65555 unless I am logged in to the web site as
someone with permission to make routes in AS65555.  I also don't think
I should be able to make route: objects for address space that doesn't
belong to me.

I don't think users should even have to understand that they are
making a route: object, I think it should just say, here are the
allocations and assignments for you, and you can make IRR entries to
facilitate BGP routing if you want to.  This system needs to become
more straight-forward so novice operators can take advantage of it.
It doesn't have to come with a deck of cards and pressurized peanuts,
but if IRR is made easy to use, more people will utilize it.  Fewer
ISPs will dump trash routes into RADB (and then never erase them) and
fewer ISPs will just do all this manually.

I further think the ARIN IRR / tools should make it pretty damn easy
to get a prefix-list for a desired as-set or aut-num, in a way that is
machine-readable, so you don't have to download the files, generate
with your own tools, and so on.  It would be pretty nice if it was
easier for transit networks to take advantage of the data that is
there (and hopefully, more accurate and safe!) but this is
surprisingly hard for many of them.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From jcurran at arin.net  Wed Oct  5 05:40:00 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 5 Oct 2011 09:40:00 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CAPWAtbJWMzS6Y1vFZcWg_JtaOu7G0K_YJXVpBXW7t=M3EBv32A@mail.gmail.com>
References: <CAPWAtbKyntGv64zpBP-58xKKwpsqj=Z1eiCKVOx9Bnhp4mAASQ@mail.gmail.com>
	<3648F6F0-BC82-4D84-B427-D46E0CE42685@arin.net>
	<CAPWAtbKiSu7=c6nNht6-4ofURSUr+skk-BwMQQ650PFv=eeLng@mail.gmail.com>
	<957C24ED-369E-4F37-8EDF-F35D8A647353@arin.net>
	<CAPWAtbLJ5eyfayonjNmA4yEBE2=1nkPDxfnK55vGDX7KFNy+7g@mail.gmail.com>
	<6B816E64-4544-4327-AAB4-005FDC7CF128@arin.net>
	<CAPWAtbJ8Y-cPd_LoTJTJMjVBDxyY-MPSsPoibj2rnqkGQ2VXTw@mail.gmail.com>
	<CC95BF4E-A921-4AD5-98B3-E186C951BD4D@arin.net>
	<CAPWAtbJTvOJMJkDiyOi27aOe2CtASzfW_d8C1MjUtK3KLD44TA@mail.gmail.com>
	<1F096BCC-6EE9-4699-8052-1B5E274EC9E2@arin.net>
	<CAPWAtbL9DgmMzdPzjqBJyLO4hUN4jaY6RGgfCzM45N47OakAMg@mail.gmail.com>
	<43A2D9E4-304E-4829-A8B8-529B4FB1E7FB@arin.net>
	<CAPWAtbJWMzS6Y1vFZcWg_JtaOu7G0K_YJXVpBXW7t=M3EBv32A@mail.gmail.com>
Message-ID: <01B29C93-E481-48F7-83FA-7E30FE0A5199@arin.net>

On Oct 5, 2011, at 2:33 AM, Jeff Wheeler wrote:

> On Tue, Oct 4, 2011 at 2:29 PM, John Curran <jcurran at arin.net> wrote:
>>> It still isn't, and won't be, until a significant portion of ARIN IRR
>>> mntners change their authentication mechanism.
>> 
>> Correct.  What should be done in this area?
> 
> I see several options with different associated headaches.
> 
> The most obvious to me is to eliminate email authentication as a
> supported choice, and replace the auth: attributes of those mntner
> objects with a garbage password.  This would force those mntners to
> contact ARIN (or perhaps use your web site automation?) to "reset
> their password" before their objects can be modified.  This way, the
> current objects will remain in the database; they cannot be
> maliciously altered or erased without non-trivial efforts; but it will
> create some customer support issues which will add work-load.

It also may be possible to do something in combination with 
ARIN Online to minimize the telephone workload level.

>> What useful things do you want us to do to "reduce DFZ bloat"  You have
>> mentioned that twice but not indicated exactly what you are looking for...
> 
> A good starting point would be to have a user-friendly interface to
> ARIN IRR.  MERIT RADB has one that is not bad, but it isn't quite
> "point and click," which would benefit the droves of less
> knowledgeable operators participating in the DFZ today.  It should be
> easy to publish correct IRR information.
> 
> I would like it if ARIN had a bot that emailed the technical contact
> for address spaces when new DFZ advertisements appear (for a sustained
> period of time, say a week) that do not match existing IRR data. 

Got it.

>> Let's look at some options -
>> 
>>  - Do you want ARIN to alter the way in which it does address allocations
>>    so it ties to the state of someone's IRR information?  If so, that
> 
> Yes.
> 
> I would also like members who are going to announce a /24 to the DFZ
> anyway to be able to request a /24.  This should have been done a very
> long time ago.  The reason is not difficult to understand -- if a
> member is going to announce a /24 and they already know that's what
> they are going to do, you can put them into a suitable address space
> where there should generally not be any de-aggregates beyond the
> nominal allocation boundary, e.g. /20.  This ALREADY HAPPENS for
> 2002-3 allocations but not because the network will announce a long
> route to the DFZ, but because 2002-3 allows them to have a pretty
> small allocation and it was the intent of the community to make it
> possible to filter garbage /24s and /22s out of other chunks of the
> address space.
> 
> I further would like members to be able to request de-aggregated
> address space for private interconnections, backbone, etc. that they
> do not want to belong to a larger aggregate DFZ announcement.  For
> example, I don't want a /24 I use for certain circuits to be announced
> to the DFZ at all, but I do want DNS authority for it, and require
> globally unique numbers for it.  I don't have a RIR /24, I have /20s
> and larger.  In order to get this behavior, I have to jump through
> some technical hoops which is not always practical or even possible;
> or de-aggregate a /20 and not announce the aggregate route, but
> instead announce a /21, /22, a /23, and a /24.  I don't do this but I
> also don't get the technical benefit of having some globally unique
> numbers for interconnection without having them be globally reachable.
> 
> I would like ARIN to come out strongly against any de-aggregation at
> all in ISP /32s.  If someone needs to de-aggregate, give them more
> /32s!  Strongly discourage them from announcing /48s because it will
> be necessary for us all to honor these /48s, meaning we cannot simply
> filter everything longer than /32 from the relevant chunks of address
> space.  If members do not feel like they should receive a bunch of
> /32s, then choose a different size and allocate these from special
> space.
> 
> If we do not do something like the above, the IPv6 DFZ will make IPv4
> look great.

These do have tradeoffs in terms of address space issued (from a very
large pool :-) and their benefit in terms of routing bloat.  That is 
the sort of tradeoff that definitely needs community discussion and 
consensus.   Is there an order you'd like to propose these policy 
changes in, and/or do you need help submitting them?

> As I mentioned above, I would like the ARIN IRR to be user-friendly.
> I agree with your idea that it be integrated into the other ARIN
> online tools, and was hoping this would indeed be implemented as you
> indicated earlier this year.  I would also like the data in it to be
> accurate and for rules to exist on what route: objects may be created
> by what user -- I don't think I should be able to insert a route:
> object with origin: AS65555 unless I am logged in to the web site as
> someone with permission to make routes in AS65555.  I also don't think
> I should be able to make route: objects for address space that doesn't
> belong to me.
> 
> I don't think users should even have to understand that they are
> making a route: object, I think it should just say, here are the
> allocations and assignments for you, and you can make IRR entries to
> facilitate BGP routing if you want to.  This system needs to become
> more straight-forward so novice operators can take advantage of it.
> It doesn't have to come with a deck of cards and pressurized peanuts,
> but if IRR is made easy to use, more people will utilize it.  Fewer
> ISPs will dump trash routes into RADB (and then never erase them) and
> fewer ISPs will just do all this manually.
> 
> I further think the ARIN IRR / tools should make it pretty damn easy
> to get a prefix-list for a desired as-set or aut-num, in a way that is
> machine-readable, so you don't have to download the files, generate
> with your own tools, and so on.  It would be pretty nice if it was
> easier for transit networks to take advantage of the data that is
> there (and hopefully, more accurate and safe!) but this is
> surprisingly hard for many of them.

I've got the list, and your timing for such suggestions is perfect
since we're in the midst of planning next year's operating plan,
including all of the development initiatives.

Thanks!
/John





From heather.skanks at gmail.com  Thu Oct  6 01:42:52 2011
From: heather.skanks at gmail.com (Heather Schiller)
Date: Thu, 6 Oct 2011 01:42:52 -0400
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111004003327.GL49464@gerbil.cluepon.net>
References: <20111002213815.GW49464@gerbil.cluepon.net>
	<0843188B-CF85-494F-85B0-02CD3F25B2B6@delong.com>
	<20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
	<20111003143124.GB49464@gerbil.cluepon.net>
	<CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>
	<20111003161145.GE49464@gerbil.cluepon.net>
	<CEC5ED5D-5EF8-46BA-8514-663A3264F09E@arin.net>
	<20111003210012.GJ49464@gerbil.cluepon.net>
	<BBCD87C0-A836-4B0D-A473-7EB3B7A6F368@arin.net>
	<20111004003327.GL49464@gerbil.cluepon.net>
Message-ID: <CADricwrMHc-tYaodXu=xLGNOusTXwCpAVxm1rxXAn8r+hVfSMg@mail.gmail.com>

I read the full thread, but feel like there is some other part of the
picture here that we are not seeing...

You are claiming geographic distance and diversity..for a single
network, under a single ASN, with a location at X and a location at Y
(presumably very far apart, with different providers servicing them?)
..and until now, you had a single allocation or assignment, that was
subnetted between X and Y.   Now X needs space and Y has some
available space - are you saying that because of routing policy you
can not pull address space from Y for X?  or is it because of your
existing utilization/subnetting design that you can't use space from Y
for X?   Are the netblocks you have available in Y smaller than /24?
Is that part of why they can't be moved?  If so, I could understand
saying "I can't move the available space across the country, because
the block would be too small to be globally announced by my upstream-
resulting in off net traffic being drawn to my other location/provider
resulting in a suboptimal path (if any..)"  Or is it just that you
don't want to deaggregate the prefix you currently have?  How is the
diversity of your connectivity forcing you to have a unique routing
policy?

Part of me thinks that MDN for IPv4 has seen its time, and the policy
should be obsoleted.  We are at rearranging the deckchairs time for
IPv4 and massive deaggregation is very likely going to be the next
step.  Folks should be making the most efficient use of the space they
have, where they can, possibly sacrificing some aggregation in the
process.  I think that day is coming, just not sure if its here
already or not.  I suppose that depends on how altruistic we feel
about being efficient with what we've already been allocated, so that
resources are available for others.

--heather

On Mon, Oct 3, 2011 at 8:33 PM, Richard A Steenbergen <ras at e-gerbil.net> wrote:
> On Mon, Oct 03, 2011 at 10:29:06PM +0000, John Curran wrote:
>>
>> The policy text does not reference unique routing policies.
>
> Even Owen, who is trying desperately to disagree with me (I'll pass on
> any particular speculations as to why :P), has stated that a discrete
> network is one which must implement unique routing policies.
>
> Since I apparently need to cite examples from every previous e-mail
> every time now, allow me to point out his attempt to "clarify the
> current defintion":
>
>> Insert new 4.5.3: Discrete networks are separate networks which have
>> cannot usefully share a common routing policy. Examples might include
>> networks with any of the following characteristics:
>
> So, if a network has one of the (previously defined in the policy
> language) characteristics, and thus cannot usefully hsare a common
> routing policy, they have discrete networks AND good justification for
> running discrete networks. I'm more than happy to have this
> clarification passed as a policy change, since it's just restating how
> it "already is".
>
>> Did you cut and paste the wrong section? ?Please resend the section
>> which refers to "unique routing policies". ?You quoted a section
>> regarding "Separate unique 'globally routable' address space' "
>
> I believe I outlined how "separate unique globally routable address
> space" equates to "unique routing policies" in a previous e-mail, but
> let me know if you didn't understand it and I'll be happy to try and
> explain it again.
>
>> > What does "I've already allocated address blocks to my POPs, which I
>> > cannot rearrange", have to do with "geographic distance and diversity
>> > requirements"? Where does this language come from? What is your basis in
>> > the policy to support this claim?
>>
>> You need a 'compelling reason' to have your infrastructure considered
>> _multiple discrete networks_
>
> Uh huh... Funny, I would have thought that meeting one of the example
> "compelling reasons" listed in the policy would serve as proof that you
> have a compelling reason. Meanwhile, you seem to feel that you need to
> add new, undocumented conditions to the example "compelling reasons" in
> order to justify a compelling reason. I fail to see how this makes any
> kind of sense, or can be justified under the current policy.
>
>> > When has this claim ever been applied
>> > to any other MDN applicant? And for the record, that part *IS*
>> > completely true in my specific situation, so it's not even a blocker,
>> > but it's also complete nonsense too, and needs to be called out as such.
>>
>> Richard - If that part is completely true in your situation, then
>> please reapply asap. You indicated otherwise on your last request to
>> ARIN for space under the MDN policy.
>
> No really I didn't, and this is the part you keep failing to understand!
> All I said was that I could potentially work around the need for this
> policy by doing something in a suboptimal way, but in the SAME WAY that
> everyone else could be too. If you think that everyone else can't do it
> too, you're confused, but fortunately the policy says NOTHING about "you
> must not be able to do this any other way". Maybe I should have just
> lied and saved myself the trouble, but I was trying to educate you on
> the practical realities of routing on the Internet. I guess no good deed
> goes unpunished, and all of that.
>
>> If that's the case, then the most constructive path would be to
>> propose unequivocal text for an MDN policy change. ?If you believe
>> that "discrete networks" are "networks that implement unique routing
>> policies" then that would be a fine change.
>
> I believe Owen has already done this for us, and I'm happy to support
> his proposal.
>
>> That would also result in the elimination of ARIN having to determine
>> if a "compelling reason" was present at all, since with such a
>> definition, since we would simply be able to ask: "Do you have two or
>> more networks with unique routing policies?", and if the applicant
>> said "yes", then they would meet the MDN policy by having _multiple
>> discrete networks_ per definition of _discrete network_.
>
> *NO* it absolutely would not! The fact that you keep saying this
> indicates a clear and massive misunderstanding somewhere, which is what
> I keep trying to correct!
>
> Having a network with a unique routing policy is a STATE OF BEING. It is
> EASY to do, all you have to do is GO CONFIGURE IT AS SUCH. This is in NO
> WAY justification for doing so, and it is certainly not justification
> for obtaining any kind of special treatment from ARIN. For that, you
> need to have a COMPELLING REASON to *BE* in that state, which the
> current policy defines (quite well too, if you would stop trying to make
> up random undocumented rules just because you think you should be :P).
>
> --
> Richard A Steenbergen <ras at e-gerbil.net> ? ? ? http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
> _______________________________________________
> 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 ras at e-gerbil.net  Thu Oct  6 03:42:15 2011
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Thu, 6 Oct 2011 02:42:15 -0500
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <CADricwrMHc-tYaodXu=xLGNOusTXwCpAVxm1rxXAn8r+hVfSMg@mail.gmail.com>
References: <20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
	<20111003143124.GB49464@gerbil.cluepon.net>
	<CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>
	<20111003161145.GE49464@gerbil.cluepon.net>
	<CEC5ED5D-5EF8-46BA-8514-663A3264F09E@arin.net>
	<20111003210012.GJ49464@gerbil.cluepon.net>
	<BBCD87C0-A836-4B0D-A473-7EB3B7A6F368@arin.net>
	<20111004003327.GL49464@gerbil.cluepon.net>
	<CADricwrMHc-tYaodXu=xLGNOusTXwCpAVxm1rxXAn8r+hVfSMg@mail.gmail.com>
Message-ID: <20111006074215.GH49464@gerbil.cluepon.net>

On Thu, Oct 06, 2011 at 01:42:52AM -0400, Heather Schiller wrote:
> 
> You are claiming geographic distance and diversity..for a single 
> network, under a single ASN, with a location at X and a location at Y 
> (presumably very far apart, with different providers servicing them?) 

Yes, which seems to be the textbook definition of that clause.

> ..and until now, you had a single allocation or assignment, that was 
> subnetted between X and Y.  Now X needs space and Y has some available 
> space - are you saying that because of routing policy you can not pull 
> address space from Y for X?  or is it because of your existing 
> utilization/subnetting design that you can't use space from Y for X?  

Technically speaking we had MDN allocations in the past, but at some 
point ARIN decided they didn't want to do them any more because they 
believed "having any backbone at all means you don't have a discrete 
network", and at the time it just wasn't worth the effort to try and 
argue with them over it.

This time we decided that rather than just deaggregate and fill the 
Internet with yet more useless /24s, we would try to actually get the 
policy fixed. We ran the above issue all the way up to John, and he 
affirmed that we were correct and that having a backbone did NOT exclude 
you from having multiple discrete networks... But then immediately after 
that, he decided to toss on some extra requirements that don't exist in 
the policy, like "and you can't possibly solve the problem any other 
way", and thus here we are...

> Are the netblocks you have available in Y smaller than /24? Is that 
> part of why they can't be moved?  If so, I could understand saying "I 
> can't move the available space across the country, because the block 
> would be too small to be globally announced by my upstream- resulting 
> in off net traffic being drawn to my other location/provider resulting 
> in a suboptimal path (if any..)" Or is it just that you don't want to 
> deaggregate the prefix you currently have?

I don't want to deaggregate the space, and nothing in the policy says I 
have to. The policy says meet one of these example compelling reasons to 
run discrete networks, and our use case is a textbook perfect example of 
example #2 (and I challenge anyone to think of a better example). That 
should be it.

This about it this way: The number one prime example use for this policy 
that EVERYONE seems to think is 100% legitimate is "the poor network 
with two POPs that aren't connected at all", right? So imagine an 
example user with two discontiguous networks who is given a /19, they 
split them up into 2x /20s, and then network A grows faster than network 
B and they need to apply for more space. If you now apply this new "and 
you can't possibly solve it with deaggregation" rule to them, you should 
be telling them "sorry why don't you go announce some /24s from network 
B over on network A to solve your problem".

NOTHING about the existance or lack of existance of a backbone changes 
the ability to use deaggregates as a workaround IN ANY WAY. It is JUST 
as easy for any network to announce a deaggregate /24, and it behaves 
EXACTLY the same, this is the part that seems to be flying right over 
some people's heads. The ONLY counterpoint that has been raised to this 
was John's "but there are some organizations that are so screwed up that 
they can't figure out how to swip space between A and B", which may or 
may not be true, but this ALSO has NOTHING to do with the existance or 
lack of existance of a backbone.

I just don't get what is so hard about this concept... discrete networks 
are simply a state of configuration, and their use requires 
justification if you expect to get anything out of ARIN as a result. One 
possible justification is having physically discontiguous networks, 
another possible justification is weird political or legal requirements, 
another possible justification is a single network/asn but with extreme 
geographic and transit diversity needs which require unique routing 
policies as a result... If you have one of these justifications, you 
have a reason to run your networks discretely, and boom you're done. Why 
is there this bizaare insistance on adding a special "and you also can't 
possibly work around it by any other means" rule to the justifications 
above, but only to the one and not the other, when there is ABSOLUTELY 
NOTHING DIFFERENT about the behavior or the possible use of this 
"workaround" between the different types of justiifcations?

> How is the diversity of your connectivity forcing you to have a unique 
> routing policy?

Please see previous discussion re: "if I want to have unique transit 
providers for each discrete network (which can EASILY be a requirement 
due to large geographic distances being spanned), I need unique routing 
policies". :)

> Part of me thinks that MDN for IPv4 has seen its time, and the policy 
> should be obsoleted.  We are at rearranging the deckchairs time for 
> IPv4 and massive deaggregation is very likely going to be the next 
> step.  Folks should be making the most efficient use of the space they 
> have, where they can, possibly sacrificing some aggregation in the 
> process.  I think that day is coming, just not sure if its here 
> already or not.  I suppose that depends on how altruistic we feel 
> about being efficient with what we've already been allocated, so that 
> resources are available for others.

The IPv4 space will run out on its own soon enough... I just don't see 
how the incredibly small amount of increased overhead on an incredibly 
small number of allocations is even REMOTELY worth the additional impact 
to the routing table, which we'll all have to live with for MANY MANY 
years to come, long after the v4 space from the RIRs is all exhausted. 

Please don't cause me 5 years of unnecessary grief just to extend the v4 
space for another week, I have more than enough routers with more than 
enough problems correctly handling large numbers of bgp paths and/or fib 
entries as it is. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)


From jcurran at arin.net  Thu Oct  6 06:00:49 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 6 Oct 2011 10:00:49 +0000
Subject: [arin-ppml] ARIN Multiple Discrete Networks Policy
In-Reply-To: <20111006074215.GH49464@gerbil.cluepon.net>
References: <20111003125653.GA49464@gerbil.cluepon.net>
	<1A694EDC-0AD4-4D93-8A2B-6673B463AD49@arin.net>
	<20111003143124.GB49464@gerbil.cluepon.net>
	<CCE49CAA-6B3B-413A-8C37-02C799676FB7@arin.net>
	<20111003161145.GE49464@gerbil.cluepon.net>
	<CEC5ED5D-5EF8-46BA-8514-663A3264F09E@arin.net>
	<20111003210012.GJ49464@gerbil.cluepon.net>
	<BBCD87C0-A836-4B0D-A473-7EB3B7A6F368@arin.net>
	<20111004003327.GL49464@gerbil.cluepon.net>
	<CADricwrMHc-tYaodXu=xLGNOusTXwCpAVxm1rxXAn8r+hVfSMg@mail.gmail.com>
	<20111006074215.GH49464@gerbil.cluepon.net>
Message-ID: <6BFFDC31-3816-405A-90F6-16ADE6FB9AB8@arin.net>

On Oct 6, 2011, at 3:42 AM, Richard A Steenbergen wrote:

> The IPv4 space will run out on its own soon enough... I just don't see 
> how the incredibly small amount of increased overhead on an incredibly 
> small number of allocations is even REMOTELY worth the additional impact 
> to the routing table, which we'll all have to live with for MANY MANY 
> years to come, long after the v4 space from the RIRs is all exhausted. 
> 
> Please don't cause me 5 years of unnecessary grief just to extend the v4 
> space for another week, I have more than enough routers with more than 
> enough problems correctly handling large numbers of bgp paths and/or fib 
> entries as it is. :)

In fact, it's been argued that the discrepancy in region runout rates may
actually hinder our chances of a successful transition to IPv6, and under
such a school of thought, it might be perfectly reasonable to treat all
network infrastructure as discrete networks, and allow organizations to 
"top off" those POPs which have >80% utilization, even if overall usage
is not yet achieved 80%.   This may or may not be deemed to be appropriate
stewardship by the community given routing implications as well as the need
to maximize the transition IPv6 success odds, but it is worth consideration.  
(Note - the regional discrepancy issue we'll hear more about on Wednesday in 
at least one presentation during the joint NANOG/ARIN portion of the program.)

FYI,
/John

John Curran
President and CEO
ARIN



From hannigan at gmail.com  Thu Oct  6 15:15:10 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 6 Oct 2011 15:15:10 -0400
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
Message-ID: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>

There are some symptoms of v4 exhaustion emerging and I think that it
is reasonable to treat them.

Any thoughts?

Proposal:

Networks that have assigned resources utilized less than 80% in
aggregate must provide their single homed downstream connected
networks IPv4 addresses to number their network into even IF the
downstream has their own provider independent address space AND their
need is longer than /24. ARIN, upon request of a network refused
addresses as a single-homed downstream with provider independent
addresses AND a need longer than /24 must initiate a Section 12 audit
upon a reasonable belief that a violation of this policy has occurred.

Rationale: Promote overall NRPM compliance capability for "all"
networks, promote efficient use of v4 addresses and to reduce table
bloat.


From bensons at queuefull.net  Thu Oct  6 18:05:38 2011
From: bensons at queuefull.net (Benson Schliesser)
Date: Thu, 6 Oct 2011 17:05:38 -0500
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
Message-ID: <06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>

Hi, Marty.

On Oct 6, 2011, at 2:15 PM, Martin Hannigan wrote:

> There are some symptoms of v4 exhaustion emerging and I think that it
> is reasonable to treat them.
> 

I agree with this principle.  But...

> Any thoughts?
> 
> Proposal:
> 
> Networks that have assigned resources utilized less than 80% in
> aggregate must provide their single homed downstream connected
> networks IPv4 addresses to number their network into even IF the
> downstream has their own provider independent address space AND their
> need is longer than /24. ARIN, upon request of a network refused
> addresses as a single-homed downstream with provider independent
> addresses AND a need longer than /24 must initiate a Section 12 audit
> upon a reasonable belief that a violation of this policy has occurred.
> 
> Rationale: Promote overall NRPM compliance capability for "all"
> networks, promote efficient use of v4 addresses and to reduce table
> bloat.

I think such a policy would be a bad idea.  The fundamental problem I have with this text, is that it assumes all downstream customers are equally valuable to the ISP.  For instance, an ISP might wish to reserve IP addresses for a high-margin aspect of their business - perhaps even at the cost of losing other customers.  This policy might result in artificial incentives that ultimately harm the ISP business, reduce competition in the ISP market, etc.

Cheers,
-Benson





From owen at delong.com  Thu Oct  6 21:19:51 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 6 Oct 2011 18:19:51 -0700
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
Message-ID: <5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>


On Oct 6, 2011, at 3:05 PM, Benson Schliesser wrote:

> Hi, Marty.
> 
> On Oct 6, 2011, at 2:15 PM, Martin Hannigan wrote:
> 
>> There are some symptoms of v4 exhaustion emerging and I think that it
>> is reasonable to treat them.
>> 
> 
> I agree with this principle.  But...
> 
>> Any thoughts?
>> 
>> Proposal:
>> 
>> Networks that have assigned resources utilized less than 80% in
>> aggregate must provide their single homed downstream connected
>> networks IPv4 addresses to number their network into even IF the
>> downstream has their own provider independent address space AND their
>> need is longer than /24. ARIN, upon request of a network refused
>> addresses as a single-homed downstream with provider independent
>> addresses AND a need longer than /24 must initiate a Section 12 audit
>> upon a reasonable belief that a violation of this policy has occurred.
>> 
>> Rationale: Promote overall NRPM compliance capability for "all"
>> networks, promote efficient use of v4 addresses and to reduce table
>> bloat.
> 
> I think such a policy would be a bad idea.  The fundamental problem I have with this text, is that it assumes all downstream customers are equally valuable to the ISP.  For instance, an ISP might wish to reserve IP addresses for a high-margin aspect of their business - perhaps even at the cost of losing other customers.  This policy might result in artificial incentives that ultimately harm the ISP business, reduce competition in the ISP market, etc.
> 


I agree with Benson. I also don't see the benefit to the community of
requiring the ISP to give PA space unless the end user is willing to
return their PI space to the free pool. All you would accomplish is
to transfer additional resources forcibly from the ISP to the end
user, benefiting the end-user but doing nothing for the community
or the ISP.

Owen



From narten at us.ibm.com  Fri Oct  7 00:53:02 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 07 Oct 2011 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201110070453.p974r2WO003531@rotala.raleigh.ibm.com>

Total of 83 messages in the last 7 days.
 
script run at: Fri Oct  7 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 36.14% |   30 | 32.77% |   226911 | jcurran at arin.net
 21.69% |   18 | 19.63% |   135924 | ras at e-gerbil.net
 12.05% |   10 | 12.54% |    86864 | owen at delong.com
  8.43% |    7 |  8.97% |    62081 | jsw at inconcepts.biz
  7.23% |    6 |  5.29% |    36611 | mysidia at gmail.com
  2.41% |    2 |  9.82% |    67994 | info at arin.net
  3.61% |    3 |  2.73% |    18924 | hannigan at gmail.com
  2.41% |    2 |  2.24% |    15544 | kevinb at thewire.ca
  1.20% |    1 |  1.78% |    12351 | susanh at arin.net
  1.20% |    1 |  1.75% |    12148 | heather.skanks at gmail.com
  1.20% |    1 |  0.87% |     6015 | bensons at queuefull.net
  1.20% |    1 |  0.84% |     5816 | narten at us.ibm.com
  1.20% |    1 |  0.76% |     5277 | john at egh.com
--------+------+--------+----------+------------------------
100.00% |   83 |100.00% |   692460 | Total


From hannigan at gmail.com  Fri Oct  7 10:46:56 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 7 Oct 2011 10:46:56 -0400
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
Message-ID: <CAMDXq5OSYH9_==g_w5Uog=OjiQEUZ_bYKrbZiC0Uq4CCy19jEA@mail.gmail.com>

On Thu, Oct 6, 2011 at 9:19 PM, Owen DeLong <owen at delong.com> wrote:
>
> On Oct 6, 2011, at 3:05 PM, Benson Schliesser wrote:
>
>> Hi, Marty.
>>
>> On Oct 6, 2011, at 2:15 PM, Martin Hannigan wrote:
>>
>>> There are some symptoms of v4 exhaustion emerging and I think that it
>>> is reasonable to treat them.
>>>
>>
>> I agree with this principle. ?But...
>>
>>> Any thoughts?
>>>
>>> Proposal:
>>>
>>> Networks that have assigned resources utilized less than 80% in
>>> aggregate must provide their single homed downstream connected
>>> networks IPv4 addresses to number their network into even IF the
>>> downstream has their own provider independent address space AND their
>>> need is longer than /24. ARIN, upon request of a network refused
>>> addresses as a single-homed downstream with provider independent
>>> addresses AND a need longer than /24 must initiate a Section 12 audit
>>> upon a reasonable belief that a violation of this policy has occurred.
>>>
>>> Rationale: Promote overall NRPM compliance capability for "all"
>>> networks, promote efficient use of v4 addresses and to reduce table
>>> bloat.
>>
>> I think such a policy would be a bad idea. ?The fundamental problem I have with this text, is that it assumes all downstream customers are equally valuable to the ISP. ?For instance, an ISP might wish to reserve IP addresses for a high-margin aspect of their business - perhaps even at the cost of losing other customers. ?This policy might result in artificial incentives that ultimately harm the ISP business, reduce competition in the ISP market, etc.

Interesting. When does choice outweigh benefit? Overall, if an ISP
forces a customer to utilize a /24 for the need of something like,
say, 20 hosts, that puts the customer in basic non compliance with
their typical RIR, utilization, and with no avenue to regain their
legitimacy based on current policy. Any thoughts on a "better"
solution in this situation? I agree, choice is key, but this issue
seems to be a bit more tricky to me.

>
> I agree with Benson. I also don't see the benefit to the community

 [ clip ]

Owen, I could propose world peace and because I proposed it, you'd be
against it.

Best,

-M<


From kkargel at polartel.com  Fri Oct  7 10:57:28 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 7 Oct 2011 09:57:28 -0500
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
Message-ID: <8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>



On Oct 6, 2011, at 3:05 PM, Benson Schliesser wrote:

> Hi, Marty.
> 
> On Oct 6, 2011, at 2:15 PM, Martin Hannigan wrote:
> 
>> There are some symptoms of v4 exhaustion emerging and I think that it
>> is reasonable to treat them.
>> 
> 
> I agree with this principle.  But...
> 
>> Any thoughts?
>> 
>> Proposal:
>> 
>> Networks that have assigned resources utilized less than 80% in
>> aggregate must provide their single homed downstream connected
>> networks IPv4 addresses to number their network into even IF the
>> downstream has their own provider independent address space AND their
>> need is longer than /24. ARIN, upon request of a network refused
>> addresses as a single-homed downstream with provider independent
>> addresses AND a need longer than /24 must initiate a Section 12 audit
>> upon a reasonable belief that a violation of this policy has occurred.
>> 
>> Rationale: Promote overall NRPM compliance capability for "all"
>> networks, promote efficient use of v4 addresses and to reduce table
>> bloat.
> 
> I think such a policy would be a bad idea.  The fundamental problem I have
with this text, is that it assumes all downstream customers are equally
valuable to the ISP.  For instance, an ISP might wish to reserve IP
addresses for a high-margin aspect of their business - perhaps even at the
cost of losing other customers.  This policy might result in artificial
incentives that ultimately harm the ISP business, reduce competition in the
ISP market, etc.
> 


I agree with Benson. I also don't see the benefit to the community of
requiring the ISP to give PA space unless the end user is willing to
return their PI space to the free pool. All you would accomplish is
to transfer additional resources forcibly from the ISP to the end
user, benefiting the end-user but doing nothing for the community
or the ISP.

Owen

[kjk] This sounds to me like ARIN trying to govern business models for
member entities and I think it is a bad idea.  Speaking as an ISP if my
customers need PA space I am more than happy to provide it for them at a
nominal cost.  I am sure this is the case at most if not all ISP's.  I
haven't heard of too many ISP's that turn down business customers are
willing to pay for. The customer is of course always free to seek a
different ISP.  
Kevin
[/kjk]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4935 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111007/3bc4fccf/attachment.bin>

From hannigan at gmail.com  Fri Oct  7 11:12:58 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 7 Oct 2011 11:12:58 -0400
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
Message-ID: <CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>

On Fri, Oct 7, 2011 at 10:57 AM, Kevin Kargel <kkargel at polartel.com> wrote:
>
>
> On Oct 6, 2011, at 3:05 PM, Benson Schliesser wrote:
>
>> Hi, Marty.
>>
>> On Oct 6, 2011, at 2:15 PM, Martin Hannigan wrote:
>>
>>> There are some symptoms of v4 exhaustion emerging and I think that it
>>> is reasonable to treat them.
>>>
>>
>> I agree with this principle. ?But...
>>
>>> Any thoughts?
>>>
>>> Proposal:
>>>
>>> Networks that have assigned resources utilized less than 80% in
>>> aggregate must provide their single homed downstream connected
>>> networks IPv4 addresses to number their network into even IF the
>>> downstream has their own provider independent address space AND their
>>> need is longer than /24. ARIN, upon request of a network refused
>>> addresses as a single-homed downstream with provider independent
>>> addresses AND a need longer than /24 must initiate a Section 12 audit
>>> upon a reasonable belief that a violation of this policy has occurred.
>>>
>>> Rationale: Promote overall NRPM compliance capability for "all"
>>> networks, promote efficient use of v4 addresses and to reduce table
>>> bloat.
>>
>> I think such a policy would be a bad idea. ?The fundamental problem I have
> with this text, is that it assumes all downstream customers are equally
> valuable to the ISP. ?For instance, an ISP might wish to reserve IP
> addresses for a high-margin aspect of their business - perhaps even at the
> cost of losing other customers. ?This policy might result in artificial
> incentives that ultimately harm the ISP business, reduce competition in the
> ISP market, etc.
>>
>
>
> I agree with Benson. I also don't see the benefit to the community of
> requiring the ISP to give PA space unless the end user is willing to
> return their PI space to the free pool. All you would accomplish is
> to transfer additional resources forcibly from the ISP to the end
> user, benefiting the end-user but doing nothing for the community
> or the ISP.
>
> Owen
>
> [kjk] This sounds to me like ARIN trying to govern business models for
> member entities and I think it is a bad idea. ?Speaking as an ISP if my

Well, if they didnt already do this, I would agree with you for the most part.

> customers need PA space I am more than happy to provide it for them at a
> nominal cost. ?I am sure this is the case at most if not all ISP's. ?I
> haven't heard of too many ISP's that turn down business customers are
> willing to pay for. The customer is of course always free to seek a
> different ISP.

Economic power comes into play in your thinking in that some networks
have the economic power to do what they please with respect to choice.
Others, not so much. In that case, this kind of "practice" is not
typically in anyones interest and all it seems to do is throw matches
on the common burning up a slot and wasting "significant" resources
that could be used to help foster transition.

Not really anything much more to say. Thanks. It's nice to be out of
the transfer/RSA/LRSA infinite loop for a bit. :-)

Best,

-M<


From kkargel at polartel.com  Fri Oct  7 11:23:52 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 7 Oct 2011 10:23:52 -0500
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>

> >
> > [kjk] This sounds to me like ARIN trying to govern business models for
> > member entities and I think it is a bad idea. ?Speaking as an ISP if my
> 
> Well, if they didnt already do this, I would agree with you for the most
> part.
[kjk] If they already do this then why the need for regulation?  Isn't this
all part of how ISP's do business?  Are you suggestion that ARIN start
operating as a regulatory body for ISP business practices?


> 
> > customers need PA space I am more than happy to provide it for them at a
> > nominal cost. ?I am sure this is the case at most if not all ISP's. ?I
> > haven't heard of too many ISP's that turn down business customers are
> > willing to pay for. The customer is of course always free to seek a
> > different ISP.
> 
> Economic power comes into play in your thinking in that some networks
> have the economic power to do what they please with respect to choice.
> Others, not so much. In that case, this kind of "practice" is not
> typically in anyones interest and all it seems to do is throw matches
> on the common burning up a slot and wasting "significant" resources
> that could be used to help foster transition.
[kjk] Again, if an ISP does not offer what a customer needs then the
customer is free to go to a different ISP.  I really do not want to see ARIN
get in to the practice of trying to control ISP business models.  That would
just be wrong on many levels.  
> 
> Not really anything much more to say. Thanks. It's nice to be out of
> the transfer/RSA/LRSA infinite loop for a bit. :-)
> 
> Best,
> 
> -M<
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4935 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111007/6f2b9038/attachment.bin>

From hannigan at gmail.com  Fri Oct  7 13:18:57 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 7 Oct 2011 13:18:57 -0400
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
Message-ID: <CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>

On Fri, Oct 7, 2011 at 11:23 AM, Kevin Kargel <kkargel at polartel.com> wrote:
>> >
>> > [kjk] This sounds to me like ARIN trying to govern business models for
>> > member entities and I think it is a bad idea. ?Speaking as an ISP if my
>>
>> Well, if they didnt already do this, I would agree with you for the most
>> part.
> [kjk] If they already do this then why the need for regulation? ?Isn't this
> all part of how ISP's do business? ?Are you suggestion that ARIN start
> operating as a regulatory body for ISP business practices?

I'm not sure I understand. Are you saying that ARIN policy doesn't
impact ISP or end user business models?

>> > customers need PA space I am more than happy to provide it for them at a
>> > nominal cost. ?I am sure this is the case at most if not all ISP's. ?I
>> > haven't heard of too many ISP's that turn down business customers are
>> > willing to pay for. The customer is of course always free to seek a
>> > different ISP.
>>
>> Economic power comes into play in your thinking in that some networks
>> have the economic power to do what they please with respect to choice.
>> Others, not so much. In that case, this kind of "practice" is not
>> typically in anyones interest and all it seems to do is throw matches
>> on the common burning up a slot and wasting "significant" resources
>> that could be used to help foster transition.

> [kjk] Again, if an ISP does not offer what a customer needs then the
> customer is free to go to a different ISP. ?I really do not want to see ARIN
> get in to the practice of trying to control ISP business models. ?That would
> just be wrong on many levels.


How should a network meet their utilization requirements and how
should ARIN foster aggregation per "RFC 2050" and "ICP-2" then? If I
have to use a /24 for a miniscule amount of addressing needs what's my
relief valve in policy then? GTL?

Best,

-M<


From kkargel at polartel.com  Fri Oct  7 13:46:03 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 7 Oct 2011 12:46:03 -0500
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
	<CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD280114CB3856@MAIL1.polartel.local>



 
> -----Original Message-----
> From: Martin Hannigan [mailto:hannigan at gmail.com]
> Sent: Friday, October 07, 2011 12:19 PM
> To: Kevin Kargel
> Cc: Benson Schliesser; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Downstreams, needs less than /24 and PI
> availability
> 
> On Fri, Oct 7, 2011 at 11:23 AM, Kevin Kargel <kkargel at polartel.com>
> wrote:
> >> >
> >> > [kjk] This sounds to me like ARIN trying to govern business models
> for
> >> > member entities and I think it is a bad idea. ?Speaking as an ISP if
> my
> >>
> >> Well, if they didnt already do this, I would agree with you for the
> most
> >> part.
> > [kjk] If they already do this then why the need for regulation? ?Isn't
> this
> > all part of how ISP's do business? ?Are you suggestion that ARIN start
> > operating as a regulatory body for ISP business practices?
> 
> I'm not sure I understand. Are you saying that ARIN policy doesn't
> impact ISP or end user business models?

[kjk] I am saying that ARIN if a *registrar*. See the "R" in ARIN. ARIN has
no business telling ISP's or other providers what services they are required
to offer to customers. What ARIN does is *register* address space to
members.

ARIN does not and should not be telling ISP's they need to provide email
addresses or broadband or file sharing or static IP's or dynamic IP's or NAT
or filtered IP or unfiltered IP or anything else like that to customers,
even if these would be good things.

If you want a regulatory rule defining ISP business practices the proper
place to get it done in the US would be in the FCC or possibly the FTC.
Good luck with that.

> 
> >> > customers need PA space I am more than happy to provide it for them
> at a
> >> > nominal cost. ?I am sure this is the case at most if not all ISP's.
> ?I
> >> > haven't heard of too many ISP's that turn down business customers are
> >> > willing to pay for. The customer is of course always free to seek a
> >> > different ISP.
> >>
> >> Economic power comes into play in your thinking in that some networks
> >> have the economic power to do what they please with respect to choice.
> >> Others, not so much. In that case, this kind of "practice" is not
> >> typically in anyones interest and all it seems to do is throw matches
> >> on the common burning up a slot and wasting "significant" resources
> >> that could be used to help foster transition.
> 
> > [kjk] Again, if an ISP does not offer what a customer needs then the
> > customer is free to go to a different ISP. ?I really do not want to see
> ARIN
> > get in to the practice of trying to control ISP business models. ?That
> would
> > just be wrong on many levels.
> 
> 
> How should a network meet their utilization requirements and how
> should ARIN foster aggregation per "RFC 2050" and "ICP-2" then? If I
> have to use a /24 for a miniscule amount of addressing needs what's my
> relief valve in policy then? GTL?
[kjk] The network should apply to their provider for PA space.  If the
provider won't give it to them they should get a new provider.  
If you are my customer and you need a /30 or a /29 of space all you need to
do is request it and agree to pay the associated fees and I will set you up.
The subnet will even be advertised in BGP, albeit as part of an aggregate.

There is a cost involved in providing a static subnet to a customer and
routing that and maintaining DNS for it.  It is right and good that the ISP
should get some reasonable return for providing that product.  

Because we have created a market for IP space those IP's now have a monetary
value.  As the market for that value fluctuates so will the cost to the
customer.  

Kevin


> 
> Best,
> 
> -M<
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4935 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111007/258ff2a8/attachment.bin>

From hannigan at gmail.com  Fri Oct  7 14:10:27 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 7 Oct 2011 14:10:27 -0400
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <8695009A81378E48879980039EEDAD280114CB3856@MAIL1.polartel.local>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
	<CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3856@MAIL1.polartel.local>
Message-ID: <CAMDXq5NU4dkcQK3JGkDZp0-sJPrWc=qVd2LyMUE4ajq8E2VgUA@mail.gmail.com>

On Fri, Oct 7, 2011 at 1:46 PM, Kevin Kargel <kkargel at polartel.com> wrote:
>
>
>

[ snip ]

>>
>> How should a network meet their utilization requirements and how
>> should ARIN foster aggregation per "RFC 2050" and "ICP-2" then? If I
>> have to use a /24 for a miniscule amount of addressing needs what's my
>> relief valve in policy then? GTL?

> [kjk] The network should apply to their provider for PA space. ?If the
> provider won't give it to them they should get a new provider.

Really? What if all providers do this?


From kkargel at polartel.com  Fri Oct  7 14:25:09 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 7 Oct 2011 13:25:09 -0500
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <CAMDXq5NU4dkcQK3JGkDZp0-sJPrWc=qVd2LyMUE4ajq8E2VgUA@mail.gmail.com>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
	<CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3856@MAIL1.polartel.local>
	<CAMDXq5NU4dkcQK3JGkDZp0-sJPrWc=qVd2LyMUE4ajq8E2VgUA@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD280114CB3857@MAIL1.polartel.local>



 

> -----Original Message-----
> From: Martin Hannigan [mailto:hannigan at gmail.com]
> Sent: Friday, October 07, 2011 1:10 PM
> To: Kevin Kargel
> Cc: Benson Schliesser; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Downstreams, needs less than /24 and PI
> availability
> 
> On Fri, Oct 7, 2011 at 1:46 PM, Kevin Kargel <kkargel at polartel.com> wrote:
> >
> >
> >
> 
> [ snip ]
> 
> >>
> >> How should a network meet their utilization requirements and how
> >> should ARIN foster aggregation per "RFC 2050" and "ICP-2" then? If I
> >> have to use a /24 for a miniscule amount of addressing needs what's my
> >> relief valve in policy then? GTL?
> 
> > [kjk] The network should apply to their provider for PA space. ?If the
> > provider won't give it to them they should get a new provider.
> 
> Really? What if all providers do this?
[kjk] Then you need to become a provider or find a different business model.
I think you will find that if you offer your provider enough money you are
going to get the PA space you need, and yes - as time goes on that PA space
is going to get more expensive.  Thank all the good folks that fought for
the IP market.  

This is what ISP's do..  they provide Internet Services to customers.  ISP's
provide different services at different rates.  If you need a basic dynamic
IP address with generic DNS you pay $x .  If you need a static IP address
with custom DNS you pay $x+y .  If you need a contiguous block of IP
addresses with custom DNS you pay $x+y^2 .  (OK, that was a little
facetious)  

So long as there are Internet Service Providers providing internet services
you will be able to get what you want, it is all a question of whether you
are willing to pay the going rate.

In any case ARIN is not the appropriate venue for accomplishing what you are
requesting.  As I said before you should be working with the FCC and the FTC
if you want to guarantee a particular service will be available to you as a
consumer.  I might add the Public Service Commission (PSC) to that list,
perhaps even the head of the list.

[/kjk]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4935 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111007/d23173c9/attachment.bin>

From owen at delong.com  Fri Oct  7 14:22:09 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 7 Oct 2011 11:22:09 -0700
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <CAMDXq5NU4dkcQK3JGkDZp0-sJPrWc=qVd2LyMUE4ajq8E2VgUA@mail.gmail.com>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
	<CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3856@MAIL1.polartel.local>
	<CAMDXq5NU4dkcQK3JGkDZp0-sJPrWc=qVd2LyMUE4ajq8E2VgUA@mail.gmail.com>
Message-ID: <2C55ADA0-326B-4B70-9830-C543E3DE0CB4@delong.com>


On Oct 7, 2011, at 11:10 AM, Martin Hannigan wrote:

> On Fri, Oct 7, 2011 at 1:46 PM, Kevin Kargel <kkargel at polartel.com> wrote:
>> 
>> 
>> 
> 
> [ snip ]
> 
>>> 
>>> How should a network meet their utilization requirements and how
>>> should ARIN foster aggregation per "RFC 2050" and "ICP-2" then? If I
>>> have to use a /24 for a miniscule amount of addressing needs what's my
>>> relief valve in policy then? GTL?
> 
>> [kjk] The network should apply to their provider for PA space.  If the
>> provider won't give it to them they should get a new provider.
> 
> Really? What if all providers do this?

An unlikely scenario at best.

Making policy based on FUD is rarely useful and almost always contrary
to the good of the community.

Owen



From kkargel at polartel.com  Fri Oct  7 14:30:54 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 7 Oct 2011 13:30:54 -0500
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <2C55ADA0-326B-4B70-9830-C543E3DE0CB4@delong.com>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
	<CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3856@MAIL1.polartel.local>
	<CAMDXq5NU4dkcQK3JGkDZp0-sJPrWc=qVd2LyMUE4ajq8E2VgUA@mail.gmail.com>
	<2C55ADA0-326B-4B70-9830-C543E3DE0CB4@delong.com>
Message-ID: <8695009A81378E48879980039EEDAD280114CB3858@MAIL1.polartel.local>



 

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Friday, October 07, 2011 1:22 PM
> To: Martin Hannigan
> Cc: Kevin Kargel; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Downstreams, needs less than /24 and PI
> availability
> 
> 
> On Oct 7, 2011, at 11:10 AM, Martin Hannigan wrote:
> 
> > On Fri, Oct 7, 2011 at 1:46 PM, Kevin Kargel <kkargel at polartel.com>
> wrote:
> >>
> >>
> >>
> >
> > [ snip ]
> >
> >>>
> >>> How should a network meet their utilization requirements and how
> >>> should ARIN foster aggregation per "RFC 2050" and "ICP-2" then? If I
> >>> have to use a /24 for a miniscule amount of addressing needs what's my
> >>> relief valve in policy then? GTL?
> >
> >> [kjk] The network should apply to their provider for PA space.  If the
> >> provider won't give it to them they should get a new provider.
> >
> > Really? What if all providers do this?
> 
> An unlikely scenario at best.
> 
> Making policy based on FUD is rarely useful and almost always contrary
> to the good of the community.
> 
> Owen
[kjk] Owen always cuts to the heart of the matter and says thing more
efficiently than I.  Thanks Owen.
[/kjk]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4935 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111007/67683e13/attachment.bin>

From hannigan at gmail.com  Fri Oct  7 16:18:20 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 7 Oct 2011 16:18:20 -0400
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <8695009A81378E48879980039EEDAD280114CB3857@MAIL1.polartel.local>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
	<CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3856@MAIL1.polartel.local>
	<CAMDXq5NU4dkcQK3JGkDZp0-sJPrWc=qVd2LyMUE4ajq8E2VgUA@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3857@MAIL1.polartel.local>
Message-ID: <CAMDXq5OzatYcEC0xNZtCmN0QDP36CL0i=JsYGO7LYK0Fn9GCng@mail.gmail.com>

On Fri, Oct 7, 2011 at 2:25 PM, Kevin Kargel <kkargel at polartel.com> wrote:
>
>
>
>
>> -----Original Message-----
>> From: Martin Hannigan [mailto:hannigan at gmail.com]
>> Sent: Friday, October 07, 2011 1:10 PM
>> To: Kevin Kargel
>> Cc: Benson Schliesser; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Downstreams, needs less than /24 and PI
>> availability
>>
>> On Fri, Oct 7, 2011 at 1:46 PM, Kevin Kargel <kkargel at polartel.com> wrote:
>> >
>> >
>> >
>>
>> [ snip ]
>>
>> >>
>> >> How should a network meet their utilization requirements and how
>> >> should ARIN foster aggregation per "RFC 2050" and "ICP-2" then? If I
>> >> have to use a /24 for a miniscule amount of addressing needs what's my
>> >> relief valve in policy then? GTL?
>>
>> > [kjk] The network should apply to their provider for PA space. ?If the
>> > provider won't give it to them they should get a new provider.
>>
>> Really? What if all providers do this?
> [kjk] Then you need to become a provider or find a different business model.


Kevin, how much upstream capacity does your network currently have?

Best,

-M<


From hannigan at gmail.com  Fri Oct  7 16:40:05 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Fri, 7 Oct 2011 16:40:05 -0400
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <8695009A81378E48879980039EEDAD280114CB3858@MAIL1.polartel.local>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
	<CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3856@MAIL1.polartel.local>
	<CAMDXq5NU4dkcQK3JGkDZp0-sJPrWc=qVd2LyMUE4ajq8E2VgUA@mail.gmail.com>
	<2C55ADA0-326B-4B70-9830-C543E3DE0CB4@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3858@MAIL1.polartel.local>
Message-ID: <CAMDXq5MMBfvNE5n0LYKbOxAAepYNVV10Nk_60Yf=D9T4cUCp7w@mail.gmail.com>

On Fri, Oct 7, 2011 at 2:30 PM, Kevin Kargel <kkargel at polartel.com> wrote:
>
>
>
>
>> -----Original Message-----
>> From: Owen DeLong [mailto:owen at delong.com]
>> Sent: Friday, October 07, 2011 1:22 PM
>> To: Martin Hannigan
>> Cc: Kevin Kargel; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Downstreams, needs less than /24 and PI
>> availability
>>
>>
>> On Oct 7, 2011, at 11:10 AM, Martin Hannigan wrote:
>>
>> > On Fri, Oct 7, 2011 at 1:46 PM, Kevin Kargel <kkargel at polartel.com>
>> wrote:
>> >>
>> >>
>> >>
>> >
>> > [ snip ]
>> >
>> >>>
>> >>> How should a network meet their utilization requirements and how
>> >>> should ARIN foster aggregation per "RFC 2050" and "ICP-2" then? If I
>> >>> have to use a /24 for a miniscule amount of addressing needs what's my
>> >>> relief valve in policy then? GTL?
>> >
>> >> [kjk] The network should apply to their provider for PA space. ?If the
>> >> provider won't give it to them they should get a new provider.
>> >
>> > Really? What if all providers do this?
>>
>> An unlikely scenario at best.
>>
>> Making policy based on FUD is rarely useful and almost always contrary
>> to the good of the community.
>>
>> Owen
> [kjk] Owen always cuts to the heart of the matter and says thing more
> efficiently than I. ?Thanks Owen.
> [/kjk]

You mean "cuts the heart". And kills the patient.

I wouldn't have brought this topic up if it wasn't _already happening_
and beginning to gain some momentum. In thinking about it, it probably
won't impact my employer so much as it will impact smaller networks.
I'm happy to waste a /24 and a burn a routing slot on each denial if
that's what the ARIN community wants me to do.

Thanks!

-M<


From kkargel at polartel.com  Fri Oct  7 16:54:13 2011
From: kkargel at polartel.com (Kevin Kargel)
Date: Fri, 7 Oct 2011 15:54:13 -0500
Subject: [arin-ppml] Downstreams, needs less than /24 and PI availability
In-Reply-To: <CAMDXq5MMBfvNE5n0LYKbOxAAepYNVV10Nk_60Yf=D9T4cUCp7w@mail.gmail.com>
References: <CAMDXq5O7V7dgSMYd-8Ycz2E=E_dJaiFGroy0cLrDAmQ++6b6qQ@mail.gmail.com>
	<06434D26-7642-4C02-BD4F-45FAD4539456@queuefull.net>
	<5DE81662-5A5D-4552-A3C4-3381C0E8C334@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3853@MAIL1.polartel.local>
	<CAMDXq5Nw9TvHdmGdbJsJfwDep9XCzAEy=Mo39b2z5YuL8=SdKw@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3854@MAIL1.polartel.local>
	<CAMDXq5MHHOEEuoES532XevkD2XPS2vBO27+-dHhVAHDfY+ymmQ@mail.gmail.com>
	<8695009A81378E48879980039EEDAD280114CB3856@MAIL1.polartel.local>
	<CAMDXq5NU4dkcQK3JGkDZp0-sJPrWc=qVd2LyMUE4ajq8E2VgUA@mail.gmail.com>
	<2C55ADA0-326B-4B70-9830-C543E3DE0CB4@delong.com>
	<8695009A81378E48879980039EEDAD280114CB3858@MAIL1.polartel.local>
	<CAMDXq5MMBfvNE5n0LYKbOxAAepYNVV10Nk_60Yf=D9T4cUCp7w@mail.gmail.com>
Message-ID: <8695009A81378E48879980039EEDAD280114CB385C@MAIL1.polartel.local>

> >>
> >> Making policy based on FUD is rarely useful and almost always contrary
> >> to the good of the community.
> >>
> >> Owen
> > [kjk] Owen always cuts to the heart of the matter and says thing more
> > efficiently than I. ?Thanks Owen.
> > [/kjk]
> 
> You mean "cuts the heart". And kills the patient.
> 
> I wouldn't have brought this topic up if it wasn't _already happening_
> and beginning to gain some momentum. In thinking about it, it probably
> won't impact my employer so much as it will impact smaller networks.
> I'm happy to waste a /24 and a burn a routing slot on each denial if
> that's what the ARIN community wants me to do.
> 
> Thanks!
> 
> -M<
[kjk] No, I meant it the way I said it.  A small subnet for a small business
is pretty common today for the small business to be able to support things
like multiple VPN's, secure servers, remote control devices (like video
cameras), et.al.  
If I were a small business working with an ISP that could not lease me a
routed subnet to satisfy a need I would certainly be looking for a new ISP.
This business dynamic is what is going to keep ISP's providing the services
that American businesses need.

Perhaps the fastest growing market for IP subnets right now (from the
viewpoint of the rural ISP) is the American farmer.  Farms are big business,
they have a great and growing need for wLAN and mWAN networks.  Farms are
using many high tech equipments and monitoring devices, many of which
require or can utilize discrete SSL and/or work much better with PA or PI
addresses per device. 
So even small rural ISP's are starting to see customers with a need for
small PA subnets.  This need is growing daily.   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4935 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111007/a83ae4a5/attachment.bin>

From owen at delong.com  Mon Oct 10 09:19:26 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 10 Oct 2011 06:19:26 -0700
Subject: [arin-ppml] Fwd: Proposed Revision to the ARIN Policy
	Development Process
In-Reply-To: <4E86001F.9090109@arin.net>
References: <4E86001F.9090109@arin.net>
Message-ID: <6E390068-B377-49A8-8EAB-220F85BA026E@delong.com>

Overall, I think the changes are good. However, I have made several notes inline below where I think things could be improved. Many of these are nits, but, there are also some substantial changes.

Owen

> 
> 
> ## * ##
> 
> 
> PART ONE ? ARIN POLICY DEVELOPMENT PROCESS GOALS
> 
> 1.	Purpose
[snip]

> The PDP is designed to bring forth clear, technically sound and useful 
> policies for ARIN to use in the management and administration of 
> Internet number resources. To accomplish this goal, the PDP charges the 
> community-elected ARIN Advisory Council (AC) as the primary policy 
> development body with appropriate checks and balances on its performance 
> in that role.
> 
This is a little bit of a nit, but, unless the BoT has chosen to modify the election process for the AC such that we are elected by the community, I believe that should read member-elected rather than community-elected.
> Part I of this document provides the underlying goals for the Policy 
> Development Process (including its purpose, scope, principles, and 
> criteria for policy changes) and Part II details the specific Policy 
> Development Process used for development of changes to Internet number 
> resource policy.  Part III details the processes for petitioning 
> specific aspects of the Policy Development Process.
> 

Another nit, the inconsistencies in the numbering are confusing. This paragraph, for example, uses roman numerals (I, II, III), but, the actual document text while the document is numbered with spelled-out numbers (Part one, Part two, Part three) with subsections numbered with arabic numerals with no precursor (e.g. 2. Definitions vs. I.2 Definitions). The numbering should at least be made consistent for each level of hierarchy. Ideally, the numbers would also be made hierarchical (e.g. I.2 Definitions)  and/or consistent indentation added to clarify hierarchy.
> 2.	Definitions
> 
> Internet Number Resources
> Internet number resources consist of Internet Protocol version 4 (IPv4) 
> address space, Internet Protocol version 6 (IPv6) address space, and 
> Autonomous System (AS) numbers.
> 

Although this is an unlikely scenario, it is possible that other protocol versions could be deployed while ARIN is still managing number resource policy. I think a more generic definition would be appropriate here, such as:

Internet number resources are those sets of numeric identifiers for which ARIN provides registration services. At the time of writing, these included Internet Protocol Addresses (regardless of version) and Autonomous System (AS) numbers.
> Policy Proposal
> An idea for a policy that is submitted to the policy development 
> process.  ARIN staff work with idea proposers to insure clarity of the 
> policy proposals, and the ARIN Advisory Council confirms the policy 
> proposal is in scope (per Section 3) of the Policy Development Process.
> 
> Draft Policy
> A policy proposal that is under active consideration by the Advisory 
> Council.  A draft policy results from a policy proposal being accepted 
> by the Advisory Council for further development. The Advisory Council 
> accepts additional policy proposals when the AC Chair determines that 
> the Advisory Council has sufficient available resources to undertake 
> additional development work.
> 
This is a significant change in terminology and removes a useful distinction in policy status from the AC's toolkit. Currently, once we place a proposal on our document, we work on the proposal until we feel that they are ready for adoption discussion at a meeting, then, we make them draft policies. Proposals and draft policies live in separate numbering spaces. I think altering the definition in this manner will create confusion without benefit.
> Recommended Draft Policy
> A draft policy that has been recommended for adoption by the Advisory 
> Council.  Policies are recommended for adoption once the Advisory 
> Council determines the draft policy meets ARIN?s Principles of Internet 
> number resource policy as specified in Section 4.
> 
> Adopted Policy
> A policy that has been adopted by the ARIN Board of Trustees.  Adopted 
> policies are incorporated into the Network Resource Policy Manual (NRPM)
> 
I believe the better term here is "Number Resource Policy Manual". I can't tell whether this was a deliberate rename or just a typo.
> Public Policy Mailing List (PPML)
> The ARIN public mailing list for discussion of Internet number resource 
> policy.
> 
> Public Policy Meeting (PPM)
> ARIN meetings open to the public for discussion of Internet number 
> resource policy.
> 
> Petition
> An action initiated by any member of the community (including a proposal 
> originator) if they are dissatisfied with the action taken by the 
> Advisory Council regarding a specific policy proposal or draft policy.
> 
> 3.	Scope of Internet Number Resource Policies
> 
> 3.1.	 Policies, not Processes, Fees, or Services
> Internet number resource policies developed through the PDP describe the 
> policies and guidelines to be followed in number resource management, 
> not the procedures that ARIN staff will use to implement the policies. 
> ARIN staff develops appropriate procedures to implement policies after 
> they are adopted.
> 
> Internet number resource policies are also distinctly separate from ARIN 
> general business practices. ARIN's general business processes, fees, and 
> services are not within the purview of the Policy Development Process, 
> and policies developed through the PDP cannot define or establish ARIN 
> fees or service offerings. All matters concerning fees and service 
> offerings are part of the fiduciary responsibility of the Board of 
> Trustees.  Note that the ARIN Consultation and Suggestion Process (ARIN 
> ACSP) may be used to propose changes in non-policy areas.
> 
Sometimes there are non-policy aspects of the desirable implementation of a policy proposal. In an ideal world, a mechanism would exist for making such submissions to the ACSP  and tying that ACSP to the Proposal and expressing the desired level of interdependence (a depends on b, b depends on a, neither should be activated independent of the other).
> 3.2.	 Relevant and applicable within the ARIN region
> Policies developed through the PDP are community self-regulatory 
> statements that govern ARIN?s actions in the management of Internet 
> number resources. Policy statements must be applicable to some portion 
> of the community or number resources managed within the ARIN region, and 
> proposals to change policy must address a clearly defined and existing 
> problem with number resource policy in the region.
> 
I recommend replacing "and existing problem" with "improvement". I think it is possible to make improvements to policy that are not necessarily a response to existing problems, per se.
> Note that the policy development process for global policies follows a 
> similar process within each RIR region with the additional process of 
> ratification by the Internet Corporation for Assigned Names and Numbers 
> (ICANN).  The global policy development process is separately documented 
> and facilitated by the Address Supporting Organization Address Council 
> (ASO AC).
> 
Actually, the global policy development process requires each RIR to pass the policy through their respective Policy Development Processes. As such, changing the AIRN PDP changes the Global PDP within the ARIN region as well. They are one in the same since the ARIN (and other RIR's) PDP(s) are incorporated by reference in the global PDP.
> 4.	Principles of Internet Number Resource Policy
> 
> Internet Number resource policy recommended for adoption must satisfy 
> three important principles, specifically:  1) enabling fair and 
> Impartial number resource administration, 2) technically sound 
> (providing for uniqueness and usability of number resources), and 3) 
> supported by the community.
> 
> 4.1.	Enabling Fair and Impartial Number Resource Administration
> Internet number resources must be managed with appropriate stewardship 
> and care. Internet number resource policy must conserve resources and 
> provide for fair and impartial distribution of resources according to 
> unambiguous processes and criteria. All policy statements must be clear, 
> complete, and concise, and any criteria that are defined in policy must 
> be simple and obtainable. Policies must be unambiguous and not subject 
> to varying degrees of interpretation.
> 
s/obtainable/attainable/ ?
> 4.2.	 Technically Sound
> Policies for Internet number resources management must be evaluated for 
> soundness against three overarching technical requirements: 
> conservation, aggregation and registration.  More specifically, policies 
> for managing Internet number resources must:
> ?	Support both conservation and efficient utilization of Internet number 
> resources to the extent feasible. Policy should maximize number resource 
> availability while respecting the significant cost to the Internet 
> community resulting from number resource depletion.
> ?	Support the aggregation of Internet number resources in a hierarchical 
> manner to the extent feasible.  Policy should permit the routing 
> scalability that is necessary for continued Internet growth.  (Note that 
> neither ARIN, nor its policies, can guarantee routability of any 
> particular Internet number resource as that is dependent on the actions 
> of the individual Internet operators.)
> ?	Support the unique registration of Internet number resources.  Policy 
> should prevent to the extent feasible any duplicate use of Internet 
> number resources that would disrupt Internet communications.
> The ARIN AC considers these requirements in assessing changes to policy 
> and only recommends those policies that achieve a technically sound 
> balance of these requirements.  The ARIN AC documents its technical 
> assessment for consideration by the community.
> 
I believe that this last criteria (uniqueness) should be first and foremost. The other two were important for IPv4 and remain useful considerations in IPv6, but, uniqueness truly is job one.
> 4.3.	 Supported by the Community
> Changes to policy must be shown to have a strong level of support in the 
> community in order to be adopted. The determination of support is most 
> commonly done after discussion of the draft policy at the Public Policy 
> Meeting (PPM) or via online poll after discussion on the Public Policy 
> Mailing List (PPML).
> 
> A strong level of community support for a policy change does not mean 
> unanimous; it may be supported by only a subset of the community, as 
> long as the policy change enjoys substantially more support than 
> opposition in the community active in the discussion.  Furthermore, any 
> specific concerns expressed by a significant portion of the community 
> must have been explicitly considered by the ARIN AC in their assessment 
> of the policy change.
> 
This paragraph concerns me. It could be construed, for example, to indicate that in moving a draft policy to recommended status, the AC must specifically note and explain each issue raised by any vocal minority in opposition to said draft policy. This could prove to be an avenue for DOS attacks against the AC.
> 5.	ARIN Board Criteria for Policy Changes
> 
> In order to maintain fidelity to the duty performed by ARIN on behalf of 
> the Internet community, changes to Internet resource numbering policy 
> must meet two specific criteria before being adopted by the ARIN Board 
> of Trustees:  1) in compliance with law and ARIN?s mission, and 2) 
> developed via open and transparent processes
> 
> 5.1.	 In Compliance with Law and ARIN?s Mission
> Policies developed through the PDP must advance ARIN?s mission, not 
> create unreasonable fiduciary or liability risk, and must be consistent 
> with ARIN's Articles of Incorporation, Bylaws, and all applicable laws 
> and regulations.
> 
> 5.2.	 Developed by Open & Transparent Processes
> Changes to policy must be developed via open and transparent processes 
> that provide for participation by all.  Policies must be considered be 
> in open, publicly accessible forum as part of the adoption process. 
> Policy discussions in the ARIN region are conducted on the Public Policy 
> Mail List (PPML) and in the Public Policy Meeting (PPM). There are no 
> qualifications for participation other than following the specified 
> rules of decorum necessary for constructive discussion. Anyone 
> interesting in participating in the process may subscribe to the PPML 
> and anyone interested may attend a PPM in person or via remote 
> participation methods.
> 
...must be considered be in open... (Second "be" should be removed)

...Anyone interesting in participating... (s/interesting/interested/)
> All aspects of the PDP are documented and publicly available via the 
> ARIN website. The PPML is archived. The proceedings of each PPM are 
> published. All policies are documented in the Number Resource Policy 
> Manual (NRPM). All draft policies are cross referenced to the original 
> policy proposal, the archives of the PPML, all related PPM proceedings, 
> and the minutes of the appropriate Advisory Council and the ARIN Board 
> of Trustees meetings. The procedures that are developed to implement the 
> policy are documented, publicly available, and followed by the ARIN staff.
> 
> 
> PART TWO ? THE POLICY DEVELOPMENT PROCESS
> This section provides the details of the ARIN Policy Development 
> Process. All references to ?days? are business days unless otherwise 
> specified.
> 
The term business days is not defined elsewhere in the PDP. Different organizations have different definitions of business days. I believe the ARIN definition is Monday through Friday exclusive of U.S. Federal holidays, but, I suggest that whatever definition ARIN follows should be made part of the PDP document if we are to use business days here.
> 1. The Policy Proposal
> Policy proposals may be submitted to the ARIN Policy Development process 
> by anyone in the global Internet community except for members of the 
> ARIN Board of Trustees or the ARIN staff. Policy proposals may be 
> submitted any time by completing the online policy proposal form on the 
> ARIN web site or by sending text copy of the form to policy at arin.net. 
> ARIN staff will work with the originator as described below to prepare 
> the policy proposal and make it available for consideration by the 
> Advisory Council.
> 
...sending text copy... (sending a plain text copy...)

This isn't just a nit. First, there's the grammatical issue, which is a nit. However, also note the addition of the word plain. It could be argued that a PDF, Pages, RTF, or other file format containing the text is a "text copy" of the form.
> Upon receipt of a policy proposal form, the ARIN staff will work with 
> the proposal originator by providing feedback within 10 days regarding 
> the clarity and understanding of the proposal text. The merits of the 
> policy proposal itself are not evaluated at this time; the purpose of 
> this step is to insure that the proposal text will be clear and 
> understandable to the ARIN staff and community, and to receive any staff 
> comments regarding potential scope considerations of the policy proposal.
> 
> The proposal originator may revise (or not) the proposal text based on 
> the feedback received, and when the originator indicates satisfaction 
> with the proposal text, the ARIN staff assigns it a policy proposal 
> number, posts the policy proposal to the public web site, and notifies 
> the Advisory Council of a new policy proposal available for initial 
> evaluation.
> 
Is it intentional to remove the posting of the proposal by the staff to PPML in this process?

> 2. Policy Proposal Initial Evaluation
> The Advisory Council (AC) performs an initial evaluation of each policy 
> proposal in a timely manner to determine if the proposal is within scope 
> of the Policy Development Process.  This will include consideration of 
> comments received from staff regarding potential scope considerations of 
> the policy proposal.  Policy proposals which are determined by the 
> Advisory Council to be out of scope or clearly without merit may be 
> rejected at this point, and the Advisory Council announces the rejection 
> of a policy proposal along with an explanation of its reasoning to the PPML.
> 
> The Advisory Council maintains a docket of draft policies under active 
> development. Any policy proposals that are not rejected upon initial 
> evaluation shall become draft policies on its docket. The AC Chair may 
> defer initial evaluation of all new policy proposals if the Chair 
> determines that there are insufficient resources available for 
> additional policy development work.
> 
Could it be desirable to add a safety valve here where the AC can also make such a deferral by some supermajority (2/3rds of voting members present, for example)?
> 3. Draft Policy Discussion and Development
> The Advisory Council is responsible for the development of draft 
> policies on its docket to meet ARIN?s principles of Internet number 
> resource policy (as described in Part One of the PDP, Section 4). During 
> this effort, the Advisory Council participates in and encourages the 
> discussion of the draft policies on the PPML, notes the merits and 
> concerns raised, and then based on its understanding of the relevant 
> issues, the Advisory Council may take various actions including 
> abandoning, revising or combining the draft policy with other draft 
> policies.
> 
It is also possible we may want to split a draft policy into multiple draft policies. This should, IMHO, either be stated above, or, s/including/including, but not limited to,/
> The Advisory Council announces any actions taken on draft policies along 
> with an explanation of its reasoning to the PPML.  The explanation 
> should show a full consideration of the issues leading to the action.. 
> The Advisory Council (AC) may have specific AC members or members of the 
> community (including the proposal originator) collaborate in the 
> consideration of the discussion and preparation of actions for the 
> Advisory Council, but only the Advisory Council may revise, combine, or 
> abandon a draft policy.
> 
Shouldn't recommend be part of that list of actions only the AC can take as well?
> The Advisory Council may submit a draft policy for a combined staff and 
> legal review (and should do so after significant changes to a draft 
> policy). This review will be completed within 10 days. Upon receipt of 
> the staff and legal review comments, the Advisory Council examines the 
> comments to ensure their understanding and resolve any issues that may 
> have been raised. This may cause the Advisory Council to revise, combine 
> or abandon the draft policy.
> 
Suggest replacing the last two sentences:
...Upon receipt of the staff and legal review comments, the AC examines comments to ensure their understanding and takes appropriate action(s) to resolve any issues that may have been raised.
> 4. Community Discussion at Public Policy Meeting
> The Advisory Council presents reports on the status of all the draft 
> policies on its docket at each public policy meeting (PPM).  The list of 
> draft policies is set 20 days in advance of the PPM, and no action to 
> add, merge or abandon draft policies may be made after that point (In 
> order to provide for flexibility but insure discussion of a single draft 
> policy version at the PPM, minor revisions to draft policy text may be 
> made by the Advisory Council up until 10 days prior to the public policy 
> meeting.)
> 
> The AC Chair designates a list of Draft Policies for discussion and 
> these are specifically listed in the Draft PPM agenda.  In each Draft 
> Policy presentation, members of the Advisory Council will present the 
> arguments for and against adoption of the Draft Policy (petitioned items 
> at the PPM are handled per PDP Section III: Petition Process) The 
> Advisory Council participates in the discussion of the draft policies at 
> the PPM, and notes merits and concerns raised in the discussion.
> Within the 30 days following the Public Policy Meeting, the Advisory 
> Council reviews all draft policies and, taking into account the 
> discussion at the public policy meeting, decides the appropriate next 
> action for each one.. Draft policies that are not abandoned remain on 
> the Advisory Council?s docket for further development.
> 
1.	I do not believe that the AC Chair alone should determine which policies the
	AC brings to the meeting.

2.	The AC should take into account not only the discussion at the public policy
	meeting, but, also the discussions on PPML and other input received from the
	community.

These two issues require a substantial rewrite of II.4 in its entirety and I don't have proposed text at this time, though I will endeavor to develop such upon request.
> 5. Advisory Council Consensus on Recommended Draft Policy
> If the Advisory Council completes its work on a draft policy and 
> believes that the draft policy meets ARIN?s principles of Internet 
> number resource policy, it may recommend the draft policy to the 
> community.  Upon recommendation, the recommended draft policy text and a 
> current staff and legal review are published on the PPML for community 
> discussion.
> 
> 6. Community Support on Recommended Draft Policy
> The Advisory Council seeks community support for its recommended draft 
> policies, and this support may be ascertained by a show of hands at the 
> public policy meeting or an online poll of the community after 10 days 
> prior notice provided to PPML.
> 
Does this mean PPML is told of the poll 10 days before the poll opens, in which case, how long does the poll remain open, or, does it mean that a notice opening the poll is posted to PPML 10 days prior to the poll closing?

I would suggest that this is an area where 14 consecutive 24 hour periods would be a more useful construct than 10 days (which in this context means 10 business days).

> The Advisory Council should carefully weigh the community support shown 
> for each of the recommended draft policies.  Clear community opposition 
> is a strong indication that policy abandonment should be considered. A 
> low level of overall support without opposition for a recommend draft 
> policy suggests further discussion of the merits of the draft policy or 
> abandonment. A clear split in the community support suggests that the 
> Advisory Council should revise the draft policy to accommodate the 
> concerns raised or further explain its consideration of the matter.
> 
This level of micromanagement of how the AC interprets community input on a policy seems ill advised at best.

Given the above paragraph, I can envision ways to claim that the AC violated the above for almost any outcome from almost any discussion other than one with overwhelming support or opposition among the entire community. Given the increasingly nuanced nature of proposal discussions over the last couple of years and that there is no reason to believe said trend will reverse itself, I believe that incorporating the above language into the PDP is asking for trouble.

> 7. Last Call
> The Advisory Council selects recommended draft policies that have the 
> support of the community and sends these policies to a last call for 
> review and discussion by the community on the PPML. The last call period 
> will be for a minimum of 10 days. The Advisory Council may decide that 
> certain draft policies require a longer last call period of review (such 
> as those that were revised based on comments received during the public 
> policy meeting). If the Advisory Council sends a draft policy different 
> than the recommended draft policy, then the Advisory Council will 
> provide an explanation for all changes to the text.
> 
I can't decipher this after 4 readings.
> Within 30 days of the end of last call the Advisory Council will review 
> the result of last call discussion, and will determine readiness for 
> consideration by the Board of Trustees.  The Advisory Council may 
> forward a draft policy directly to the Board of Trustees only if minor, 
> non-substantive changes were made as a result of last call discussion. 
> Any other changes require that the recommended policy be sent again to 
> last call, or held on the docket as a draft policy for further 
> development.  The AC can also decide to abandon a draft policy at this 
> point.
> 
> The results of the Advisory Council's decisions, and the reasons for
> them, are announced to the PPML. The Advisory Council forwards the 
> recommended draft policies to the Board of Trustees for adoption.
> 
The use of the term recommended draft policies here seems ambiguous and, unless I misunderstand the use of the same term above, would mandate forwarding things to the board that may have been abandoned in the previous paragraph.
> 9. Board of Trustees Review
> The ARIN Board of Trustees reviews and evaluates each recommended draft 
> policy at their next meeting. In its review, the Board evaluates the 
> policy with respect to the Policy Development Goals as described in Part 
> One of the PDP including specifically whether the ARIN Policy 
> Development Process has been followed, and whether the policy is in 
> compliance with law and ARIN?s mission.
> 
> The Board may adopt, reject or remand recommended policies to the 
> Advisory Council.  All rejections will include an explanation. Remands 
> will include an explanation and suggestions for further development. The 
> Board may also seek clarification from the Advisory Council without 
> remanding the recommended policy. The results of the Board's decision 
> are announced to the PPML.
> 
> 10. Implementation
> The projected implementation date of the policy is announced at the time 
> that adoption of the policy is announced. ARIN staff updates the NRPM to 
> include the adopted policy and implements and publishes a new version of 
> the manual.
> 
> 11.  Special Policy Actions
> 11.1 Emergency PDP
> If urgently necessary pursuant to ARIN?s mission, the Board of Trustees 
> may initiate policy by declaring an emergency and posting a draft policy 
> to the PPML for discussion for a minimum of 10 business days. The 
> Advisory Council will review the draft policy within 5 days of the end 
> of the discussion period and make a recommendation to the Board of 
> Trustees. If the Board of Trustees adopts the policy, it will be 
> presented at the next public policy meeting for reconsideration.
> 
> 11.2  Policy Suspension
> If, after a policy has been adopted, the Board receives credible 
> information that a policy is flawed in such a way that it may cause 
> significant problems if it continues to be followed, the Board of 
> Trustees may suspend the policy and request a recommendation from the 
> Advisory Council on how to proceed. The recommendation of the Advisory 
> Council will be published for discussion on the PPML for a period of at 
> least 10 days. The Board of Trustees will review the Advisory Council's 
> recommendation and the PPML discussion. If suspended, the policy will be 
> presented at the next scheduled public policy meeting in accordance with 
> the procedures outlined in this document.
> 
This seems somewhat backwards to me. I believe that the issue should be discussed on PPML followed by the AC making a recommendation, rather than the AC making a recommendation to be discussed on PPML then returned to the board without further involvement of the AC.
> 
> PART THREE ? PDP PETITION PROCESS
> This section provides the details of the petitions within the Policy 
> Development Process.  Petitions can be made at points where decisions 
> are made in the policy process.  Points where petitions are available 
> are depicted on the main PDP flow diagram in Appendix A.  All days in 
> the process below are business days unless otherwise specified.
> 
We are evaluating this without the benefit of the diagram referenced above as appendix A was not attached to this document.
> 1. Petition Principles
> 
> 1.1	Available to the community
> Any member of the community may initiate a Petition if they are 
> dissatisfied with a specific action taken by the ARIN Advisory Council 
> (AC) regarding any policy proposal or draft policy.  The petitioner does 
> not have to be located in the ARIN region or associated with an 
> organization that is a Member of ARIN; any party (including a policy 
> proposal originator) with interest in policy development matters within 
> the ARIN region may initiate a petition.
> 
> Notwithstanding the above, ARIN Staff and ARIN Board members may not 
> initiate or be counted in support of petitions as these individuals 
> already have a formally defined role in the Policy Development Process.
> 
I am glad to see that this was modified so as not to exclude the AC members from participating in petitions.
> 1.2	Petition Initiation and Process
> 
> A petition may be initiated by sending an email message to the ARIN 
> Public Policy Mailing List (PPML) clearly requesting a petition against 
> a specific action and includes a statement to the community on why the 
> petition is warranted.  The ARIN Staff will confirm the validity of the 
> petition and then announce the start of the petition period on the PPML 
> mailing list.
> 
> Until the close of the petition period, Members of the community (as 
> allowed to petition per 1.1 above) may be counted in support for an 
> existing petition by sending an email message to the PPML clearly 
> stating their support for the petition.  Only one petition will be 
> considered for given policy action; all subsequent requests to petition 
> for the same action within the petition period shall be considered as 
> support for the original petition.
> 
> The petition shall remain open for 5 days, at which time the ARIN Staff 
> shall determine if the petition succeeds (success requires expressions 
> of petition support from at least 10 different people from 10 different 
> organizations).  A successful petition will result in a change of status 
> for the policy proposal or draft policy as specified below.
> Staff and legal reviews will be conducted and published for draft 
> policies placed on the AC docket by successful petitions.
> All draft policies successfully petitioned are presented for discussion 
> at the next PPM by an individual chosen by the petition supporters.  If 
> consensus is not achieved in determining the presenter, then the 
> President may facilitate the selection process.
> 
> 2. Valid Petitions
> Petitions may be made regarding policy proposals or draft policies as 
> described below.
> 
> 2.1.  Petition against Abandonment or Rejection due to out of scope
> The Advisory Council?s decision to abandon a policy proposal or draft 
> policy may be petitioned.
> 
"...due to out of scope" should be removed. It is one of several reasons covered in the text below, not the only reason covered.
> Petitions may be initiated until 5 days following the announcement date 
> of an Advisory Council abandonment of a specific policy proposal or 
> draft policy. For sake of clarity, the ?announcement date? of an action 
> shall be the publication date of the action in the ARIN AC minutes.
> 
> For a draft policy, a successful petition will result in the draft 
> policy being placed back on the AC docket for PPML discussion and 
> presentation at the next PPM.
> 
> For a policy proposal rejected due to being out of scope of the PDP, a 
> successful petition will result in the question of policy proposal being 
> referred the ARIN Board for consideration.
> 
> For a policy proposal otherwise abandoned, a successful petition will 
> result in the policy proposal becoming a draft policy that will be 
> placed on the AC docket and published for discussion and review by the 
> community on the PPML.  The resulting draft policy shall be under 
> control of the AC going forward as any other draft policy and 
> subsequently may be revised or abandoned per the normal policy 
> development process.
> 
> 2.2.  Petition for Original Version
> The Advisory Council?s decision to revise a draft policy may be petitioned.
> 
> Petitions may be initiated anytime until 5 days following the 
> announcement date of an Advisory Council revision or publication date of 
> the draft agenda of the next Public Policy Meeting (PPM).
> 
> A successful petition will result in the original version of the draft 
> policy being added to the AC docket for PPML discussion and presentation 
> at the next PPM.
> 
> 2.3.  Last Call Petition
> Any member of the community may initiate a Last Call Petition if they 
> are dissatisfied with the AC?s failure to act within 30 days after a PPM 
> to send a draft policy to last call. If successful, the petition will 
> move the draft policy to last call discussion and review by the 
> community on the PPML.
> 
> 2.4.  Board of Trustees Consideration Petition
> Any member of the community may initiate a Board of Trustees 
> Consideration Petition if they are dissatisfied with the AC?s failure to 
> act within 30 days after a last call review. If successful, this 
> petition will move the draft policy for consideration by the Board of 
> Trustees.
> 
> _______________________________________________
> 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/20111010/2e2da024/attachment.htm>

From mike at nationwideinc.com  Mon Oct 10 09:53:51 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 10 Oct 2011 09:53:51 -0400
Subject: [arin-ppml] Spartan allocation proposal for transfers
Message-ID: <1ABEE6E505BF4D8B9177818C3DE1772A@MPC>


New HBS paper which may be of interest to this community seeks to offer market flexibility while contraining table growth:

http://www.hbs.edu/research/pdf/12-020.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111010/f536f02f/attachment.htm>

From owen at delong.com  Mon Oct 10 11:44:30 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 10 Oct 2011 08:44:30 -0700
Subject: [arin-ppml] Spartan allocation proposal for transfers
In-Reply-To: <1ABEE6E505BF4D8B9177818C3DE1772A@MPC>
References: <1ABEE6E505BF4D8B9177818C3DE1772A@MPC>
Message-ID: <DA282FE6-13A2-4FDD-B40F-FD19C1292059@delong.com>

Mike,
	Thanks for posting that. I found it largely indecipherable, but, I confess ignorance in both the math involved and the theoretical economics.

	I do find the assumption that the price of IPv4 addresses declines post exhaustion rather startling vs. the reality that everyone expects IPv4 addressing prices will increase until IPv4 is obsoleted.

	I find the spartan rule idea novel and interesting. I don't believe it is a viable substitute for needs-basis, but, I do believe it might be a worth-while additional constraint.

Owen

On Oct 10, 2011, at 6:53 AM, Mike Burns wrote:

>  
> New HBS paper which may be of interest to this community seeks to offer market flexibility while contraining table growth:
>  
> http://www.hbs.edu/research/pdf/12-020.pdf
>  
> _______________________________________________
> 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/20111010/cba3ab01/attachment.htm>

From mike at nationwideinc.com  Mon Oct 10 11:59:04 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 10 Oct 2011 11:59:04 -0400
Subject: [arin-ppml] Spartan allocation proposal for transfers
In-Reply-To: <DA282FE6-13A2-4FDD-B40F-FD19C1292059@delong.com>
References: <1ABEE6E505BF4D8B9177818C3DE1772A@MPC>
	<DA282FE6-13A2-4FDD-B40F-FD19C1292059@delong.com>
Message-ID: <55A1EC0B02C949E687E9C6A813086FEA@MPC>

Hi Owen,

Yes, it was a dense read, I was hoping that since Edelman advised ARIN that the spartan concept had been discussed at some level there, and some simplification of the concepts elucidated in the paper could be forthcoming from that direction.

However, I find the price graphs baffling, and the duration of extinguishment and protections against agents adopting multiple identities to be subjects for more discussion.

Of course this begs the question of transfer restrictions driving unbooked transfers, but still the concept is interesting.

I don?t find the social cost of table growth to be as high as the authors believe, I don?t foresee fragmentation happening to such an extent as to damage stability, but I realize this is just opinion at this stage.

As the authors state, this is an unusual market and it may be fruitful for economists to apply their tools.

Regards,
Mike


From: Owen DeLong 
Sent: Monday, October 10, 2011 11:44 AM
To: Mike Burns 
Cc: arin-ppml at arin.net 
Subject: Re: [arin-ppml] Spartan allocation proposal for transfers

Mike, 
Thanks for posting that. I found it largely indecipherable, but, I confess ignorance in both the math involved and the theoretical economics.

I do find the assumption that the price of IPv4 addresses declines post exhaustion rather startling vs. the reality that everyone expects IPv4 addressing prices will increase until IPv4 is obsoleted.

I find the spartan rule idea novel and interesting. I don't believe it is a viable substitute for needs-basis, but, I do believe it might be a worth-while additional constraint.

Owen

On Oct 10, 2011, at 6:53 AM, Mike Burns wrote:



  New HBS paper which may be of interest to this community seeks to offer market flexibility while contraining table growth:

  http://www.hbs.edu/research/pdf/12-020.pdf

  _______________________________________________
  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/20111010/2ec7a2b1/attachment.htm>

From owen at delong.com  Mon Oct 10 12:25:09 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 10 Oct 2011 09:25:09 -0700
Subject: [arin-ppml] Spartan allocation proposal for transfers
In-Reply-To: <55A1EC0B02C949E687E9C6A813086FEA@MPC>
References: <1ABEE6E505BF4D8B9177818C3DE1772A@MPC>
	<DA282FE6-13A2-4FDD-B40F-FD19C1292059@delong.com>
	<55A1EC0B02C949E687E9C6A813086FEA@MPC>
Message-ID: <006B0C5B-B42C-426C-B747-990103D2540F@delong.com>


On Oct 10, 2011, at 8:59 AM, Mike Burns wrote:

> Hi Owen,
>  
> Yes, it was a dense read, I was hoping that since Edelman advised ARIN that the spartan concept had been discussed at some level there, and some simplification of the concepts elucidated in the paper could be forthcoming from that direction.
>  

I believe this is research Mr. Edelman pursued after (and likely as a result of) his advising ARIN in the development of NRPM 8.3. I certainly would support the idea of ARIN bringing Mr. Edelman back to discuss this with the community.

> However, I find the price graphs baffling, and the duration of extinguishment and protections against agents adopting multiple identities to be subjects for more discussion.

Definitely. I would not support an extinguishment period less than the maximum duration allowed for justified need under policy.

>  
> Of course this begs the question of transfer restrictions driving unbooked transfers, but still the concept is interesting.

I think for the reasons outlined in the paper and the other reasons already well discussed on this list, those are of less concern than some would have us believe. I think the likelihood of unbooked transfers achieving long-term success on a wide scale is rather small.

>  
> I don?t find the social cost of table growth to be as high as the authors  believe, I don?t foresee fragmentation happening to such an extent as to damage stability, but I realize this is just opinion at this stage.

I'm actually beginning to believe that IPv4 table fragmentation may become the biggest IPv6 driver relatively soon, so, I'm willing to agree that perhaps continuing to make efforts to artificially constrain IPv4 table growth may, in fact, be unwise.

>  
> As the authors state, this is an unusual market and it may be fruitful for economists to apply their tools.

Or, perhaps, it is an unusual market and their tools will prove wholly inadequate to the task at hand until they have experience enough with the market to develop applicable tools. Unfortunately, only time will tell.

Note, I'm not saying that the above is the case, just saying that there are at least two possibilities worthy of consideration.

Owen

>  
> Regards,
> Mike
>  
>  
> From: Owen DeLong
> Sent: Monday, October 10, 2011 11:44 AM
> To: Mike Burns
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Spartan allocation proposal for transfers
>  
> Mike,
> Thanks for posting that. I found it largely indecipherable, but, I confess ignorance in both the math involved and the theoretical economics.
>  
> I do find the assumption that the price of IPv4 addresses declines post exhaustion rather startling vs. the reality that everyone expects IPv4 addressing prices will increase until IPv4 is obsoleted.
>  
> I find the spartan rule idea novel and interesting. I don't believe it is a viable substitute for needs-basis, but, I do believe it might be a worth-while additional constraint.
>  
> Owen
>  
> On Oct 10, 2011, at 6:53 AM, Mike Burns wrote:
> 
>>  
>> New HBS paper which may be of interest to this community seeks to offer market flexibility while contraining table growth:
>>  
>> http://www.hbs.edu/research/pdf/12-020.pdf
>>  
>> _______________________________________________
>> 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/20111010/917d39ee/attachment.htm>

From jcurran at arin.net  Mon Oct 10 13:16:41 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 10 Oct 2011 17:16:41 +0000
Subject: [arin-ppml] Spartan allocation proposal for transfers
In-Reply-To: <006B0C5B-B42C-426C-B747-990103D2540F@delong.com>
References: <1ABEE6E505BF4D8B9177818C3DE1772A@MPC>
	<DA282FE6-13A2-4FDD-B40F-FD19C1292059@delong.com>
	<55A1EC0B02C949E687E9C6A813086FEA@MPC>
	<006B0C5B-B42C-426C-B747-990103D2540F@delong.com>
Message-ID: <0CF27E98-4F81-4BF5-B5F1-EC84E216D713@corp.arin.net>

On Oct 10, 2011, at 12:25 PM, Owen DeLong wrote:

> I believe this is research Mr. Edelman pursued after (and likely as a result of) his advising ARIN in the development of NRPM 8.3. I certainly would support the idea of ARIN bringing Mr. Edelman back to discuss this with the community.

Ben Edelman's work on this paper is not an activity requested by ARIN,
although he remains available to the organization in an advisory capacity 
if needed.

FYI,
/John

John Curran
President and CEO
ARIN



From jcurran at arin.net  Mon Oct 10 17:20:12 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 10 Oct 2011 21:20:12 +0000
Subject: [arin-ppml] Reminder - Open Policy Hour at ARIN XXVIII
References: <4E848BFB.8070501@arin.net>
Message-ID: <3891F07C-E0C4-4CDB-AD99-A9EEDA7B21DC@arin.net>

Folks -

   If anyone would like to raise new ideas and/or suggestions regarding
   future ARIN number resource policy, please register to speak at the
   Open Policy Hour to be held this Thursday during the ARIN Public
   Policy Meeting.  While not required, this will greatly assist us in time
   planning for that session.

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

From: ARIN <info at arin.net<mailto:info at arin.net>>
Subject: [arin-ppml] Open Policy Hour at ARIN XXVIII
Date: September 29, 2011 11:17:15 AM EDT
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>

ARIN XXVIII is only two weeks away, so make sure you are ready.

The Open Policy Hour (OPH) will take place Thursday afternoon within the Public Policy Meeting.  OPH is not for discussion of draft policies that are already on the ARIN XXVIII agenda, but an open floor for new ideas and suggestions. If you have a policy idea on which you would like to receive feedback before submitting a proposal, seize this opportunity to present it to the ARIN community.

Sign up by Friday, 7 October to ensure you will be able to take the microphone. Send an email to policy at arin.net<mailto:policy at arin.net> with your name, organization, and a general description of the policy subject you wish to present. You do not need to have a formal presentation in order to participate. Signing up in advance is not required, but it allows us to confirm your turn to present.

Hope to see you in Philadelphia!

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<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 if you experience any issues.

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

From ben at benedelman.org  Mon Oct 10 18:38:54 2011
From: ben at benedelman.org (Ben Edelman)
Date: Mon, 10 Oct 2011 18:38:54 -0400
Subject: [arin-ppml] Spartan allocation proposal for transfers
Message-ID: <15ac01cc879d$646fb740$2d4f25c0$@benedelman.org>

Thanks for your interest.  A couple quick thoughts --

 

As John says, this paper is not work ARIN requested of me; it's a paper I
wrote on my own.  Incidentally I wrote an earlier paper on v4 scarcity,
available here: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1337075 ,
also independent of my work with ARIN.  

 

On the complexity of the paper and mathematical approach: Indeed.  The
economics profession typically uses a certain formality, which is sometimes
helpful and sometimes a distraction.  I write in that genre in order to fit
the norms of those who expect it.  But I have a healthy skepticism for how
useful it is.  At the very least, I'll always do my best to help clarify
wherever folks flag the problem.

 

Owen wrote: "I do find the assumption that the price of IPv4 addresses
declines post exhaustion rather startling vs. the reality that everyone
expects IPv4 addressing prices will increase until IPv4 is obsoleted."  

 

My intuition here: If a seller thought the price was about to jump, why
would the seller sell?  Perhaps the seller badly needs the money, but then
the seller might be better off getting a bank loan and repaying that loan
with the IP addresses to be sold at a later date.  Clearly not everyone can
get loans, for various important reasons.  But if most folks expect prices
to rise, it's not clear why anyone would sell.  That's the basic intuition
for why prices shouldn't rise slowly over time, but rather should quickly
rise to a level that reflects expectations of future value.

 

Of course if the v6 transition goes more slowly than expected -- bearing in
mind that it may already be expected to take quite some time -- then demand
for v4 may exceed prior expectations, and prices may increase further.  

 

Mike, in prior discussion with ARIN members and others, I did occasionally
hear casual mention of approaches that sound like the spartan allocation
rule.  For example, some suggested that if a seller is selling an entire
allocation, it doesn't matter whether the buyer needs to buy from several
such sellers because, on net, no new routes are being created.  Of course
there might still be a downside of permitting those transactions, e.g. if
that buyer would previously have bought just one block, but now ends up with
several, and then some big sellers disaggregates to satisfy several small
buyers.  Our paper is a step towards evaluating the pros and cons of
policies in this area.

 

I'll be in Philadelphia beginning Wednesday evening (unfortunately can't
make it before then).  I read this list and am always reachable by email .

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

From jcurran at arin.net  Mon Oct 10 19:01:33 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 10 Oct 2011 23:01:33 +0000
Subject: [arin-ppml] Proposed Revision to the ARIN Policy	Development
 Process
In-Reply-To: <6E390068-B377-49A8-8EAB-220F85BA026E@delong.com>
References: <4E86001F.9090109@arin.net>
	<6E390068-B377-49A8-8EAB-220F85BA026E@delong.com>
Message-ID: <F969D3E1-91A5-4905-BE41-617E8D49BF0F@arin.net>

On Oct 10, 2011, at 9:19 AM, Owen DeLong wrote:

Overall, I think the changes are good. However, I have made several notes inline below where I think things could be improved. Many of these are nits, but, there are also some substantial changes.

Owen

... To accomplish this goal, the PDP charges the
community-elected ARIN Advisory Council (AC) as the primary policy
development body with appropriate checks and balances on its performance
in that role.



This is a little bit of a nit, but, unless the BoT has chosen to modify the election process for the AC such that we are elected by the community, I believe that should read member-elected rather than community-elected.

Nit noted.  :-)

Part I of this document provides the underlying goals for the Policy
Development Process (including its purpose, scope, principles, and
criteria for policy changes) and Part II details the specific Policy
Development Process used for development of changes to Internet number
resource policy.  Part III details the processes for petitioning
specific aspects of the Policy Development Process.


Another nit, the inconsistencies in the numbering are confusing. This paragraph, for example, uses roman numerals (I, II, III), but, the actual document text while the document is numbered with spelled-out numbers (Part one, Part two, Part three) with subsections numbered with arabic numerals with no precursor (e.g. 2. Definitions vs. I.2 Definitions). The numbering should at least be made consistent for each level of hierarchy. Ideally, the numbers would also be made hierarchical (e.g. I.2 Definitions)  and/or consistent indentation added to clarify hierarchy.

Agreed.

2.      Definitions

Internet Number Resources
Internet number resources consist of Internet Protocol version 4 (IPv4)
address space, Internet Protocol version 6 (IPv6) address space, and
Autonomous System (AS) numbers.


Although this is an unlikely scenario, it is possible that other protocol versions could be deployed while ARIN is still managing number resource policy. I think a more generic definition would be appropriate here, such as:

Internet number resources are those sets of numeric identifiers for which ARIN provides registration services. At the time of writing, these included Internet Protocol Addresses (regardless of version) and Autonomous System (AS) numbers.

An interesting (if somewhat academic) point.  I'm thinking that we'd have plenty of
time to update the PDP if an even newer version of the Internet Protocol were to
begin to appear, but point taken.

Policy Proposal
An idea for a policy that is submitted to the policy development
process.  ARIN staff work with idea proposers to insure clarity of the
policy proposals, and the ARIN Advisory Council confirms the policy
proposal is in scope (per Section 3) of the Policy Development Process.

Draft Policy
A policy proposal that is under active consideration by the Advisory
Council.  A draft policy results from a policy proposal being accepted
by the Advisory Council for further development. The Advisory Council
accepts additional policy proposals when the AC Chair determines that
the Advisory Council has sufficient available resources to undertake
additional development work.



This is a significant change in terminology and removes a useful distinction in policy status from the AC's toolkit. Currently, once we place a proposal on our document, we work on the proposal until we feel that they are ready for adoption discussion at a meeting, then, we make them draft policies. Proposals and draft policies live in separate numbering spaces. I think altering the definition in this manner will create confusion without benefit.

Well, since you've opened the topic:  The original intent of Policy Proposal versus Draft
Policy was more akin to the process in the IETF, in that Draft was meant to reflect a
higher degree of maturity.  With respect to the current PDP, Draft Policies are supposed
to be those "technically sound and useful draft policies that, if adopted, will make a
positive contribution to the Number Resource Policy Manual."

The AC has recently been bringing nearly all policy proposals to the public policy
meeting, even when there is no consensus with the AC (or consensus to the contrary)
regarding the technically sound and useful nature of the policy proposal.

My preference would be that the community knows that a policy proposal is actually
being actively proposed for adoption by the AC, but actual practice has departed
from this direction.  "Ready for adoption discussion" <> "Determined to be sound
and useful by the AC".   This needs to be discussed by the community in detail.


Adopted Policy
A policy that has been adopted by the ARIN Board of Trustees.  Adopted
policies are incorporated into the Network Resource Policy Manual (NRPM)



I believe the better term here is "Number Resource Policy Manual". I can't tell whether this was a deliberate rename or just a typo.

Typo - it will be corrected.

Sometimes there are non-policy aspects of the desirable implementation of a policy proposal. In an ideal world, a mechanism would exist for making such submissions to the ACSP  and tying that ACSP to the Proposal and expressing the desired level of interdependence (a depends on b, b depends on a, neither should be activated independent of the other).

Agreed.  The staff works hard to explain how it will go about implementation, and
welcomes feedback on the staff and legal reviews to make sure that they are correct.  I
have even asked if an implementation process outline matches policy intent on occasion.

I'd prefer to keep this information together, even if it means adding an "implementation
considerations" section the policy proposal template.

3.2.     Relevant and applicable within the ARIN region
Policies developed through the PDP are community self-regulatory
statements that govern ARIN?s actions in the management of Internet
number resources. Policy statements must be applicable to some portion
of the community or number resources managed within the ARIN region, and
proposals to change policy must address a clearly defined and existing
problem with number resource policy in the region.



I recommend replacing "and existing problem" with "improvement". I think it is possible to make improvements to policy that are not necessarily a response to existing problems, per se.

Agreed.

Note that the policy development process for global policies follows a
similar process within each RIR region with the additional process of
ratification by the Internet Corporation for Assigned Names and Numbers
(ICANN).  The global policy development process is separately documented
and facilitated by the Address Supporting Organization Address Council
(ASO AC).



Actually, the global policy development process requires each RIR to pass the policy through their respective Policy Development Processes. As such, changing the AIRN PDP changes the Global PDP within the ARIN region as well. They are one in the same since the ARIN (and other RIR's) PDP(s) are incorporated by reference in the global PDP.

Correct - this reference to the global policy development process will recurse back to
here with respect to the ARIN portion of the process....  (and proving termination of
that recursion is definitely left as a exercise for the reader. ;-)

...All policy statements must be clear,
complete, and concise, and any criteria that are defined in policy must
be simple and obtainable. Policies must be unambiguous and not subject
to varying degrees of interpretation.



s/obtainable/attainable/ ?

Agreed.

4.2.     Technically Sound
Policies for Internet number resources management must be evaluated for
soundness against three overarching technical requirements:
conservation, aggregation and registration.  More specifically, policies
for managing Internet number resources must:
?       Support both conservation and efficient utilization of Internet number
resources to the extent feasible. Policy should maximize number resource
availability while respecting the significant cost to the Internet
community resulting from number resource depletion.
?       Support the aggregation of Internet number resources in a hierarchical
manner to the extent feasible.  Policy should permit the routing
scalability that is necessary for continued Internet growth.  (Note that
neither ARIN, nor its policies, can guarantee routability of any
particular Internet number resource as that is dependent on the actions
of the individual Internet operators.)
?       Support the unique registration of Internet number resources.  Policy
should prevent to the extent feasible any duplicate use of Internet
number resources that would disrupt Internet communications.
The ARIN AC considers these requirements in assessing changes to policy
and only recommends those policies that achieve a technically sound
balance of these requirements.  The ARIN AC documents its technical
assessment for consideration by the community.



I believe that this last criteria (uniqueness) should be first and foremost. The other two were important for IPv4 and remain useful considerations in IPv6, but, uniqueness truly is job one.

Agreed.

4.3.     Supported by the Community
Changes to policy must be shown to have a strong level of support in the
community in order to be adopted. The determination of support is most
commonly done after discussion of the draft policy at the Public Policy
Meeting (PPM) or via online poll after discussion on the Public Policy
Mailing List (PPML).

A strong level of community support for a policy change does not mean
unanimous; it may be supported by only a subset of the community, as
long as the policy change enjoys substantially more support than
opposition in the community active in the discussion.  Furthermore, any
specific concerns expressed by a significant portion of the community
must have been explicitly considered by the ARIN AC in their assessment
of the policy change.



This paragraph concerns me. It could be construed, for example, to indicate that in moving a draft policy to recommended status, the AC must specifically note and explain each issue raised by any vocal minority in opposition to said draft policy. This could prove to be an avenue for DOS attacks against the AC.

It is an important principle of deliberatively bodies that all parties get to express
their viewpoints. It is not possible to for anyone to discern if their particular view
(even if less popular) was given consideration by the AC unless it is documented.

Recognizing the potential for DoS attacks and similar, perhaps "material" or
"substantial" rather than "specific" would make sure that such decisions were
well documented without creating an unreasonable obligation on the AC?

5.2.     Developed by Open & Transparent Processes
Changes to policy must be developed via open and transparent processes
that provide for participation by all.  Policies must be considered be
in open, publicly accessible forum as part of the adoption process.
Policy discussions in the ARIN region are conducted on the Public Policy
Mail List (PPML) and in the Public Policy Meeting (PPM). There are no
qualifications for participation other than following the specified
rules of decorum necessary for constructive discussion. Anyone
interesting in participating in the process may subscribe to the PPML
and anyone interested may attend a PPM in person or via remote
participation methods.



...must be considered be in open... (Second "be" should be removed)

It shall be be removed.

...Anyone interesting in participating... (s/interesting/interested/)

Got it.   We do have some interesting participation, but that's not the
intent of the text - the PPML is open to all interested.

All aspects of the PDP are documented and publicly available via the
ARIN website. The PPML is archived. The proceedings of each PPM are
published. All policies are documented in the Number Resource Policy
Manual (NRPM). All draft policies are cross referenced to the original
policy proposal, the archives of the PPML, all related PPM proceedings,
and the minutes of the appropriate Advisory Council and the ARIN Board
of Trustees meetings. The procedures that are developed to implement the
policy are documented, publicly available, and followed by the ARIN staff.


PART TWO ? THE POLICY DEVELOPMENT PROCESS
This section provides the details of the ARIN Policy Development
Process. All references to ?days? are business days unless otherwise
specified.



The term business days is not defined elsewhere in the PDP. Different organizations have different definitions of business days. I believe the ARIN definition is Monday through Friday exclusive of U.S. Federal holidays, but, I suggest that whatever definition ARIN follows should be made part of the PDP document if we are to use business days here.

Agreed that the definition should be explicit, although this may need to be on the
website rather than embedded in the PDP.

1. The Policy Proposal
Policy proposals may be submitted to the ARIN Policy Development process
by anyone in the global Internet community except for members of the
ARIN Board of Trustees or the ARIN staff. Policy proposals may be
submitted any time by completing the online policy proposal form on the
ARIN web site or by sending text copy of the form to policy at arin.net<mailto:policy at arin.net>.
ARIN staff will work with the originator as described below to prepare
the policy proposal and make it available for consideration by the
Advisory Council.



...sending text copy... (sending a plain text copy...)

This isn't just a nit. First, there's the grammatical issue, which is a nit. However, also note the addition of the word plain. It could be argued that a PDF, Pages, RTF, or other file format containing the text is a "text copy" of the form.

Is your intent that ARIN reject such policy proposals even if staff is able to decode?

Upon receipt of a policy proposal form, the ARIN staff will work with
the proposal originator by providing feedback within 10 days regarding
the clarity and understanding of the proposal text. The merits of the
policy proposal itself are not evaluated at this time; the purpose of
this step is to insure that the proposal text will be clear and
understandable to the ARIN staff and community, and to receive any staff
comments regarding potential scope considerations of the policy proposal.

The proposal originator may revise (or not) the proposal text based on
the feedback received, and when the originator indicates satisfaction
with the proposal text, the ARIN staff assigns it a policy proposal
number, posts the policy proposal to the public web site, and notifies
the Advisory Council of a new policy proposal available for initial
evaluation.



Is it intentional to remove the posting of the proposal by the staff to PPML in this process?

No; it will be made explicit rather than implied via "posts to the public web site."

2. Policy Proposal Initial Evaluation
The Advisory Council (AC) performs an initial evaluation of each policy
proposal in a timely manner to determine if the proposal is within scope
of the Policy Development Process.  This will include consideration of
comments received from staff regarding potential scope considerations of
the policy proposal.  Policy proposals which are determined by the
Advisory Council to be out of scope or clearly without merit may be
rejected at this point, and the Advisory Council announces the rejection
of a policy proposal along with an explanation of its reasoning to the PPML.

The Advisory Council maintains a docket of draft policies under active
development. Any policy proposals that are not rejected upon initial
evaluation shall become draft policies on its docket. The AC Chair may
defer initial evaluation of all new policy proposals if the Chair
determines that there are insufficient resources available for
additional policy development work.



Could it be desirable to add a safety valve here where the AC can also make such a deferral by some supermajority (2/3rds of voting members present, for example)?

Or provide for removal of a non-confidence Chair? (as that safety value presumes
a Chair which is running seriously contrary to the intentions of the overall body)

3. Draft Policy Discussion and Development
The Advisory Council is responsible for the development of draft
policies on its docket to meet ARIN?s principles of Internet number
resource policy (as described in Part One of the PDP, Section 4). During
this effort, the Advisory Council participates in and encourages the
discussion of the draft policies on the PPML, notes the merits and
concerns raised, and then based on its understanding of the relevant
issues, the Advisory Council may take various actions including
abandoning, revising or combining the draft policy with other draft
policies.



It is also possible we may want to split a draft policy into multiple draft policies. This should, IMHO, either be stated above, or, s/including/including, but not limited to,/

Agreed.

The Advisory Council announces any actions taken on draft policies along
with an explanation of its reasoning to the PPML.  The explanation
should show a full consideration of the issues leading to the action..
The Advisory Council (AC) may have specific AC members or members of the
community (including the proposal originator) collaborate in the
consideration of the discussion and preparation of actions for the
Advisory Council, but only the Advisory Council may revise, combine, or
abandon a draft policy.



Shouldn't recommend be part of that list of actions only the AC can take as well?

It wasn't included here,  for clarity it's addressed below.  We can include it in the list
for completeness.

The Advisory Council may submit a draft policy for a combined staff and
legal review (and should do so after significant changes to a draft
policy). This review will be completed within 10 days. Upon receipt of
the staff and legal review comments, the Advisory Council examines the
comments to ensure their understanding and resolve any issues that may
have been raised. This may cause the Advisory Council to revise, combine
or abandon the draft policy.



Suggest replacing the last two sentences:
...Upon receipt of the staff and legal review comments, the AC examines comments to ensure their understanding and takes appropriate action(s) to resolve any issues that may have been raised.

Agreed.

4. Community Discussion at Public Policy Meeting
The Advisory Council presents reports on the status of all the draft
policies on its docket at each public policy meeting (PPM).  The list of
draft policies is set 20 days in advance of the PPM, and no action to
add, merge or abandon draft policies may be made after that point (In
order to provide for flexibility but insure discussion of a single draft
policy version at the PPM, minor revisions to draft policy text may be
made by the Advisory Council up until 10 days prior to the public policy
meeting.)

The AC Chair designates a list of Draft Policies for discussion and
these are specifically listed in the Draft PPM agenda.  In each Draft
Policy presentation, members of the Advisory Council will present the
arguments for and against adoption of the Draft Policy (petitioned items
at the PPM are handled per PDP Section III: Petition Process) The
Advisory Council participates in the discussion of the draft policies at
the PPM, and notes merits and concerns raised in the discussion.
Within the 30 days following the Public Policy Meeting, the Advisory
Council reviews all draft policies and, taking into account the
discussion at the public policy meeting, decides the appropriate next
action for each one.. Draft policies that are not abandoned remain on
the Advisory Council?s docket for further development.



1. I do not believe that the AC Chair alone should determine which policies the
AC brings to the meeting.

The reference of the AC Chair allows this to be done without requiring a vote of the
AC for each policy to be discussed at the PPM, i.e. based on discussion of the AC
and the consensus reached.   However, if an explicit vote is to bring each to the PPM
for discussion is desired, it can be put back in.


2. The AC should take into account not only the discussion at the public policy
meeting, but, also the discussions on PPML and other input received from the
community.

Agreed.

These two issues require a substantial rewrite of II.4 in its entirety and I don't have proposed text at this time, though I will endeavor to develop such upon request.

I suggest holding for additional comments on this from the community, but it is your call.


5. Advisory Council Consensus on Recommended Draft Policy
If the Advisory Council completes its work on a draft policy and
believes that the draft policy meets ARIN?s principles of Internet
number resource policy, it may recommend the draft policy to the
community.  Upon recommendation, the recommended draft policy text and a
current staff and legal review are published on the PPML for community
discussion.

6. Community Support on Recommended Draft Policy
The Advisory Council seeks community support for its recommended draft
policies, and this support may be ascertained by a show of hands at the
public policy meeting or an online poll of the community after 10 days
prior notice provided to PPML.



Does this mean PPML is told of the poll 10 days before the poll opens, in which case, how long does the poll remain open, or, does it mean that a notice opening the poll is posted to PPML 10 days prior to the poll closing?

We have no worked out the mechanisms, but want to allow such polls to be an option
for the AC to have available.

I would suggest that this is an area where 14 consecutive 24 hour periods would be a more useful construct than 10 days (which in this context means 10 business days).

Worth considering.

The Advisory Council should carefully weigh the community support shown
for each of the recommended draft policies.  Clear community opposition
is a strong indication that policy abandonment should be considered. A
low level of overall support without opposition for a recommend draft
policy suggests further discussion of the merits of the draft policy or
abandonment. A clear split in the community support suggests that the
Advisory Council should revise the draft policy to accommodate the
concerns raised or further explain its consideration of the matter.



This level of micromanagement of how the AC interprets community input on a policy seems ill advised at best.

Given the above paragraph, I can envision ways to claim that the AC violated the above for almost any outcome from almost any discussion other than one with overwhelming support or opposition among the entire community. Given the increasingly nuanced nature of proposal discussions over the last couple of years and that there is no reason to believe said trend will reverse itself, I believe that incorporating the above language into the PDP is asking for trouble.


I believe this is in here specifically at the request of the AC on how to interpret the
"support" from the community shown for a given proposal.  There were several such
requests over the last two years regarding "how much support is enough" and this was
the best proposed text that the team was able to achieve.


7. Last Call
The Advisory Council selects recommended draft policies that have the
support of the community and sends these policies to a last call for
review and discussion by the community on the PPML. The last call period
will be for a minimum of 10 days. The Advisory Council may decide that
certain draft policies require a longer last call period of review (such
as those that were revised based on comments received during the public
policy meeting). If the Advisory Council sends a draft policy different
than the recommended draft policy, then the Advisory Council will
provide an explanation for all changes to the text.



I can't decipher this after 4 readings.

Before sending policies to the Board for adoption, they go to last call.  If the text is
different than the last version the community saw, explain why.

Within 30 days of the end of last call the Advisory Council will review
the result of last call discussion, and will determine readiness for
consideration by the Board of Trustees.  The Advisory Council may
forward a draft policy directly to the Board of Trustees only if minor,
non-substantive changes were made as a result of last call discussion.
Any other changes require that the recommended policy be sent again to
last call, or held on the docket as a draft policy for further
development.  The AC can also decide to abandon a draft policy at this
point.

The results of the Advisory Council's decisions, and the reasons for
them, are announced to the PPML. The Advisory Council forwards the
recommended draft policies to the Board of Trustees for adoption.



The use of the term recommended draft policies here seems ambiguous and, unless I misunderstand the use of the same term above, would mandate forwarding things to the board that may have been abandoned in the previous paragraph.

I believe that a sentence needs to be inserted that states that "any recommended
policies shall reviewed after last call, to confirm that they are still recommended"
and then "Policies still recommended after this review are sent to the Board... "


11.2  Policy Suspension
If, after a policy has been adopted, the Board receives credible
information that a policy is flawed in such a way that it may cause
significant problems if it continues to be followed, the Board of
Trustees may suspend the policy and request a recommendation from the
Advisory Council on how to proceed. The recommendation of the Advisory
Council will be published for discussion on the PPML for a period of at
least 10 days. The Board of Trustees will review the Advisory Council's
recommendation and the PPML discussion. If suspended, the policy will be
presented at the next scheduled public policy meeting in accordance with
the procedures outlined in this document.



This seems somewhat backwards to me. I believe that the issue should be discussed on PPML followed by the AC making a recommendation, rather than the AC making a recommendation to be discussed on PPML then returned to the board without further involvement of the AC.

The AC certainly has that as a option... i.e. discuss the problem on PPML first,
then make a recommendation.  Perhaps that text could be expanded to not imply
otherwise.

PART THREE ? PDP PETITION PROCESS
This section provides the details of the petitions within the Policy
Development Process.  Petitions can be made at points where decisions
are made in the policy process.  Points where petitions are available
are depicted on the main PDP flow diagram in Appendix A.  All days in
the process below are business days unless otherwise specified.



We are evaluating this without the benefit of the diagram referenced above as appendix A was not attached to this document.

Correct.

1. Petition Principles

1.1     Available to the community
Any member of the community may initiate a Petition if they are
dissatisfied with a specific action taken by the ARIN Advisory Council
(AC) regarding any policy proposal or draft policy.  The petitioner does
not have to be located in the ARIN region or associated with an
organization that is a Member of ARIN; any party (including a policy
proposal originator) with interest in policy development matters within
the ARIN region may initiate a petition.

Notwithstanding the above, ARIN Staff and ARIN Board members may not
initiate or be counted in support of petitions as these individuals
already have a formally defined role in the Policy Development Process.



I am glad to see that this was modified so as not to exclude the AC members from participating in petitions.

There are some interesting aspects both in favor and against such a
constraint.  In the end, it was felt that unless absolutely necessary,
it should not be a constraint.


2. Valid Petitions
Petitions may be made regarding policy proposals or draft policies as
described below.

2.1.  Petition against Abandonment or Rejection due to out of scope
The Advisory Council?s decision to abandon a policy proposal or draft
policy may be petitioned.



"...due to out of scope" should be removed. It is one of several reasons covered in the text below, not the only reason covered.

Also agreed... it is not necessary to include in this context.

Owen - Thanks for that thorough and excellent review of the proposed
revised PDP; it certainly will help the final product, and hopefully help
get discussion going on some of the more philosophical issues raised
by the proposed changes.

Thanks!
/John

John Curran
President and CEO
ARIN



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

From owen at delong.com  Mon Oct 10 23:41:40 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 10 Oct 2011 20:41:40 -0700
Subject: [arin-ppml] Spartan allocation proposal for transfers
In-Reply-To: <15ac01cc879d$646fb740$2d4f25c0$@benedelman.org>
References: <15ac01cc879d$646fb740$2d4f25c0$@benedelman.org>
Message-ID: <DB1DAC06-3EF2-4431-AE7C-9A3B55BE5C6A@delong.com>


On Oct 10, 2011, at 3:38 PM, Ben Edelman wrote:

> Thanks for your interest.  A couple quick thoughts --
>  
> As John says, this paper is not work ARIN requested of me; it's a paper I wrote on my own.  Incidentally I wrote an earlier paper on v4 scarcity, available here: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1337075, also independent of my work with ARIN. 
>  
> On the complexity of the paper and mathematical approach: Indeed.  The economics profession typically uses a certain formality, which is sometimes helpful and sometimes a distraction.  I write in that genre in order to fit the norms of those who expect it.  But I have a healthy skepticism for how useful it is.  At the very least, I'll always do my best to help clarify wherever folks flag the problem.
>  
> Owen wrote: "I do find the assumption that the price of IPv4 addresses declines post exhaustion rather startling vs. the reality that everyone expects IPv4 addressing prices will increase until IPv4 is obsoleted." 
>  
> My intuition here: If a seller thought the price was about to jump, why would the seller sell?  Perhaps the seller badly needs the money, but then the seller might be better off getting a bank loan and repaying that loan with the IP addresses to be sold at a later date.  Clearly not everyone can get loans, for various important reasons.  But if most folks expect prices to rise, it's not clear why anyone would sell.  That's the basic intuition for why prices shouldn't rise slowly over time, but rather should quickly rise to a level that reflects expectations of future value.
>  

I can see that might be the case, but, I think that this ignores the potential for a feedback loop where the rapid rise creates new expectations among those that haven't freed up their resources yet and they come to the market later with even higher expectations.

> Of course if the v6 transition goes more slowly than expected -- bearing in mind that it may already be expected to take quite some time -- then demand for v4 may exceed prior expectations, and prices may increase further. 

Which, in spite of my level of enthusiasm and desire for expediting IPv6, is, IMHO, a very likely scenario.

>  
> Mike, in prior discussion with ARIN members and others, I did occasionally hear casual mention of approaches that sound like the spartan allocation rule.  For example, some suggested that if a seller is selling an entire allocation, it doesn't matter whether the buyer needs to buy from several such sellers because, on net, no new routes are being created.  Of course there might still be a downside of permitting those transactions, e.g. if that buyer would previously have bought just one block, but now ends up with several, and then some big sellers disaggregates to satisfy several small buyers.  Our paper is a step towards evaluating the pros and cons of policies in this area.

That's true, but, what is of concern here isn't the buyer buying multiple blocks to meet a larger need so much as the following (likely) scenarios:

1.	A buyer with a large need buys portions of several other blocks.
2.	Several buyers with smaller needs are willing to pay more for smaller pieces
	of a given block than the smaller number of buyers with larger needs.

>  
> I'll be in Philadelphia beginning Wednesday evening (unfortunately can't make it before then).  I read this list and am always reachable by email .

Cool. I don't know whether there is any time available in the ARIN agenda, but, could you at least consider discussing this at the Open Policy Hour if not elsewhere in the agenda?

Owen

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

From matthew at matthew.at  Tue Oct 11 00:13:16 2011
From: matthew at matthew.at (Matthew Kaufman)
Date: Mon, 10 Oct 2011 21:13:16 -0700
Subject: [arin-ppml] Spartan allocation proposal for transfers
In-Reply-To: <1ABEE6E505BF4D8B9177818C3DE1772A@MPC>
References: <1ABEE6E505BF4D8B9177818C3DE1772A@MPC>
Message-ID: <4E93C25C.4010304@matthew.at>

So, first off, during the time ARIN has addresses still available, the 
rental price is zero. But the claim (on the next graph) is then that 
because the expected rental price is higher in the future, the market 
price is at its maximum.

Except for two things: first, because ARIN still has addresses 
available, there's not much demand for addresses with prices much above 
zero (the Microsoft deal notwithstanding)... and if "need" is still 
required for *both* addresses obtained from ARIN and addresses obtained 
on the open market, there's even less reason to buy them. Unless they 
*are* being bought, at the forecast maximum price, and the transfers 
just aren't being recorded... hmm.

I do not that the theoretical results in the graphs and the earlier 
paragraphs all assume a completely open and transparent market (which I 
suspect also requires that there be no needs assessment prior to 
transfer), and yet there's substantial evidence that the only market 
we've seen start to form so far is pretty much at the opposite end of 
that spectrum with regard to knowledge of who is willing to sell what, 
and who is actually buying. And never mind that it also requires 
"complete information", which I take it includes things like knowing 
whether or not trying to unilaterally switch your services to IPv6 will 
be successful or not, rather than finding out late in the game that you 
too need some extra IPv4 to make it through a transition that is lasting 
longer than anyone initially predicted. (This is exactly the IPv4 demand 
spike that I think will happen, personally... the first round will be 
speculators against either future sales or rental, the followup will be 
the people who really *need* the space but didn't think they'd ever find 
themselves in that situation for one reason or another.)

Meanwhile, a policy such as is proposed in the paper is still possible 
to be worked around by name changes, transfers under alternative 
policies (such as 8.2), or simply failing to list the transfers (or 
rentals).

All in all, an interesting demonstration of economic theory when taken 
to its theoretical limits, and raises some possible ways to attack the 
disaggregation problem (if there is such a problem), but I question 
whether or not this theory and reality will have much to do with one 
another.

Matthew Kaufman

ps. I note that since, eventually, the unified world government as 
aligned with the  United Federation of Planets will offer free housing 
to everyone on Earth, we should, for the past several decades or more, 
have been observing the beginning of the monotonic decrease in home 
prices to zero, using this same theory.




From narten at us.ibm.com  Fri Oct 14 00:53:03 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 14 Oct 2011 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201110140453.p9E4r3dS009724@rotala.raleigh.ibm.com>

Total of 25 messages in the last 7 days.
 
script run at: Fri Oct 14 00:53:03 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 20.00% |    5 | 32.97% |   129181 | owen at delong.com
 24.00% |    6 | 21.78% |    85346 | kkargel at polartel.com
 12.00% |    3 | 23.57% |    92363 | jcurran at arin.net
 24.00% |    6 | 10.69% |    41874 | hannigan at gmail.com
  8.00% |    2 |  4.32% |    16930 | mike at nationwideinc.com
  4.00% |    1 |  3.42% |    13390 | ben at benedelman.org
  4.00% |    1 |  1.67% |     6556 | matthew at matthew.at
  4.00% |    1 |  1.57% |     6144 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   25 |100.00% |   391784 | Total



From sweeny at indiana.edu  Fri Oct 14 17:30:51 2011
From: sweeny at indiana.edu (Brent Sweeny)
Date: Fri, 14 Oct 2011 17:30:51 -0400
Subject: [arin-ppml] question about NRPM 'efficient utilization' criteria
Message-ID: <4E98AA0B.60408@indiana.edu>

the NRPM refers in at least two places to the requirement for
demonstrating efficient utilization "using the table format described in
Section 4.2.3.7.5"--but there *is* no section 4.2.3.7.5!  and I can't
locate the table referred to.  there is an HD example in the appendix,
but no table example as suggested (that I can find, anyway).

thanks. Brent Sweeny, Indiana University


From gary.buhrmaster at gmail.com  Fri Oct 14 17:48:51 2011
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 14 Oct 2011 21:48:51 +0000
Subject: [arin-ppml] question about NRPM 'efficient utilization' criteria
In-Reply-To: <4E98AA0B.60408@indiana.edu>
References: <4E98AA0B.60408@indiana.edu>
Message-ID: <CAMfXtQwt4Z8JzdYYNWPO4MkAaz6UqFtMc7Wn=3-eAqMqJ6wh2g@mail.gmail.com>

On Fri, Oct 14, 2011 at 21:30, Brent Sweeny <sweeny at indiana.edu> wrote:
> the NRPM refers in at least two places to the requirement for
> demonstrating efficient utilization "using the table format described in
> Section 4.2.3.7.5"--but there *is* no section 4.2.3.7.5! ?and I can't
> locate the table referred to. ?there is an HD example in the appendix,
> but no table example as suggested (that I can find, anyway).
>
> thanks. Brent Sweeny, Indiana University

The 4.2.3.7.5 table was deleted by 2010-14 (you can see the original
format in the previous versions of the NRPM).  Clearly the references
should have been updated/removed.

Previous version of the NRPM with the table:
  https://www.arin.net/policy/archive/nrpm_20110727.pdf


Gary


From mysidia at gmail.com  Fri Oct 14 21:17:16 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 14 Oct 2011 20:17:16 -0500
Subject: [arin-ppml] question about NRPM 'efficient utilization' criteria
In-Reply-To: <CAMfXtQwt4Z8JzdYYNWPO4MkAaz6UqFtMc7Wn=3-eAqMqJ6wh2g@mail.gmail.com>
References: <4E98AA0B.60408@indiana.edu>
	<CAMfXtQwt4Z8JzdYYNWPO4MkAaz6UqFtMc7Wn=3-eAqMqJ6wh2g@mail.gmail.com>
Message-ID: <CAAAwwbXuEc3vQNBAK+2Gcr8x8KO8UmAW325dTP_66Spe92QBaw@mail.gmail.com>

On Fri, Oct 14, 2011 at 4:48 PM, Gary Buhrmaster
<gary.buhrmaster at gmail.com> wrote:

> The 4.2.3.7.5 table was deleted by 2010-14 (you can see the original
> format in the previous versions of the NRPM). ?Clearly the references
> should have been updated/removed.

Oops... someone free()'d   the page the table was on,  but left a dangling
pointer reference in the NRPM.

I would call that a bug. :)

> Previous version of the NRPM with the table:
> ?https://www.arin.net/policy/archive/nrpm_20110727.pdf

If the table is gone...   the conclusion I would have is that the
table is no longer
allowed under the policy,   so it doesn't matter what the old version said,
if it's no longer an allowed method.

--
-JH


From owen at delong.com  Sat Oct 15 12:23:55 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 15 Oct 2011 12:23:55 -0400
Subject: [arin-ppml] question about NRPM 'efficient utilization' criteria
In-Reply-To: <CAAAwwbXuEc3vQNBAK+2Gcr8x8KO8UmAW325dTP_66Spe92QBaw@mail.gmail.com>
References: <4E98AA0B.60408@indiana.edu>
	<CAMfXtQwt4Z8JzdYYNWPO4MkAaz6UqFtMc7Wn=3-eAqMqJ6wh2g@mail.gmail.com>
	<CAAAwwbXuEc3vQNBAK+2Gcr8x8KO8UmAW325dTP_66Spe92QBaw@mail.gmail.com>
Message-ID: <1720B009-AD1B-484B-AAEE-BD986DAD7D24@delong.com>

I don't think that's correct. I think the reference to the table governs and the table should be restored (with appropriate referential updates) to a more appropriate location.

Owen


Sent from my iPad

On Oct 14, 2011, at 21:17, Jimmy Hess <mysidia at gmail.com> wrote:

> On Fri, Oct 14, 2011 at 4:48 PM, Gary Buhrmaster
> <gary.buhrmaster at gmail.com> wrote:
> 
>> The 4.2.3.7.5 table was deleted by 2010-14 (you can see the original
>> format in the previous versions of the NRPM).  Clearly the references
>> should have been updated/removed.
> 
> Oops... someone free()'d   the page the table was on,  but left a dangling
> pointer reference in the NRPM.
> 
> I would call that a bug. :)
> 
>> Previous version of the NRPM with the table:
>>  https://www.arin.net/policy/archive/nrpm_20110727.pdf
> 
> If the table is gone...   the conclusion I would have is that the
> table is no longer
> allowed under the policy,   so it doesn't matter what the old version said,
> if it's no longer an allowed method.
> 
> --
> -JH
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From mysidia at gmail.com  Sat Oct 15 15:23:46 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 15 Oct 2011 14:23:46 -0500
Subject: [arin-ppml] question about NRPM 'efficient utilization' criteria
In-Reply-To: <1720B009-AD1B-484B-AAEE-BD986DAD7D24@delong.com>
References: <4E98AA0B.60408@indiana.edu>
	<CAMfXtQwt4Z8JzdYYNWPO4MkAaz6UqFtMc7Wn=3-eAqMqJ6wh2g@mail.gmail.com>
	<CAAAwwbXuEc3vQNBAK+2Gcr8x8KO8UmAW325dTP_66Spe92QBaw@mail.gmail.com>
	<1720B009-AD1B-484B-AAEE-BD986DAD7D24@delong.com>
Message-ID: <CAAAwwbWTmTSVsZ7JgT8uSn8okKmvfahvHwuS0wFirRjkxK1y6g@mail.gmail.com>

On Sat, Oct 15, 2011 at 11:23 AM, Owen DeLong <owen at delong.com> wrote:

Not that I am in favor of the change;  I would strongly prefer the
table option to still exist, and for the table to be restored, but
2010_14 was rather explicit

"Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5."

The table option for accounting for additional utilization was
specifically striken from the policy
by that particular change.

And now we have a situation that needs to be corrected, where we have
one policy referring to another policy that no longer exists.


> I don't think that's correct. I think the reference to the table governs and the table should be restored (with appropriate referential updates) to a more appropriate location.
>
> Owen

--
-JH


From owen at delong.com  Sat Oct 15 16:43:20 2011
From: owen at delong.com (Owen DeLong)
Date: Sat, 15 Oct 2011 13:43:20 -0700
Subject: [arin-ppml] question about NRPM 'efficient utilization' criteria
In-Reply-To: <CAAAwwbWTmTSVsZ7JgT8uSn8okKmvfahvHwuS0wFirRjkxK1y6g@mail.gmail.com>
References: <4E98AA0B.60408@indiana.edu>
	<CAMfXtQwt4Z8JzdYYNWPO4MkAaz6UqFtMc7Wn=3-eAqMqJ6wh2g@mail.gmail.com>
	<CAAAwwbXuEc3vQNBAK+2Gcr8x8KO8UmAW325dTP_66Spe92QBaw@mail.gmail.com>
	<1720B009-AD1B-484B-AAEE-BD986DAD7D24@delong.com>
	<CAAAwwbWTmTSVsZ7JgT8uSn8okKmvfahvHwuS0wFirRjkxK1y6g@mail.gmail.com>
Message-ID: <F6663ACF-52B2-4D74-B7D4-7942BD7E1896@delong.com>


On Oct 15, 2011, at 12:23 PM, Jimmy Hess wrote:

> On Sat, Oct 15, 2011 at 11:23 AM, Owen DeLong <owen at delong.com> wrote:
> 
> Not that I am in favor of the change;  I would strongly prefer the
> table option to still exist, and for the table to be restored, but
> 2010_14 was rather explicit
> 
> "Strike sections 4.2.3.7.2., 4.2.3.7.4. and 4.2.3.7.5."
> 

Yes. 4.2.3.7.5 was stricken because the policy it was part of was being
removed in favor of a more streamlined policy. The external dependencies
on this paragraph were overlooked in the process. 4.2.3.7.5 is not the place
such a table format should be specified when multiple policies depend on
it and the correct result, IMHO, would be to restore the table specification as
an appendix to the NRPM and correct the references.

> The table option for accounting for additional utilization was
> specifically striken from the policy
> by that particular change.
> 

And I don't think that the table option still applies to that particular section
of policy, but, it does (and should) still apply to the remaining sections that
now have dangling references to it (justifications for initial ISP allocations).

> And now we have a situation that needs to be corrected, where we have
> one policy referring to another policy that no longer exists.
> 

Correct. However, I believe the reference is not to another policy, but, instead
to a specification that was originally part of a policy and should have been
moved when it turned into a multiple-policy referent, but wasn't.

In short, I believe the intent of 2010-14 was to strike the table (along with
significant other content from 4.2.3.7 et. seq.) without intending to affect
other seemingly unrelated parts of 4.2 and the now dangling references were
simply overlooked.

If anyone in the community believes that the intent of 2010-14 was otherwise,
please speak up.

Owen



From jcurran at arin.net  Sat Oct 15 23:46:22 2011
From: jcurran at arin.net (John Curran)
Date: Sun, 16 Oct 2011 03:46:22 +0000
Subject: [arin-ppml] question about NRPM 'efficient utilization' criteria
In-Reply-To: <F6663ACF-52B2-4D74-B7D4-7942BD7E1896@delong.com>
References: <4E98AA0B.60408@indiana.edu>
	<CAMfXtQwt4Z8JzdYYNWPO4MkAaz6UqFtMc7Wn=3-eAqMqJ6wh2g@mail.gmail.com>
	<CAAAwwbXuEc3vQNBAK+2Gcr8x8KO8UmAW325dTP_66Spe92QBaw@mail.gmail.com>
	<1720B009-AD1B-484B-AAEE-BD986DAD7D24@delong.com>
	<CAAAwwbWTmTSVsZ7JgT8uSn8okKmvfahvHwuS0wFirRjkxK1y6g@mail.gmail.com>
	<F6663ACF-52B2-4D74-B7D4-7942BD7E1896@delong.com>
Message-ID: <DB2F9F3E-2263-430C-9E34-7C66B9C9F742@arin.net>

On Oct 15, 2011, at 4:43 PM, Owen DeLong wrote:

> Yes. 4.2.3.7.5 was stricken because the policy it was part of was being
> removed in favor of a more streamlined policy. The external dependencies
> on this paragraph were overlooked in the process. 4.2.3.7.5 is not the place
> such a table format should be specified when multiple policies depend on
> it and the correct result, IMHO, would be to restore the table specification as
> an appendix to the NRPM and correct the references.

The prior policy change failed to remove all references to the table,
and we should have caught that during the review process.  Staff will 
prepare an editorial correction to the NRPM to address this oversight 
for the ARIN AC's consideration. There is precedent for the ARIN Board 
approving corrections to the NRPM with the ARIN AC's concurrence that
the change is purely editorial in nature, e.g. NRPM 2009.4 (Sept 2009).  
If the AC feels that the change is not editorial in nature, then it is 
likely to result in a new policy proposal in the policy development 
process.

FYI,
/John

John Curran
President and CEO
ARIN




From info at arin.net  Wed Oct 19 15:11:11 2011
From: info at arin.net (ARIN)
Date: Wed, 19 Oct 2011 15:11:11 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - October 2011
Message-ID: <4E9F20CF.2030809@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 14 October 2011 and made decisions about
several draft policies and proposals.

The AC moved the following draft policies to last call (they will be
posted separately to last call):

   ARIN-2011-1: ARIN Inter-RIR Transfers
   ARIN-2011-8: Combined M&A and Specified Transfers
   ARIN-2011-9 (Global Proposal): Global Policy for Post Exhaustion IPv4 
Allocation Mechanisms by the IANA
   ARIN-2011-10: Remove Single Aggregate Requirement from Specified Transfer

The following remain on the AC's docket:

   ARIN-2011-7: Compliance Requirement
   ARIN-2011-11: Clarify Justified Need for Transfers
   ARIN-2011-12: Set Transfer Need to 24 months

The following proposal was added to the AC's docket for development and 
evaluation:

   ARIN-prop-157 Section 8.3 Simplification

The AC abandoned the following:

   ARIN-2011-13: IPv4 Number Resources for Use Within Region
   ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

Regarding 2011-13 the AC provided the following statement, "Given the 
overwhelming number of objections by the community to the policy text as 
written, and the lack of demonstrated consensus in the community to 
continue work in this area, the AC has abandoned this draft policy."

And for prop-153 the AC stated, "Since ARIN-Prop-153 was in direct 
conflict with ARIN-2011-10: Remove Single Aggregate Requirement from 
Specified Transfer, that reached consensus at the PPM and has been sent 
to last call, the AC has abandoned ARIN-Prop-153: Correct Erroneous 
Syntax in NRPM 8.3."

The AC abandoned ARIN-2011-13 and ARIN-prop-153. Anyone dissatisfied 
with these decisions may initiate a petition. The petition to advance 
ARIN-2011-13 would be the "Last Call Petition." The petition to advance 
prop-153 would be the "Discussion Petition." The deadline to begin a 
petition will be five business days after the AC's draft meeting minutes 
are published. For more information on starting and participating in 
petitions, see PDP Petitions at:
https://www.arin.net/policy/pdp_petitions.html

Draft Policy and 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,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


From info at arin.net  Wed Oct 19 15:11:59 2011
From: info at arin.net (ARIN)
Date: Wed, 19 Oct 2011 15:11:59 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
Message-ID: <4E9F20FF.1070203@arin.net>

The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
send an amended version of the following draft policy to an extended 
last call:

   ARIN-2011-1: ARIN Inter-RIR Transfers

The AC provided the following statement:

********
The Advisory Council reviewed the results of feedback from the ARIN
XXVIII Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR
Transfers.  While there were concerns regarding the presented wording,
there was significant continued support for a policy enabling
Inter-Regional transfers of IPv4 number resources from organizations 
able to make them available to any organization with valid requirements.

In addition to cumbersome wording, the presented text could not be
cleanly inserted into the NRPM.  The following is new language that
directly modifies section 8.3 "Transfers to Specified Recipients" to
allow such transfers to or from organizations in other regions.

The first paragraph is a modified version of the current 8.3 policy
language, envisioning resources being released to ARIN by the authorized
resources holder or additionally by another RIR to be transferred to a
specified recipient.  The second sentence was reorganized to emphasize
that it applies to an organization within the ARIN region that will
receive such a specified transfer, and to eliminate the single aggregate
language per 2011-10 which is also being sent to last call.

The new second paragraph adds language enabling transfers to a specified
recipient in another RIR's service region.  This language specifies that
such recipients justify their need to their RIR, following that RIR's
policies.  ARIN will verify that there is a compatible needs based
policy that the other RIR will use to evaluate the need of the recipient
and that both RIR's agree to the transfer. Implicit in the intent of
the language presented and in conformance with statements made, the size
of the block to be transferred is identified as /24 or larger, for
obvious practical reasons.

In accordance with concern for immediate adoption, the AC chose to
forward this version to last call.  Concerns expressed by some
stakeholders for further controls were noted by the AC, and are being
considered for future policy modification, assuaged in part by ARIN
staff assurances that if any significant abuse of this policy were to
occur, then the policy could easily be suspended.

The AC thanks everyone in the community for their help in crafting this
important policy and for your statements of support or other comments
during Last Call.
********

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2011-1 will
expire on 16 November 2011. After last call the AC will conduct their 
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2011-1
ARIN Inter-RIR Transfers

Date/version: 14 October 2011

Policy statement:

8.3 Transfers to Specified Recipients

In addition to transfers under section 8.2, IPv4 number resources may be
released to ARIN by the authorized resource holder or another RIR, in
whole or in part, for transfer to another specified organizational
recipient.  Organizations in the ARIN region may receive transferred
number resources under RSA if they can demonstrate the need for such
resources in the amount which they can justify under current ARIN policies.

IPv4 address resources may be transferred to organizations in another
RIR's service region if they demonstrate need to their region's RIR,
according to that RIR's policies. Inter-regional transfers may take
place only via RIRs who agree to the transfer and share compatible,
needs-based policies. Such resources must be transferred in blocks of
/24 or larger and will become part of the resource holdings of the
recipient RIR.

Timetable for implementation: immediate


From info at arin.net  Wed Oct 19 15:12:18 2011
From: info at arin.net (ARIN)
Date: Wed, 19 Oct 2011 15:12:18 -0400
Subject: [arin-ppml] ARIN-2011-8: Combined M&A and Specified Transfers -
	Last Call
Message-ID: <4E9F2112.4050102@arin.net>

The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
send the following draft policy to last call:

   ARIN-2011-8: Combined M&A and Specified Transfers

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2011-8 will
expire on 2 November 2011. After last call the AC will conduct their 
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2018
Combined M&A and Specified Transfers

Date/version: 26 July 2011

Policy statement:

To section 8.2 change "... 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)." to "...ARIN will work with the resource holder(s) to 
return, aggregate, transfer, or reclaim resources as needed to restore 
compliance via the processes outlined in current ARIN policy."

Rationale:

Given that both M&A transfers and specified transfers are possible, it 
should be possible to execute a combined transfer in which unneeded 
resources are transferred via 8.3 (rather than returning unneeded 
resources to the free pool) and the rest are transferred via 8.2. Doing 
this in the wrong order (i.e., attempting to execute the 8.2 transfer 
first) should not penalize the transferring entity... especially as 
ARIN's opinion as to what is "no longer justified under ARIN policy" is 
best known by ARIN and may not be completely knowable by the 
transferring entity. Note that as there is no ARIN policy permitting 
IPv6 specified transfers, this policy would only affect IPv4 resources 
at this time.

Timetable for implementation: immediate


From info at arin.net  Wed Oct 19 15:12:39 2011
From: info at arin.net (ARIN)
Date: Wed, 19 Oct 2011 15:12:39 -0400
Subject: [arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for post
 exhaustion IPv4 allocation mechanisms by the IANA - Last Call
Message-ID: <4E9F2127.9060809@arin.net>

The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
send the following draft policy to last call:

   ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4 
allocation mechanisms by the IANA

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2011-9 will
expire on 2 November 2011. After last call the AC will conduct their 
last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2011-9 (Global Proposal)
Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA

Date: 22 September 2011

Policy statement:

The IANA shall establish a Recovered IPv4 Pool to be utilized post
RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain
any fragments that may be left over in the IANA. It will also hold
any space returned to the IANA by any other means.
The Recovered IPv4 Pool will be administered by the IANA. It will
contain:
a. Any fragments left over in the IANA inventory after the last
/8s of IPv4 space are delegated to the RIRs

     The IANA inventory excludes "Special use IPv4 addresses" as
     defined in BCP 153 and any addresses allocated by the IANA
     for experimental use.

b. Any IPv4 space returned to the IANA by any means.
The Recovered IPv4 Pool will stay inactive until the first RIR has
less than a total of a /9 in its inventory of IPv4 address space.
When one of the RIRs declares it has less than a total of a /9 in
its inventory, the Recovered IPv4 pool will be declared active, and
IP addresses from the Recovered IPv4 Pool will be allocated as
follows:
a. Allocations from the IANA may begin once the pool is declared
active.
b. In each "IPv4 allocation period", each RIR will receive a
single "IPv4 allocation unit" from the IANA.
c. An "IPv4 allocation period" is defined as a 6-month period
following 1 March or 1 September in each year.
d. The IANA will calculate the size of the "IPv4 allocation unit"
at the following times:

     When the Recovered IPv4 Pool is first activated
     At the beginning of each IPv4 allocation period

To calculate the "IPv4 allocation unit" at these times, the
IANA will use the following formula:
IPv4 allocation unit = 1/5 of Recovered IPv4 pool,
rounded down to the next CIDR
(power-of-2) boundary.
No RIR may get more than this calculation used to determine
the IPv4 allocation unit even when they can justify a need for
it.
The minimum "IPv4 allocation unit" size will be a /24. If the
calculation used to determine the IPv4 allocation unit results
in a block smaller than a /24, the IANA will not distribute
any addresses in that IPv4 allocation period.
The IANA may make public announcements of IPv4 address
transactions that occur under this policy. The IANA will make
appropriate modifications to the "Internet Protocol V4 Address
Space" page of the IANA website and may make announcements to its
own appropriate announcement lists. The IANA announcements will
be limited to which address ranges, the time of allocation, and to
which Registry they have been allocated.

Rationale:

The policy provides a mechanism for the ongoing distribution of
IPv4 address space, while removing the areas that have been
problematic in previous attemts at this proposal. The proposal:

- Permits regional variation in runout policy amongst RIRs to
be accounted for in the distribution of the Recovered IPv4 Pool

- Prevents the possibility of a single RIR being eligible to
be allocated the entire Recovered IPv4 Pool in the first
(and perhaps only) allocation period

- Removes two areas of policy that have failed to reach
agreement in previous attempts at this proposal:

- How addresses should be placed in the Recovered IPv4 Pool
- References to how transfers should or should not take
place

The NRO must clarify that this Global Policy is not intended to
supersede the IETF?s right to make IPv4 assignments for
?specialised address blocks (such as multicast or anycast
blocks)? as documented in section 4.3 of RFC 2860. The
NRO and IANA should coordinate with the IETF to make such
assignments as necessary, and honor any reservations made
for works currently in progress.

Timetable for implementation:

Once consensus has been reached in each of the 5 RIR regions, the
policy will be forwarded to ICANN for approval and then implemented
by the IANA.


From info at arin.net  Wed Oct 19 15:12:54 2011
From: info at arin.net (ARIN)
Date: Wed, 19 Oct 2011 15:12:54 -0400
Subject: [arin-ppml] ARIN-2011-10: Remove Single Aggregate requirement from
 Specified Transfer - Last Call
Message-ID: <4E9F2136.70201@arin.net>

The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
send the following draft policy to last call:

   ARIN-2011-10: Remove Single Aggregate requirement from Specified Transfer

Feedback is encouraged during the last call period. All comments should
be provided to the Public Policy Mailing List. Last call for 2011-10 
will expire on 2 November 2011. After last call the AC will conduct 
their last call review.

The draft policy text is below and available at:
https://www.arin.net/policy/proposals/

The ARIN Policy Development Process is available at:
https://www.arin.net/policy/pdp.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2011-10
Remove Single Aggregate requirement from Specified Transfer

Date: 24 August 2011

Policy statement:

Modify Section 8.3 as follows: Change "can demonstrate the need for such 
resources, as a single aggregate, in the exact amount which they can 
justify under current ARIN policies" to "can demonstrate the need for 
such resources in the amount which they can justify under current ARIN 
policies"

Rationale:

The "as a single aggregate" has been interpreted to apply only to 
"demonstrate the need" as opposed to the resources which may be received 
by ARIN staff. It is possible that the original intent was to require 
than each transfer be of a single aggregate.

HOWEVER, as multiple Section 8.3 transfers may be executed serially by a 
pair of entities which wish to use the specified transfer policy in 
order to transfer any number of blocks as long as there is needs 
justification for each, it simply saves the transferring entity, the 
recipient, AND ARIN paperwork to allow a transfer of multiple blocks to 
proceed as a single transfer.

Timetable for implementation: immediate


From bill at herrin.us  Wed Oct 19 15:36:49 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 19 Oct 2011 15:36:49 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4E9F20FF.1070203@arin.net>
References: <4E9F20FF.1070203@arin.net>
Message-ID: <CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>

On Wed, Oct 19, 2011 at 3:11 PM, ARIN <info at arin.net> wrote:
> 8.3 Transfers to Specified Recipients
>
> In addition to transfers under section 8.2, IPv4 number resources may be
> released to ARIN by the authorized resource holder or another RIR, in
> whole or in part, for transfer to another specified organizational
> recipient. ?Organizations in the ARIN region may receive transferred
> number resources under RSA if they can demonstrate the need for such
> resources in the amount which they can justify under current ARIN policies.
>
> IPv4 address resources may be transferred to organizations in another
> RIR's service region if they demonstrate need to their region's RIR,
> according to that RIR's policies. Inter-regional transfers may take
> place only via RIRs who agree to the transfer and share compatible,
> needs-based policies. Such resources must be transferred in blocks of
> /24 or larger and will become part of the resource holdings of the
> recipient RIR.


Am I the only one who doesn't think that transfers between ARIN
registrants and transfers between RIR's should be mashed into the same
policy subsection?

Besides, doesn't this language prevent inter-region address transfer
due to mergers or acquisitions? If I want to buy a web hosting shop
and move it off shore, why should I be denied?

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 randy.whitney at verizon.com  Wed Oct 19 15:59:22 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Wed, 19 Oct 2011 15:59:22 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4E9F20FF.1070203@arin.net>
References: <4E9F20FF.1070203@arin.net>
Message-ID: <4E9F2C1A.6070409@verizon.com>

On 10/19/2011 3:11 PM, ARIN wrote:
> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
> send an amended version of the following draft policy to an extended
> last call:
>
>     ARIN-2011-1: ARIN Inter-RIR Transfers
>
> The AC provided the following statement:
>
> ********
> The Advisory Council reviewed the results of feedback from the ARIN
> XXVIII Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR
> Transfers.  While there were concerns regarding the presented wording,
> there was significant continued support for a policy enabling
> Inter-Regional transfers of IPv4 number resources from organizations
> able to make them available to any organization with valid requirements.

I support immediate adoption of this policy, (alleged) warts and all in 
the interests of passing the _Global_ standard for Inter-RIR Transfers.

> The AC thanks everyone in the community for their help in crafting this
> important policy and for your statements of support or other comments
> during Last Call.
> ********

It certainly was a lively meeting!

Best Regards,
Randy Whitney.



From owen at delong.com  Wed Oct 19 16:02:19 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 19 Oct 2011 22:02:19 +0200
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
Message-ID: <E4BFFC09-8D59-4E11-B361-605C8EC2BA61@delong.com>



Sent from my iPad

On Oct 19, 2011, at 9:36 PM, William Herrin <bill at herrin.us> wrote:

> On Wed, Oct 19, 2011 at 3:11 PM, ARIN <info at arin.net> wrote:
>> 8.3 Transfers to Specified Recipients
>> 
>> In addition to transfers under section 8.2, IPv4 number resources may be
>> released to ARIN by the authorized resource holder or another RIR, in
>> whole or in part, for transfer to another specified organizational
>> recipient.  Organizations in the ARIN region may receive transferred
>> number resources under RSA if they can demonstrate the need for such
>> resources in the amount which they can justify under current ARIN policies.
>> 
>> IPv4 address resources may be transferred to organizations in another
>> RIR's service region if they demonstrate need to their region's RIR,
>> according to that RIR's policies. Inter-regional transfers may take
>> place only via RIRs who agree to the transfer and share compatible,
>> needs-based policies. Such resources must be transferred in blocks of
>> /24 or larger and will become part of the resource holdings of the
>> recipient RIR.
> 
> 
> Am I the only one who doesn't think that transfers between ARIN
> registrants and transfers between RIR's should be mashed into the same
> policy subsection?

They aren't. There is nothing about transfers between RIR's here other than the role the RIRs play in transfers between registrants in different RIR's service regions.
> 
> Besides, doesn't this language prevent inter-region address transfer
> due to mergers or acquisitions? If I want to buy a web hosting shop
> and move it off shore, why should I be denied?
> 
There remain all the same options that have always existed under section 8.2 for such actions.
This policy does not seek to change that. If you feel it should be changed, you should submit a proposal to make the changes you consider desirable.

Owen

> 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 randy.whitney at verizon.com  Wed Oct 19 16:20:55 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Wed, 19 Oct 2011 16:20:55 -0400
Subject: [arin-ppml] ARIN-2011-10: Remove Single Aggregate requirement
 from Specified Transfer - Last Call
In-Reply-To: <4E9F2136.70201@arin.net>
References: <4E9F2136.70201@arin.net>
Message-ID: <4E9F3127.1000803@verizon.com>

On 10/19/2011 3:12 PM, ARIN wrote:
> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
> send the following draft policy to last call:
>
>     ARIN-2011-10: Remove Single Aggregate requirement from Specified Transfer
>
> Policy statement:
>
> Modify Section 8.3 as follows: Change "can demonstrate the need for such
> resources, as a single aggregate, in the exact amount which they can
> justify under current ARIN policies" to "can demonstrate the need for
> such resources in the amount which they can justify under current ARIN
> policies"
>

I support immediate adoption of this policy. Giving out more resources
than necessary due to an aggregation requirement, or forcing resource
holders to "serially" submit resource requests to "do the right thing"
seems suboptimal in either case.

Best Regards,
Randy



From lsawyer at gci.com  Wed Oct 19 16:25:15 2011
From: lsawyer at gci.com (Leif Sawyer)
Date: Wed, 19 Oct 2011 12:25:15 -0800
Subject: [arin-ppml] ARIN-2011-10: Remove Single Aggregate requirement
 from Specified Transfer - Last Call
In-Reply-To: <4E9F3127.1000803@verizon.com>
References: <4E9F2136.70201@arin.net> <4E9F3127.1000803@verizon.com>
Message-ID: <18B2C6E38A3A324986B392B2D18ABC5101D2E41272@fnb1mbx01.gci.com>

Randy Whitney wrote:
> On 10/19/2011 3:12 PM, ARIN wrote:
>> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
>> send the following draft policy to last call:
>>
>>     ARIN-2011-10: Remove Single Aggregate requirement from 
>>                   Specified Transfer
>>
>> Policy statement:
>>
>> Modify Section 8.3 as follows: Change "can demonstrate the 
>> need for such resources, as a single aggregate, in the exact
>> amount which they can justify under current ARIN policies" to
>> "can demonstrate the need for such resources in the amount
>> which they can justify under current ARIN policies"
>>
> 
> I support immediate adoption of this policy. Giving out more resources
> than necessary due to an aggregation requirement, or forcing resource
> holders to "serially" submit resource requests to "do the right thing"
> seems suboptimal in either case.

+1 for KISS fixups.


From bill at herrin.us  Wed Oct 19 16:33:33 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 19 Oct 2011 16:33:33 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <E4BFFC09-8D59-4E11-B361-605C8EC2BA61@delong.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<E4BFFC09-8D59-4E11-B361-605C8EC2BA61@delong.com>
Message-ID: <CAP-guGVAiL4Whw5Ur_jg+YoyRCOJ5cVeHmL-xOmQQP12Xmvhrw@mail.gmail.com>

On Wed, Oct 19, 2011 at 4:02 PM, Owen DeLong <owen at delong.com> wrote:
> On Oct 19, 2011, at 9:36 PM, William Herrin <bill at herrin.us> wrote:
>> On Wed, Oct 19, 2011 at 3:11 PM, ARIN <info at arin.net> wrote:
>>> 8.3 Transfers to Specified Recipients
>>>
>>> In addition to transfers under section 8.2, IPv4 number resources may be
>>> released to ARIN by the authorized resource holder or another RIR, in
>>> whole or in part, for transfer to another specified organizational
>>> recipient. ?Organizations in the ARIN region may receive transferred
>>> number resources under RSA if they can demonstrate the need for such
>>> resources in the amount which they can justify under current ARIN policies.
>>>
>>> IPv4 address resources may be transferred to organizations in another
>>> RIR's service region if they demonstrate need to their region's RIR,
>>> according to that RIR's policies. Inter-regional transfers may take
>>> place only via RIRs who agree to the transfer and share compatible,
>>> needs-based policies. Such resources must be transferred in blocks of
>>> /24 or larger and will become part of the resource holdings of the
>>> recipient RIR.
>>
>>
>> Am I the only one who doesn't think that transfers between ARIN
>> registrants and transfers between RIR's should be mashed into the same
>> policy subsection?
>
> They aren't. There is nothing about transfers between RIR's here other than the role the RIRs play in transfers between registrants in different RIR's service regions.

I don't think in-region transfers between two ARIN registrants and
out-region transfers between an ARIN registrant and a non-ARIN
registrant belong in the same subsection. I think mashing them
together in one section clutters and confuses the issues for both.

Would you like me to find another few ways to restate my objection, or
are you tracking now despite any other possible ways to interpret the
words?



>> Besides, doesn't this language prevent inter-region address transfer
>> due to mergers or acquisitions? If I want to buy a web hosting shop
>> and move it off shore, why should I be denied?
>>
> There remain all the same options that have always existed under section 8.2 for such actions.

Which are?

2011-1 as published 9/22/11 applied equally to 8.2 and 8.3 transfers.


I also object to the end-run around the PDP. The AC is not empowered
to insert a proposal directly to Last Call and this proposal is (at
best) the "same idea" as proposal 2011-1. Structurally, it's a whole
new proposal which should go through the normal draft and discussion
process. Should the board feel action is urgent, they alone hold the
authority to jump that process.


Regards,
Bill Herrin


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


From scottleibrand at gmail.com  Wed Oct 19 17:00:18 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 19 Oct 2011 14:00:18 -0700
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGVAiL4Whw5Ur_jg+YoyRCOJ5cVeHmL-xOmQQP12Xmvhrw@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<E4BFFC09-8D59-4E11-B361-605C8EC2BA61@delong.com>
	<CAP-guGVAiL4Whw5Ur_jg+YoyRCOJ5cVeHmL-xOmQQP12Xmvhrw@mail.gmail.com>
Message-ID: <CAGkMwz7=TDA5QAWOQ4ppuHocGzfTC9h=SEo=cw_cTAHQUOHHXA@mail.gmail.com>

On Wed, Oct 19, 2011 at 1:33 PM, William Herrin <bill at herrin.us> wrote:

> On Wed, Oct 19, 2011 at 4:02 PM, Owen DeLong <owen at delong.com> wrote:
> > On Oct 19, 2011, at 9:36 PM, William Herrin <bill at herrin.us> wrote:
> >> On Wed, Oct 19, 2011 at 3:11 PM, ARIN <info at arin.net> wrote:
> >>> 8.3 Transfers to Specified Recipients
> >>>
> >>> In addition to transfers under section 8.2, IPv4 number resources may
> be
> >>> released to ARIN by the authorized resource holder or another RIR, in
> >>> whole or in part, for transfer to another specified organizational
> >>> recipient.  Organizations in the ARIN region may receive transferred
> >>> number resources under RSA if they can demonstrate the need for such
> >>> resources in the amount which they can justify under current ARIN
> policies.
> >>>
> >>> IPv4 address resources may be transferred to organizations in another
> >>> RIR's service region if they demonstrate need to their region's RIR,
> >>> according to that RIR's policies. Inter-regional transfers may take
> >>> place only via RIRs who agree to the transfer and share compatible,
> >>> needs-based policies. Such resources must be transferred in blocks of
> >>> /24 or larger and will become part of the resource holdings of the
> >>> recipient RIR.
> >>
> >>
> >> Am I the only one who doesn't think that transfers between ARIN
> >> registrants and transfers between RIR's should be mashed into the same
> >> policy subsection?
> >
> > They aren't. There is nothing about transfers between RIR's here other
> than the role the RIRs play in transfers between registrants in different
> RIR's service regions.
>
> I don't think in-region transfers between two ARIN registrants and
> out-region transfers between an ARIN registrant and a non-ARIN
> registrant belong in the same subsection. I think mashing them
> together in one section clutters and confuses the issues for both.
>
> Would you like me to find another few ways to restate my objection, or
> are you tracking now despite any other possible ways to interpret the
> words?
>

Objection noted.  The only other thing you might be able to help us with is
actual suggested text changes that you feel makes in more clear.  When I
drafted this text I was striving for as few (new) words as possible, while
being as clear and explicit as possible.  If you can find a better balance
there, I'm all ears.


> >> Besides, doesn't this language prevent inter-region address transfer
> >> due to mergers or acquisitions? If I want to buy a web hosting shop
> >> and move it off shore, why should I be denied?
> >>
> > There remain all the same options that have always existed under section
> 8.2 for such actions.
>
> Which are?
>

I believe there are a handful of companies holding ARIN space outside of the
ARIN region.  This proposal would not necessarily allow them to transfer
their registration to another RIR.  We discussed this in the AC meeting, and
one of the points I recall was that 8.2 transfers are generally only done
when the network assets that justified the number resources are transferred
between organizations.  Since those network assets usually can't be moved
between continents, inter-regional 8.2 transfers should be fairly rare.  In
any case, we felt it would be better to fully consider that issue as a
separate policy proposal, since the question of inter-regional 8.2 transfers
wasn't sufficiently discussed on PPML or at the public policy meeting in
Philly.


>
> 2011-1 as published 9/22/11 applied equally to 8.2 and 8.3 transfers.
>

I believe that is one valid interpretation of the unfortunately vague
language of the 9/22 version of 2011-1.  ARIN staff mentioned that they
couldn't actually do a staff assessment of that text, and instead assessed
what they interpreted our intent to be.


> I also object to the end-run around the PDP. The AC is not empowered
> to insert a proposal directly to Last Call and this proposal is (at
> best) the "same idea" as proposal 2011-1. Structurally, it's a whole
> new proposal which should go through the normal draft and discussion
> process. Should the board feel action is urgent, they alone hold the
> authority to jump that process.
>

Objection noted.  I would argue that there was a consensus at the PPM in
Philadelphia for the AC to make revisions to 2011-1 to address the concerns
discussed at the meeting, and there was an overwhelming consensus in favor
of inter-regional transfers.  So even aside from any urgency concerns, I
believe that the revisions to 2011-1 being discussed today have been
adequately discussed at the public policy meeting, and are appropriate to
send to last call.

If anyone else feels strongly on this subject, or more importantly has any
objections or suggestions to the draft policy text that was just sent out to
last call, please speak up.  I voted for an extended last call to ensure we
captured all of that input, so the AC can evaluate it at our next meeting.
And thanks, Bill, for jumping in with substantive comments so quickly.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111019/75672eef/attachment.htm>

From farmer at umn.edu  Wed Oct 19 17:17:05 2011
From: farmer at umn.edu (David Farmer)
Date: Wed, 19 Oct 2011 16:17:05 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
Message-ID: <4E9F3E51.8030102@umn.edu>


On 10/19/11 14:36 CDT, William Herrin wrote:
> On Wed, Oct 19, 2011 at 3:11 PM, ARIN<info at arin.net>  wrote:
>> 8.3 Transfers to Specified Recipients
>>
>> In addition to transfers under section 8.2, IPv4 number resources may be
>> released to ARIN by the authorized resource holder or another RIR, in
>> whole or in part, for transfer to another specified organizational
>> recipient.  Organizations in the ARIN region may receive transferred
>> number resources under RSA if they can demonstrate the need for such
>> resources in the amount which they can justify under current ARIN policies.
>>
>> IPv4 address resources may be transferred to organizations in another
>> RIR's service region if they demonstrate need to their region's RIR,
>> according to that RIR's policies. Inter-regional transfers may take
>> place only via RIRs who agree to the transfer and share compatible,
>> needs-based policies. Such resources must be transferred in blocks of
>> /24 or larger and will become part of the resource holdings of the
>> recipient RIR.
>
> Am I the only one who doesn't think that transfers between ARIN
> registrants and transfers between RIR's should be mashed into the same
> policy subsection?

Bill that is good feed back, I will consider it, do other feel similarly?

However, let me explain why I was thinking of it as one and the same all 
along;

To complete a inter-regional transfer you should more or less just be 
reusing the first half or last half of the current in region policy. 
Then the other half is completed by the other RIR according to their 
policies.  It seems duplicate to more or less repeat the same policy 
components in an inter-regional policy.  Also, I'm fairly confident we 
don't want any differences between the in region transfer policy and the 
appropriate local half of the inter-regional transfer policy.

> Besides, doesn't this language prevent inter-region address transfer
> due to mergers or acquisitions? If I want to buy a web hosting shop
> and move it off shore, why should I be denied?

I don't remember inter-regional M&A coming up before, but from 
discussion with Staff last week it appears this has been some small 
demand for this for a while now.  However, its not clear to me that most 
of the community was think of this issue when we discussed 
inter-regional transfers.  That's not to say we shouldn't, but I'm just 
not sure we should try to do it all in one bite anyway.

-- 
===============================================
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 jcurran at arin.net  Wed Oct 19 17:28:09 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 19 Oct 2011 21:28:09 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4E9F3E51.8030102@umn.edu>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
Message-ID: <CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>

On Oct 19, 2011, at 5:17 PM, David Farmer wrote:

>> Besides, doesn't this language prevent inter-region address transfer
>> due to mergers or acquisitions? If I want to buy a web hosting shop
>> and move it off shore, why should I be denied?
> 
> I don't remember inter-regional M&A coming up before, but from discussion with Staff last week it appears this has been some small demand for this for a while now.  However, its not clear to me that most of the community was think of this issue when we discussed inter-regional transfers.  That's not to say we shouldn't, but I'm just not sure we should try to do it all in one bite anyway.

International M&A transactions often don't appear to be interregional,
because the acquiring parties often have business units in our region
which actually end up being the acquiring business unit.  As long as
the infrastructure making use of the addresses is being acquired as
well, the processing of these requests is relatively routine (and is
generally between in-region businesses, even if one is held entirely
by an international firm.)

FYI,
/John

John Curran
President and CEO
ARIN





From bill at herrin.us  Wed Oct 19 17:54:54 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 19 Oct 2011 17:54:54 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
Message-ID: <CAP-guGWavN0aD59tKOacuMiXqgCFa-vCQC9gq0oyPyc8QWJecw@mail.gmail.com>

On Wed, Oct 19, 2011 at 5:28 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 19, 2011, at 5:17 PM, David Farmer wrote:
>>> Besides, doesn't this language prevent inter-region address transfer
>>> due to mergers or acquisitions? If I want to buy a web hosting shop
>>> and move it off shore, why should I be denied?
>>
>> I don't remember inter-regional M&A coming up before, but from discussion with Staff last week it appears this has been some small demand for this for a while now. ?However, its not clear to me that most of the community was think of this issue when we discussed inter-regional transfers. ?That's not to say we shouldn't, but I'm just not sure we should try to do it all in one bite anyway.
>
> International M&A transactions often don't appear to be interregional,
> because the acquiring parties often have business units in our region
> which actually end up being the acquiring business unit. ?As long as
> the infrastructure making use of the addresses is being acquired as
> well, the processing of these requests is relatively routine (and is
> generally between in-region businesses, even if one is held entirely
> by an international firm.)

Hi John,

For the sake of the argument, let's put a web hosting company holding
a /20 in El Paso. They're bought by a Mexican firm which puts the
servers on trucks and moves the operation to Juarez.

2011-1 as previously written says: 8.2 bought the company. 8.2 bought
the infrastructure. 2011-1 LACNIC has ARIN-compatible policies.
Transfer to LACNIC. Done.

2011-1 as posted today says... not an 8.3 transfer. 8.2 says... in
region transfers. RSA 8 says... hmm, you do not appear to have any
ARIN-region infrastructure with which to maintain your justification
for those addresses. RSA 14b says... we'll take take those address,
thank you. Buh bye!


Now, I'm sure this particular case happens at least several times a
day, but seriously: separated from section 8.2 and 8.3, draft 2011-1
was sufficiently comprehensive to handle it. Merged with section 8.3,
it isn't.

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  Wed Oct 19 17:57:35 2011
From: farmer at umn.edu (David Farmer)
Date: Wed, 19 Oct 2011 16:57:35 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
Message-ID: <4E9F47CF.9030900@umn.edu>


On 10/19/11 16:28 CDT, John Curran wrote:
> On Oct 19, 2011, at 5:17 PM, David Farmer wrote:
>
>>> Besides, doesn't this language prevent inter-region address transfer
>>> due to mergers or acquisitions? If I want to buy a web hosting shop
>>> and move it off shore, why should I be denied?
>>
>> I don't remember inter-regional M&A coming up before,

Additionally, there has been NO discussion of Inter-regional transfers 
of ASNs or IPv6 by the community, which is also implied in 8.2 and not 
allowed under 8.3 as it is currently.  Therefore, I think inter-regional 
M&A should be considered as a separate subject so we can explore all of 
it implications.

>> but from discussion with Staff last week it appears this has been some small demand for this for a while now.  However, its not clear to me that most of the community was think of this issue when we discussed inter-regional transfers.  That's not to say we shouldn't, but I'm just not sure we should try to do it all in one bite anyway.
>
> International M&A transactions often don't appear to be interregional,
> because the acquiring parties often have business units in our region
> which actually end up being the acquiring business unit.  As long as
> the infrastructure making use of the addresses is being acquired as
> well, the processing of these requests is relatively routine (and is
> generally between in-region businesses, even if one is held entirely
> by an international firm.)

Thank you for clarifying John.

> FYI,
> /John
>
> John Curran
> President and CEO
> ARIN
>
>
>

-- 
===============================================
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  Wed Oct 19 18:07:54 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 19 Oct 2011 18:07:54 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4E9F47CF.9030900@umn.edu>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
Message-ID: <CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>

On Wed, Oct 19, 2011 at 5:57 PM, David Farmer <farmer at umn.edu> wrote:
> Additionally, there has been NO discussion of Inter-regional transfers of
> ASNs or IPv6 by the community, which is also implied in 8.2 and not allowed
> under 8.3 as it is currently. ?Therefore, I think inter-regional M&A should
> be considered as a separate subject so we can explore all of it
> implications.

Hi David,

I tend to think that the 2011-1 discussion didn't veer in that
direction because if anyone finds 8.2 transfers out-region to be
offensive, they find it vastly less so than 8.3 transfers.

Perhaps I'm wrong and someone will tell me how strenuously they object
to transferring AS numbers and IPv4 and IPv6 addresses when a company
is sold and its infrastructure moved from one country to another.

Regards,
Bill Herrin


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


From scottleibrand at gmail.com  Wed Oct 19 18:13:41 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 19 Oct 2011 15:13:41 -0700
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
Message-ID: <CAGkMwz4qb68NDottuiW+Tun1JOvTepgcFX4Nb+LbHLU2otBm=A@mail.gmail.com>

On Wed, Oct 19, 2011 at 3:07 PM, William Herrin <bill at herrin.us> wrote:

> On Wed, Oct 19, 2011 at 5:57 PM, David Farmer <farmer at umn.edu> wrote:
> > Additionally, there has been NO discussion of Inter-regional transfers of
> > ASNs or IPv6 by the community, which is also implied in 8.2 and not
> allowed
> > under 8.3 as it is currently.  Therefore, I think inter-regional M&A
> should
> > be considered as a separate subject so we can explore all of it
> > implications.
>
> Hi David,
>
> I tend to think that the 2011-1 discussion didn't veer in that
> direction because if anyone finds 8.2 transfers out-region to be
> offensive, they find it vastly less so than 8.3 transfers.
>
> Perhaps I'm wrong and someone will tell me how strenuously they object
> to transferring AS numbers and IPv4 and IPv6 addresses when a company
> is sold and its infrastructure moved from one country to another.



I think you're both right.  There isn't a lot of objection to it, but there
isn't a lot of demand for it either.

I have seen some support for and objections to allowing ASN transfers under
8.3, as proposed in ARIN-prop-157...

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

From bill at herrin.us  Wed Oct 19 18:13:42 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 19 Oct 2011 18:13:42 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAGkMwz7=TDA5QAWOQ4ppuHocGzfTC9h=SEo=cw_cTAHQUOHHXA@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<E4BFFC09-8D59-4E11-B361-605C8EC2BA61@delong.com>
	<CAP-guGVAiL4Whw5Ur_jg+YoyRCOJ5cVeHmL-xOmQQP12Xmvhrw@mail.gmail.com>
	<CAGkMwz7=TDA5QAWOQ4ppuHocGzfTC9h=SEo=cw_cTAHQUOHHXA@mail.gmail.com>
Message-ID: <CAP-guGU=xmtJBFrC7fofmpvNYocWHqSiUt+9YhQMVApDsctzxA@mail.gmail.com>

On Wed, Oct 19, 2011 at 5:00 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On Wed, Oct 19, 2011 at 1:33 PM, William Herrin <bill at herrin.us> wrote:
>> I also object to the end-run around the PDP. The AC is not empowered
>> to insert a proposal directly to Last Call and this proposal is (at
>> best) the "same idea" as proposal 2011-1. Structurally, it's a whole
>> new proposal which should go through the normal draft and discussion
>> process. Should the board feel action is urgent, they alone hold the
>> authority to jump that process.
>
> Objection noted. ?I would argue that there was a consensus at the PPM in
> Philadelphia for the AC to make revisions to 2011-1 to address the concerns
> discussed at the meeting, and there was an overwhelming consensus in favor
> of inter-regional transfers.

Hi Scott,

I have no reason to disagree with your assessment either of the
consensus to revise draft 2011-1 or the consensus in favor of the IDEA
of inter-region transfers. However:

22 September 2011

> Policy statement:
>
> Address resources may be transferred in or out of the ARIN region to
> those who demonstrate need and plan to deploy them for a networking
> purpose within 3 months. Such transfers will take place between RIRs who
> share compatible, needs-based policies supporting entities agreeing to
> the transfer and which otherwise meet both RIR's policies. Transferred
> resources will become part of the resource holdings of the recipient RIR
> unless otherwise agreed by both RIRs.

14 October 2011

>Policy statement:
>
>[Strike NRPM section 8.3 and replace with]
>8.3 Transfers to Specified Recipients
>
>In addition to transfers under section 8.2, IPv4 number resources may be
>released to ARIN by the authorized resource holder or another RIR, in
>whole or in part, for transfer to another specified organizational
>recipient.  Organizations in the ARIN region may receive transferred
>number resources under RSA if they can demonstrate the need for such
>resources in the amount which they can justify under current ARIN policies.
>
>IPv4 address resources may be transferred to organizations in another
>RIR's service region if they demonstrate need to their region's RIR,
>according to that RIR's policies. Inter-regional transfers may take
>place only via RIRs who agree to the transfer and share compatible,
>needs-based policies. Such resources must be transferred in blocks of
>/24 or larger and will become part of the resource holdings of the
>recipient RIR.


This is not a revised "draft policy." It's a whole new draft policy
based on similar ideas. Read them side by side; the difference is so
blatant it defies description.

The PDP requires development, discussion and consensus on DRAFT POLICY
before last call. Not development, discussion and consensus on IDEAS
that may become draft policy.

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  Wed Oct 19 18:37:59 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 20 Oct 2011 00:37:59 +0200
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGVAiL4Whw5Ur_jg+YoyRCOJ5cVeHmL-xOmQQP12Xmvhrw@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<E4BFFC09-8D59-4E11-B361-605C8EC2BA61@delong.com>
	<CAP-guGVAiL4Whw5Ur_jg+YoyRCOJ5cVeHmL-xOmQQP12Xmvhrw@mail.gmail.com>
Message-ID: <A8D2A623-D4E8-48B2-8B6C-56EFDD56E357@delong.com>



Sent from my iPad

On Oct 19, 2011, at 10:33 PM, William Herrin <bill at herrin.us> wrote:

> On Wed, Oct 19, 2011 at 4:02 PM, Owen DeLong <owen at delong.com> wrote:
>> On Oct 19, 2011, at 9:36 PM, William Herrin <bill at herrin.us> wrote:
>>> On Wed, Oct 19, 2011 at 3:11 PM, ARIN <info at arin.net> wrote:
>>>> 8.3 Transfers to Specified Recipients
>>>> 
>>>> In addition to transfers under section 8.2, IPv4 number resources may be
>>>> released to ARIN by the authorized resource holder or another RIR, in
>>>> whole or in part, for transfer to another specified organizational
>>>> recipient.  Organizations in the ARIN region may receive transferred
>>>> number resources under RSA if they can demonstrate the need for such
>>>> resources in the amount which they can justify under current ARIN policies.
>>>> 
>>>> IPv4 address resources may be transferred to organizations in another
>>>> RIR's service region if they demonstrate need to their region's RIR,
>>>> according to that RIR's policies. Inter-regional transfers may take
>>>> place only via RIRs who agree to the transfer and share compatible,
>>>> needs-based policies. Such resources must be transferred in blocks of
>>>> /24 or larger and will become part of the resource holdings of the
>>>> recipient RIR.
>>> 
>>> 
>>> Am I the only one who doesn't think that transfers between ARIN
>>> registrants and transfers between RIR's should be mashed into the same
>>> policy subsection?
>> 
>> They aren't. There is nothing about transfers between RIR's here other than the role the RIRs play in transfers between registrants in different RIR's service regions.
> 
> I don't think in-region transfers between two ARIN registrants and
> out-region transfers between an ARIN registrant and a non-ARIN
> registrant belong in the same subsection. I think mashing them
> together in one section clutters and confuses the issues for both.
> 
> Would you like me to find another few ways to restate my objection, or
> are you tracking now despite any other possible ways to interpret the
> words?
> 
> 

Ah, OK... sorry, I misread your original message. My bad.
Yes, I'm tracking now. I understand your objection. I don't agree with 
it in this case and think that maintaining parallel and separate policies
proved to be a distinct form of rat hole in multiple attempts.

> 
>>> Besides, doesn't this language prevent inter-region address transfer
>>> due to mergers or acquisitions? If I want to buy a web hosting shop
>>> and move it off shore, why should I be denied?
>>> 
>> There remain all the same options that have always existed under section 8.2 for such actions.
> 
> Which are?

I will happily discuss this with you in another thread or off-list, but, they really
aren't germane to the current topic and I don't want to hijack the thread down
that particular rat-hole.

> 
> 2011-1 as published 9/22/11 applied equally to 8.2 and 8.3 transfers.
> 
> 
> I also object to the end-run around the PDP. The AC is not empowered
> to insert a proposal directly to Last Call and this proposal is (at
> best) the "same idea" as proposal 2011-1. Structurally, it's a whole
> new proposal which should go through the normal draft and discussion
> process. Should the board feel action is urgent, they alone hold the
> authority to jump that process.
> 

Bill, with all due respect, this is the same idea as 2011-1 and in fact largely the same policy. The AC is empowered to amend draft policies based on community feedback and send the result to last call. That is what happened in this case. There was significant community feedback at the meeting and the majority of the AC felt that this policy incorporated the original stated intent of the draft policy as well as the feedback received from the community on the mailing list and at the PPM.

Owen



From farmer at umn.edu  Wed Oct 19 18:43:17 2011
From: farmer at umn.edu (David Farmer)
Date: Wed, 19 Oct 2011 17:43:17 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
Message-ID: <4E9F5285.5070106@umn.edu>


On 10/19/11 17:07 CDT, William Herrin wrote:
> On Wed, Oct 19, 2011 at 5:57 PM, David Farmer<farmer at umn.edu>  wrote:
>> Additionally, there has been NO discussion of Inter-regional transfers of
>> ASNs or IPv6 by the community, which is also implied in 8.2 and not allowed
>> under 8.3 as it is currently.  Therefore, I think inter-regional M&A should
>> be considered as a separate subject so we can explore all of it
>> implications.
>
> Hi David,
>
> I tend to think that the 2011-1 discussion didn't veer in that
> direction because if anyone finds 8.2 transfers out-region to be
> offensive, they find it vastly less so than 8.3 transfers.
>
> Perhaps I'm wrong and someone will tell me how strenuously they object
> to transferring AS numbers and IPv4 and IPv6 addresses when a company
> is sold and its infrastructure moved from one country to another.

Honestly, I'm not fundamentally opposed to ASN or IPv6 transfers, in 
region or inter-region.  But, I am opposed to sneaking them in the back 
door, if we allow them they need to be discussed fully.  I view Prop-157 
is the start of that discussion.

Additionally, I think we really need to give some serious thought about 
some of the technical issue around IPv6, especially regarding issues 
like sparse allocation, but I'm sure there are others too.  These could 
be tricky in region, but they are even more tricky transferring out of 
region.  Like, do we transfer to the other RIR only the registered 
block, the registered block plus the next 1,2, or 3 nibbles?  Especially 
in IPv6 we could create consequences that we have to live with for a 
very long time.  I'd rather not rush that discussion.

Even more, I'd rather not block inter-region IPv4 transfers with that 
discussion.

-- 
===============================================
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 jcurran at arin.net  Wed Oct 19 18:43:34 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 19 Oct 2011 22:43:34 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGWavN0aD59tKOacuMiXqgCFa-vCQC9gq0oyPyc8QWJecw@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<CAP-guGWavN0aD59tKOacuMiXqgCFa-vCQC9gq0oyPyc8QWJecw@mail.gmail.com>
Message-ID: <7964F6AF-C54B-4AD0-A10B-461230530D8F@arin.net>


On Oct 19, 2011, at 5:54 PM, William Herrin wrote:

> On Wed, Oct 19, 2011 at 5:28 PM, John Curran <jcurran at arin.net> wrote:
>> On Oct 19, 2011, at 5:17 PM, David Farmer wrote:
>>>> Besides, doesn't this language prevent inter-region address transfer
>>>> due to mergers or acquisitions? If I want to buy a web hosting shop
>>>> and move it off shore, why should I be denied?
>>> 
>>> I don't remember inter-regional M&A coming up before, but from discussion with Staff last week it appears this has been some small demand for this for a while now.  However, its not clear to me that most of the community was think of this issue when we discussed inter-regional transfers.  That's not to say we shouldn't, but I'm just not sure we should try to do it all in one bite anyway.
>> 
>> International M&A transactions often don't appear to be interregional,
>> because the acquiring parties often have business units in our region
>> which actually end up being the acquiring business unit.  As long as
>> the infrastructure making use of the addresses is being acquired as
>> well, the processing of these requests is relatively routine (and is
>> generally between in-region businesses, even if one is held entirely
>> by an international firm.)
> 
> Hi John,
> 
> For the sake of the argument, let's put a web hosting company holding
> a /20 in El Paso. They're bought by a Mexican firm which puts the
> servers on trucks and moves the operation to Juarez.
> 
> 2011-1 as previously written says: 8.2 bought the company. 8.2 bought
> the infrastructure. 2011-1 LACNIC has ARIN-compatible policies.
> Transfer to LACNIC. Done.
> 
> 2011-1 as posted today says... not an 8.3 transfer. 8.2 says... in
> region transfers. RSA 8 says... hmm, you do not appear to have any
> ARIN-region infrastructure with which to maintain your justification
> for those addresses. RSA 14b says... we'll take take those address,
> thank you. Buh bye!
> 
> Now, I'm sure this particular case happens at least several times a
> day, but seriously: separated from section 8.2 and 8.3, draft 2011-1
> was sufficiently comprehensive to handle it. Merged with section 8.3,
> it isn't.

Bill - 

  I don't know if we've ever seen your particular scenario or not.
 
  M&A transfers are handled under NRPM 8.2.  I do not believe that
  any version of 2011-1 specifically prevents inter-RIR M&A transfers 
  from occurring, and the present 2011-1 draft policy for specified 
  transfers clearly is distinct from NRPM 8.2 due to starting with 
  the line "In addition to transfers under section 8.2,..."

  You've indicated 8.2 says "in region transfers" transfers, and 
  yet that is not present in the policy text nor in the overarching 
  NRPM 8.1 section on Transfer Principles.  If a large ISP from 
  another region presented legal documentation that it has fully 
  acquired an in-ARIN-region ISP, we would update the registrations 
  accordingly, and I seen no version of 2011-1 which would alter 
  this situation (Note - one might have attempted to twist Draft 
  Policy 2011-13, which is now abandoned, into such a creative 
  interpretation but even that would be questionable given the 
  specific draft policy text that was being considered.)

  If you believe that inter-RIR M&A transfers should not be 
  allowed, I would suggest submitting specific policy language 
  for inclusion into NRPM section 8.2.

Thanks,
/John

John Curran
President and CEO
ARIN








From bill at herrin.us  Wed Oct 19 19:17:13 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 19 Oct 2011 19:17:13 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4E9F5285.5070106@umn.edu>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
Message-ID: <CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>

On Wed, Oct 19, 2011 at 6:43 PM, David Farmer <farmer at umn.edu> wrote:
> Additionally, I think we really need to give some serious thought about some
> of the technical issue around IPv6, especially regarding issues like sparse
> allocation, but I'm sure there are others too. ?These could be tricky in
> region, but they are even more tricky transferring out of region. ?Like, do
> we transfer to the other RIR only the registered block, the registered block
> plus the next 1,2, or 3 nibbles? ?Especially in IPv6 we could create
> consequences that we have to live with for a very long time. ?I'd rather not
> rush that discussion.
>
> Even more, I'd rather not block inter-region IPv4 transfers with that
> discussion.


Hi David,

I have no particular objection to considering 8.2 style inter-region
transfers separately from 8.3 style transfers. Nevertheless, that's
one of a number of material differences between the draft presented at
the meeting and the draft presented today.

I don't want to belabor the point, so I'll try to confine my following
messages to issues and suggestions for the draft language itself, but
the bottom line is this: I think you guys need to request a ruling
from counsel as to whether language changes of this magnitude are
permissible within the section 4 portion of the PDP process as
published. As I read the PDP, non-cosmetic change requires a return to
the AC's docket, i.e. PDP section 2. And with proposed changes this
significant on a topic of such controversy, I'm inclined to hold your
feet to the fire.

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  Wed Oct 19 19:34:57 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 19 Oct 2011 23:34:57 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
Message-ID: <A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>

On Oct 19, 2011, at 7:17 PM, William Herrin wrote:
> I think you guys need to request a ruling from counsel as to whether
> language changes of this magnitude are permissible within the section 4
> portion of the PDP process as published. As I read the PDP, non-cosmetic
> change requires a return to the AC's docket, i.e. PDP section 2. 


Bill - 
 
  The requirement is that the AC must explain its changes to the
  policy text if the policy text sent to last call is different
  than what was put before the Public Policy meeting:

" 4.3 Last Call

The Advisory Council selects draft policies that have the support of the community and the Advisory Council and sends these draft policies to a last call for review and discussion by the community on the PPML. The last call period will be for a minimum of 10 days. The Advisory Council may decide that certain draft policies require a longer last call period of review, such as those that were revised based on comments received while the text was frozen. If the Advisory Council sends a draft policy to last call that is different from the frozen version, then the Advisory Council will provide an explanation for all changes to the text.
"

  Furthermore, the AC still retains the freedom to make changes even
  after last call is complete (during its last call review).  If any
  changes are made, the resulting text may be sent for an additional
  last call (and then to the Board of Trustees) or back to the docket
  for additional work, as the AC deems appropriate:

" 4.4. Last Call Review

Within 30 days of the end of last call the Advisory Council determines consensus for each draft policy by reviewing last call comments, revisiting its decision (the Advisory Council may take any action such as rewrite, merge, or abandon), and determining readiness for consideration by the Board of Trustees. If the Advisory Council modifies a draft policy, it will be sent to another last call or may be placed back on the docket of the Advisory Council for further development and evaluation.
"

FYI,
/John

John Curran
President and CEO
ARIN

From hannigan at gmail.com  Wed Oct 19 19:51:57 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 19 Oct 2011 19:51:57 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
Message-ID: <CAMDXq5O1o22Sx71gNgVE8puMRHtr6=tvWzJLq+=P3=Qad7xAKQ@mail.gmail.com>

John,

I believe that the CEO is an ex officious member of the AC. I wouldn't mind
if you explained the changes for us.

Best,

Marty
 On Oct 19, 2011 7:35 PM, "John Curran" <jcurran at arin.net> wrote:

> On Oct 19, 2011, at 7:17 PM, William Herrin wrote:
> > I think you guys need to request a ruling from counsel as to whether
> > language changes of this magnitude are permissible within the section 4
> > portion of the PDP process as published. As I read the PDP, non-cosmetic
> > change requires a return to the AC's docket, i.e. PDP section 2.
>
>
> Bill -
>
>  The requirement is that the AC must explain its changes to the
>  policy text if the policy text sent to last call is different
>  than what was put before the Public Policy meeting:
>
> " 4.3 Last Call
>
> The Advisory Council selects draft policies that have the support of the
> community and the Advisory Council and sends these draft policies to a last
> call for review and discussion by the community on the PPML. The last call
> period will be for a minimum of 10 days. The Advisory Council may decide
> that certain draft policies require a longer last call period of review,
> such as those that were revised based on comments received while the text
> was frozen. If the Advisory Council sends a draft policy to last call that
> is different from the frozen version, then the Advisory Council will provide
> an explanation for all changes to the text.
> "
>
>  Furthermore, the AC still retains the freedom to make changes even
>  after last call is complete (during its last call review).  If any
>  changes are made, the resulting text may be sent for an additional
>  last call (and then to the Board of Trustees) or back to the docket
>  for additional work, as the AC deems appropriate:
>
> " 4.4. Last Call Review
>
> Within 30 days of the end of last call the Advisory Council determines
> consensus for each draft policy by reviewing last call comments, revisiting
> its decision (the Advisory Council may take any action such as rewrite,
> merge, or abandon), and determining readiness for consideration by the Board
> of Trustees. If the Advisory Council modifies a draft policy, it will be
> sent to another last call or may be placed back on the docket of the
> Advisory Council for further development and evaluation.
> "
>
> FYI,
> /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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111019/47bcc95a/attachment.htm>

From jcurran at arin.net  Wed Oct 19 19:58:27 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 19 Oct 2011 23:58:27 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAMDXq5O1o22Sx71gNgVE8puMRHtr6=tvWzJLq+=P3=Qad7xAKQ@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
	<CAMDXq5O1o22Sx71gNgVE8puMRHtr6=tvWzJLq+=P3=Qad7xAKQ@mail.gmail.com>
Message-ID: <1A1DD3F8-B862-41BA-9745-9DC73ED0019C@arin.net>

On Oct 19, 2011, at 7:51 PM, Martin Hannigan wrote:

John,

I believe that the CEO is an ex officious member of the AC. I wouldn't mind if you explained the changes for us.

Marty -

   You probably mean: "The President of ARIN is a non-voting ex officio member of the Advisory Council."

   However, I'm not understanding the question:  What changes do you want me to explain?

Thanks,
/John

John Curran
President and CEO
ARIN


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

From hannigan at gmail.com  Wed Oct 19 20:03:53 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 19 Oct 2011 20:03:53 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <1A1DD3F8-B862-41BA-9745-9DC73ED0019C@arin.net>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
	<CAMDXq5O1o22Sx71gNgVE8puMRHtr6=tvWzJLq+=P3=Qad7xAKQ@mail.gmail.com>
	<1A1DD3F8-B862-41BA-9745-9DC73ED0019C@arin.net>
Message-ID: <CAMDXq5PL2wzNmDP5Y0zoL5QQ=JdnyvedbyP9+ufwnHeun7m8XA@mail.gmail.com>

I do. And you've excercised that standing. I don't mind if you represent us
all now and answer all of Bills questions with straight answers.

Best,

Marty
 On Oct 19, 2011 7:58 PM, "John Curran" <jcurran at arin.net> wrote:

>   On Oct 19, 2011, at 7:51 PM, Martin Hannigan wrote:
>
> John,
>
> I believe that the CEO is an ex officious member of the AC. I wouldn't mind
> if you explained the changes for us.
>
> Marty -
>
>     You probably mean: "The President of ARIN is a non-voting ex officio
> member of the Advisory Council."
>
>     However, I'm not understanding the question:  What changes do you want
> me to explain?
>
>  Thanks,
> /John
>
>  John Curran
> President and CEO
> ARIN
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111019/807157d8/attachment.htm>

From jcurran at arin.net  Wed Oct 19 20:17:14 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 20 Oct 2011 00:17:14 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAMDXq5PL2wzNmDP5Y0zoL5QQ=JdnyvedbyP9+ufwnHeun7m8XA@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
	<CAMDXq5O1o22Sx71gNgVE8puMRHtr6=tvWzJLq+=P3=Qad7xAKQ@mail.gmail.com>
	<1A1DD3F8-B862-41BA-9745-9DC73ED0019C@arin.net>
	<CAMDXq5PL2wzNmDP5Y0zoL5QQ=JdnyvedbyP9+ufwnHeun7m8XA@mail.gmail.com>
Message-ID: <859B4DF4-A1EA-4C11-8F97-D4C652E17983@arin.net>

On Oct 19, 2011, at 8:03 PM, Martin Hannigan wrote:
> I do. And you've excercised that standing. I don't mind if you represent us all now and answer all of Bills questions with straight answers.

Marty - 
    
    In general, I do not represent the AC, and it is the AC members working
    on various policy drafts who are the ones best qualified to speak regarding 
    their specific disposition.   When I see questions about ARIN business,
    the Policy Development Process, or staff handing of requests in accordance
    with policy, I try to be as responsive as humanly possible in answering.

    I believe I've provided straight answers to all of Bill's questions that are mine
    to answer, but please let me know if I missed any.

Thanks!
/John

John Curran
President and CEO
ARIN

   

From bill at herrin.us  Wed Oct 19 20:28:10 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 19 Oct 2011 20:28:10 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
Message-ID: <CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com>

On Wed, Oct 19, 2011 at 7:34 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 19, 2011, at 7:17 PM, William Herrin wrote:
>> I think you guys need to request a ruling from counsel as to whether
>> language changes of this magnitude are permissible within the section 4
>> portion of the PDP process as published. As I read the PDP, non-cosmetic
>> change requires a return to the AC's docket, i.e. PDP section 2.
>
> ?The requirement is that the AC must explain its changes to the
> ?policy text if the policy text sent to last call is different
> ?than what was put before the Public Policy meeting:

John,

I chose my words poorly. Please allow me to rephrase:

I would like to see the AC request a ruling as to whether changes of
this magnitude within section 4 of the PDP process are defensible as
mere changes to the draft versus the new text being considered a fresh
draft policy subject to entry into the process at section 2.

If a draft can, among other things, switch from adding text for a new
situation to the NRPM to rewriting and changing the meaning of
existing text in the NRPM then what's the point of having a PDP
section 2 and 3 at all? Let's just discuss ideas and then start all
the drafts at last call.

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  Wed Oct 19 20:47:00 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 20 Oct 2011 00:47:00 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
	<CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com>
Message-ID: <7CBCE3B6-E091-460D-A928-8DF6E3C782AB@arin.net>

On Oct 19, 2011, at 8:28 PM, William Herrin wrote:

> On Wed, Oct 19, 2011 at 7:34 PM, John Curran <jcurran at arin.net> wrote:
>> ...
>>  The requirement is that the AC must explain its changes to the
>>  policy text if the policy text sent to last call is different
>>  than what was put before the Public Policy meeting:
> 
> John,
> 
> I chose my words poorly. Please allow me to rephrase:
> 
> I would like to see the AC request a ruling as to whether changes of
> this magnitude within section 4 of the PDP process are defensible as
> mere changes to the draft versus the new text being considered a fresh
> draft policy subject to entry into the process at section 2.

The changes that occur to a draft policy text after presentation 
at the public policy meeting can be quite extensive and include 
any action including rewriting, merging, or abandoning. I believe 
that you are seeing the result of a "rewrite" of the draft policy,
and this is noted as specifically allowed by the PDP for policies
after PPM, with the protection being that any change results in 
another last call to the community.

Note also that you do have the option to petition for the original 
policy text to be sent to last call, if you do not like the action
taken by the ARIN AC on the draft policy.

Thanks!
/John

John Curran
President and CEO
ARIN





From jcurran at arin.net  Wed Oct 19 21:00:15 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 20 Oct 2011 01:00:15 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <7CBCE3B6-E091-460D-A928-8DF6E3C782AB@arin.net>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
	<CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com>
	<7CBCE3B6-E091-460D-A928-8DF6E3C782AB@arin.net>
Message-ID: <9AD3F6B7-C1B3-463B-A934-1E358D5585CA@arin.net>

On Oct 19, 2011, at 8:47 PM, John Curran wrote:

> The changes that occur to a draft policy text after presentation 
> at the public policy meeting can be quite extensive and include 
> any action including rewriting, merging, or abandoning. I believe 
> that you are seeing the result of a "rewrite" of the draft policy,
> and this is noted as specifically allowed by the PDP for policies
> after PPM, with the protection being that any change results in 
> another last call to the community.
> ...


I'd like to take a moment to highlight the hard work that the ARIN AC
does in the policy development process, and note that these folks really
do deserve our thanks for all of their efforts...!

Speaking of which, we've got just over two days until the polls close
on the 2011 Election process for ARIN Board and ARIN AC members.  IF
YOU HAVE NOT YET VOTED AND ARE THE DESIGNATED MEMBER REPRESENTATIVE
FOR YOUR ORGANIZATION, PLEASE GO TO https://www.arin.net/app/election/ 
and click "Vote Now"...   (see attached email for details)

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

> From: ARIN <info at arin.net>
> Subject: [arin-announce] ARIN Board and Advisory Council Elections - Voting Open Until Saturday
> Date: October 17, 2011 1:56:15 PM EDT
> To: <arin-announce at arin.net>
> 
> The polls remain open for the elections to fill two (2) seats on the ARIN Board of Trustees and five (5) seats on ARIN Advisory Council. The polls close at 5:00 PM ET, this Saturday 22 October. Brief candidate biographies and a link to submit or view statements of support can be found through ARIN Election Headquarters at:
> 
> https://www.arin.net/app/election/
> 
> You must be the designated member representative (DMR) from a General Member in good standing as of 1 January 2011 to vote. As stated in previous announcements, the deadline for establishing voter eligibility was 27 September 2011. To vote, visit ARIN Election Headquarters and click on the "Vote Now" button.
> 
> The online election is a two-step process.
> 
> Step 1. Register to vote (or login if previously voted) using the DMR email on file with ARIN.
> 
> Step 2. Vote and confirm the vote via the online voting booth. Only confirmed votes will be counted.
> 
> Designated member representatives must cast and confirm their ballots by 5:00 ET, 22 October.
> 
> If you have any questions about voting or encounter problems with the system, please immediately contact ARIN Communication and Member Services at info at arin.net.
> 
> Regards,
> 
> Communication and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> _______________________________________________
> ARIN-Announce
> You are receiving this message because you are subscribed to
> the ARIN Announce Mailing List (ARIN-announce at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-announce
> Please contact info at arin.net if you experience any issues.

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



From bill at herrin.us  Wed Oct 19 21:11:34 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 19 Oct 2011 21:11:34 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <7CBCE3B6-E091-460D-A928-8DF6E3C782AB@arin.net>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
	<CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com>
	<7CBCE3B6-E091-460D-A928-8DF6E3C782AB@arin.net>
Message-ID: <CAP-guGXxK5vzvYa+WmN9go-gW1-2tep_m=MAY1+3GsFXHVm=Cw@mail.gmail.com>

On Wed, Oct 19, 2011 at 8:47 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 19, 2011, at 8:28 PM, William Herrin wrote:
>> I would like to see the AC request a ruling as to whether changes of
>> this magnitude within section 4 of the PDP process are defensible as
>> mere changes to the draft versus the new text being considered a fresh
>> draft policy subject to entry into the process at section 2.
>
> The changes that occur to a draft policy text after presentation
> at the public policy meeting can be quite extensive and include
> any action including rewriting, merging, or abandoning. I believe
> that you are seeing the result of a "rewrite" of the draft policy,
> and this is noted as specifically allowed by the PDP for policies
> after PPM, with the protection being that any change results in
> another last call to the community.

Is this John Curran's opinion or is this the President of ARIN's
ruling on the process question as it relates to draft 2011-1?


> Note also that you do have the option to petition for the original
> policy text to be sent to last call, if you do not like the action
> taken by the ARIN AC on the draft policy.

The original text has all of the faults that have been attributed to
it in this thread. It was not expressed in clear, actionable policy
language and was indubitably in need of editing. The last thing I want
to do is petition for that text to be sent to last call.

In my opinion, the draft on the table IS NOT an edited version of that
text. This is probably a good thing. Purely from a "is this well
written actionable policy text," Scott's document is structurally
superior. But when you write a whole new proposal, it's a new
proposal. Throwing away a document and writing a new one is not a
change to the document, it's a new document.

And it should be treated as a new document.

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  Wed Oct 19 21:12:31 2011
From: farmer at umn.edu (David Farmer)
Date: Wed, 19 Oct 2011 20:12:31 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
	<CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com>
Message-ID: <4E9F757F.6010507@umn.edu>


On 10/19/11 19:28 CDT, William Herrin wrote:
.....
> If a draft can, among other things, switch from adding text for a new
> situation to the NRPM to rewriting and changing the meaning of
> existing text in the NRPM then what's the point of having a PDP
> section 2 and 3 at all? Let's just discuss ideas and then start all
> the drafts at last call.

There has never been anything explicitly stated about this being a 
separate section of the NRPM,  Almost all of the discussion I find is in 
a context of 8.3 transfers, there was one mention of including IPv6, but 
it didn't get much traction that I see.  Further, there was a fairly 
long thread in May with the subject "Integrating Draft Policy 
ARIN-2011-1 into NRPM 8.3" and back at San Juan Bill's slides had much 
the same context.

https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Monday/darte_prop2011_1.pdf

The idea that this would not be integrated into 8.3 in one way or 
another is not supported by what I could find in the discussion anywhere.

I'll admit, we are making non-trivial changes to the text, we said that, 
that is why we did an Extended Last-Call.  But I believe it is what the 
community was asking us to do.

Finally, if the consensus of the community in last-call is to take it 
back to another PPM, I'm fine with that too.  However, that is not the 
sense of the room I took out of Philly.

I would really appreciate a clear consensus from the community on this 
one.  What do you want us to do?  Please comment, even if it is simply 
you support or not the text as written.

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 BillD at cait.wustl.edu  Wed Oct 19 21:35:54 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 19 Oct 2011 20:35:54 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
References: <4E9F20FF.1070203@arin.net><CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com><4E9F3E51.8030102@umn.edu><CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net><4E9F47CF.9030900@umn.edu><CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com><4E9F5285.5070106@umn.edu><CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com><A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net><CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com><7CBCE3B6-E091-460D-A928-8DF6E3C782AB@arin.net>
	<CAP-guGXxK5vzvYa+WmN9go-gW1-2tep_m=MAY1+3GsFXHVm=Cw@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087915BCB@ex1.cait.wustl.edu>

Bill,

I appreciate your concern for the policy process and asking for clarification is a fine and useful mechanism for all to gain a more complete understanding.  Questioning John Curran about whether he is representing ARIN or himself when he is clearing speaking about the PDP and signing his emails in an official manner as the President of ARIN seems to be less useful.

Furthermore, I do not believe that you interpret the changes to the Draft Policy correctly by stating that it is a new policy.  But, for clarification, please help us all understand precisely where you interpret the changes in the modified text to change the character, intent or the will of the community for an Inter-regional transfer policy.

Thanks,

bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of William Herrin
Sent: Wed 10/19/2011 8:11 PM
To: John Curran
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
 
On Wed, Oct 19, 2011 at 8:47 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 19, 2011, at 8:28 PM, William Herrin wrote:
>> I would like to see the AC request a ruling as to whether changes of
>> this magnitude within section 4 of the PDP process are defensible as
>> mere changes to the draft versus the new text being considered a fresh
>> draft policy subject to entry into the process at section 2.
>
> The changes that occur to a draft policy text after presentation
> at the public policy meeting can be quite extensive and include
> any action including rewriting, merging, or abandoning. I believe
> that you are seeing the result of a "rewrite" of the draft policy,
> and this is noted as specifically allowed by the PDP for policies
> after PPM, with the protection being that any change results in
> another last call to the community.

Is this John Curran's opinion or is this the President of ARIN's
ruling on the process question as it relates to draft 2011-1?


> Note also that you do have the option to petition for the original
> policy text to be sent to last call, if you do not like the action
> taken by the ARIN AC on the draft policy.

The original text has all of the faults that have been attributed to
it in this thread. It was not expressed in clear, actionable policy
language and was indubitably in need of editing. The last thing I want
to do is petition for that text to be sent to last call.

In my opinion, the draft on the table IS NOT an edited version of that
text. This is probably a good thing. Purely from a "is this well
written actionable policy text," Scott's document is structurally
superior. But when you write a whole new proposal, it's a new
proposal. Throwing away a document and writing a new one is not a
change to the document, it's a new document.

And it should be treated as a new document.

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/20111019/0097ceaf/attachment.htm>

From cja at daydream.com  Wed Oct 19 21:37:59 2011
From: cja at daydream.com (CJ Aronson)
Date: Wed, 19 Oct 2011 19:37:59 -0600
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4E9F757F.6010507@umn.edu>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
	<CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com>
	<4E9F757F.6010507@umn.edu>
Message-ID: <CAMvf=7YNRPuE+EXTP41Env26CCkSoeY9WoYXGvo8tb_4iXRqVQ@mail.gmail.com>

I agree with David.. all policies get integrated into NRPM.   One of the
comments we got in Philly is that the text being discussed was not written
in a way that it fit into the NRPM.

The AC moved this text to last call.  According to the PDP this is within
our purview to do so.  So let's talk about this text and what folks
like/don't like about it.

If you want to propose changes to the PDP we can start another discussion
about that.. Note that there is a new PDP out right now to the community for
comments.

Thanks
----Cathy

On Wed, Oct 19, 2011 at 7:12 PM, David Farmer <farmer at umn.edu> wrote:

>
> On 10/19/11 19:28 CDT, William Herrin wrote:
> .....
>
>  If a draft can, among other things, switch from adding text for a new
>> situation to the NRPM to rewriting and changing the meaning of
>> existing text in the NRPM then what's the point of having a PDP
>> section 2 and 3 at all? Let's just discuss ideas and then start all
>> the drafts at last call.
>>
>
> There has never been anything explicitly stated about this being a separate
> section of the NRPM,  Almost all of the discussion I find is in a context of
> 8.3 transfers, there was one mention of including IPv6, but it didn't get
> much traction that I see.  Further, there was a fairly long thread in May
> with the subject "Integrating Draft Policy ARIN-2011-1 into NRPM 8.3" and
> back at San Juan Bill's slides had much the same context.
>
> https://www.arin.net/**participate/meetings/reports/**
> ARIN_XXVII/PDF/Monday/darte_**prop2011_1.pdf<https://www.arin.net/participate/meetings/reports/ARIN_XXVII/PDF/Monday/darte_prop2011_1.pdf>
>
> The idea that this would not be integrated into 8.3 in one way or another
> is not supported by what I could find in the discussion anywhere.
>
> I'll admit, we are making non-trivial changes to the text, we said that,
> that is why we did an Extended Last-Call.  But I believe it is what the
> community was asking us to do.
>
> Finally, if the consensus of the community in last-call is to take it back
> to another PPM, I'm fine with that too.  However, that is not the sense of
> the room I took out of Philly.
>
> I would really appreciate a clear consensus from the community on this one.
>  What do you want us to do?  Please comment, even if it is simply you
> support or not the text as written.
>
> 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<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/20111019/95c5969e/attachment.htm>

From jcurran at arin.net  Wed Oct 19 21:40:38 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 20 Oct 2011 01:40:38 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGXxK5vzvYa+WmN9go-gW1-2tep_m=MAY1+3GsFXHVm=Cw@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<CAP-guGX-+7gnMMo2G4=1jOBsfSdppTcQRPnExQLRwQvFcfq_2Q@mail.gmail.com>
	<4E9F3E51.8030102@umn.edu>
	<CBD7ACA3-912A-4614-A6F5-B07864E3A53A@arin.net>
	<4E9F47CF.9030900@umn.edu>
	<CAP-guGURW6QrKPUC3qxLQz40JiBtJRfL71ZJpw_+xjeKQZOCMA@mail.gmail.com>
	<4E9F5285.5070106@umn.edu>
	<CAP-guGXY17Uut=JQbqJSE_uKFfPQ+c=m_ECSZ97tZjiX6x+Rtg@mail.gmail.com>
	<A5A8E58E-AE31-4E74-8A77-5AE20EAEABDF@arin.net>
	<CAP-guGUcwjwLf-gmQZL4i8BC89W9Ofp_9eHJLckbSd00Fi2uDA@mail.gmail.com>
	<7CBCE3B6-E091-460D-A928-8DF6E3C782AB@arin.net>
	<CAP-guGXxK5vzvYa+WmN9go-gW1-2tep_m=MAY1+3GsFXHVm=Cw@mail.gmail.com>
Message-ID: <5A0F9029-FEBB-4565-92BD-0FEA55113946@arin.net>

On Oct 19, 2011, at 9:11 PM, William Herrin wrote:

> On Wed, Oct 19, 2011 at 8:47 PM, John Curran <jcurran at arin.net> wrote:
>> 
>> The changes that occur to a draft policy text after presentation
>> at the public policy meeting can be quite extensive and include
>> any action including rewriting, merging, or abandoning. I believe
>> that you are seeing the result of a "rewrite" of the draft policy,
>> and this is noted as specifically allowed by the PDP for policies
>> after PPM, with the protection being that any change results in
>> another last call to the community.
> 
> Is this John Curran's opinion or is this the President of ARIN's
> ruling on the process question as it relates to draft 2011-1?

It is the President's ruling on your process question.

>> Note also that you do have the option to petition for the original
>> policy text to be sent to last call, if you do not like the action
>> taken by the ARIN AC on the draft policy.
> 
> The original text has all of the faults that have been attributed to
> it in this thread. It was not expressed in clear, actionable policy
> language and was indubitably in need of editing. The last thing I want
> to do is petition for that text to be sent to last call.

If that is the case, then I would suggest that you provide 
suggested changes that would improve the draft policy text. 

Thanks!
/John

John Curran
President and CEO
ARIN



From hannigan at gmail.com  Wed Oct 19 22:32:40 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 19 Oct 2011 22:32:40 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
Message-ID: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>

On Wed, Oct 19, 2011 at 9:40 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 19, 2011, at 9:11 PM, William Herrin wrote:
>
>> On Wed, Oct 19, 2011 at 8:47 PM, John Curran <jcurran at arin.net> wrote:
>>>
>>> The changes that occur to a draft policy text after presentation
>>> at the public policy meeting can be quite extensive and include
>>> any action including rewriting, merging, or abandoning. I believe
>>> that you are seeing the result of a "rewrite" of the draft policy,
>>> and this is noted as specifically allowed by the PDP for policies
>>> after PPM, with the protection being that any change results in
>>> another last call to the community.
>>
>> Is this John Curran's opinion or is this the President of ARIN's
>> ruling on the process question as it relates to draft 2011-1?
>
> It is the President's ruling on your process question.
>
>>> Note also that you do have the option to petition for the original
>>> policy text to be sent to last call, if you do not like the action
>>> taken by the ARIN AC on the draft policy.
>>
>> The original text has all of the faults that have been attributed to
>> it in this thread. It was not expressed in clear, actionable policy
>> language and was indubitably in need of editing. The last thing I want
>> to do is petition for that text to be sent to last call.
>
> If that is the case, then I would suggest that you provide
> suggested changes that would improve the draft policy text.
>


Bill,

I agree with you, the process has failed at least from an integrity
perspective.  The last call text presented in this thread should not
be allowed to propagate under the cover of community blessing. What
was presented in Philadelphia was this:

      https://www.arin.net/participate/meetings/reports/ARIN_XXVIII/PDF/thursday/darte_2011_1.pdf

Slide 8 is the basis that is being used to claim that the community
has empowered the AC. The last call text was neither publicly
presented or polled in the public policy meeting. A completely
different and unrelated question was asked that had very narrow
consensus. There is no mandate to proceed as some have claimed.

The last call text presented in this thread was primarily written
during the AC meeting. Even if it isn't formally in violation of the
PDP, it's poorly thought out, ill defined shotgun policy that didn't
need to be written and rushed through in the manner that is has been.
No-one on the AC is able to clearly articulate why this was necessary.
Including myself. The AC meeting minutes will paint an even  messier
picture supporting my contention.

A successful petition would continue to emphasize that we expect that
ARIN will implement critical, business impacting policy in an open,
transparent and fair way. I would certainly consider supporting one.

I certainly appreciate the hard work of my colleagues.

Best,

-M<


From kevinb at thewire.ca  Wed Oct 19 22:54:07 2011
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Thu, 20 Oct 2011 02:54:07 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4E9F20FF.1070203@arin.net>
References: <4E9F20FF.1070203@arin.net>
Message-ID: <7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>

I will endeavor to be helpful but I also share the concern about the significant changes in the draft policy from the meeting and what was brought to last call.

I see that "entities agreeing to the transfer and which otherwise meet both RIR's policies." was removed, which I considered to be a bi-lateral justification. That shifted the onus to "share compatible, needs based policies". If that is the case I don't believe that "compatible" is strong enough and in my mind is way to ambiguous. It also removes any of the other provisions of the NRPM which might be required if abuse of the policy is found.  

Kevin Blumberg
T 416.214.9473 x31
F 416.862.9473
kevinb at thewire.ca






> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of ARIN
> Sent: Wednesday, October 19, 2011 3:12 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
> 
> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to send
> an amended version of the following draft policy to an extended last call:
> 
>    ARIN-2011-1: ARIN Inter-RIR Transfers
> 
> The AC provided the following statement:
> 
> ********
> The Advisory Council reviewed the results of feedback from the ARIN XXVIII
> Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR Transfers.
> While there were concerns regarding the presented wording, there was
> significant continued support for a policy enabling Inter-Regional transfers of
> IPv4 number resources from organizations able to make them available to
> any organization with valid requirements.
> 
> In addition to cumbersome wording, the presented text could not be cleanly
> inserted into the NRPM.  The following is new language that directly modifies
> section 8.3 "Transfers to Specified Recipients" to allow such transfers to or
> from organizations in other regions.
> 
> The first paragraph is a modified version of the current 8.3 policy language,
> envisioning resources being released to ARIN by the authorized resources
> holder or additionally by another RIR to be transferred to a specified
> recipient.  The second sentence was reorganized to emphasize that it applies
> to an organization within the ARIN region that will receive such a specified
> transfer, and to eliminate the single aggregate language per 2011-10 which is
> also being sent to last call.
> 
> The new second paragraph adds language enabling transfers to a specified
> recipient in another RIR's service region.  This language specifies that such
> recipients justify their need to their RIR, following that RIR's policies.  ARIN
> will verify that there is a compatible needs based policy that the other RIR will
> use to evaluate the need of the recipient and that both RIR's agree to the
> transfer. Implicit in the intent of the language presented and in conformance
> with statements made, the size of the block to be transferred is identified as
> /24 or larger, for obvious practical reasons.
> 
> In accordance with concern for immediate adoption, the AC chose to forward
> this version to last call.  Concerns expressed by some stakeholders for
> further controls were noted by the AC, and are being considered for future
> policy modification, assuaged in part by ARIN staff assurances that if any
> significant abuse of this policy were to occur, then the policy could easily be
> suspended.
> 
> The AC thanks everyone in the community for their help in crafting this
> important policy and for your statements of support or other comments
> during Last Call.
> ********
> 
> Feedback is encouraged during the last call period. All comments should be
> provided to the Public Policy Mailing List. Last call for 2011-1 will expire on 16
> November 2011. After last call the AC will conduct their last call review.
> 
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
> 
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Draft Policy ARIN-2011-1
> ARIN Inter-RIR Transfers
> 
> Date/version: 14 October 2011
> 
> Policy statement:
> 
> 8.3 Transfers to Specified Recipients
> 
> In addition to transfers under section 8.2, IPv4 number resources may be
> released to ARIN by the authorized resource holder or another RIR, in whole
> or in part, for transfer to another specified organizational recipient.
> Organizations in the ARIN region may receive transferred number resources
> under RSA if they can demonstrate the need for such resources in the
> amount which they can justify under current ARIN policies.
> 
> IPv4 address resources may be transferred to organizations in another RIR's
> service region if they demonstrate need to their region's RIR, according to
> that RIR's policies. Inter-regional transfers may take place only via RIRs who
> agree to the transfer and share compatible, needs-based policies. Such
> resources must be transferred in blocks of
> /24 or larger and will become part of the resource holdings of the recipient
> RIR.
> 
> 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 BillD at cait.wustl.edu  Wed Oct 19 22:56:00 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Wed, 19 Oct 2011 21:56:00 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
	Transfers - Last Call
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>

Marty,

The text that was presented at the meeting was flawed seriously and acknowledge to be so.  Many of those speaking at the microphones agreed that the text was flawed but expressed support for an Inter-regional transfer policy.

I believe that slide 8 was the basis for the first polling question after the DP was presented and had overwhelming consensus.
The re-written version of the DP which was crafted in the AC meeting expresses the will of the community (I believe) and incorporates all of the same elements that were itemized as the intent of the flawed text on Slide 6 of the same set of slides you reference below.  I would be interested to hear how you believe the current text deviates substantially from those objectives.

The mandate of the community was for the AC to proceed to make good policy in this area (I believe) and the AC has a duty to do so.  I believe that the current text is faithful to both.  

But, I respect your hard work and interpretation, and like you I'm sure...hope that the rest of community will weigh in during this last call period to express their opinion...having heard yours and mine...and tell us whether what the AC has crafted is worthy of being sent to the BoT for acceptance.

Bill Darte
2011-1 DP Shepherd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Martin Hannigan
Sent: Wed 10/19/2011 9:32 PM
To: William Herrin; arin-ppml at arin.net
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
 
On Wed, Oct 19, 2011 at 9:40 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 19, 2011, at 9:11 PM, William Herrin wrote:
>
>> On Wed, Oct 19, 2011 at 8:47 PM, John Curran <jcurran at arin.net> wrote:
>>>
>>> The changes that occur to a draft policy text after presentation
>>> at the public policy meeting can be quite extensive and include
>>> any action including rewriting, merging, or abandoning. I believe
>>> that you are seeing the result of a "rewrite" of the draft policy,
>>> and this is noted as specifically allowed by the PDP for policies
>>> after PPM, with the protection being that any change results in
>>> another last call to the community.
>>
>> Is this John Curran's opinion or is this the President of ARIN's
>> ruling on the process question as it relates to draft 2011-1?
>
> It is the President's ruling on your process question.
>
>>> Note also that you do have the option to petition for the original
>>> policy text to be sent to last call, if you do not like the action
>>> taken by the ARIN AC on the draft policy.
>>
>> The original text has all of the faults that have been attributed to
>> it in this thread. It was not expressed in clear, actionable policy
>> language and was indubitably in need of editing. The last thing I want
>> to do is petition for that text to be sent to last call.
>
> If that is the case, then I would suggest that you provide
> suggested changes that would improve the draft policy text.
>


Bill,

I agree with you, the process has failed at least from an integrity
perspective.  The last call text presented in this thread should not
be allowed to propagate under the cover of community blessing. What
was presented in Philadelphia was this:

      https://www.arin.net/participate/meetings/reports/ARIN_XXVIII/PDF/thursday/darte_2011_1.pdf

Slide 8 is the basis that is being used to claim that the community
has empowered the AC. The last call text was neither publicly
presented or polled in the public policy meeting. A completely
different and unrelated question was asked that had very narrow
consensus. There is no mandate to proceed as some have claimed.

The last call text presented in this thread was primarily written
during the AC meeting. Even if it isn't formally in violation of the
PDP, it's poorly thought out, ill defined shotgun policy that didn't
need to be written and rushed through in the manner that is has been.
No-one on the AC is able to clearly articulate why this was necessary.
Including myself. The AC meeting minutes will paint an even  messier
picture supporting my contention.

A successful petition would continue to emphasize that we expect that
ARIN will implement critical, business impacting policy in an open,
transparent and fair way. I would certainly consider supporting one.

I certainly appreciate the hard work of my colleagues.

Best,

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

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

From owen at delong.com  Thu Oct 20 01:40:47 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 20 Oct 2011 07:40:47 +0200
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>
References: <4E9F20FF.1070203@arin.net>
	<7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>
Message-ID: <64674FA3-C68C-43EF-8E3A-78E46481904A@delong.com>

I'll note that the current text doesn't actually remove that intent. It does move it around a little bit. The current text expresses (or at least was intended to) clearly that the recipient of an inter-RIR transfer must meet the recipient RIR's policies for recipients and the donor must meet the donor RIR's policies for donors.

The combination of share compatible needs-based policies and the requirement that both RIRs agree are intended as additional safety valves against unilateral policy changes by other RIRs giving ARIN staff discretion to take the appropriate action in the event circumstances change faster than policy can.

The original language quoted below ("entities agreeing...meet both RIR's policies") was vague and virtually impossible to implement. By clarifying that the intent is for the recipient to meet the receiving RIR's policies for recipients and the donor to meet the source RIR's policies for donors, I believe this makes the resulting text both quite a bit easier to understand and much better to implement.

Owen


Sent from my iPad

On Oct 20, 2011, at 4:54 AM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> I will endeavor to be helpful but I also share the concern about the significant changes in the draft policy from the meeting and what was brought to last call.
> 
> I see that "entities agreeing to the transfer and which otherwise meet both RIR's policies." was removed, which I considered to be a bi-lateral justification. That shifted the onus to "share compatible, needs based policies". If that is the case I don't believe that "compatible" is strong enough and in my mind is way to ambiguous. It also removes any of the other provisions of the NRPM which might be required if abuse of the policy is found.  
> 
> Kevin Blumberg
> T 416.214.9473 x31
> F 416.862.9473
> kevinb at thewire.ca
> 
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of ARIN
>> Sent: Wednesday, October 19, 2011 3:12 PM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
>> 
>> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to send
>> an amended version of the following draft policy to an extended last call:
>> 
>>   ARIN-2011-1: ARIN Inter-RIR Transfers
>> 
>> The AC provided the following statement:
>> 
>> ********
>> The Advisory Council reviewed the results of feedback from the ARIN XXVIII
>> Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR Transfers.
>> While there were concerns regarding the presented wording, there was
>> significant continued support for a policy enabling Inter-Regional transfers of
>> IPv4 number resources from organizations able to make them available to
>> any organization with valid requirements.
>> 
>> In addition to cumbersome wording, the presented text could not be cleanly
>> inserted into the NRPM.  The following is new language that directly modifies
>> section 8.3 "Transfers to Specified Recipients" to allow such transfers to or
>> from organizations in other regions.
>> 
>> The first paragraph is a modified version of the current 8.3 policy language,
>> envisioning resources being released to ARIN by the authorized resources
>> holder or additionally by another RIR to be transferred to a specified
>> recipient.  The second sentence was reorganized to emphasize that it applies
>> to an organization within the ARIN region that will receive such a specified
>> transfer, and to eliminate the single aggregate language per 2011-10 which is
>> also being sent to last call.
>> 
>> The new second paragraph adds language enabling transfers to a specified
>> recipient in another RIR's service region.  This language specifies that such
>> recipients justify their need to their RIR, following that RIR's policies.  ARIN
>> will verify that there is a compatible needs based policy that the other RIR will
>> use to evaluate the need of the recipient and that both RIR's agree to the
>> transfer. Implicit in the intent of the language presented and in conformance
>> with statements made, the size of the block to be transferred is identified as
>> /24 or larger, for obvious practical reasons.
>> 
>> In accordance with concern for immediate adoption, the AC chose to forward
>> this version to last call.  Concerns expressed by some stakeholders for
>> further controls were noted by the AC, and are being considered for future
>> policy modification, assuaged in part by ARIN staff assurances that if any
>> significant abuse of this policy were to occur, then the policy could easily be
>> suspended.
>> 
>> The AC thanks everyone in the community for their help in crafting this
>> important policy and for your statements of support or other comments
>> during Last Call.
>> ********
>> 
>> Feedback is encouraged during the last call period. All comments should be
>> provided to the Public Policy Mailing List. Last call for 2011-1 will expire on 16
>> November 2011. After last call the AC will conduct their last call review.
>> 
>> The draft policy text is below and available at:
>> https://www.arin.net/policy/proposals/
>> 
>> The ARIN Policy Development Process is available at:
>> https://www.arin.net/policy/pdp.html
>> 
>> Regards,
>> 
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> ## * ##
>> 
>> 
>> Draft Policy ARIN-2011-1
>> ARIN Inter-RIR Transfers
>> 
>> Date/version: 14 October 2011
>> 
>> Policy statement:
>> 
>> 8.3 Transfers to Specified Recipients
>> 
>> In addition to transfers under section 8.2, IPv4 number resources may be
>> released to ARIN by the authorized resource holder or another RIR, in whole
>> or in part, for transfer to another specified organizational recipient.
>> Organizations in the ARIN region may receive transferred number resources
>> under RSA if they can demonstrate the need for such resources in the
>> amount which they can justify under current ARIN policies.
>> 
>> IPv4 address resources may be transferred to organizations in another RIR's
>> service region if they demonstrate need to their region's RIR, according to
>> that RIR's policies. Inter-regional transfers may take place only via RIRs who
>> agree to the transfer and share compatible, needs-based policies. Such
>> resources must be transferred in blocks of
>> /24 or larger and will become part of the resource holdings of the recipient
>> RIR.
>> 
>> Timetable for implementation: immediate
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From owen at delong.com  Thu Oct 20 01:44:05 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 20 Oct 2011 07:44:05 +0200
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
	Transfers - Last Call
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
Message-ID: <C9111B4A-87B0-4D22-854D-966C4B2B92A8@delong.com>

I agree with Bill below. This was discussed at length at the PPM and deliberated at great length by the AC afterwards. The resulting text is, IMHO, the best effort possible to move forward according to the (relatively) clear will of the community. I will note that the room was polled with respect to whether we should make the necessary corrections to the draft policy and send it to last call or send it back around for another meeting, there was strong (though not overwhelming) support from the community for moving forward to last call.

Owen


Sent from my iPad

On Oct 20, 2011, at 4:56 AM, "Bill Darte" <BillD at cait.wustl.edu> wrote:

> Marty,
> 
> The text that was presented at the meeting was flawed seriously and acknowledge to be so.  Many of those speaking at the microphones agreed that the text was flawed but expressed support for an Inter-regional transfer policy.
> 
> I believe that slide 8 was the basis for the first polling question after the DP was presented and had overwhelming consensus.
> The re-written version of the DP which was crafted in the AC meeting expresses the will of the community (I believe) and incorporates all of the same elements that were itemized as the intent of the flawed text on Slide 6 of the same set of slides you reference below.  I would be interested to hear how you believe the current text deviates substantially from those objectives.
> 
> The mandate of the community was for the AC to proceed to make good policy in this area (I believe) and the AC has a duty to do so.  I believe that the current text is faithful to both. 
> 
> But, I respect your hard work and interpretation, and like you I'm sure...hope that the rest of community will weigh in during this last call period to express their opinion...having heard yours and mine...and tell us whether what the AC has crafted is worthy of being sent to the BoT for acceptance.
> 
> Bill Darte
> 2011-1 DP Shepherd
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of Martin Hannigan
> Sent: Wed 10/19/2011 9:32 PM
> To: William Herrin; arin-ppml at arin.net
> Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
> 
> On Wed, Oct 19, 2011 at 9:40 PM, John Curran <jcurran at arin.net> wrote:
> > On Oct 19, 2011, at 9:11 PM, William Herrin wrote:
> >
> >> On Wed, Oct 19, 2011 at 8:47 PM, John Curran <jcurran at arin.net> wrote:
> >>>
> >>> The changes that occur to a draft policy text after presentation
> >>> at the public policy meeting can be quite extensive and include
> >>> any action including rewriting, merging, or abandoning. I believe
> >>> that you are seeing the result of a "rewrite" of the draft policy,
> >>> and this is noted as specifically allowed by the PDP for policies
> >>> after PPM, with the protection being that any change results in
> >>> another last call to the community.
> >>
> >> Is this John Curran's opinion or is this the President of ARIN's
> >> ruling on the process question as it relates to draft 2011-1?
> >
> > It is the President's ruling on your process question.
> >
> >>> Note also that you do have the option to petition for the original
> >>> policy text to be sent to last call, if you do not like the action
> >>> taken by the ARIN AC on the draft policy.
> >>
> >> The original text has all of the faults that have been attributed to
> >> it in this thread. It was not expressed in clear, actionable policy
> >> language and was indubitably in need of editing. The last thing I want
> >> to do is petition for that text to be sent to last call.
> >
> > If that is the case, then I would suggest that you provide
> > suggested changes that would improve the draft policy text.
> >
> 
> 
> Bill,
> 
> I agree with you, the process has failed at least from an integrity
> perspective.  The last call text presented in this thread should not
> be allowed to propagate under the cover of community blessing. What
> was presented in Philadelphia was this:
> 
>       https://www.arin.net/participate/meetings/reports/ARIN_XXVIII/PDF/thursday/darte_2011_1.pdf
> 
> Slide 8 is the basis that is being used to claim that the community
> has empowered the AC. The last call text was neither publicly
> presented or polled in the public policy meeting. A completely
> different and unrelated question was asked that had very narrow
> consensus. There is no mandate to proceed as some have claimed.
> 
> The last call text presented in this thread was primarily written
> during the AC meeting. Even if it isn't formally in violation of the
> PDP, it's poorly thought out, ill defined shotgun policy that didn't
> need to be written and rushed through in the manner that is has been.
> No-one on the AC is able to clearly articulate why this was necessary.
> Including myself. The AC meeting minutes will paint an even  messier
> picture supporting my contention.
> 
> A successful petition would continue to emphasize that we expect that
> ARIN will implement critical, business impacting policy in an open,
> transparent and fair way. I would certainly consider supporting one.
> 
> I certainly appreciate the hard work of my colleagues.
> 
> Best,
> 
> -M<
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 
> _______________________________________________
> 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/20111020/89ed6bc6/attachment.htm>

From jcurran at arin.net  Thu Oct 20 07:59:45 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 20 Oct 2011 11:59:45 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
Message-ID: <EAE2CBD6-F1A2-4E86-82A7-C74B9D6C86C0@arin.net>

On Oct 19, 2011, at 10:32 PM, Martin Hannigan wrote:
> 
> Bill,
> 
> I agree with you, the process has failed at least from an integrity
> perspective.  The last call text presented in this thread should not
> be allowed to propagate under the cover of community blessing.

Marty - 

  The ARIN AC is fully empowered to develop policy text on 
  behalf of the community based on its best understanding. 
 
  The Policy Development Process specifies that the ARIN AC
  determines whether a draft policy has the support of the 
  community.  There is a requirement to present the draft
  policy text at the Public Policy meeting, but no requirement 
  for a vote to be taken on specific text. Any discussion 
  and/or votes taken at the at the meeting done are for the 
  consideration of the Advisory Council in doing its policy 
  development work.
  
  If the text has been changed from what is presented at the 
  Public Policy Meeting, then it _must_ be sent for last call 
  to obtain community feedback on the revised proposed text. 
  That is the integrity check in the process, and the community
  has an important obligation to provide feedback during last 
  call regarding any and all aspects of the draft policy that 
  they feel needs to be changed.  If the community doesn't 
  provide any feedback on necessary changes during last call, 
  then that definitely qualifies as validation of community
  support.  If there is a change to the policy text as a result 
  of the last call feedback, the policy may go to another last 
  call or be put back on docket for further development.

  Ultimately, the Board of Trustees will be the judge of the 
  process by which the policy was developed, if the policy is 
  recommended for adopted.  At this time, Draft policy 2011-1's
  development is fully in keeping the Policy Development Process,
  and what is lacking is last call feedback to the AC regarding 
  any aspects of the revised policy text that needs to be changed.

Thanks!
/John

John Curran
President and CEO
ARIN



From cja at daydream.com  Thu Oct 20 08:52:26 2011
From: cja at daydream.com (CJ Aronson)
Date: Thu, 20 Oct 2011 06:52:26 -0600
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>
References: <4E9F20FF.1070203@arin.net>
	<7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>
Message-ID: <CAMvf=7ZwxeFZPH2MafNiTJViNkbUkUdFV0n8h+3_-4U7QMaFFw@mail.gmail.com>

Kevin,

We changed that text in response to staff comments about how the previous
text was too ambiguous.  John Curran told us in the meeting that these
changes made it clearer to ARIN staff.  We're open to suggestions though.
 Can you suggest some text you feel would be clearer?

Thanks!
----Cathy

On Wed, Oct 19, 2011 at 8:54 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:

> I will endeavor to be helpful but I also share the concern about the
> significant changes in the draft policy from the meeting and what was
> brought to last call.
>
> I see that "entities agreeing to the transfer and which otherwise meet both
> RIR's policies." was removed, which I considered to be a bi-lateral
> justification. That shifted the onus to "share compatible, needs based
> policies". If that is the case I don't believe that "compatible" is strong
> enough and in my mind is way to ambiguous. It also removes any of the other
> provisions of the NRPM which might be required if abuse of the policy is
> found.
>
> Kevin Blumberg
> T 416.214.9473 x31
> F 416.862.9473
> kevinb at thewire.ca
>
>
>
>
>
>
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> > Behalf Of ARIN
> > Sent: Wednesday, October 19, 2011 3:12 PM
> > To: arin-ppml at arin.net
> > Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
> >
> > The ARIN Advisory Council (AC) met on 14 October 2011 and decided to send
> > an amended version of the following draft policy to an extended last
> call:
> >
> >    ARIN-2011-1: ARIN Inter-RIR Transfers
> >
> > The AC provided the following statement:
> >
> > ********
> > The Advisory Council reviewed the results of feedback from the ARIN
> XXVIII
> > Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR Transfers.
> > While there were concerns regarding the presented wording, there was
> > significant continued support for a policy enabling Inter-Regional
> transfers of
> > IPv4 number resources from organizations able to make them available to
> > any organization with valid requirements.
> >
> > In addition to cumbersome wording, the presented text could not be
> cleanly
> > inserted into the NRPM.  The following is new language that directly
> modifies
> > section 8.3 "Transfers to Specified Recipients" to allow such transfers
> to or
> > from organizations in other regions.
> >
> > The first paragraph is a modified version of the current 8.3 policy
> language,
> > envisioning resources being released to ARIN by the authorized resources
> > holder or additionally by another RIR to be transferred to a specified
> > recipient.  The second sentence was reorganized to emphasize that it
> applies
> > to an organization within the ARIN region that will receive such a
> specified
> > transfer, and to eliminate the single aggregate language per 2011-10
> which is
> > also being sent to last call.
> >
> > The new second paragraph adds language enabling transfers to a specified
> > recipient in another RIR's service region.  This language specifies that
> such
> > recipients justify their need to their RIR, following that RIR's
> policies.  ARIN
> > will verify that there is a compatible needs based policy that the other
> RIR will
> > use to evaluate the need of the recipient and that both RIR's agree to
> the
> > transfer. Implicit in the intent of the language presented and in
> conformance
> > with statements made, the size of the block to be transferred is
> identified as
> > /24 or larger, for obvious practical reasons.
> >
> > In accordance with concern for immediate adoption, the AC chose to
> forward
> > this version to last call.  Concerns expressed by some stakeholders for
> > further controls were noted by the AC, and are being considered for
> future
> > policy modification, assuaged in part by ARIN staff assurances that if
> any
> > significant abuse of this policy were to occur, then the policy could
> easily be
> > suspended.
> >
> > The AC thanks everyone in the community for their help in crafting this
> > important policy and for your statements of support or other comments
> > during Last Call.
> > ********
> >
> > Feedback is encouraged during the last call period. All comments should
> be
> > provided to the Public Policy Mailing List. Last call for 2011-1 will
> expire on 16
> > November 2011. After last call the AC will conduct their last call
> review.
> >
> > The draft policy text is below and available at:
> > https://www.arin.net/policy/proposals/
> >
> > The ARIN Policy Development Process is available at:
> > https://www.arin.net/policy/pdp.html
> >
> > Regards,
> >
> > Communications and Member Services
> > American Registry for Internet Numbers (ARIN)
> >
> >
> > ## * ##
> >
> >
> > Draft Policy ARIN-2011-1
> > ARIN Inter-RIR Transfers
> >
> > Date/version: 14 October 2011
> >
> > Policy statement:
> >
> > 8.3 Transfers to Specified Recipients
> >
> > In addition to transfers under section 8.2, IPv4 number resources may be
> > released to ARIN by the authorized resource holder or another RIR, in
> whole
> > or in part, for transfer to another specified organizational recipient.
> > Organizations in the ARIN region may receive transferred number resources
> > under RSA if they can demonstrate the need for such resources in the
> > amount which they can justify under current ARIN policies.
> >
> > IPv4 address resources may be transferred to organizations in another
> RIR's
> > service region if they demonstrate need to their region's RIR, according
> to
> > that RIR's policies. Inter-regional transfers may take place only via
> RIRs who
> > agree to the transfer and share compatible, needs-based policies. Such
> > resources must be transferred in blocks of
> > /24 or larger and will become part of the resource holdings of the
> recipient
> > RIR.
> >
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111020/9daa39e4/attachment.htm>

From john.sweeting at twcable.com  Thu Oct 20 09:43:54 2011
From: john.sweeting at twcable.com (Sweeting, John)
Date: Thu, 20 Oct 2011 09:43:54 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAMDXq5PL2wzNmDP5Y0zoL5QQ=JdnyvedbyP9+ufwnHeun7m8XA@mail.gmail.com>
Message-ID: <CAC59D17.B7C6%john.sweeting@twcable.com>

Good morning Marty,

Just wanted to point out that no single AC member has the right to speak for "us all" especially without discussing it openly with each of us. I am working with the shepherds in order to post a detailed explanation of the changes between the Text presented at the Philadelphia PPM and the current text in last call.

Thanks,
John

+++

From: Martin Hannigan <hannigan at gmail.com<mailto:hannigan at gmail.com>>
Date: Wed, 19 Oct 2011 20:03:53 -0400
To: John Curran <jcurran at arin.net<mailto:jcurran at arin.net>>
Cc: "arin-ppml at arin.net<mailto:arin-ppml at arin.net>" <arin-ppml at arin.net<mailto:arin-ppml at arin.net>>
Subject: Re: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call


I do. And you've excercised that standing. I don't mind if you represent us all now and answer all of Bills questions with straight answers.

Best,

Marty

On Oct 19, 2011 7:58 PM, "John Curran" <jcurran at arin.net<mailto:jcurran at arin.net>> wrote:
On Oct 19, 2011, at 7:51 PM, Martin Hannigan wrote:

John,

I believe that the CEO is an ex officious member of the AC. I wouldn't mind if you explained the changes for us.

Marty -

   You probably mean: "The President of ARIN is a non-voting ex officio member of the Advisory Council."

   However, I'm not understanding the question:  What changes do you want me to explain?

Thanks,
/John

John Curran
President and CEO
ARIN



________________________________
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 randy.whitney at verizon.com  Thu Oct 20 09:57:54 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Thu, 20 Oct 2011 09:57:54 -0400
Subject: [arin-ppml] ARIN-2011-8: Combined M&A and Specified Transfers -
 Last Call
In-Reply-To: <4E9F2112.4050102@arin.net>
References: <4E9F2112.4050102@arin.net>
Message-ID: <4EA028E2.3060605@verizon.com>

On 10/19/2011 3:12 PM, ARIN wrote:
> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
> send the following draft policy to last call:
>
>     ARIN-2011-8: Combined M&A and Specified Transfers
>
> ## * ##
>
>
> Draft Policy ARIN-2018
> Combined M&A and Specified Transfers
>
> Date/version: 26 July 2011
>
> Policy statement:
>
> To section 8.2 change "... 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)." to "...ARIN will work with the resource holder(s) to
> return, aggregate, transfer, or reclaim resources as needed to restore
> compliance via the processes outlined in current ARIN policy."
>


I support immediate adoption of this policy. The emphasis on restoring
compliance is an improvement over previous wording and better reflects
the intent.

Best Regards,
Randy.




From hannigan at gmail.com  Thu Oct 20 10:46:05 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 20 Oct 2011 10:46:05 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <EAE2CBD6-F1A2-4E86-82A7-C74B9D6C86C0@arin.net>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EAE2CBD6-F1A2-4E86-82A7-C74B9D6C86C0@arin.net>
Message-ID: <CAMDXq5Mc_mqp=gPw3+jpravd8dWs5MpQRoi5G9acy8_=TmOoQQ@mail.gmail.com>

On Thu, Oct 20, 2011 at 7:59 AM, John Curran <jcurran at arin.net> wrote:
> On Oct 19, 2011, at 10:32 PM, Martin Hannigan wrote:
>>
>> Bill,
>>
>> I agree with you, the process has failed at least from an integrity
>> perspective. ?The last call text presented in this thread should not
>> be allowed to propagate under the cover of community blessing.
>
> Marty -
>

[ snip Owen ]
[ snip John ]
[ snip CJ ]
[ snip Sweeting ]

ARIN has a history of circling the wagons after it is unable to
prevent public dissent. Generally, a "first strike" mentality exists
whenever the organizations credibility or integrity of it's process is
challenged. It's unfortunate that we spend so much time controlling
and so little time working on good policy that makes sense. Right now,
transition is failing as a result of ARIN over-controlling policy that
is related to v4 transfer.

Not much more I can say on the topic. I would like to again thank my
colleagues for their hard work.

Best,

-M<


From randy.whitney at verizon.com  Thu Oct 20 10:59:52 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Thu, 20 Oct 2011 10:59:52 -0400
Subject: [arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for
 post exhaustion IPv4 allocation mechanisms by the IANA - Last Call
In-Reply-To: <4E9F2127.9060809@arin.net>
References: <4E9F2127.9060809@arin.net>
Message-ID: <4EA03768.8090804@verizon.com>

On 10/19/2011 3:12 PM, ARIN wrote:
> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
> send the following draft policy to last call:
>
> Draft Policy ARIN-2011-9 (Global Proposal)
> Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
>
> Date: 22 September 2011
>
> Policy statement:
>
> The IANA shall establish a Recovered IPv4 Pool to be utilized post
> RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain
> any fragments that may be left over in the IANA. It will also hold
> any space returned to the IANA by any other means.
> The Recovered IPv4 Pool will be administered by the IANA. It will
> contain:

...

> The NRO must clarify that this Global Policy is not intended to
> supersede the IETF?s right to make IPv4 assignments for
> ?specialised address blocks (such as multicast or anycast
> blocks)? as documented in section 4.3 of RFC 2860. The
> NRO and IANA should coordinate with the IETF to make such
> assignments as necessary, and honor any reservations made
> for works currently in progress.

I'm not sure I understand this concern. Do we see this happening on
either side? Do we see IETF making "new" assignments outside of what has
been defined for many years (under the classfull system, IIRC)? Do we
see IANA trying to break into Class E space, for example, for new
allocations?

I support immediate adoption of this proposal, preferably without this
last statement. I don't really wish to delay the adoption of this policy
by trying to force a formal statement out of the NRO nor delay
subsequent RIR allocations under this policy by compelling IANA to
coordinate these allocation efforts with IETF, when no such cooperation
is required.

(To complete this thought: if in the future, IANA chooses to break into
IETF space for allocations, we as a community could always write new
policy to reject the reserved space as invalid.)

Best Regards,
Randy




From john.sweeting at twcable.com  Thu Oct 20 11:04:29 2011
From: john.sweeting at twcable.com (Sweeting, John)
Date: Thu, 20 Oct 2011 11:04:29 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAMDXq5Mc_mqp=gPw3+jpravd8dWs5MpQRoi5G9acy8_=TmOoQQ@mail.gmail.com>
Message-ID: <CAC5B092.B8D4%john.sweeting@twcable.com>

Hi Marty,

Just trying to keep the thread accurate - CJ and Sweeting never replied to
this thread.

Thanks,
John

++

On 10/20/11 10:46 AM, "Martin Hannigan" <hannigan at gmail.com> wrote:

>On Thu, Oct 20, 2011 at 7:59 AM, John Curran <jcurran at arin.net> wrote:
>> On Oct 19, 2011, at 10:32 PM, Martin Hannigan wrote:
>>>
>>> Bill,
>>>
>>> I agree with you, the process has failed at least from an integrity
>>> perspective.  The last call text presented in this thread should not
>>> be allowed to propagate under the cover of community blessing.
>>
>> Marty -
>>
>
>[ snip Owen ]
>[ snip John ]
>[ snip CJ ]
>[ snip Sweeting ]
>
>ARIN has a history of circling the wagons after it is unable to
>prevent public dissent. Generally, a "first strike" mentality exists
>whenever the organizations credibility or integrity of it's process is
>challenged. It's unfortunate that we spend so much time controlling
>and so little time working on good policy that makes sense. Right now,
>transition is failing as a result of ARIN over-controlling policy that
>is related to v4 transfer.
>
>Not much more I can say on the topic. I would like to again thank my
>colleagues for their hard work.
>
>Best,
>
>-M<
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.


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 randy.whitney at verizon.com  Thu Oct 20 11:08:09 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Thu, 20 Oct 2011 11:08:09 -0400
Subject: [arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for
 post exhaustion IPv4 allocation mechanisms by the IANA - Last Call
In-Reply-To: <4E9F2127.9060809@arin.net>
References: <4E9F2127.9060809@arin.net>
Message-ID: <4EA03959.8030408@verizon.com>

On 10/19/2011 3:12 PM, ARIN wrote:
> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
> send the following draft policy to last call:
>
>     ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4
> allocation mechanisms by the IANA
>

Update from other RIRs:

RIPE (today) has adopted the Global proposal, with the following stated
concern:

"This proposal does not provide details of how address space may be
returned to the IANA IPv4 Recovered Pool."

Best Regards,
Randy.



From bill at herrin.us  Thu Oct 20 11:08:23 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 20 Oct 2011 11:08:23 -0400
Subject: [arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for
 post exhaustion IPv4 allocation mechanisms by the IANA - Last Call
In-Reply-To: <4EA03768.8090804@verizon.com>
References: <4E9F2127.9060809@arin.net> <4EA03768.8090804@verizon.com>
Message-ID: <CAP-guGX9vsH0GOV5LnMRuZCto=vFX8BLPB14+ZW27ADAyr9b4w@mail.gmail.com>

On Thu, Oct 20, 2011 at 10:59 AM, Randy Whitney
<randy.whitney at verizon.com> wrote:
> On 10/19/2011 3:12 PM, ARIN wrote:
>> The NRO must clarify that this Global Policy is not intended to
>> supersede the IETF?s right to make IPv4 assignments for
>> ?specialised address blocks (such as multicast or anycast
>> blocks)? as documented in section 4.3 of RFC 2860. The
>> NRO and IANA should coordinate with the IETF to make such
>> assignments as necessary, and honor any reservations made
>> for works currently in progress.
>
> I'm not sure I understand this concern. Do we see this happening on
> either side? Do we see IETF making "new" assignments outside of what has
> been defined for many years (under the classfull system, IIRC)? Do we
> see IANA trying to break into Class E space, for example, for new
> allocations?

Hi Randy,

ARIN recently got beaten up about wanting to assign an address space
for a carrier NAT function vice assigning addresses to a particular
organization. Translate the paragraph to, "Nothing here should be
construed to usurp an addressing function that an IETF RFC doesn't
assign 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 jcurran at arin.net  Thu Oct 20 11:10:05 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 20 Oct 2011 15:10:05 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAMDXq5Mc_mqp=gPw3+jpravd8dWs5MpQRoi5G9acy8_=TmOoQQ@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EAE2CBD6-F1A2-4E86-82A7-C74B9D6C86C0@arin.net>
	<CAMDXq5Mc_mqp=gPw3+jpravd8dWs5MpQRoi5G9acy8_=TmOoQQ@mail.gmail.com>
Message-ID: <26D00014-7A4F-4CD3-9F03-BC898C5B632F@corp.arin.net>

On Oct 20, 2011, at 10:46 AM, Martin Hannigan wrote:

> ARIN has a history of circling the wagons after it is unable to
> prevent public dissent. Generally, a "first strike" mentality exists
> whenever the organizations credibility or integrity of it's process is
> challenged. 

Actually, public dissent is not only welcome, it's openly encouraged.  

If you indicate that ARIN isn't following its own procedures, it 
is indeed my job to look into and that respond.  When there is a 
legitimate issue, we correct it.  When there is an spurious claim, 
I note that (such as your claim of process failure w.r.t 2011-1)

Input is also welcome on the processes themselves, and in fact,
the PDP is conveniently up for public comment right now, as has
also been pointed out to you.

Finally, input is obviously welcome on the actual policy proposals, 
and I've asked you directly for your suggested changes to 2011-1, 
but have not seen any responses from you on how it can be improved.

> It's unfortunate that we spend so much time controlling
> and so little time working on good policy that makes sense. 

Let's work on good policy.   What changes to the revised 2011-1
do you think are needed?

Thanks!
/John

John Curran
President and CEO
ARIN






From jcurran at arin.net  Thu Oct 20 11:16:47 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 20 Oct 2011 15:16:47 +0000
Subject: [arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for
 post exhaustion IPv4 allocation mechanisms by the IANA - Last Call
In-Reply-To: <CAP-guGX9vsH0GOV5LnMRuZCto=vFX8BLPB14+ZW27ADAyr9b4w@mail.gmail.com>
References: <4E9F2127.9060809@arin.net> <4EA03768.8090804@verizon.com>
	<CAP-guGX9vsH0GOV5LnMRuZCto=vFX8BLPB14+ZW27ADAyr9b4w@mail.gmail.com>
Message-ID: <0D71BF8D-D329-46F5-8ED8-6191712DBC78@arin.net>

On Oct 20, 2011, at 11:08 AM, William Herrin wrote:
> 
> ARIN recently got beaten up about wanting to assign an address space
> for a carrier NAT function vice assigning addresses to a particular
> organization. Translate the paragraph to, "Nothing here should be
> construed to usurp an addressing function that an IETF RFC doesn't
> assign to the RIRs."

Bill's right on target.  The concern was that the policy could 
be (very indirectly) read as precluding the IANA from issuing 
any address space other than via mechanisms in the policy, which
would in effect prevent the IANA from doing any assignments that
the IETF might specify for technical purposes in an IETF RFC.  I 
believe that all parties now understand that this was not the 
intent of this global policy, and is a non-issue at this point.

FYI,
/John

John Curran
President and CEO
ARIN





From owen at delong.com  Thu Oct 20 11:26:08 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 20 Oct 2011 17:26:08 +0200
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
	Transfers - Last Call
In-Reply-To: <CAMDXq5Mc_mqp=gPw3+jpravd8dWs5MpQRoi5G9acy8_=TmOoQQ@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EAE2CBD6-F1A2-4E86-82A7-C74B9D6C86C0@arin.net>
	<CAMDXq5Mc_mqp=gPw3+jpravd8dWs5MpQRoi5G9acy8_=TmOoQQ@mail.gmail.com>
Message-ID: <E315A840-7AB6-4495-9E96-D39344914B57@delong.com>

Marty,

I don't think anyone is circling wagons or attempting to crush dissent.

I don't think we are trying to control anything.

I think everyone on the AC is attempting to make a good faith effort to do right by the community with a difficult situation.

I welcome Bill H's expression of his concerns about how we arrived at the current point. Though I don't agree with him, I think this kind of feedback for the community is important.

I think that, faced with the circumstances that existed and the input we received from the community, we did the best we could with the tools we have. I believe everyone has acted with integrity and within the defined PDP. I also think that your claim that the process has failed from an integrity perspective is baseless. So long as we can get (and incorporate) good feedback on the current text from the community in this last call, things are working as intended.

I honestly don't know whether this text should advance or go back to a PPM or get revised and go for another last call. I look forward to seeing how the community at large feels on the subject.

What I do know is that we went to the Philadelphia meeting with policy text that was poorly formulated, ambiguous at best, and would have required extensive creativity to integrate into the NRPM. Now we have much better text that seems to incorporate the feedback from the community both in the meeting and on the list before the meeting. It seems to have addressed the concerns raised by staff.

I do find it interesting that instead of discussing the policy and working to develop better text (if you object to the current text), you have chosen to focus on criticizing the manner in which the text was delivered while simultaneously criticizing the focus on such meta-issues vs. working on the actual development of policy.

Owen

Sent from my iPad

On Oct 20, 2011, at 4:46 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> On Thu, Oct 20, 2011 at 7:59 AM, John Curran <jcurran at arin.net> wrote:
>> On Oct 19, 2011, at 10:32 PM, Martin Hannigan wrote:
>>> 
>>> Bill,
>>> 
>>> I agree with you, the process has failed at least from an integrity
>>> perspective.  The last call text presented in this thread should not
>>> be allowed to propagate under the cover of community blessing.
>> 
>> Marty -
>> 
> 
> [ snip Owen ]
> [ snip John ]
> [ snip CJ ]
> [ snip Sweeting ]
> 
> ARIN has a history of circling the wagons after it is unable to
> prevent public dissent. Generally, a "first strike" mentality exists
> whenever the organizations credibility or integrity of it's process is
> challenged. It's unfortunate that we spend so much time controlling
> and so little time working on good policy that makes sense. Right now,
> transition is failing as a result of ARIN over-controlling policy that
> is related to v4 transfer.
> 
> Not much more I can say on the topic. I would like to again thank my
> colleagues for their hard work.
> 
> Best,
> 
> -M<
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From owen at delong.com  Thu Oct 20 11:38:41 2011
From: owen at delong.com (Owen DeLong)
Date: Thu, 20 Oct 2011 17:38:41 +0200
Subject: [arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for
	post exhaustion IPv4 allocation mechanisms by the IANA - Last Call
In-Reply-To: <4EA03768.8090804@verizon.com>
References: <4E9F2127.9060809@arin.net> <4EA03768.8090804@verizon.com>
Message-ID: <8A3824D4-6C94-4AB6-9753-E0E462DD3076@delong.com>



Sent from my iPad

On Oct 20, 2011, at 4:59 PM, Randy Whitney <randy.whitney at verizon.com> wrote:

> On 10/19/2011 3:12 PM, ARIN wrote:
>> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
>> send the following draft policy to last call:
>> 
>> Draft Policy ARIN-2011-9 (Global Proposal)
>> Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
>> 
>> Date: 22 September 2011
>> 
>> Policy statement:
>> 
>> The IANA shall establish a Recovered IPv4 Pool to be utilized post
>> RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain
>> any fragments that may be left over in the IANA. It will also hold
>> any space returned to the IANA by any other means.
>> The Recovered IPv4 Pool will be administered by the IANA. It will
>> contain:
> 
> ...
> 
>> The NRO must clarify that this Global Policy is not intended to
>> supersede the IETF?s right to make IPv4 assignments for
>> ?specialised address blocks (such as multicast or anycast
>> blocks)? as documented in section 4.3 of RFC 2860. The
>> NRO and IANA should coordinate with the IETF to make such
>> assignments as necessary, and honor any reservations made
>> for works currently in progress.
> 
> I'm not sure I understand this concern. Do we see this happening on
> either side? Do we see IETF making "new" assignments outside of what has
> been defined for many years (under the classfull system, IIRC)? Do we
> see IANA trying to break into Class E space, for example, for new
> allocations?
> 
Prior to recent changes to draft-Weil and draft-bdgks, there was a concern that this proposal and the effort to get a shared transition /10 made available could collide in a way where IANA process may not lead to the desired result.

> I support immediate adoption of this proposal, preferably without this
> last statement. I don't really wish to delay the adoption of this policy
> by trying to force a formal statement out of the NRO nor delay
> subsequent RIR allocations under this policy by compelling IANA to
> coordinate these allocation efforts with IETF, when no such cooperation
> is required.
> 

I think the need for the last statement is past and it is now moot. I don't think its presence or absence will affect the timing.

> (To complete this thought: if in the future, IANA chooses to break into
> IETF space for allocations, we as a community could always write new
> policy to reject the reserved space as invalid.)
> 

It was more intended to make sure that new special address space requested by draft-Weil did not get tied up and shunted into this policy.

Owen

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


From farmer at umn.edu  Thu Oct 20 12:15:39 2011
From: farmer at umn.edu (David Farmer)
Date: Thu, 20 Oct 2011 11:15:39 -0500
Subject: [arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for
 post exhaustion IPv4 allocation mechanisms by the IANA - Last Call
In-Reply-To: <4EA03768.8090804@verizon.com>
References: <4E9F2127.9060809@arin.net> <4EA03768.8090804@verizon.com>
Message-ID: <4EA0492B.40007@umn.edu>

Randy,

I found myself more or less repeating what Bill, John and Owen said 
already.  So, instead I will just say +1 to what they said and then ask 
you;

Does that clarify the issue for you?  And do you have any further 
concerns?

Thanks

On 10/20/11 09:59 CDT, Randy Whitney wrote:
> On 10/19/2011 3:12 PM, ARIN wrote:
>> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
>> send the following draft policy to last call:
>>
>> Draft Policy ARIN-2011-9 (Global Proposal)
>> Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA
>>
>> Date: 22 September 2011
>>
>> Policy statement:
>>
>> The IANA shall establish a Recovered IPv4 Pool to be utilized post
>> RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain
>> any fragments that may be left over in the IANA. It will also hold
>> any space returned to the IANA by any other means.
>> The Recovered IPv4 Pool will be administered by the IANA. It will
>> contain:
>
> ...
>
>> The NRO must clarify that this Global Policy is not intended to
>> supersede the IETF?s right to make IPv4 assignments for
>> ?specialised address blocks (such as multicast or anycast
>> blocks)? as documented in section 4.3 of RFC 2860. The
>> NRO and IANA should coordinate with the IETF to make such
>> assignments as necessary, and honor any reservations made
>> for works currently in progress.
>
> I'm not sure I understand this concern. Do we see this happening on
> either side? Do we see IETF making "new" assignments outside of what has
> been defined for many years (under the classfull system, IIRC)? Do we
> see IANA trying to break into Class E space, for example, for new
> allocations?
>
> I support immediate adoption of this proposal, preferably without this
> last statement. I don't really wish to delay the adoption of this policy
> by trying to force a formal statement out of the NRO nor delay
> subsequent RIR allocations under this policy by compelling IANA to
> coordinate these allocation efforts with IETF, when no such cooperation
> is required.
>
> (To complete this thought: if in the future, IANA chooses to break into
> IETF space for allocations, we as a community could always write new
> policy to reject the reserved space as invalid.)
>
> Best Regards,
> Randy
>
>
> _______________________________________________
> 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 randy.whitney at verizon.com  Thu Oct 20 12:43:28 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Thu, 20 Oct 2011 12:43:28 -0400
Subject: [arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for
 post exhaustion IPv4 allocation mechanisms by the IANA - Last Call
In-Reply-To: <4EA0492B.40007@umn.edu>
References: <4E9F2127.9060809@arin.net> <4EA03768.8090804@verizon.com>
	<4EA0492B.40007@umn.edu>
Message-ID: <4EA04FB0.2070707@verizon.com>

On 10/20/2011 12:15 PM, David Farmer wrote:
> Randy,
>
> I found myself more or less repeating what Bill, John and Owen said
> already.  So, instead I will just say +1 to what they said and then ask
> you;
>
> Does that clarify the issue for you?  And do you have any further
> concerns?
>

Thank you to all that responded providing background and clarification.
Although I'd still prefer to see the NRO statement removed, I still
support the policy either way and won't object further if it is not.

Best Regards,
Randy



From ppml at rs.seastrom.com  Thu Oct 20 13:56:08 2011
From: ppml at rs.seastrom.com (Robert Seastrom)
Date: Thu, 20 Oct 2011 13:56:08 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
	Transfers - Last Call
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
Message-ID: <F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>


Hi folks,

The proposal which is being sent to last call is a very close match with the slide deck that was presented at the public policy meeting.   Of course it had to be mashed around in order to "NRPM-ize" it (more on that later).  The salient changes are as follows:

* Demonstrated need is solely the determination of the recipient's RIR (subject to them having a needs-based policy in place) rather than having to qualify with both the recipient RIR and with ARIN.

* Delete "within 3 months" immediate need clause.

There was support for these changes at the Philly meeting and overwhelming support for the concept of inter-RIR transfers at both San Juan (41-1) and Philadelphia (53-1).  Nobody can credibly claim that the process is being short circuited here.

That's not to say that execution has been perfect on 2011-1.  We committed one big error which I hope we all learn from and don't repeat.  The lesson learned is that by the time the AC moves a policy proposal to draft policy (pp-xxx to 20xx-xx promotion) it had better be "NRPM-ized".  A proposal that does not countenance specific and well-defined changes to the NRPM is simply a wish, it is not a fully developed policy proposal.

That said, I think that what has come out of 2011-1 is both workable and fully in compliance with the PDP as I have always understood it.

By the way, part of the last call process is accepting feedback and input as well as offering clarification when needed. As the "other shepherd", everyone should feel free to reach out to me with any comments or further suggested changes.

-r (other shepherd on 2011-1).


On Oct 19, 2011, at 10:56 PM, Bill Darte wrote:

> Marty,
> 
> The text that was presented at the meeting was flawed seriously and acknowledge to be so.  Many of those speaking at the microphones agreed that the text was flawed but expressed support for an Inter-regional transfer policy.
> 
> I believe that slide 8 was the basis for the first polling question after the DP was presented and had overwhelming consensus.
> The re-written version of the DP which was crafted in the AC meeting expresses the will of the community (I believe) and incorporates all of the same elements that were itemized as the intent of the flawed text on Slide 6 of the same set of slides you reference below.  I would be interested to hear how you believe the current text deviates substantially from those objectives.
> 
> The mandate of the community was for the AC to proceed to make good policy in this area (I believe) and the AC has a duty to do so.  I believe that the current text is faithful to both. 
> 
> But, I respect your hard work and interpretation, and like you I'm sure...hope that the rest of community will weigh in during this last call period to express their opinion...having heard yours and mine...and tell us whether what the AC has crafted is worthy of being sent to the BoT for acceptance.
> 
> Bill Darte
> 2011-1 DP Shepherd
> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net on behalf of Martin Hannigan
> Sent: Wed 10/19/2011 9:32 PM
> To: William Herrin; arin-ppml at arin.net
> Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
> 
> On Wed, Oct 19, 2011 at 9:40 PM, John Curran <jcurran at arin.net> wrote:
> > On Oct 19, 2011, at 9:11 PM, William Herrin wrote:
> >
> >> On Wed, Oct 19, 2011 at 8:47 PM, John Curran <jcurran at arin.net> wrote:
> >>>
> >>> The changes that occur to a draft policy text after presentation
> >>> at the public policy meeting can be quite extensive and include
> >>> any action including rewriting, merging, or abandoning. I believe
> >>> that you are seeing the result of a "rewrite" of the draft policy,
> >>> and this is noted as specifically allowed by the PDP for policies
> >>> after PPM, with the protection being that any change results in
> >>> another last call to the community.
> >>
> >> Is this John Curran's opinion or is this the President of ARIN's
> >> ruling on the process question as it relates to draft 2011-1?
> >
> > It is the President's ruling on your process question.
> >
> >>> Note also that you do have the option to petition for the original
> >>> policy text to be sent to last call, if you do not like the action
> >>> taken by the ARIN AC on the draft policy.
> >>
> >> The original text has all of the faults that have been attributed to
> >> it in this thread. It was not expressed in clear, actionable policy
> >> language and was indubitably in need of editing. The last thing I want
> >> to do is petition for that text to be sent to last call.
> >
> > If that is the case, then I would suggest that you provide
> > suggested changes that would improve the draft policy text.
> >
> 
> 
> Bill,
> 
> I agree with you, the process has failed at least from an integrity
> perspective.  The last call text presented in this thread should not
> be allowed to propagate under the cover of community blessing. What
> was presented in Philadelphia was this:
> 
>       https://www.arin.net/participate/meetings/reports/ARIN_XXVIII/PDF/thursday/darte_2011_1.pdf
> 
> Slide 8 is the basis that is being used to claim that the community
> has empowered the AC. The last call text was neither publicly
> presented or polled in the public policy meeting. A completely
> different and unrelated question was asked that had very narrow
> consensus. There is no mandate to proceed as some have claimed.
> 
> The last call text presented in this thread was primarily written
> during the AC meeting. Even if it isn't formally in violation of the
> PDP, it's poorly thought out, ill defined shotgun policy that didn't
> need to be written and rushed through in the manner that is has been.
> No-one on the AC is able to clearly articulate why this was necessary.
> Including myself. The AC meeting minutes will paint an even  messier
> picture supporting my contention.
> 
> A successful petition would continue to emphasize that we expect that
> ARIN will implement critical, business impacting policy in an open,
> transparent and fair way. I would certainly consider supporting one.
> 
> I certainly appreciate the hard work of my colleagues.
> 
> Best,
> 
> -M<
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 
> _______________________________________________
> 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 Oct 20 14:37:30 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 20 Oct 2011 11:37:30 -0700
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
Message-ID: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>

On Thu, Oct 20, 2011 at 7:46 AM, Martin Hannigan <hannigan at gmail.com> wrote:

>
> It's unfortunate that we spend so much time controlling
> and so little time working on good policy that makes sense.


I would agree that time spent arguing about whether process was followed
doesn't get us toward better policy.

Do you have any more suggestions for how to improve 2011-1?  I know you've
made a number of suggestions already (thanks), some of which are
incorporated in the current text, but it sounds like you may have others as
well.


> Right now, transition is failing as a result of ARIN over-controlling
> policy that
> is related to v4 transfer.
>

I see 2011-1 as one of several steps currently in last call towards removing
unnecessary restrictions from policy.  Do you feel that 2011-1 is a step in
the right direction?  Should we be doing more to liberalize policy for
inter-regional transfers?  Is there anything about the current 2011-1 text
you would change?

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111020/6c7e50b7/attachment.htm>

From hannigan at gmail.com  Thu Oct 20 14:53:45 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 20 Oct 2011 14:53:45 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
Message-ID: <CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>

On Thu, Oct 20, 2011 at 2:37 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On Thu, Oct 20, 2011 at 7:46 AM, Martin Hannigan <hannigan at gmail.com> wrote:
>>
>> It's unfortunate that we spend so much time controlling
>> and so little time working on good policy that makes sense.
>
> I would agree that time spent arguing about whether process was followed
> doesn't get us toward better policy.
> Do you have any more suggestions for how to improve 2011-1?

Yes, I suggest that the AC reverse the last call state and bring this
to a public meeting of ARIN.

At best, section one of the "pdp" has been thrown out with the bath
water with respect to the at least four versions presented to the
community. A concept is not a policy and I don't dispute that we agree
on the concept of allowing interRIR transfers.

Best,

-M<


From scottleibrand at gmail.com  Thu Oct 20 15:04:07 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 20 Oct 2011 12:04:07 -0700
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
Message-ID: <CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>

On Thu, Oct 20, 2011 at 11:53 AM, Martin Hannigan <hannigan at gmail.com>wrote:

> On Thu, Oct 20, 2011 at 2:37 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> > On Thu, Oct 20, 2011 at 7:46 AM, Martin Hannigan <hannigan at gmail.com>
> wrote:
> >>
> >> It's unfortunate that we spend so much time controlling
> >> and so little time working on good policy that makes sense.
> >
> > I would agree that time spent arguing about whether process was followed
> > doesn't get us toward better policy.
> > Do you have any more suggestions for how to improve 2011-1?
>
> Yes, I suggest that the AC reverse the last call state and bring this
> to a public meeting of ARIN.
>
> At best, section one of the "pdp" has been thrown out with the bath
> water with respect to the at least four versions presented to the
> community. A concept is not a policy and I don't dispute that we agree
> on the concept of allowing interRIR transfers.
>

Understood.  After the last call is completed, that is one possible action
that the AC could take.

But I was hoping you (and anyone else with ideas) could provide actual
constructive feedback on how the text could be improved.  If such
suggestions are being provided here on list, we can discuss whether they are
potential improvements we should incorporate.  If not, the choice is between
moving forward or delaying.  I'm not sure how delaying another 6 months
helps.

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

From hannigan at gmail.com  Thu Oct 20 15:08:33 2011
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 20 Oct 2011 15:08:33 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
Message-ID: <CAMDXq5OYympNMnM0cY8J2oytsm+bdTmPSvvt60hCZw6UhY_kxg@mail.gmail.com>

On Thu, Oct 20, 2011 at 3:04 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On Thu, Oct 20, 2011 at 11:53 AM, Martin Hannigan <hannigan at gmail.com>
> wrote:
>>
>> On Thu, Oct 20, 2011 at 2:37 PM, Scott Leibrand <scottleibrand at gmail.com>
>> wrote:
>> > On Thu, Oct 20, 2011 at 7:46 AM, Martin Hannigan <hannigan at gmail.com>
>> > wrote:
>> >>
>> >> It's unfortunate that we spend so much time controlling
>> >> and so little time working on good policy that makes sense.
>> >
>> > I would agree that time spent arguing about whether process was followed
>> > doesn't get us toward better policy.
>> > Do you have any more suggestions for how to improve 2011-1?
>>
>> Yes, I suggest that the AC reverse the last call state and bring this
>> to a public meeting of ARIN.
>>
>> At best, section one of the "pdp" has been thrown out with the bath
>> water with respect to the at least four versions presented to the
>> community. A concept is not a policy and I don't dispute that we agree
>> on the concept of allowing interRIR transfers.
>
> Understood. ?After the last call is completed, that is one possible action
> that the AC could take.

> But I was hoping you (and anyone else with ideas) could provide actual
> constructive feedback on how the text could be improved.

That is actual constructive feedback unless of course nobody is listening.

>If such
> suggestions are being provided here on list, we can discuss whether they are
> potential improvements we should incorporate. ?If not, the choice is between
> moving forward or delaying. ?I'm not sure how delaying another 6 months
> helps.

Can you explain how it hurts?

Best,

-M<


From bill at herrin.us  Thu Oct 20 15:58:23 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 20 Oct 2011 15:58:23 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
Message-ID: <CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>

On Thu, Oct 20, 2011 at 3:04 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> But I was hoping you (and anyone else with ideas) could provide actual
> constructive feedback on how the text could be improved. ?If such
> suggestions are being provided here on list, we can discuss whether they are
> potential improvements we should incorporate.

Hi Scott,

1. Pull it out of section 8.3 and put it in its own section 8.4. At no
time in the process do I recall the community express a desire to
tamper with section 8.3 as part of the inter-region transfer process.
While such integration may become desirable in the future it is, IMHO,
not desirable now. We should implement, learn from and tune the
inter-region policy long before considering whether or how to
integrate it with the in-region transfer policy.

2. Earlier drafts required potential recipients to meet the
eligibility criteria set by BOTH regions. While this increases the
hassle factor associated with transferring addresses in or out of the
region, I believe it provides a valuable safeguard for this, our first
attempt at inter-region transfers. If, over time, we find that it's
all hassle for no benefit, we can remove it.

3. Who determines that ARIN and another RIR "share compatible,
needs-based policies?" Unless we set out explicit criteria, this is an
open-ended policy-level question which should be decided by
policy-level people, i.e. the Board. NOT by staff. I offered this
criticism on the earlier drafts as well and I'm disappointed to see it
hasn't been addressed.


>  If not, the choice is between
> moving forward or delaying.  I'm not sure how delaying another 6 months
> helps.

I have some other nitpicks, but without first correcting these large
issues, I'm with Marty: good try but you failed to capture the
community's intent. The newly written draft would benefit from another
cycle of discussion, modification and presentation so that it can move
forward with consensus on the actual policy language.

Regards,
Bill Herrin

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


From scottleibrand at gmail.com  Thu Oct 20 16:25:14 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 20 Oct 2011 13:25:14 -0700
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAMDXq5OYympNMnM0cY8J2oytsm+bdTmPSvvt60hCZw6UhY_kxg@mail.gmail.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
	<CAMDXq5OYympNMnM0cY8J2oytsm+bdTmPSvvt60hCZw6UhY_kxg@mail.gmail.com>
Message-ID: <CAGkMwz4QYZj=FhAQEsC4M=ndROfr7Y1YGvyuBcy5FtE8=2dazw@mail.gmail.com>

On Thu, Oct 20, 2011 at 12:08 PM, Martin Hannigan <hannigan at gmail.com>wrote:

> On Thu, Oct 20, 2011 at 3:04 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> > On Thu, Oct 20, 2011 at 11:53 AM, Martin Hannigan <hannigan at gmail.com>
> > wrote:
> >>
> >> On Thu, Oct 20, 2011 at 2:37 PM, Scott Leibrand <
> scottleibrand at gmail.com>
> >> wrote:
> >> > On Thu, Oct 20, 2011 at 7:46 AM, Martin Hannigan <hannigan at gmail.com>
> >> > wrote:
> >> >>
> >> >> It's unfortunate that we spend so much time controlling
> >> >> and so little time working on good policy that makes sense.
> >> >
> >> > I would agree that time spent arguing about whether process was
> followed
> >> > doesn't get us toward better policy.
> >> > Do you have any more suggestions for how to improve 2011-1?
> >>
> >> Yes, I suggest that the AC reverse the last call state and bring this
> >> to a public meeting of ARIN.
> >>
> >> At best, section one of the "pdp" has been thrown out with the bath
> >> water with respect to the at least four versions presented to the
> >> community. A concept is not a policy and I don't dispute that we agree
> >> on the concept of allowing interRIR transfers.
> >
> > Understood.  After the last call is completed, that is one possible
> action
> > that the AC could take.
>
> > But I was hoping you (and anyone else with ideas) could provide actual
> > constructive feedback on how the text could be improved.
>
> That is actual constructive feedback unless of course nobody is listening.
>

I'm listening.  I believe we both share a goal of updating ARIN's transfer
policies to remove unnecessary restrictions.  I am hearing your feedback,
that we shouldn't do so yet.  But I haven't seen any additional feedback on
the actual text being discussed.  In particular, I would love to know what
improvements you would like to make to the text.


>If such
> > suggestions are being provided here on list, we can discuss whether they
> are
> > potential improvements we should incorporate.  If not, the choice is
> between
> > moving forward or delaying.  I'm not sure how delaying another 6 months
> > helps.
>
> Can you explain how it hurts?


As I mentioned previously (at the mic in Philly and/or on PPML, IIRC), I
expect there will be organizations who wish to transfer space from
organization in the ARIN region to organizations in the APNIC region, quite
possibly in the next 6 months.  If that demand materializes and we can't
meet it, that will hurt someone, either the parties that wish to do the
transfer (if they decide not to do it) or the community (if they decide to
do it outside of the RIR system).

We've heard from Marty and Bill.  If anyone else feels that 2011-1 should be
revised, should go back for another meeting, or should move forward as is,
please speak up.

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

From springer at inlandnet.com  Thu Oct 20 16:41:25 2011
From: springer at inlandnet.com (John Springer)
Date: Thu, 20 Oct 2011 13:41:25 -0700 (PDT)
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4E9F20FF.1070203@arin.net>
References: <4E9F20FF.1070203@arin.net>
Message-ID: <20111020133934.T73083@mail.inlandnet.com>

I support the policy as written and thank the members of the AC for what 
appears to be a lot of hard work.

John Springer

On Wed, 19 Oct 2011, ARIN wrote:

> The ARIN Advisory Council (AC) met on 14 October 2011 and decided to
> send an amended version of the following draft policy to an extended last 
> call:
>
>  ARIN-2011-1: ARIN Inter-RIR Transfers
>
> The AC provided the following statement:
>
> ********
> The Advisory Council reviewed the results of feedback from the ARIN
> XXVIII Public Policy Meeting concerning Draft Policy 2011-1 Inter-RIR
> Transfers.  While there were concerns regarding the presented wording,
> there was significant continued support for a policy enabling
> Inter-Regional transfers of IPv4 number resources from organizations able to 
> make them available to any organization with valid requirements.
>
> In addition to cumbersome wording, the presented text could not be
> cleanly inserted into the NRPM.  The following is new language that
> directly modifies section 8.3 "Transfers to Specified Recipients" to
> allow such transfers to or from organizations in other regions.
>
> The first paragraph is a modified version of the current 8.3 policy
> language, envisioning resources being released to ARIN by the authorized
> resources holder or additionally by another RIR to be transferred to a
> specified recipient.  The second sentence was reorganized to emphasize
> that it applies to an organization within the ARIN region that will
> receive such a specified transfer, and to eliminate the single aggregate
> language per 2011-10 which is also being sent to last call.
>
> The new second paragraph adds language enabling transfers to a specified
> recipient in another RIR's service region.  This language specifies that
> such recipients justify their need to their RIR, following that RIR's
> policies.  ARIN will verify that there is a compatible needs based
> policy that the other RIR will use to evaluate the need of the recipient
> and that both RIR's agree to the transfer. Implicit in the intent of
> the language presented and in conformance with statements made, the size
> of the block to be transferred is identified as /24 or larger, for
> obvious practical reasons.
>
> In accordance with concern for immediate adoption, the AC chose to
> forward this version to last call.  Concerns expressed by some
> stakeholders for further controls were noted by the AC, and are being
> considered for future policy modification, assuaged in part by ARIN
> staff assurances that if any significant abuse of this policy were to
> occur, then the policy could easily be suspended.
>
> The AC thanks everyone in the community for their help in crafting this
> important policy and for your statements of support or other comments
> during Last Call.
> ********
>
> Feedback is encouraged during the last call period. All comments should
> be provided to the Public Policy Mailing List. Last call for 2011-1 will
> expire on 16 November 2011. After last call the AC will conduct their last 
> call review.
>
> The draft policy text is below and available at:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2011-1
> ARIN Inter-RIR Transfers
>
> Date/version: 14 October 2011
>
> Policy statement:
>
> 8.3 Transfers to Specified Recipients
>
> In addition to transfers under section 8.2, IPv4 number resources may be
> released to ARIN by the authorized resource holder or another RIR, in
> whole or in part, for transfer to another specified organizational
> recipient.  Organizations in the ARIN region may receive transferred
> number resources under RSA if they can demonstrate the need for such
> resources in the amount which they can justify under current ARIN policies.
>
> IPv4 address resources may be transferred to organizations in another
> RIR's service region if they demonstrate need to their region's RIR,
> according to that RIR's policies. Inter-regional transfers may take
> place only via RIRs who agree to the transfer and share compatible,
> needs-based policies. Such resources must be transferred in blocks of
> /24 or larger and will become part of the resource holdings of the
> recipient RIR.
>
> 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  Thu Oct 20 17:35:16 2011
From: farmer at umn.edu (David Farmer)
Date: Thu, 20 Oct 2011 16:35:16 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>
References: <4E9F20FF.1070203@arin.net>
	<7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>
Message-ID: <4EA09414.2060905@umn.edu>

On 10/19/11 21:54 CDT, Kevin Blumberg wrote:
> I will endeavor to be helpful but I also share the concern about the
> significant changes in the draft policy from the meeting and what was
> brought to last call.

Thank you.

> I see that "entities agreeing to the transfer and which otherwise
> meet both RIR's policies." was removed, which I considered to be a
> bi-lateral justification. That shifted the onus to "share compatible,
> needs based policies".

In my opinion that text created confusion that we wanted to require both 
RIR's criteria for justified need to be satisfied by the organization 
that is receiving the resources.  Rather than the source organization 
meeting the requirements of it RIR and the receiving organization 
meeting the requirements of it RIR.  Even if you believe the text meant 
that both policies were to apply, on both ends, I don't believe that how 
ARIN staff said they would implement that language.

By replacing that with  "IPv4 address resources may be transferred to 
organizations in another RIR's service region if they demonstrate need 
to their region's RIR, according to that RIR's policies."  we make it 
clear that the recipient justifies their need to their RIR using that 
RIR's policies.  I believe this is in line with how ARIN staff said they 
would implement the language anyway.

I believe It is impractical to have either RIR evaluate based on both 
policies, it is equally impractical to have each RIR evaluate both 
organizations based on there separate policies.  The only reasonable 
option it to have the source organization evaluated based on their RIR's 
policies and the receiving organization evaluated based on their RIR's 
policies.

> If that is the case I don't believe that
> "compatible" is strong enough and in my mind is way to ambiguous. It
> also removes any of the other provisions of the NRPM which might be
> required if abuse of the policy is found.

However, we are also saying that the other RIR must have a compatible 
needs based policy, and yes that is still a little ambiguous.  However, 
by stating that the receiving organization must  "demonstrate need to 
their region's RIR, according to that RIR's policies", "compatible" now 
has much more meaning and context that it didn't have before.

The other RIR must have a needs based policy compatible with the concept 
of receiving organization demonstrating its need to the RIR, and that 
RIR evaluating it.  So, if the other RIR didn't require any kind of 
demonstrated need, or there were no criteria to evaluate against, it 
therefore wouldn't be a compatible policy.  So while some ambiguity 
remains, and probably needs to in order to allow for some room for staff 
to do the right thing, there is now a fundamental basis for determining 
what a compatible needs based policy should be.


-- 
===============================================
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 scottleibrand at gmail.com  Thu Oct 20 17:47:57 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 20 Oct 2011 14:47:57 -0700
Subject: [arin-ppml] Should inter-regional transfers be part of 8.3? Was:
 ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
Message-ID: <CAGkMwz53=6-ceKSN9OYscF_1yE0JurHZ4kUZqzweDPzE3VGmhw@mail.gmail.com>

Thanks, Bill, for summarizing your suggested changes.

Does anyone in the community have input on Bill's item #1 (whether 2011-1
should be part of 8.3, or separated out as 8.4)?

Further comments inline...

On Thu, Oct 20, 2011 at 12:58 PM, William Herrin <bill at herrin.us> wrote:

> On Thu, Oct 20, 2011 at 3:04 PM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> > But I was hoping you (and anyone else with ideas) could provide actual
> > constructive feedback on how the text could be improved.  If such
> > suggestions are being provided here on list, we can discuss whether they
> are
> > potential improvements we should incorporate.
>
> Hi Scott,
>
> 1. Pull it out of section 8.3 and put it in its own section 8.4. At no
> time in the process do I recall the community express a desire to
> tamper with section 8.3 as part of the inter-region transfer process.
> While such integration may become desirable in the future it is, IMHO,
> not desirable now. We should implement, learn from and tune the
> inter-region policy long before considering whether or how to
> integrate it with the in-region transfer policy.
>

I personally disagree, but I think it's a valid point, and would be happy to
adjust the text accordingly if the community agrees that we should do so.


>
> 2. Earlier drafts required potential recipients to meet the
> eligibility criteria set by BOTH regions. While this increases the
> hassle factor associated with transferring addresses in or out of the
> region, I believe it provides a valuable safeguard for this, our first
> attempt at inter-region transfers. If, over time, we find that it's
> all hassle for no benefit, we can remove it.
>

When that was put in place prior to the APNIC Busan meeting, I agree it was
a valuable safeguard.  But now that all the RIRs' transfer policies are
needs-based, I believe this would just be an extra hassle with no real
benefit.  In addition, part of APNIC's reason for re-adding needs basis to
their transfer policy was to avoid having to justify needs to ARIN.  So in
addition to being unnecessary, I believe a requirement to have ARIN do such
a needs justification on out-of-region transfer recipients is harmful to the
spirit of inter-RIR cooperation.

It's also worth noting that this topic was discussed in Philly, and my sense
of the room was that there was a consensus for the destination RIR doing the
needs assessment.


>
> 3. Who determines that ARIN and another RIR "share compatible,
> needs-based policies?" Unless we set out explicit criteria, this is an
> open-ended policy-level question which should be decided by
> policy-level people, i.e. the Board. NOT by staff. I offered this
> criticism on the earlier drafts as well and I'm disappointed to see it
> hasn't been addressed.
>

We discussed this.  John can elaborate, but the gist was that an RIR with a
transfer policy that requires that a transfer recipient justify need to
their RIR would be a compatible transfer policy.  By contrast, a transfer
policy where the transfer recipient simply must attest that they have need
would not be compatible.  I believe that is exactly what the community wants
here, so I don't see this as an issue.

-Scott


>
>
> >  If not, the choice is between
> > moving forward or delaying.  I'm not sure how delaying another 6 months
> > helps.
>
> I have some other nitpicks, but without first correcting these large
> issues, I'm with Marty: good try but you failed to capture the
> community's intent. The newly written draft would benefit from another
> cycle of discussion, modification and presentation so that it can move
> forward with consensus on the actual policy language.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111020/ef73e858/attachment.htm>

From jcurran at arin.net  Thu Oct 20 18:05:43 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 20 Oct 2011 22:05:43 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4EA09414.2060905@umn.edu>
References: <4E9F20FF.1070203@arin.net>
	<7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>
	<4EA09414.2060905@umn.edu>
Message-ID: <A80BCBAA-4FD9-45E2-85B4-DD69CF935891@arin.net>

On Oct 20, 2011, at 5:35 PM, David Farmer wrote:

> On 10/19/11 21:54 CDT, Kevin Blumberg wrote:
>> I see that "entities agreeing to the transfer and which otherwise
>> meet both RIR's policies." was removed, which I considered to be a
>> bi-lateral justification. That shifted the onus to "share compatible,
>> needs based policies".
> 
> In my opinion that text created confusion that we wanted to require both RIR's criteria for justified need to be satisfied by the organization that is receiving the resources.  Rather than the source organization meeting the requirements of it RIR and the receiving organization meeting the requirements of it RIR.  Even if you believe the text meant that both policies were to apply, on both ends, I don't believe that how ARIN staff said they would implement that language.

Correct. The staff assessment indicated that the prior language was unclear 
and wide open to interpretation.  For avoidance of doubt, the assessment 
specified the process that would be followed if the prior language was adopted, 
and it required that the source and recipient meet the respective portions of 
both RIR's transfer policies.  The revised 2011-1 policy text is much clearer 
on this point, and would have the same implementation process.  

Clarity on this point is definitely helpful in implementation, and if the 
alternative is the desired outcome (wherein both RIRs independently apply 
their full transfer processes to both parties), then that should be made 
clear.  Note that the implications of this approach have not been assessed, 
and it has the potential for significant legal, language, and support 
implications.

FYI,
/John

John Curran
President and CEO
ARIN



From mysidia at gmail.com  Thu Oct 20 20:05:10 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 20 Oct 2011 19:05:10 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
Message-ID: <CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>

On Thu, Oct 20, 2011 at 12:56 PM, Robert Seastrom <ppml at rs.seastrom.com> wrote:
>later). ?The salient changes are as follows:
> * Demonstrated need is solely the determination of the recipient's RIR (subject to them having a needs-based policy in place) rather than having to qualify with both the recipient RIR and with ARIN.
> * Delete "within 3 months" immediate need clause.

Exactly.    I oppose the policy as written, and those particular
changes make it worse.

I see  from the draft that it is proposed ARIN throw caution to the
wind and automatically accept whatever the recipient's RIR rules are
as long as ARIN staff interpret the receiving RIR as having a
"compatible needs based policy that the other RIR will use to evaluate
the need of the recipient".

There's really no community benefit of even listing the restriction
when it gets that weak,  as  ARIN's own justified need policy is the
most restrictive.    Some RIRs have less restrictive policies  to
evaluate the recipient,  therefore, the result is _all_  RIRs
actually have  policies for evaluating the recipient that are
compatible with ARIN transferring addresses.

Why bother with the restriction, on the off chance another RIR will
come up with a stricter criteria for receiving addresses, resulting in
incompatibility with ARIN's  justified need policy?

That is... there's not really RIRs that would have a policy resulting
in them rejecting a transfer that ARIN would approve in their own
region,  and if there are,   just let the receiving RIR enforce their
own policy rather than encumbering the Inter-RIR transfer rule  with
some ambiguous notion  of "compatibility".

>to draft policy (pp-xxx to 20xx-xx promotion) it had better be "NRPM-ized". ?A proposal that does not >countenance specific and well-defined changes to the NRPM is simply a wish, it is not a fully developed >policy proposal.

Exactly.
It should be in the form of  a policy proposal at the time discussed.

It is all good and well with the AC drafting policy proposals, but
THIS should not be at last call.

THIS specific proposal should be further discussed.



--
-JH


From jcurran at arin.net  Thu Oct 20 20:31:13 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Oct 2011 00:31:13 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
Message-ID: <450C139F-7961-45A0-AA21-01B257ADBA01@arin.net>

On Oct 20, 2011, at 8:05 PM, Jimmy Hess wrote:

> I see  from the draft that it is proposed ARIN throw caution to the
> wind and automatically accept whatever the recipient's RIR rules are
> as long as ARIN staff interpret the receiving RIR as having a
> "compatible needs based policy that the other RIR will use to evaluate
> the need of the recipient".
> 
> There's really no community benefit of even listing the restriction
> when it gets that weak,  as  ARIN's own justified need policy is the
> most restrictive.    Some RIRs have less restrictive policies  to
> evaluate the recipient,  therefore, the result is _all_  RIRs
> actually have  policies for evaluating the recipient that are
> compatible with ARIN transferring addresses.
> 
> Why bother with the restriction, on the off chance another RIR will
> come up with a stricter criteria for receiving addresses, resulting in
> incompatibility with ARIN's  justified need policy?
> 
> That is... there's not really RIRs that would have a policy resulting
> in them rejecting a transfer that ARIN would approve in their own
> region,  and if there are,   just let the receiving RIR enforce their
> own policy rather than encumbering the Inter-RIR transfer rule  with
> some ambiguous notion  of "compatibility".

For clarity, "compatible, needs-based policy" will be interpreted for
outward transfers as a requirement for the other RIR to have a policy
which: 1) requires the recipient to have need for the address space,
and 3) that the recipient must demonstrate that need to their RIR for 
transfer approval.

Under the proposed policy text, it does not matter if the other RIRs
requirements are more or less strict than ARIN's, as long as the other
RIR requires the recipient to demonstrate their need for the address 
space which they're obtaining from the party in the ARIN region.

I am not asserting that is a desirable policy outcome or otherwise, 
but simply providing this information to assist in understanding how
the proposed policy text would be implemented.

FYI,
/John

John Curran
President and CEO
ARIN



From BillD at cait.wustl.edu  Thu Oct 20 21:20:25 2011
From: BillD at cait.wustl.edu (Bill Darte)
Date: Thu, 20 Oct 2011 20:20:25 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
	Transfers - Last Call
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com><EAE2CBD6-F1A2-4E86-82A7-C74B9D6C86C0@arin.net>
	<CAMDXq5Mc_mqp=gPw3+jpravd8dWs5MpQRoi5G9acy8_=TmOoQQ@mail.gmail.com>
Message-ID: <EACF8B735E9CBA4B8BAF9E4165D03087915BD0@ex1.cait.wustl.edu>

Marty,

I've asked you for substantive discussion about the current wording of the policy text of 2011-1 and how it does or does not conform to the objectives listed on Slide 6 of my presentation and community consensus for an Inter-regional transfer policy.

Instead you 'strike' out about the system and some 'circling the wagons' conspiracy.

Please be specific when you speak of over-controlling policy related to v4 transfers...which is stifling transition.  If you have more than base-less charges, please share them.  Through open and legitimate debate we can make progress. But not, I'm afraid, through incendiary rhetoric.

bd


-----Original Message-----
From: arin-ppml-bounces at arin.net on behalf of Martin Hannigan
Sent: Thu 10/20/2011 9:46 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
 
On Thu, Oct 20, 2011 at 7:59 AM, John Curran <jcurran at arin.net> wrote:
> On Oct 19, 2011, at 10:32 PM, Martin Hannigan wrote:
>>
>> Bill,
>>
>> I agree with you, the process has failed at least from an integrity
>> perspective. ?The last call text presented in this thread should not
>> be allowed to propagate under the cover of community blessing.
>
> Marty -
>

[ snip Owen ]
[ snip John ]
[ snip CJ ]
[ snip Sweeting ]

ARIN has a history of circling the wagons after it is unable to
prevent public dissent. Generally, a "first strike" mentality exists
whenever the organizations credibility or integrity of it's process is
challenged. It's unfortunate that we spend so much time controlling
and so little time working on good policy that makes sense. Right now,
transition is failing as a result of ARIN over-controlling policy that
is related to v4 transfer.

Not much more I can say on the topic. I would like to again thank my
colleagues for their hard work.

Best,

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

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

From mysidia at gmail.com  Thu Oct 20 21:29:54 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 20 Oct 2011 20:29:54 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <EACF8B735E9CBA4B8BAF9E4165D03087915BD0@ex1.cait.wustl.edu>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EAE2CBD6-F1A2-4E86-82A7-C74B9D6C86C0@arin.net>
	<CAMDXq5Mc_mqp=gPw3+jpravd8dWs5MpQRoi5G9acy8_=TmOoQQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BD0@ex1.cait.wustl.edu>
Message-ID: <CAAAwwbUxsLYMvtNCc_NwZTKwqZq6Wzmf=Vo1s3_w+jZPkWW89g@mail.gmail.com>

On Thu, Oct 20, 2011 at 8:20 PM, Bill Darte <BillD at cait.wustl.edu> wrote:

> Please be specific when you speak of over-controlling policy related to v4
> transfers...which is stifling transition.? If you have more than base-less

I am also curious about this point...   what over-controlling v4
transfer policy?

If anything, I would say the current transfer policies lack  even
sufficient controls.
The transfer policy currently is very liberal, as long as the transfer recipient
can meet the baseline simple needs-based justification,

which is even more liberal than the current needs justification required for
a fresh allocation.

In what way might the 8.2/8.3 policies as they stand be too liberal?
The way they've been interpreted, to allow a transfer recipient to receive
less addresses than they need and effect multiple transfers,   resulting in
a transfer recipient getting multiple non-aggregable blocks transferred to
them,   so  they can only route their  "needed (but divided)" addresses
by polluting the routing tables, as in,   generating multiple and potentially
excessive numbers of routing table entries for the same network,  due to
getting say the /16 they need,  as   256   discrete non-aggregable /24s....

--
-JH


From owen at delong.com  Thu Oct 20 21:38:44 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 21 Oct 2011 03:38:44 +0200
Subject: [arin-ppml] ARIN-2011-9 (Global Proposal): Global Policy for
	post exhaustion IPv4 allocation mechanisms by the IANA - Last Call
In-Reply-To: <4EA04FB0.2070707@verizon.com>
References: <4E9F2127.9060809@arin.net> <4EA03768.8090804@verizon.com>
	<4EA0492B.40007@umn.edu> <4EA04FB0.2070707@verizon.com>
Message-ID: <F82C1CFA-B1FD-4108-81D1-6792241322D9@delong.com>



Sent from my iPad

On Oct 20, 2011, at 6:43 PM, Randy Whitney <randy.whitney at verizon.com> wrote:

> On 10/20/2011 12:15 PM, David Farmer wrote:
>> Randy,
>> 
>> I found myself more or less repeating what Bill, John and Owen said
>> already.  So, instead I will just say +1 to what they said and then ask
>> you;
>> 
>> Does that clarify the issue for you?  And do you have any further
>> concerns?
>> 
> 
> Thank you to all that responded providing background and clarification.
> Although I'd still prefer to see the NRO statement removed, I still
> support the policy either way and won't object further if it is not.
> 

At this point, I actually agree with you. I'm the one that put the original
pressure on to include it for the reasons stated and for the reasons
subsequently stated, it is now moot.

Owen

> Best Regards,
> Randy
> 
> _______________________________________________
> 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  Thu Oct 20 22:01:18 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 21 Oct 2011 04:01:18 +0200
Subject: [arin-ppml] Should inter-regional transfers be part of 8.3?
	Was: ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAGkMwz53=6-ceKSN9OYscF_1yE0JurHZ4kUZqzweDPzE3VGmhw@mail.gmail.com>
References: <CAGkMwz53=6-ceKSN9OYscF_1yE0JurHZ4kUZqzweDPzE3VGmhw@mail.gmail.com>
Message-ID: <2F351F67-CD56-4FE5-98C7-F30DB5730BB0@delong.com>



Sent from my iPad

On Oct 20, 2011, at 11:47 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:

> Thanks, Bill, for summarizing your suggested changes.
> 
> Does anyone in the community have input on Bill's item #1 (whether 2011-1 should be part of 8.3, or separated out as 8.4)?  
> 
> Further comments inline...
> 
> On Thu, Oct 20, 2011 at 12:58 PM, William Herrin <bill at herrin.us> wrote:
> On Thu, Oct 20, 2011 at 3:04 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> > But I was hoping you (and anyone else with ideas) could provide actual
> > constructive feedback on how the text could be improved.  If such
> > suggestions are being provided here on list, we can discuss whether they are
> > potential improvements we should incorporate.
> 
> Hi Scott,
> 
> 1. Pull it out of section 8.3 and put it in its own section 8.4. At no
> time in the process do I recall the community express a desire to
> tamper with section 8.3 as part of the inter-region transfer process.
> While such integration may become desirable in the future it is, IMHO,
> not desirable now. We should implement, learn from and tune the
> inter-region policy long before considering whether or how to
> integrate it with the in-region transfer policy.
> 
> I personally disagree, but I think it's a valid point, and would be happy to adjust the text accordingly if the community agrees that we should do so.

I don't care one way or the other on this one. I think worrying about it amounts to getting wrapped around the axle on process rather than focusing on whether the policy actually reflects the intent of the community. The placement of the wording is much less relevant than the actual effect the words have.

I'm fine with moving it to 8.4. I'm fine with leaving it in 8.3. However, what I don't want to do is make a silly positioning change and have to repeat last call without any substantive change to the meaning of the policy.

>  
> 
> 2. Earlier drafts required potential recipients to meet the
> eligibility criteria set by BOTH regions. While this increases the
> hassle factor associated with transferring addresses in or out of the
> region, I believe it provides a valuable safeguard for this, our first
> attempt at inter-region transfers. If, over time, we find that it's
> all hassle for no benefit, we can remove it.
> 
> When that was put in place prior to the APNIC Busan meeting, I agree it was a valuable safeguard.  But now that all the RIRs' transfer policies are needs-based, I believe this would just be an extra hassle with no real benefit.  In addition, part of APNIC's reason for re-adding needs basis to their transfer policy was to avoid having to justify needs to ARIN.  So in addition to being unnecessary, I believe a requirement to have ARIN do such a needs justification on out-of-region transfer recipients is harmful to the spirit of inter-RIR cooperation.
> 
> It's also worth noting that this topic was discussed in Philly, and my sense of the room was that there was a consensus for the destination RIR doing the needs assessment.
>  

Yes and no. I think that the current text contains adequate safeguards, but, I will point out that APNIC needs based policy is in last call, it is not yet fully ratified, let alone implemented. I hope that this proposal is sufficiently clear that ARIN staff will not agree to transfers with APNIC until such time as APNIC has completed the implementation of their needs-based policy.

I also think that we should remain aware that other RIRs could change their policies at any time independent of ours. That is why we chose to keep the terms "compatible needs-based" and "agreement of both RIRs" in the policy. I believe those provide safeguards and allow staff discretion to reject transfers that should not occur.

> 
> 3. Who determines that ARIN and another RIR "share compatible,
> needs-based policies?" Unless we set out explicit criteria, this is an
> open-ended policy-level question which should be decided by
> policy-level people, i.e. the Board. NOT by staff. I offered this
> criticism on the earlier drafts as well and I'm disappointed to see it
> hasn't been addressed.
> 
> We discussed this.  John can elaborate, but the gist was that an RIR with a transfer policy that requires that a transfer recipient justify need to their RIR would be a compatible transfer policy.  By contrast, a transfer policy where the transfer recipient simply must attest that they have need would not be compatible.  I believe that is exactly what the community wants here, so I don't see this as an issue.
> 

Yes, I actually agree. As much as I find this whole transfer thing distasteful and would prefer that it was practical to simply require organizations no longer using space to return it, that's not the reality we are faced with.

While I understand your desire to have these decisions made at the board and not the staff level, the reality is that in this case, staff can consult the board on a case-by-case basis if needed if we provide them a policy with sufficient latitude and I trust the board (and John) not to let staff get too far out into the weeds with their discretion. They have a pretty good track record. OTOH, if we were to make a rigid policy here, it could be very difficult for staff to adapt to quickly changing situations and might even complicate the board making a determination on a specific case as well.

I'm sure we'll spend significant resources continuing to fine tune section 8 over the next several policy cycles. For the time being, I think that this represents a significant step in the right direction.
> 
> I have some other nitpicks, but without first correcting these large
> issues, I'm with Marty: good try but you failed to capture the
> community's intent. The newly written draft would benefit from another
> cycle of discussion, modification and presentation so that it can move
> forward with consensus on the actual policy language.
> 

Thanks, Bill... That's good and useful feedback. I hope others in the community will let us know if they agree with you or if they feel that this policy as is (or with additional changes and another last call) should move forward without waiting for another policy cycle.

Owen

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

From owen at delong.com  Thu Oct 20 22:29:17 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 21 Oct 2011 04:29:17 +0200
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
	Transfers - Last Call
In-Reply-To: <CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
Message-ID: <9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>

> Why bother with the restriction, on the off chance another RIR will
> come up with a stricter criteria for receiving addresses, resulting in
> incompatibility with ARIN's  justified need policy?
> 
I believe that a substantially less restrictive policy would be incompatible.

Currently all RIRs have relatively similar needs-based policies for transfers, except APNIC.
APNIC is currently incompatible, but, they have a compatible policy in last call at this time.

> That is... there's not really RIRs that would have a policy resulting
> in them rejecting a transfer that ARIN would approve in their own
> region,  and if there are,   just let the receiving RIR enforce their
> own policy rather than encumbering the Inter-RIR transfer rule  with
> some ambiguous notion  of "compatibility".
> 

The intent of that language is to provide ARIN a safety valve to not approve a transfer in a case where the receiving region's policy is regarded as too lax or non-needs-based. It is, in fact, intended to avoid throwing caution to the wind. Staff has also provided clarification that it would be implemented in that way.

With these clarifications, does that help?

Owen



From andrew.koch at gawul.net  Thu Oct 20 23:10:15 2011
From: andrew.koch at gawul.net (Andrew Koch)
Date: Thu, 20 Oct 2011 22:10:15 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
	<CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>
Message-ID: <CAN0k1Yi1Eh9EK6YB6J04zk=F6-mMbdnAwU1odK_Arc-e2aADKg@mail.gmail.com>

On Thu, Oct 20, 2011 at 14:58, William Herrin <bill at herrin.us> wrote:
>
> 1. Pull it out of section 8.3 and put it in its own section 8.4. At no
> time in the process do I recall the community express a desire to
> tamper with section 8.3 as part of the inter-region transfer process.
> While such integration may become desirable in the future it is, IMHO,
> not desirable now. We should implement, learn from and tune the
> inter-region policy long before considering whether or how to
> integrate it with the in-region transfer policy.

I do not agree that a separate policy is needed for transfers.  All
transfers should fall under the same criteria for the resource
recipient in my opinion.

> 2. Earlier drafts required potential recipients to meet the
> eligibility criteria set by BOTH regions. While this increases the
> hassle factor associated with transferring addresses in or out of the
> region, I believe it provides a valuable safeguard for this, our first
> attempt at inter-region transfers. If, over time, we find that it's
> all hassle for no benefit, we can remove it.

I completely disagree with this point.  I believe that requiring the
recipient to meet criteria in both regions will hinder the process to
non-usability.  I am ok with leaving this as is.  I would also be ok
with requiring the recipient to meet the existing registrant's RIR
policy on transfer.


> 3. Who determines that ARIN and another RIR "share compatible,
> needs-based policies?" Unless we set out explicit criteria, this is an
> open-ended policy-level question which should be decided by
> policy-level people, i.e. the Board. NOT by staff. I offered this
> criticism on the earlier drafts as well and I'm disappointed to see it
> hasn't been addressed.
>

This is a point I agree with.  What is your recommendation on
resolving this?  Place text that this transfer policy only can go into
effect when the Board makes notice that another RIR has compatible
needs-based policy?  Would you require them to review this on some
type of interval?  Where should this be published?

Regards,
Andy Koch


From andrew.koch at gawul.net  Thu Oct 20 23:16:14 2011
From: andrew.koch at gawul.net (Andrew Koch)
Date: Thu, 20 Oct 2011 22:16:14 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <A80BCBAA-4FD9-45E2-85B4-DD69CF935891@arin.net>
References: <4E9F20FF.1070203@arin.net>
	<7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>
	<4EA09414.2060905@umn.edu>
	<A80BCBAA-4FD9-45E2-85B4-DD69CF935891@arin.net>
Message-ID: <CAN0k1Yg1zkamjAm=wYD9k+Rj-n3j=_TapRNcPQ80Bsf04fJy0A@mail.gmail.com>

On Thu, Oct 20, 2011 at 17:05, John Curran <jcurran at arin.net> wrote:

> Clarity on this point is definitely helpful in implementation, and if the
> alternative is the desired outcome (wherein both RIRs independently apply
> their full transfer processes to both parties), then that should be made
> clear. ?Note that the implications of this approach have not been assessed,
> and it has the potential for significant legal, language, and support
> implications.
>

John,

Previously in this thread, you indicated the process of taking this
policy to last call met the requirements of the PDP.  You are now
advising that further review by legal is required.  At what point are
staff and legal reviews required on the text before it can proceed in
the PDP?  Should this policy be held in last-call, resubmitted to
another last-call following the reviews or do the results of the
reviews require another PPM discussion?

Thanks,
Andy Koch


From jcurran at arin.net  Fri Oct 21 00:13:43 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Oct 2011 04:13:43 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAN0k1Yg1zkamjAm=wYD9k+Rj-n3j=_TapRNcPQ80Bsf04fJy0A@mail.gmail.com>
References: <4E9F20FF.1070203@arin.net>
	<7E7773B523E82C478734E793E58F69E7FC3076@SBS2011.thewireinc.local>
	<4EA09414.2060905@umn.edu>
	<A80BCBAA-4FD9-45E2-85B4-DD69CF935891@arin.net>
	<CAN0k1Yg1zkamjAm=wYD9k+Rj-n3j=_TapRNcPQ80Bsf04fJy0A@mail.gmail.com>
Message-ID: <95C5004D-EFEB-4650-BB1D-294A4DB7DA87@arin.net>

On Oct 20, 2011, at 11:16 PM, Andrew Koch wrote:

> On Thu, Oct 20, 2011 at 17:05, John Curran <jcurran at arin.net> wrote:
> 
>> Clarity on this point is definitely helpful in implementation, and if the
>> alternative is the desired outcome (wherein both RIRs independently apply
>> their full transfer processes to both parties), then that should be made
>> clear.  Note that the implications of this approach have not been assessed,
>> and it has the potential for significant legal, language, and support
>> implications.
>> 
> 
> John,
> 
> Previously in this thread, you indicated the process of taking this
> policy to last call met the requirements of the PDP.  You are now
> advising that further review by legal is required.  At what point are
> staff and legal reviews required on the text before it can proceed in
> the PDP?  Should this policy be held in last-call, resubmitted to
> another last-call following the reviews or do the results of the
> reviews require another PPM discussion?

A staff and legal review is being done now on the revised 2011-1 text, 
but will likely not be that substantially different from the assessmet
results of the previous policy text.

My note above is that if there were a change to the policy text to specify 
that the both RIRs independently apply their full transfer processes to 
both parties could have very significant implications, and that this has
not been assessed because that is not the current proposed policy text.

Thanks,
/John

John Curran
President and CEO
ARIN



From narten at us.ibm.com  Fri Oct 21 00:53:02 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 21 Oct 2011 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201110210453.p9L4r2a4003703@rotala.raleigh.ibm.com>

Total of 84 messages in the last 7 days.
 
script run at: Fri Oct 21 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 16.67% |   14 | 13.88% |    95605 | jcurran at arin.net
 13.10% |   11 | 16.26% |   112031 | owen at delong.com
 11.90% |   10 | 10.43% |    71826 | bill at herrin.us
  7.14% |    6 |  9.89% |    68123 | scottleibrand at gmail.com
  7.14% |    6 |  6.67% |    45913 | farmer at umn.edu
  7.14% |    6 |  6.64% |    45761 | hannigan at gmail.com
  7.14% |    6 |  5.09% |    35058 | randy.whitney at verizon.com
  5.95% |    5 |  5.19% |    35759 | info at arin.net
  3.57% |    3 |  5.78% |    39809 | billd at cait.wustl.edu
  4.76% |    4 |  3.62% |    24966 | mysidia at gmail.com
  2.38% |    2 |  4.90% |    33718 | cja at daydream.com
  2.38% |    2 |  1.96% |    13513 | john.sweeting at twcable.com
  2.38% |    2 |  1.95% |    13401 | andrew.koch at gawul.net
  1.19% |    1 |  1.68% |    11575 | ppml at rs.seastrom.com
  1.19% |    1 |  1.47% |    10135 | kevinb at thewire.ca
  1.19% |    1 |  1.37% |     9447 | springer at inlandnet.com
  1.19% |    1 |  0.91% |     6286 | narten at us.ibm.com
  1.19% |    1 |  0.82% |     5658 | lsawyer at gci.com
  1.19% |    1 |  0.81% |     5583 | gary.buhrmaster at gmail.com
  1.19% |    1 |  0.68% |     4651 | sweeny at indiana.edu
--------+------+--------+----------+------------------------
100.00% |   84 |100.00% |   688818 | Total



From bill at herrin.us  Fri Oct 21 04:50:00 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 21 Oct 2011 04:50:00 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
Message-ID: <CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>

On Thu, Oct 20, 2011 at 10:29 PM, Owen DeLong <owen at delong.com> wrote:
> I believe that a substantially less restrictive policy would be incompatible.

Unfortunately, John Curran has just posted that's not the case. Under
the current text, another RIR's policy whose basis for needs
justification is substantially less restrictive than ARIN's would
still control for addresses transferred out of the region. 2011-1, as
presently written, may cause substantially more restrictive
justification policies to be applied to ARIN transferees receiving
ARIN addresses than to out-region transferees receiving ARIN
addresses.

I find that fundamentally unfair and have a big problem with 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 john.sweeting at twcable.com  Fri Oct 21 08:09:43 2011
From: john.sweeting at twcable.com (Sweeting, John)
Date: Fri, 21 Oct 2011 08:09:43 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
Message-ID: <CAC6D923.BCBC%john.sweeting@twcable.com>

Hi Bill,

Sorry but I cannot find that quote from John, is it possible for you to
include it in your email?

Thanks,
John

++

On 10/21/11 4:50 AM, "William Herrin" <bill at herrin.us> wrote:

>On Thu, Oct 20, 2011 at 10:29 PM, Owen DeLong <owen at delong.com> wrote:
>> I believe that a substantially less restrictive policy would be
>>incompatible.
>
>Unfortunately, John Curran has just posted that's not the case. Under
>the current text, another RIR's policy whose basis for needs
>justification is substantially less restrictive than ARIN's would
>still control for addresses transferred out of the region. 2011-1, as
>presently written, may cause substantially more restrictive
>justification policies to be applied to ARIN transferees receiving
>ARIN addresses than to out-region transferees receiving ARIN
>addresses.
>
>I find that fundamentally unfair and have a big problem with 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
>_______________________________________________
>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 bill at herrin.us  Fri Oct 21 08:26:25 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 21 Oct 2011 08:26:25 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAC6D923.BCBC%john.sweeting@twcable.com>
References: <CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<CAC6D923.BCBC%john.sweeting@twcable.com>
Message-ID: <CAP-guGVC6wSG6LkckdDuEC0A=WE-LUH-iL5G_sjr+JjcyRKO6w@mail.gmail.com>

On Fri, Oct 21, 2011 at 8:09 AM, Sweeting, John
<john.sweeting at twcable.com> wrote:
> On 10/21/11 4:50 AM, "William Herrin" <bill at herrin.us> wrote:
>
>>On Thu, Oct 20, 2011 at 10:29 PM, Owen DeLong <owen at delong.com> wrote:
>>> I believe that a substantially less restrictive policy would be
>>>incompatible.
>>
>>Unfortunately, John Curran has just posted that's not the case. Under
>>the current text, another RIR's policy whose basis for needs
>>justification is substantially less restrictive than ARIN's would
>>still control for addresses transferred out of the region. 2011-1, as
>>presently written, may cause substantially more restrictive
>>justification policies to be applied to ARIN transferees receiving
>>ARIN addresses than to out-region transferees receiving ARIN
>>addresses.

> Sorry but I cannot find that quote from John, is it possible for you to
> include it in your email?

"Under the proposed policy text, it does not matter if the other RIRs
requirements are more or less strict than ARIN's, as long as the other
RIR requires the recipient to demonstrate their need for the address
space"

http://lists.arin.net/pipermail/arin-ppml/2011-October/023429.html

Regards,
Bill Herrin


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


From john.sweeting at twcable.com  Fri Oct 21 08:33:06 2011
From: john.sweeting at twcable.com (Sweeting, John)
Date: Fri, 21 Oct 2011 08:33:06 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAP-guGVC6wSG6LkckdDuEC0A=WE-LUH-iL5G_sjr+JjcyRKO6w@mail.gmail.com>
Message-ID: <CAC6DE57.BCC3%john.sweeting@twcable.com>

Thanks Bill, I guess I was looking for "substantially less restrictive"
rather than "more or less strict".

++

On 10/21/11 8:26 AM, "William Herrin" <bill at herrin.us> wrote:

>On Fri, Oct 21, 2011 at 8:09 AM, Sweeting, John
><john.sweeting at twcable.com> wrote:
>> On 10/21/11 4:50 AM, "William Herrin" <bill at herrin.us> wrote:
>>
>>>On Thu, Oct 20, 2011 at 10:29 PM, Owen DeLong <owen at delong.com> wrote:
>>>> I believe that a substantially less restrictive policy would be
>>>>incompatible.
>>>
>>>Unfortunately, John Curran has just posted that's not the case. Under
>>>the current text, another RIR's policy whose basis for needs
>>>justification is substantially less restrictive than ARIN's would
>>>still control for addresses transferred out of the region. 2011-1, as
>>>presently written, may cause substantially more restrictive
>>>justification policies to be applied to ARIN transferees receiving
>>>ARIN addresses than to out-region transferees receiving ARIN
>>>addresses.
>
>> Sorry but I cannot find that quote from John, is it possible for you to
>> include it in your email?
>
>"Under the proposed policy text, it does not matter if the other RIRs
>requirements are more or less strict than ARIN's, as long as the other
>RIR requires the recipient to demonstrate their need for the address
>space"
>
>http://lists.arin.net/pipermail/arin-ppml/2011-October/023429.html
>
>Regards,
>Bill Herrin
>
>
>--
>William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
>3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
>Falls Church, VA 22042-3004


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  Fri Oct 21 08:42:03 2011
From: farmer at umn.edu (David Farmer)
Date: Fri, 21 Oct 2011 07:42:03 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
Message-ID: <4EA1689B.10006@umn.edu>



On 10/21/11 03:50 CDT, William Herrin wrote:
> On Thu, Oct 20, 2011 at 10:29 PM, Owen DeLong<owen at delong.com>  wrote:
>> I believe that a substantially less restrictive policy would be incompatible.
>
> Unfortunately, John Curran has just posted that's not the case. Under
> the current text, another RIR's policy whose basis for needs
> justification is substantially less restrictive than ARIN's would
> still control for addresses transferred out of the region. 2011-1, as
> presently written, may cause substantially more restrictive
> justification policies to be applied to ARIN transferees receiving
> ARIN addresses than to out-region transferees receiving ARIN
> addresses.
>
> I find that fundamentally unfair and have a big problem with it.

First, I'm not unsympathetic to the fairness argument, and on the 
surface applying both RIR's transfer policies seems like a fair way to 
solve this problem.  However, once you scratch the surface and start 
looking at how such a policy will work from a practical point of view 
things get ugly very fast and it no longer looks as fair as it did on 
the surface.

ARIN will not have any independent history to base its analysis of need 
on and will be dependent on the records of the other RIR anyway.  The 
organization from the other RIR's region will not necessarily be 
familiar with ARIN's policy and processes.  It doubles the work for the 
organizations involved in the transfer.  There will frequently be 
language and cultural issues that get in the way of a fair and complete 
analysis, there are a more practical issues like business hours, etc... 
that will interfere with easy flow of information.  These are the exact 
reasons that the RIR system was crated in the first place.  Forcing both 
policies to be applied ignores more than a decade of experience in good 
Internet number resource management.  How is that fair?

Beyond that, we really need to be careful when we start throwing around 
the word "FAIR", it cuts both ways.  With the legacy resources in our 
region we have approximately half of all IPv4 resources.  On the 
surface, there are NOT many ways that seems fair, its not fair by 
population, its not even fair by land mass.  But if you dig down there 
are valid reasons why.

So, on the surface it may seem fair to apply both policies, but we have 
to dig deeper, and when you do, applying both policies really isn't 
practical, probably will not really result in more fairness in the 
system as a whole, and it is possible that it would be less fair.

By the way, thank you for holding our feet to the fire, by actually 
asking questions, it is far more important to the system than actually 
writing the text, not that that's easy either.

-- 
===============================================
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 jcurran at arin.net  Fri Oct 21 08:47:22 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Oct 2011 12:47:22 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
Message-ID: <3437B3DE-C765-42D6-B411-342CD1A7B11A@arin.net>

On Oct 21, 2011, at 4:50 AM, William Herrin wrote:

> On Thu, Oct 20, 2011 at 10:29 PM, Owen DeLong <owen at delong.com> wrote:
>> I believe that a substantially less restrictive policy would be incompatible.
> 
> Unfortunately, John Curran has just posted that's not the case. Under
> the current text, another RIR's policy whose basis for needs
> justification is substantially less restrictive than ARIN's would
> still control for addresses transferred out of the region. 2011-1,
> as presently written, may cause substantially more restrictive
> justification policies to be applied to ARIN transferees receiving
> ARIN addresses than to out-region transferees receiving ARIN
> addresses.

Bill is correct, in that any policy which requires the recipient
to have need, and requires demonstration of that need to the other 
RIR would presently be deemed "compatible".  We've given some thought 
to how this could be implemented, and most likely ARIN would need to
maintain a public list of those compatible RIR transfer policies.
Staff could directly update as changes occur, or staff could bring  
the recommendation to the Board for concurrence, or bring it to 
the ARIN AC for their recommendation and then Board concurrence.
(Absent addition guidance here, staff recommendation with Board
concurrence is the most likely implementation to occur, and that 
will be in the revised staff and legal review presently underway)

> I find that fundamentally unfair and have a big problem with it.

Presently, the RIRs have documents between us (ICANN, ICANN ICP-2)
that agree to basic principles (including conservation, IP address
distribution according to need, open and transparent processes, etc.)
An Inter-RIR transfer policy which requires adherence to any of these
principles is quite straightforward from my perspective; a policy which 
goes beyond basic principles and sets specific criteria for another RIR 
policies is new ground.  Specific criteria may or may not be a desirable 
policy outcome (that is for the community to decide) but is not inherently
building on an area of existing agreement among the RIRs.  Obviously, if a 
modified InterRIR transfer policy (requiring specific criteria for another 
RIRs transfer policies) where to be adopted, ARIN would still implement it 
and encourage compatible policies whenever possible.

FYI,
/John

John Curran
President and CEO
ARIN



From jcurran at arin.net  Fri Oct 21 08:52:02 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Oct 2011 12:52:02 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <3437B3DE-C765-42D6-B411-342CD1A7B11A@arin.net>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<3437B3DE-C765-42D6-B411-342CD1A7B11A@arin.net>
Message-ID: <5016761F-37E3-4DB5-8094-622D7CF0E8F1@arin.net>

Errata (due to insufficient caffeine :-)

On Oct 21, 2011, at 8:47 AM, John Curran wrote:

> Presently, the RIRs have documents between us (ICANN, ICANN ICP-2)

Presently, the RIRs have documents between us (RFC 2050, ICANN ICP-2)



From bill at herrin.us  Fri Oct 21 09:35:58 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 21 Oct 2011 09:35:58 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <4EA1689B.10006@umn.edu>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
Message-ID: <CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>

On Fri, Oct 21, 2011 at 8:42 AM, David Farmer <farmer at umn.edu> wrote:
> once you scratch the surface and start looking at how
> such a policy will work from a practical point of view things get ugly very
> fast and it no longer looks as fair as it did on the surface.

David,

I make the same claim about the text on the table. We could argue for
days whether overall it's more or less fair than making a registrant
meet both RIR's policies, but at the end of the argument the truth
remains that the text on the table is not fair to would-be ARIN-region
recipients.

Would it be unreasonable to suggest that any unavoidable unfairness in
this, ARIN's process, be weighted in favor of ARIN's registrants
rather than against them?

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 cja at daydream.com  Fri Oct 21 09:57:58 2011
From: cja at daydream.com (CJ Aronson)
Date: Fri, 21 Oct 2011 07:57:58 -0600
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
Message-ID: <CAMvf=7bfx+-tzcV5=z-jxPcMaT9r_Sd_HTsn7vp-u5oRw4kXKg@mail.gmail.com>

Bill,

I have a question for you. Right now ARIN's policy is sometimes stricter
than in other regions.  Having gotten address space in the past from ARIN,
RIPE and APNIC this could seriously be debated but the perception is that
ARIN is more difficult. This is based on the policies developed in this
region for the acquisition of address space.  Do you want to make those
policies less restrictive for transfers than for getting address space from
the free pool?

I feel that there would be a huge public outcry if another region changed
their needs based policy specifically for transfers to make it easier than
their regular needs based policy for getting space from whatever free pool
they have left.  APNIC has a policy in last call right now to specifically
add needs basis back in (in essence making their policy more stringent) so
that they can be compatible and get transfers from this region.

I am interested in peoples' thoughts on this.  Should we have two different
justifications for need, one for transfers and one for the free pool?

Thanks!
-----Cathy



On Fri, Oct 21, 2011 at 7:35 AM, William Herrin <bill at herrin.us> wrote:

> On Fri, Oct 21, 2011 at 8:42 AM, David Farmer <farmer at umn.edu> wrote:
> > once you scratch the surface and start looking at how
> > such a policy will work from a practical point of view things get ugly
> very
> > fast and it no longer looks as fair as it did on the surface.
>
> David,
>
> I make the same claim about the text on the table. We could argue for
> days whether overall it's more or less fair than making a registrant
> meet both RIR's policies, but at the end of the argument the truth
> remains that the text on the table is not fair to would-be ARIN-region
> recipients.
>
> Would it be unreasonable to suggest that any unavoidable unfairness in
> this, ARIN's process, be weighted in favor of ARIN's registrants
> rather than against them?
>
> 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/20111021/4fc41e60/attachment.htm>

From mike at nationwideinc.com  Fri Oct 21 10:44:35 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Fri, 21 Oct 2011 10:44:35 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN
	Inter-RIRTransfers - Last Call
In-Reply-To: <CAMvf=7bfx+-tzcV5=z-jxPcMaT9r_Sd_HTsn7vp-u5oRw4kXKg@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.
	wustl.edu><F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com><CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail
	.com><9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com><CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com><4EA1
	689B.10006@umn.edu><CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<CAMvf=7bfx+-tzcV5=z-jxPcMaT9r_Sd_HTsn7vp-u5oRw4kXKg@mail.gmail.com>
Message-ID: <3C1442548AC24C969B810843BAF661D7@MPC>

IMO, yes, there should be a stringent justification for need for free pool addresses, and no need justification for transfers, as long as we prevent gaming the system through simple expedients like preventing transfers of addresses from those who have tapped the free pool less than a year ago, and limiting needs-free transfers to less than a /12 per year.

It?s the insistence on maintaining control of addresses already allocated from the free pool which is the cause of all this consternation over the inter-regional transfers.

Once addresses have a monetary value, there is no need for stewards to maintain a needs test, since the market will naturally provide efficient use of transferred addresses.

Once again, Prop-151 would moot this discussion.

Regards,

Mike Burns


From: CJ Aronson 
Sent: Friday, October 21, 2011 9:57 AM
To: William Herrin 
Cc: arin-ppml at arin.net 
Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIRTransfers - Last Call

Bill, 

I have a question for you. Right now ARIN's policy is sometimes stricter than in other regions.  Having gotten address space in the past from ARIN, RIPE and APNIC this could seriously be debated but the perception is that ARIN is more difficult. This is based on the policies developed in this region for the acquisition of address space.  Do you want to make those policies less restrictive for transfers than for getting address space from the free pool?   

I feel that there would be a huge public outcry if another region changed their needs based policy specifically for transfers to make it easier than their regular needs based policy for getting space from whatever free pool they have left.  APNIC has a policy in last call right now to specifically add needs basis back in (in essence making their policy more stringent) so that they can be compatible and get transfers from this region.  

I am interested in peoples' thoughts on this.  Should we have two different justifications for need, one for transfers and one for the free pool? 

Thanks!
-----Cathy




On Fri, Oct 21, 2011 at 7:35 AM, William Herrin <bill at herrin.us> wrote:

  On Fri, Oct 21, 2011 at 8:42 AM, David Farmer <farmer at umn.edu> wrote:
  > once you scratch the surface and start looking at how
  > such a policy will work from a practical point of view things get ugly very
  > fast and it no longer looks as fair as it did on the surface.


  David,

  I make the same claim about the text on the table. We could argue for
  days whether overall it's more or less fair than making a registrant
  meet both RIR's policies, but at the end of the argument the truth
  remains that the text on the table is not fair to would-be ARIN-region
  recipients.

  Would it be unreasonable to suggest that any unavoidable unfairness in
  this, ARIN's process, be weighted in favor of ARIN's registrants
  rather than against them?


  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.




--------------------------------------------------------------------------------
_______________________________________________
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/20111021/60d99a9b/attachment.htm>

From jcurran at arin.net  Fri Oct 21 11:17:56 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Oct 2011 15:17:56 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN
 Inter-RIRTransfers - Last Call
In-Reply-To: <3C1442548AC24C969B810843BAF661D7@MPC>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<"4EA1 689B.10006"@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<CAMvf=7bfx+-tzcV5=z-jxPcMaT9r_Sd_HTsn7vp-u5oRw4kXKg@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
Message-ID: <8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>

On Oct 21, 2011, at 10:44 AM, Mike Burns wrote:

IMO, yes, there should be a stringent justification for need for free pool addresses, and no need justification for transfers, as long as we prevent gaming the system through simple expedients like preventing transfers of addresses from those who have tapped the free pool less than a year ago, and limiting needs-free transfers to less than a /12 per year.

Mike -

    A party which requests assignments from ARIN's free pool
    based on documented need, and then subsequently attempts
    to transfer them within 12 months is likely to be considered
    an attempt at number resource fraud under existing policy
    (as they filed documentation which explained their need and
    which they now no longer have, but now replaced by a desire
    for monetization of the obtained resources)   ARIN is highly
    likely to initiate NRPM 12 resource review to confirm that the
    original request for resources was not fraudulent in nature.

    I cannot state the converse is true (a party which transfers
    addresses suddenly having developed a new need for more
    addresses because of changing circumstances)  We would
    obviously carefully evaluate the request, but are unlikely to
    be able to prevent making an otherwise valid assignment
    without specific policy guidance which prevents that form
    of "gaming the system".  I do not know if such policy would
    be desirable but note it for completeness in consideration of
    the proposed draft policy.

FYI,
/John

John Curran
President and CEO
ARIN

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

From bill at herrin.us  Fri Oct 21 11:23:56 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 21 Oct 2011 11:23:56 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN Inter-RIR
 Transfers - Last Call
In-Reply-To: <CAMvf=7bfx+-tzcV5=z-jxPcMaT9r_Sd_HTsn7vp-u5oRw4kXKg@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.wustl.edu>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<CAMvf=7bfx+-tzcV5=z-jxPcMaT9r_Sd_HTsn7vp-u5oRw4kXKg@mail.gmail.com>
Message-ID: <CAP-guGV2o8TpwuFXegLr8DzLjtYW-89CX5-JWhm3vbwry_O_9w@mail.gmail.com>

On Fri, Oct 21, 2011 at 9:57 AM, CJ Aronson <cja at daydream.com> wrote:
> I have a question for you. Right now ARIN's policy is sometimes stricter
> than in other regions. ?Having gotten address space in the past from ARIN,
> RIPE and APNIC this could seriously be debated but the perception is that
> ARIN is more difficult. This is based on the policies developed in this
> region for the acquisition of address space. ?Do you want to make those
> policies less restrictive for transfers than for getting address space from
> the free pool?

Hi Cathy,

I really haven't made up my mind on the question. Post free pool, I
think there's some merit to the proposition that dollars and sense is
sufficient to assure efficient utilization by the recipient. But we
aren't post-free-pool yet, we haven't made new free pool assignments
off-limits to transfers and regardless that's a larger debate than
adding inter-region transfers to our existing in-region transfer
process.

> I am interested in peoples' thoughts on this.  Should we have two different
> justifications for need, one for transfers and one for the free pool?

As long as there's a free pool (or at least a free pool that isn't
*very* tightly restricted) I tend to think it's better to have the
same standard for both free pool and transfer recipients.

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 mike at nationwideinc.com  Fri Oct 21 11:44:16 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Fri, 21 Oct 2011 11:44:16 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
	ARINInter-RIRTransfers - Last Call
In-Reply-To: <8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com><EACF8B735E9CBA4B8BAF9E4165D03087915BCC@ex1.cait.
	wustl.edu><F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com><CAAAwwbVsVHoTUbDq2G8XebHsRJfAQz5k4Ot1qaeVrUYoNKMD+Q@mail.gmail
	.com><9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com><CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<"4EA1689B.10006"@umn.edu><CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com><CAMvf=7bfx+-tzcV5=z-jxPcMaT9r_Sd
	_HTsn7vp-u5oRw4kXKg@mail.gmail.com><3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
Message-ID: <D67DFABA981C4F56ADD781618C4FC246@MPC>

Hi John,

Thanks, then the effect of current policy would be to prevent people from acquiring space from the free pool and then selling it within a year.
All to the good.

In that case I will simply say in answer to Cathy that I support stringent needs tests for free pool allocations and no needs test for all transfers, within and outside our region.
This would put ARIN members on an equal footing with the rest of the world and assuage the doubts Bill Herrin rightly has about fairness, should another RIR change policies to remove or reduce needs tests.

In the converse case you present, I would support a policy whereby those who sell addresses may not tap the free pool again, even if their needs change and they have a justifiable need.
Let them get their new addresses from the transfer market.

But I don?t want to take this discussion off the rails.

Let me say to Bill and others that should another RIR decide to remove or reduce needs tests for transfers, leaving ARIN members at an unfair disadvantage, the expedient solution is to have ARIN drop their needs requirements for transfers, restoring fairness. 

Regards,
Mike


From: John Curran 
Sent: Friday, October 21, 2011 11:17 AM
To: Mike Burns 
Cc: CJ Aronson ; William Herrin ; arin-ppml at arin.net 
Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARINInter-RIRTransfers - Last Call

On Oct 21, 2011, at 10:44 AM, Mike Burns wrote:


  IMO, yes, there should be a stringent justification for need for free pool addresses, and no need justification for transfers, as long as we prevent gaming the system through simple expedients like preventing transfers of addresses from those who have tapped the free pool less than a year ago, and limiting needs-free transfers to less than a /12 per year.

Mike - 

    A party which requests assignments from ARIN's free pool
    based on documented need, and then subsequently attempts 
    to transfer them within 12 months is likely to be considered
    an attempt at number resource fraud under existing policy
    (as they filed documentation which explained their need and 
    which they now no longer have, but now replaced by a desire
    for monetization of the obtained resources)   ARIN is highly
    likely to initiate NRPM 12 resource review to confirm that the
    original request for resources was not fraudulent in nature.

    I cannot state the converse is true (a party which transfers
    addresses suddenly having developed a new need for more
    addresses because of changing circumstances)  We would
    obviously carefully evaluate the request, but are unlikely to
    be able to prevent making an otherwise valid assignment
    without specific policy guidance which prevents that form 
    of "gaming the system".  I do not know if such policy would
    be desirable but note it for completeness in consideration of
    the proposed draft policy.

FYI,
/John

John Curran
President and CEO
ARIN
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111021/b45bae47/attachment.htm>

From randy.whitney at verizon.com  Fri Oct 21 12:16:00 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Fri, 21 Oct 2011 12:16:00 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
	<CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>
Message-ID: <4EA19AC0.9020701@verizon.com>

On 10/20/2011 3:58 PM, William Herrin wrote:
> On Thu, Oct 20, 2011 at 3:04 PM, Scott Leibrand<scottleibrand at gmail.com>  wrote:
>> But I was hoping you (and anyone else with ideas) could provide actual
>> constructive feedback on how the text could be improved.  If such
>> suggestions are being provided here on list, we can discuss whether they are
>> potential improvements we should incorporate.
>
> Hi Scott,
>
> 1. Pull it out of section 8.3 and put it in its own section 8.4. At no
> time in the process do I recall the community express a desire to
> tamper with section 8.3 as part of the inter-region transfer process.
> While such integration may become desirable in the future it is, IMHO,
> not desirable now. We should implement, learn from and tune the
> inter-region policy long before considering whether or how to
> integrate it with the in-region transfer policy.

I see no problem leaving it in 8.3 for now. Perhaps you can write this
into a subsequent proposal recommending to spin it off into a new section.

> 2. Earlier drafts required potential recipients to meet the
> eligibility criteria set by BOTH regions. While this increases the
> hassle factor associated with transferring addresses in or out of the
> region, I believe it provides a valuable safeguard for this, our first
> attempt at inter-region transfers. If, over time, we find that it's
> all hassle for no benefit, we can remove it.

I have to disagree with this. If both RIRs have implemented "compatible,
needs-based policies" there is no point in having the recipient run the
gauntlet twice, complicating and extending the transfers process.

> 3. Who determines that ARIN and another RIR "share compatible,
> needs-based policies?" Unless we set out explicit criteria, this is an
> open-ended policy-level question which should be decided by
> policy-level people, i.e. the Board. NOT by staff. I offered this
> criticism on the earlier drafts as well and I'm disappointed to see it
> hasn't been addressed.

Would you recommend more specific text here? How about something like
"share compatible needs-based policies as determined by the
[AC|Board|NRO|ICANN|POTUS]"? Perhaps the wording should be more concrete
as to the party who determines whether policies are compatible, but not
as to the point of defining explicit criteria determining compatible
policies.

>>   If not, the choice is between
>> moving forward or delaying.  I'm not sure how delaying another 6 months
>> helps.

I agree. Delaying until the next meeting would not look good. I'll
repeat my first statement of support: I believe we should adopt the
policy, warts and all. To which I will also assert: further alterations
should be addressed through new policy proposals.

Best Regards,
Randy.



From springer at inlandnet.com  Fri Oct 21 12:35:26 2011
From: springer at inlandnet.com (John Springer)
Date: Fri, 21 Oct 2011 09:35:26 -0700 (PDT)
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4EA19AC0.9020701@verizon.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
	<CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>
	<4EA19AC0.9020701@verizon.com>
Message-ID: <20111021092857.U53574@mail.inlandnet.com>

inline

On Fri, 21 Oct 2011, Randy Whitney wrote:

> On 10/20/2011 3:58 PM, William Herrin wrote:
>> On Thu, Oct 20, 2011 at 3:04 PM, Scott Leibrand<scottleibrand at gmail.com> 
>> wrote:

<snip>

>>>   If not, the choice is between
>>> moving forward or delaying.  I'm not sure how delaying another 6 months
>>> helps.
>
> I agree. Delaying until the next meeting would not look good. I'll
> repeat my first statement of support: I believe we should adopt the
> policy, warts and all. To which I will also assert: further alterations
> should be addressed through new policy proposals.
>
> Best Regards,
> Randy.

This is a central matter, I very much agree.

John Springer

____________________________________________
> 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 mike at nationwideinc.com  Fri Oct 21 12:36:33 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Fri, 21 Oct 2011 12:36:33 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4EA19AC0.9020701@verizon.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com><CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cP
	Fqg@mail.gmail.com><CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com><CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqd
	xJ3mAot=Yb2A@mail.gmail.com> <4EA19AC0.9020701@verizon.com>
Message-ID: <89EEA9ACB1AB447E8ECFF0F649C2FF91@MPC>

I agree with Randy's sentiments and support adoption of the policy.

Regards,

Mike

-----Original Message----- 
From: Randy Whitney
Sent: Friday, October 21, 2011 12:16 PM
To: William Herrin
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call

On 10/20/2011 3:58 PM, William Herrin wrote:
> On Thu, Oct 20, 2011 at 3:04 PM, Scott Leibrand<scottleibrand at gmail.com> 
> wrote:
>> But I was hoping you (and anyone else with ideas) could provide actual
>> constructive feedback on how the text could be improved.  If such
>> suggestions are being provided here on list, we can discuss whether they 
>> are
>> potential improvements we should incorporate.
>
> Hi Scott,
>
> 1. Pull it out of section 8.3 and put it in its own section 8.4. At no
> time in the process do I recall the community express a desire to
> tamper with section 8.3 as part of the inter-region transfer process.
> While such integration may become desirable in the future it is, IMHO,
> not desirable now. We should implement, learn from and tune the
> inter-region policy long before considering whether or how to
> integrate it with the in-region transfer policy.

I see no problem leaving it in 8.3 for now. Perhaps you can write this
into a subsequent proposal recommending to spin it off into a new section.

> 2. Earlier drafts required potential recipients to meet the
> eligibility criteria set by BOTH regions. While this increases the
> hassle factor associated with transferring addresses in or out of the
> region, I believe it provides a valuable safeguard for this, our first
> attempt at inter-region transfers. If, over time, we find that it's
> all hassle for no benefit, we can remove it.

I have to disagree with this. If both RIRs have implemented "compatible,
needs-based policies" there is no point in having the recipient run the
gauntlet twice, complicating and extending the transfers process.

> 3. Who determines that ARIN and another RIR "share compatible,
> needs-based policies?" Unless we set out explicit criteria, this is an
> open-ended policy-level question which should be decided by
> policy-level people, i.e. the Board. NOT by staff. I offered this
> criticism on the earlier drafts as well and I'm disappointed to see it
> hasn't been addressed.

Would you recommend more specific text here? How about something like
"share compatible needs-based policies as determined by the
[AC|Board|NRO|ICANN|POTUS]"? Perhaps the wording should be more concrete
as to the party who determines whether policies are compatible, but not
as to the point of defining explicit criteria determining compatible
policies.

>>   If not, the choice is between
>> moving forward or delaying.  I'm not sure how delaying another 6 months
>> helps.

I agree. Delaying until the next meeting would not look good. I'll
repeat my first statement of support: I believe we should adopt the
policy, warts and all. To which I will also assert: further alterations
should be addressed through new policy proposals.

Best Regards,
Randy.

_______________________________________________
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  Fri Oct 21 13:21:58 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 21 Oct 2011 13:21:58 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4EA19AC0.9020701@verizon.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
	<CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>
	<4EA19AC0.9020701@verizon.com>
Message-ID: <CAP-guGWeoiomxkKg5dKJsG4nvmqthFhZU7-wE2yHxr8v_7pd9g@mail.gmail.com>

On Fri, Oct 21, 2011 at 12:16 PM, Randy Whitney
<randy.whitney at verizon.com> wrote:
> On 10/20/2011 3:58 PM, William Herrin wrote:
>> 2. Earlier drafts required potential recipients to meet the
>> eligibility criteria set by BOTH regions. While this increases the
>> hassle factor associated with transferring addresses in or out of the
>> region, I believe it provides a valuable safeguard for this, our first
>> attempt at inter-region transfers. If, over time, we find that it's
>> all hassle for no benefit, we can remove it.
>
> I have to disagree with this. If both RIRs have implemented "compatible,
> needs-based policies" there is no point in having the recipient run the
> gauntlet twice, complicating and extending the transfers process.

Randy,

See John Curran's explanation of what ARIN will consider to be a
"compatible needs-based policy." As I understand it, a policy to the
effect of, "You must demonstrate that your operations will require the
use of these IP addresses within the next 50 years" IS a compatible
needs-based policy as ARIN understands the phrase, although "You must
claim that you will use the IP addresses within the next 50 years" is
not.


>> 3. Who determines that ARIN and another RIR "share compatible,
>> needs-based policies?" Unless we set out explicit criteria, this is an
>> open-ended policy-level question which should be decided by
>> policy-level people, i.e. the Board. NOT by staff. I offered this
>> criticism on the earlier drafts as well and I'm disappointed to see it
>> hasn't been addressed.
>
> Would you recommend more specific text here? How about something like
> "share compatible needs-based policies as determined by the
> [AC|Board|NRO|ICANN|POTUS]"?

I did, way back when. I suggested "share compatible needs-based
policies as unanimously determined by the board of trustees" or
something to that effect.

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 Oct 21 14:37:56 2011
From: farmer at umn.edu (David Farmer)
Date: Fri, 21 Oct 2011 13:37:56 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <CAP-guGWeoiomxkKg5dKJsG4nvmqthFhZU7-wE2yHxr8v_7pd9g@mail.gmail.com>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
	<CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>
	<4EA19AC0.9020701@verizon.com>
	<CAP-guGWeoiomxkKg5dKJsG4nvmqthFhZU7-wE2yHxr8v_7pd9g@mail.gmail.com>
Message-ID: <4EA1BC04.6020601@umn.edu>



On 10/21/11 12:21 CDT, William Herrin wrote:
> On Fri, Oct 21, 2011 at 12:16 PM, Randy Whitney
> <randy.whitney at verizon.com>  wrote:
>> On 10/20/2011 3:58 PM, William Herrin wrote:
...
>>> 3. Who determines that ARIN and another RIR "share compatible,
>>> needs-based policies?" Unless we set out explicit criteria, this is an
>>> open-ended policy-level question which should be decided by
>>> policy-level people, i.e. the Board. NOT by staff. I offered this
>>> criticism on the earlier drafts as well and I'm disappointed to see it
>>> hasn't been addressed.
>>
>> Would you recommend more specific text here? How about something like
>> "share compatible needs-based policies as determined by the
>> [AC|Board|NRO|ICANN|POTUS]"?
>
> I did, way back when. I suggested "share compatible needs-based
> policies as unanimously determined by the board of trustees" or
> something to that effect.

As long as the text makes it clear that the board only does this once 
and then reviews things when the policy of another RIR changes or 
someone calls another RIR's implementation of policy into question, I 
could support with something like this.  But if it essentially turns 
into the Board having to approve each individual transfer, that just 
won't work.

-- 
===============================================
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 jcurran at arin.net  Fri Oct 21 14:50:24 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Oct 2011 18:50:24 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4EA1BC04.6020601@umn.edu>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
	<CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>
	<4EA19AC0.9020701@verizon.com>
	<CAP-guGWeoiomxkKg5dKJsG4nvmqthFhZU7-wE2yHxr8v_7pd9g@mail.gmail.com>
	<4EA1BC04.6020601@umn.edu>
Message-ID: <6A8BF167-1785-4566-9F3E-6A98E7A8D03D@arin.net>

On Oct 21, 2011, at 2:37 PM, David Farmer wrote:
> As long as the text makes it clear that the board only does this once and then reviews things when the policy of another RIR changes or someone calls another RIR's implementation of policy into question, I could support with something like this.  But if it essentially turns into the Board having to approve each individual transfer, that just won't work.

Correct.  It will be the former; i.e. ARIN will maintain 
a list of RIR's with compatible transfer policies.

FYI,
/John

John Curran
President and CEO
ARIN





From JOHN at egh.com  Fri Oct 21 15:04:46 2011
From: JOHN at egh.com (John Santos)
Date: Fri, 21 Oct 2011 15:04:46 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN
	Inter-RIRTransfers - Last Call
In-Reply-To: <3C1442548AC24C969B810843BAF661D7@MPC>
Message-ID: <1111021144842.416H-100000@Ives.egh.com>


Mike Burns wrote:

IMO, yes, there should be a stringent justification for need for free pool
addresses, and no need justification for transfers, as long as we prevent
gaming the system through simple expedients like preventing transfers of
addresses from those who have tapped the free pool less than a year ago, and
limiting needs-free transfers to less than a /12 per year.

Itbs the insistence on maintaining control of addresses already allocated
from the free pool which is the cause of all this consternation over the
inter-regional transfers.

Once addresses have a monetary value, there is no need for stewards to 
maintain
a needs test, since the market will naturally provide efficient use of
transferred addresses.

Once again, Prop-151 would moot this discussion.

Regards,

Mike Burns

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

I think the essential difference is that the market defines "need" as 
"something someone is willing to spend money on", while ARIN defines "need"
in terms of technical requirements.  Conflating the two definitions of
need and treating them as equivalent doesn't help matters at all.

In market terms, "need" includes "I need to buy a yacht, and successfully
speculating in IPv4 addresses will allow me to do that."  

This is definitely not a justification that would work to prove "need"
to ARIN for a free pool allocation.

Also, a market (even a restricted market) defines "relative need" as
"who is willing to pay the most for a limited resource."  This could
potentially shut out "poor" organizations that have limited monetary
resources, such as educational institutions, non-profits, and third-world 
countries.

Since the Internet depends to some extent on such organizations for
new development (such as open source software, game-changing experiments,
and so on), we would be shooting ourselves in the foot to limit this.)
On the other hand, 1) I hope at this point most such developments are
using or trending to IPv6, and so don't care much about IPv4 policy,
and 2) I'm pretty sure that the cost of IP transport is much greater 
than the cost of IP address space, so even if the cost goes way up in
a market, this would be a minor effect.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

From mike at nationwideinc.com  Fri Oct 21 15:31:11 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Fri, 21 Oct 2011 15:31:11 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN
	Inter-RIRTransfers - Last Call
In-Reply-To: <1111021144842.416H-100000@Ives.egh.com>
References: <1111021144842.416H-100000@Ives.egh.com>
Message-ID: <669BA1A0B8E44F3FA6B93975E26E9B4E@MPC>

Hi John,

Once the free pool depletes, the only available addresses will be in the 
transfer market.
At that point the poor organizations will be shut out, regardless of their 
need.
Speculators could be limited by the /12 maximum I mentioned, and more 
importantly by the uncertain IPv6 transition timeframe.

The market definition of need that you assert ("something someone is willing 
to spend money on") will serve the same stewardship requirements as does a 
needs justification for free pool allocations, to wit efficient usage.

I will say no more about the issue in this thread, I think it too 
diversionary and the passage of this policy too important to be sidetracked.

I understand ARIN will maintain a list of RIRs with "compatible" policies.
It will be a short list, and if policy changes substantially at another RIR 
which puts ARIN  members at a relative disadvantage, we can discuss the 
issue further and tweak policy then if necessary.

I support passage of 2011-1.

Regards,

MIke





-----Original Message----- 
From: John Santos
Sent: Friday, October 21, 2011 3:04 PM
To: Mike Burns
Cc: CJ Aronson ; William Herrin ; arin-ppml at arin.net
Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN 
Inter-RIRTransfers - Last Call


Mike Burns wrote:

IMO, yes, there should be a stringent justification for need for free pool
addresses, and no need justification for transfers, as long as we prevent
gaming the system through simple expedients like preventing transfers of
addresses from those who have tapped the free pool less than a year ago, and
limiting needs-free transfers to less than a /12 per year.

Itbs the insistence on maintaining control of addresses already allocated
from the free pool which is the cause of all this consternation over the
inter-regional transfers.

Once addresses have a monetary value, there is no need for stewards to
maintain
a needs test, since the market will naturally provide efficient use of
transferred addresses.

Once again, Prop-151 would moot this discussion.

Regards,

Mike Burns

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

I think the essential difference is that the market defines "need" as
"something someone is willing to spend money on", while ARIN defines "need"
in terms of technical requirements.  Conflating the two definitions of
need and treating them as equivalent doesn't help matters at all.

In market terms, "need" includes "I need to buy a yacht, and successfully
speculating in IPv4 addresses will allow me to do that."

This is definitely not a justification that would work to prove "need"
to ARIN for a free pool allocation.

Also, a market (even a restricted market) defines "relative need" as
"who is willing to pay the most for a limited resource."  This could
potentially shut out "poor" organizations that have limited monetary
resources, such as educational institutions, non-profits, and third-world
countries.

Since the Internet depends to some extent on such organizations for
new development (such as open source software, game-changing experiments,
and so on), we would be shooting ourselves in the foot to limit this.)
On the other hand, 1) I hope at this point most such developments are
using or trending to IPv6, and so don't care much about IPv4 policy,
and 2) I'm pretty sure that the cost of IP transport is much greater
than the cost of IP address space, so even if the cost goes way up in
a market, this would be a minor effect.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539 



From jcurran at arin.net  Fri Oct 21 16:04:58 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Oct 2011 20:04:58 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARIN
 Inter-RIRTransfers - Last Call
In-Reply-To: <1111021144842.416H-100000@Ives.egh.com>
References: <1111021144842.416H-100000@Ives.egh.com>
Message-ID: <1612F810-3F3B-41BE-8309-BC39DA7D30C4@arin.net>

On Oct 21, 2011, at 3:04 PM, John Santos wrote:

> I think the essential difference is that the market defines "need" as 

> "something someone is willing to spend money on", while ARIN defines "need"
> in terms of technical requirements.  Conflating the two definitions of
> need and treating them as equivalent doesn't help matters at all.
> 
> In market terms, "need" includes "I need to buy a yacht, and successfully
> speculating in IPv4 addresses will allow me to do that."  
> 
> This is definitely not a justification that would work to prove "need"
> to ARIN for a free pool allocation.

Correct. ARIN's use of the term "need" is actually a reference 
to "operational needs" as expressed in RFC 2050:

1) Conservation: Fair distribution of globally unique Internet address
   space according to the operational needs of the end-users and Internet
   Service Providers operating networks using this address space.

FYI,
/John

John Curran
President and CEO
ARIN



From bill at herrin.us  Fri Oct 21 16:59:49 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 21 Oct 2011 16:59:49 -0400
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4EA1BC04.6020601@umn.edu>
References: <CAGkMwz58zdovX8ztWFkp4LU4cybLFPkRdv0SMAjhK1NkWOL80Q@mail.gmail.com>
	<CAMDXq5OV8XNXgyJFNRGPtB-XpEgqvcFrCtpKiRJGZ-yn4cPFqg@mail.gmail.com>
	<CAGkMwz6zVy0AuY7AXaanzrm+sYmeiAHcW6WwTbiZRAuqQHQHnw@mail.gmail.com>
	<CAP-guGVQABJzEGVeNYMxGNrraAdqRVLiX0SGqdxJ3mAot=Yb2A@mail.gmail.com>
	<4EA19AC0.9020701@verizon.com>
	<CAP-guGWeoiomxkKg5dKJsG4nvmqthFhZU7-wE2yHxr8v_7pd9g@mail.gmail.com>
	<4EA1BC04.6020601@umn.edu>
Message-ID: <CAP-guGUAxDpHN8W35QMFgvq26HSKQRiPPqi8jj+bWBratagW0A@mail.gmail.com>

On Fri, Oct 21, 2011 at 2:37 PM, David Farmer <farmer at umn.edu> wrote:
> On 10/21/11 12:21 CDT, William Herrin wrote:
>> On Fri, Oct 21, 2011 at 12:16 PM, Randy Whitney
>> <randy.whitney at verizon.com> ?wrote:
>>> On 10/20/2011 3:58 PM, William Herrin wrote:
>>>> 3. Who determines that ARIN and another RIR "share compatible,
>>>> needs-based policies?"
>>> Would you recommend more specific text here? How about something like
>>> "share compatible needs-based policies as determined by the
>>> [AC|Board|NRO|ICANN|POTUS]"?
>>
>> I did, way back when. I suggested "share compatible needs-based
>> policies as unanimously determined by the board of trustees" or
>> something to that effect.
>
> As long as the text makes it clear that the board only does this once and
> then reviews things when the policy of another RIR changes or someone calls
> another RIR's implementation of policy into question, I could support with
> something like this. ?But if it essentially turns into the Board having to
> approve each individual transfer, that just won't work.

Hi David,

ARIN interprets policy text in the least restrictive way that still
makes any sense. They have to or they'll be sued. So they'd interpret
it to mean that transfers do not need individual board approvals but
RIRs need compatible-policy certifications by the board.

I would not object to making it explicit.

Regards,
Bill


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


From bill at herrin.us  Fri Oct 21 17:31:31 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 21 Oct 2011 17:31:31 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <D67DFABA981C4F56ADD781618C4FC246@MPC>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
Message-ID: <CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>

On Fri, Oct 21, 2011 at 11:44 AM, Mike Burns <mike at nationwideinc.com> wrote:
> In the converse case you present, I would support a policy whereby those who
> sell addresses may not tap the free pool again, even if their needs change
> and they have a justifiable need.

Mike,

Impractical. $5k lets me stand up a new, independent legal entity that
can legitimately tap the free pool regardless of any other entity's
prior behavior. Done it for customers. Twice.


On Fri, Oct 21, 2011 at 11:17 AM, John Curran <jcurran at arin.net> wrote:
>     A party which requests assignments from ARIN's free pool
>     based on documented need, and then subsequently attempts
>     to transfer them within 12 months is likely to be considered
>     an attempt at number resource fraud under existing policy
>     (as they filed documentation which explained their need and
>     which they now no longer have, but now replaced by a desire
>     for monetization of the obtained resources)   ARIN is highly
>     likely to initiate NRPM 12 resource review to confirm that the
>     original request for resources was not fraudulent in nature.

John,

I am allocated a /16 for my 50,000 customer Smartphone business so I
can stop using my ISP's addresses. I configure the addresses on my
DHCP equipment which assigns them to each always-on smartphone. Fast
forward 30 days. Another company offers me $100,000 to convert all the
phones to carrier NAT and transfer the /16 to them. I accept. My
paperwork "proves" all this. Do I fail the audit?

I have a 50,000 customer Smartphone business. I use carrier NAT to
isolate them behind a few IP public addresses. I request a /16 so I
can assign real, global IP addresses to every always-on phone. Is my
request denied?

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  Fri Oct 21 17:56:26 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Oct 2011 21:56:26 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
Message-ID: <9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>

On Oct 21, 2011, at 5:31 PM, William Herrin wrote:

> I am allocated a /16 for my 50,000 customer Smartphone business so I
> can stop using my ISP's addresses. I configure the addresses on my
> DHCP equipment which assigns them to each always-on smartphone. Fast
> forward 30 days. Another company offers me $100,000 to convert all the
> phones to carrier NAT and transfer the /16 to them. I accept. My
> paperwork "proves" all this. Do I fail the audit?

Unless you somehow made fraudulent claim in requesting the addresses,
no number resource fraud would be found.  That seems unlikely based
on what you indicate above, but obviously the actual materials supplied 
in the original resource request would govern.

> I have a 50,000 customer Smartphone business. I use carrier NAT to
> isolate them behind a few IP public addresses. I request a /16 so I
> can assign real, global IP addresses to every always-on phone. Is my
> request denied?

Same theory, but quite likely different due to your statements vs 
actions.  You would have had to request the addresses because you 
_would be_ assigning public IP's to the smartphones (not just "can
assign such addresses to them") and did not do so, your request 
was approved based on false statements, and your addresses would be 
subject to being reclaimed.  That's okay, as your changing business
circumstances indicate you don't actually appear to need them anymore.

I hope the above example helps in the assessment of the proposed 
policy.

/John

John Curran
President and CEO
ARIN






From bill at herrin.us  Fri Oct 21 20:44:43 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 21 Oct 2011 20:44:43 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
Message-ID: <CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>

On Fri, Oct 21, 2011 at 5:56 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 21, 2011, at 5:31 PM, William Herrin wrote:
>> I am allocated a /16 for my 50,000 customer Smartphone business so I
>> can stop using my ISP's addresses. I configure the addresses on my
>> DHCP equipment which assigns them to each always-on smartphone. Fast
>> forward 30 days. Another company offers me $100,000 to convert all the
>> phones to carrier NAT and transfer the /16 to them. I accept. My
>> paperwork "proves" all this. Do I fail the audit?
>
> Unless you somehow made fraudulent claim in requesting the addresses,
> no number resource fraud would be found. ?That seems unlikely based
> on what you indicate above, but obviously the actual materials supplied
> in the original resource request would govern.

Thanks John,

So to summarize: I would find it difficult to be a repeat offender,
but as long as I dot my i's cross my t's and content myself with just
one grab, draft policy 2011-1 as presently written would enable me to
buy a Lexus by raiding the free pool and more or less immediately
selling the results out-region... to someone with no access to a free
pool operating under a much more permissive needs-based justification
than ARIN requires. And with little risk: at worst really just the
loss of the $4500 allocation fee.

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 Oct 21 21:18:13 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 21 Oct 2011 21:18:13 -0400
Subject: [arin-ppml] Gaming the system
Message-ID: <CAP-guGWoyGEGFE1mtL8YzYCQmfyYT-98xhi_pECFHOkksN_eSQ@mail.gmail.com>

On Fri, Oct 21, 2011 at 8:44 PM, William Herrin <bill at herrin.us> wrote:
> So to summarize: I would find it difficult to be a repeat offender,
> but as long as I dot my i's cross my t's and content myself with just
> one grab, draft policy 2011-1 as presently written would enable me to
> buy a Lexus by raiding the free pool and more or less immediately
> selling the results out-region... to someone with no access to a free
> pool operating under a much more permissive needs-based justification
> than ARIN requires. And with little risk: at worst really just the
> loss of the $4500 allocation fee.


If I may step aside from the 2011-1 rhetoric for a moment...

May I respectfully suggest that EVERY draft policy which crosses the
AC's desk and every proposed change to ARIN's process would benefit
from gaming an aggressive attempt to misuse it. I've seen a lot of
sloppy policy go through whose proponents are shocked, just shocked
when a Microsoft-Nortel incident comes along. If you *look* for the
holes and don't poo-poo the people who point them out to you, they're
not that hard to find or fix.

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 jsw at inconcepts.biz  Fri Oct 21 23:54:16 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Fri, 21 Oct 2011 23:54:16 -0400
Subject: [arin-ppml] Gaming the system
In-Reply-To: <CAP-guGWoyGEGFE1mtL8YzYCQmfyYT-98xhi_pECFHOkksN_eSQ@mail.gmail.com>
References: <CAP-guGWoyGEGFE1mtL8YzYCQmfyYT-98xhi_pECFHOkksN_eSQ@mail.gmail.com>
Message-ID: <CAPWAtb+8DQz_8fGwUuEL3s_T6GP-w6Ca9ASb1SgUz1mnMxmGcw@mail.gmail.com>

On Fri, Oct 21, 2011 at 9:18 PM, William Herrin <bill at herrin.us> wrote:
> May I respectfully suggest that EVERY draft policy which crosses the
> AC's desk and every proposed change to ARIN's process would benefit
> from gaming an aggressive attempt to misuse it.

You may have noticed my explanation of how many ISPs can easily
qualify for the maximum possible IPv6 allocation under 2011-3.  It is
not clear to me what happens once they have acquired two /12s.
Paragraph 6.5.3(d) is not explicit one way or the other.  If you read
the NANOG discussion about this, Owen DeLong points out that if it is
indeed abused, there should be plenty of opportunity to correct it;
but it is clear to me that your suggestion is a good idea.  Many
people were surprised that 2011-3 can be used by mid-sized ISPs to get
such huge allocations.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From jcurran at arin.net  Sat Oct 22 01:16:03 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 22 Oct 2011 05:16:03 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
Message-ID: <F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>

On Oct 21, 2011, at 8:44 PM, William Herrin wrote:

> On Fri, Oct 21, 2011 at 5:56 PM, John Curran <jcurran at arin.net> wrote:
>> Unless you somehow made fraudulent claim in requesting the addresses,
>> no number resource fraud would be found.  That seems unlikely based
>> on what you indicate above, but obviously the actual materials supplied
>> in the original resource request would govern.
> 
> Thanks John,
> 
> So to summarize: I would find it difficult to be a repeat offender,
> but as long as I dot my i's cross my t's and content myself with just
> one grab, draft policy 2011-1 as presently written would enable me to
> buy a Lexus by raiding the free pool and more or less immediately
> selling the results out-region... to someone with no access to a free
> pool operating under a much more permissive needs-based justification
> than ARIN requires. And with little risk: at worst really just the
> loss of the $4500 allocation fee.

If you follow through on using the assigned resources as
specified on the request, then no resource fraud would be
found.

This indeed means that parties with existing address space
could optimize their network address usage and monetize the 
result.  As long as the resources had been used operationally 
as specified, the subsequent optimization and transfer would
be allowable per policy (whether the resources were received
years, months, or weeks ago)   Note also that this potential 
concern exists in the existing NRPM 8.3 policy with respect 
to in-region transfers.

FYI,
/John

John Curran
President and CEO
ARIN




From rbf+arin-ppml at panix.com  Sat Oct 22 12:04:05 2011
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Sat, 22 Oct 2011 11:04:05 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
References: <CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
Message-ID: <20111022160405.GA18047@panix.com>

On Sat, Oct 22, 2011 at 05:16:03AM +0000, John Curran wrote:
> On Oct 21, 2011, at 8:44 PM, William Herrin wrote:
> 
> > So to summarize: I would find it difficult to be a repeat offender,
> > but as long as I dot my i's cross my t's and content myself with just
> > one grab, draft policy 2011-1 as presently written would enable me to
> > buy a Lexus by raiding the free pool and more or less immediately
> > selling the results out-region... to someone with no access to a free
> > pool operating under a much more permissive needs-based justification
> > than ARIN requires. And with little risk: at worst really just the
> > loss of the $4500 allocation fee.
> 
> If you follow through on using the assigned resources as
> specified on the request, then no resource fraud would be
> found.
> 
> This indeed means that parties with existing address space
> could optimize their network address usage and monetize the 
> result.  As long as the resources had been used operationally 
> as specified, the subsequent optimization and transfer would
> be allowable per policy (whether the resources were received
> years, months, or weeks ago)   

The point is that this appears to be loopable.  I start with a /16 of
SmartPhones behind NAT.  I request a /16 from ARIN to give all the
phones routable addresses.  As soon as I get the allocation, I promptly
use it -- I assign all the SmartPhones addresses from my new /16. 
Then, a few weeks later, I monetize the /16 and put the phones back
behind NAT.  No fraud -- I requested addresses for devices that really
existed, and I really did assign the addresses to those devices.

Now I'm back where I started, and I can do it all over again.

> Note also that this potential concern exists in the existing NRPM 8.3
> policy with respect to in-region transfers.

In-region, there's no motivation to do it.  The "loop" I describe above
only works if there are addresses in ARIN's free pool (because if
ARIN's pool is empty, obviously ARIN won't be allocating me any
addresses, regardless of my justification).  As long as there are
addresses in ARIN's free pool, there's no motivation for anyone
in-region to offer me $100K to go through the motions I describe 
above -- they can't transfer the addresses from me unless they can justify 
their need, and if they can justify their need, ARIN will allocate 
them addresses directly (and at a considerably lower price than buying 
the addresses from me).

But ... someone in a different region, where there is no free pool, has
no ability to get addresses directly from ARIN's free pool, because,
regardless of need, ARIN won't allocate to an organization in another
region.  So organizations in a region that has no free addresses
remaining can offer me (the hypothetical me described above -- I
actually have no SmartPhone business) $100K to un-NAT my phones, get
addresses from ARIN, re-NAT my phones, and sell the addresses.

     -- Brett


From jcurran at arin.net  Sat Oct 22 12:10:45 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 22 Oct 2011 16:10:45 +0000
Subject: [arin-ppml] 2011-1
In-Reply-To: <20111022160405.GA18047@panix.com>
References: <CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<20111022160405.GA18047@panix.com>
Message-ID: <5E2CAA6F-9E43-4173-830C-F4459D33A480@arin.net>

On Oct 22, 2011, at 12:04 PM, Brett Frankenberger wrote:
> 
> But ... someone in a different region, where there is no free pool, has
> no ability to get addresses directly from ARIN's free pool, because,
> regardless of need, ARIN won't allocate to an organization in another
> region.  So organizations in a region that has no free addresses
> remaining can offer me (the hypothetical me described above -- I
> actually have no SmartPhone business) $100K to un-NAT my phones, get
> addresses from ARIN, re-NAT my phones, and sell the addresses.

And if the organization is in a region where there is a 
need-based transfer policy, and they have actual operational
need for addresses which they can demonstrate to their RIR, 
and that RIR therefore approves the transfer, then indeed 
this can happen under the proposed policy text.  

FYI,
/John

John Curran
President and CEO
ARIN




From cgrundemann at gmail.com  Mon Oct 24 15:29:52 2011
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Mon, 24 Oct 2011 13:29:52 -0600
Subject: [arin-ppml] Post PPM Revision of ARIN-2011-7: Compliance Requirement
Message-ID: <CAC1-dtkW6YU4EGkuoFNgLeDFSV+-a5e8MvxpASAX8JWFwN3+QQ@mail.gmail.com>

Hello,

As the primary shepherd of draft policy ARIN-2011-7: Compliance
Requirement, I took your feedback from the Public Policy Meeting in
Philadelphia and revised the text. I believe that this new text
continues to meet the originators intentions while also addressing all
significant concerns raised thus far. Please let me know what you
think. If there are no major objections from the community here, I
plan to recommend this policy for last call at the next AC meeting.

New text:

----8<----8<----8<----

12.4 - Update to:
Organizations found by ARIN to be out of compliance with current ARIN
policy shall be required to update reassignment information or return
resources as needed to bring them into (or reasonably close to)
compliance.
1. The degree to which an organization may remain out of compliance
shall be based on the reasonable judgment of the ARIN staff and shall
balance all facts known, including the organization's utilization
rate, available address pool, and other factors as appropriate so as
to avoid forcing returns which will result in near-term additional
requests or unnecessary route de-aggregation.
2. To the extent possible, entire blocks should be returned. Partial
address blocks shall be returned in such a way that the portion
retained will comprise a single aggregate block.

12.5 - Update to:
Except in cases of fraud when immediate action can be taken, an
organization shall be given thirty (30) days to respond. If an
organization fails to respond within thirty (30) days, ARIN may cease
providing reverse DNS services to that organization. If progress of
resource returns or record corrections has not occurred within sixty
(60) days after ARIN initiated contact, ARIN shall cease providing
reverse DNS services for the resources in question. At any time ninety
(90) days after initial ARIN contact, ARIN may initiate the revocation
of any resources issued by ARIN as required to bring the organization
into overall compliance. ARIN may permit a longer period of time to
come into compliance, if ARIN believes the organization is working in
good faith to restore compliance with policy and has a valid need for
additional time to comply, including but not limited to renumbering
out of the affected blocks. ARIN shall follow the same guidelines for
revocation that are required for voluntary return in the previous
paragraph.

(leave 12.6 as is)

----8<----8<----8<----

Cheers,
~Chris


From bill at herrin.us  Mon Oct 24 17:42:03 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 24 Oct 2011 17:42:03 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
Message-ID: <CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>

On Sat, Oct 22, 2011 at 1:16 AM, John Curran <jcurran at arin.net> wrote:
> On Oct 21, 2011, at 8:44 PM, William Herrin wrote:
>> So to summarize: I would find it difficult to be a repeat offender,
>> but as long as I dot my i's cross my t's and content myself with just
>> one grab, draft policy 2011-1 as presently written would enable me to
>> buy a Lexus by raiding the free pool and more or less immediately
>> selling the results out-region... to someone with no access to a free
>> pool operating under a much more permissive needs-based justification
>> than ARIN requires. And with little risk: at worst really just the
>> loss of the $4500 allocation fee.
>
>If you follow through on using the assigned resources as
>specified on the request, then no resource fraud would be
>found.

Just in case there's anyone entertaining the idea that, "This isn't a
concern because no one with 50,000 smartphone customers would risk our
wrath," here's an alternate play that's strictly fly-by-night.

Stand up 16 legal entities, 1 each named after nearby public parks.
Install a solar-powered wifi hotspot at each park and backhaul them
(wirelessly of course) to two additional entities designed to be
BGP-speaking backhauls. I'm such a nice guy, I'll even make the park
wifi free to park patrons. While it's running anyway; reliability
isn't my priority.

For this modest investment, each of the 16 entities is now multihomed
and, as each park could easily host 150 wifi clients, can justify a
/24. Acquire addresses from the ARIN free pool and configure them on
the equipment. Drive around and make sure each site logs enough users
at least once to justify the full /24. I now hold 16 /24's and
documentation which fulfills my justified use obligation.

Sell them outregion to an entity that can't get /24's locally and
meets it's local RIR's nominal needs-based justification. Initiate
specified recipient transfers per 2011-1.

Upon completion of the transfer (including the ARIN audits in which
the documentation shows fulfillment of all the use justification thus
no fraud) tear down the wifi hotspots and terminate the organizations
created for them.

Stand up 16 more legal entities, named after a set of shopping mall
food courts. Rinse and repeat.

At $5/address this is not practical, but if addresses go for $20 each
this grosses $82k on an investment around $40k with a 3ish month
turnaround. So, double your money in three months with a by-the-book
raid on the ARIN free pool. And I'm sure this could be refined further
to either cut the cost or increase the block size from /24 so that
even at $5/address you could come out ahead.


> Note also that this potential
> concern exists in the existing NRPM 8.3 policy with respect
> to in-region transfers.

Without draft 2011-1 it does me limited good to acquire these
addresses. Any transferee will be in the ARIN region where they have
the same access I do to the remaining free pool and have to meet the
same justified use criteria that I do in order to receive addresses
either from the free pool or from me. I present the transferee no
value as a middleman.


Note that the board recognized the related-legal-entities issue a few
years ago, but IIRC they abandoned their attempt to address it,
possibly for lack of a usable legal framework. No joy to be found down
that blind alley and I imagine the prevailing view was that with a
strong needs justification applied independently to each legal entity
there was relatively little damage that could be done.

Regards,
Bill Herrin

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


From jcurran at arin.net  Mon Oct 24 18:03:38 2011
From: jcurran at arin.net (John Curran)
Date: Mon, 24 Oct 2011 22:03:38 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
Message-ID: <F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>

On Oct 24, 2011, at 9:42 PM, William Herrin wrote:

> Note that the board recognized the related-legal-entities issue a few
> years ago, but IIRC they abandoned their attempt to address it,
> possibly for lack of a usable legal framework. No joy to be found down
> that blind alley and I imagine the prevailing view was that with a
> strong needs justification applied independently to each legal entity
> there was relatively little damage that could be done.

Bill - 
 
  It's actually simpler than that... These "independent" entities
  with limited history are actually valid address recipients.
  We do our best to unveil companies which are entirely shell
  companies (and effectively deduplicate requests) but as long as
  there's policy which allows new parties to obtain address space, 
  these sorts of requests will occur.  Also note that having 
  policy that allows bona fide new entrants is an fundamental 
  expectation of any fair and equitable industry self-regulation.
  
  I agree that presently this new entrant "loophole" could
  potentially be exacerbated by an InterRIR transfer policy; 
  I just wanted to  make it clear that it may also be a serious
  problem as we approach in-region depletion in general.

FYI,
/John

John Curran
President and CEO
ARIN




From mike at nationwideinc.com  Mon Oct 24 18:43:46 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 24 Oct 2011 18:43:46 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
	ARIN-2011-1:ARINInter-RIRTransfers - Last Call
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com><F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom
	.com><9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com><CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com><4EA1
	689B.10006@umn.edu><CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com><3C1442548AC24C969B810843BAF661D7@MPC><8
	190263C-9923-4CAE-8D36-9F35D379119C@arin.net><D67DFABA981C4F56ADD781618C4FC246@MPC><CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrM
	U-195Ejw@mail.gmail.com><9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net><CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mai
	l.gmail.com><F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
Message-ID: <735EF76B2CC947B19A7D1CF10A86D75C@video>

Hi Bill,

We are talking about very public information here.

ARIN will know who the applicant was, what the blocks were, when they were 
applied for, why they were requested, when they were sold, and to whom they 
were sold.

How many times could you rinse/repeat this cycle before the activity became 
so evident that ARIN refused to authorize the transfer, and instead 
attempted reclamation due to fraud?

If there is something in the RSA which speaks to a declared intention of the 
applicant, engaging in the behavior you describe would display another 
intention entirely, and would rise to a level of fraud such that Section 12 
could be employed.

If these are shell entities, then you have to add the cost of creating and 
maintaining the shells, and most importantly, the risk cost of engaging in 
fraudulent contracts.

Since the transfers are done in the open, it wouldn't be too hard to spot 
patterns of abuse such as you describe, in fact ARIN would have a community 
of watch dogs with access to these transactions.

I agree that the Inter Regional transfer policy creates the motivations 
which would prompt such behavior, but we would be facing the same 
motivations here in less than five years anyway.

I agree that protections against fraud in obtaining addresses from the free 
pool will become increasingly important, and if there was some work in the 
past related to detecting related-legal-entities, it would be prudent to 
revisit that subject.

Bill, what would you think about preventing those who receive addresses from 
the free pool from selling addresses for some timeframe commencing at the 
time of their last allocation?

I believe a year's prohibition would crimp many of these kind of plans, but 
maybe it should be a shorter or longer time period?

I think that as addresses gain monetary value, analyzing the scammability of 
policies is vital.

Regards,

Mike




Just in case there's anyone entertaining the idea that, "This isn't a
concern because no one with 50,000 smartphone customers would risk our
wrath," here's an alternate play that's strictly fly-by-night.

Stand up 16 legal entities, 1 each named after nearby public parks.
Install a solar-powered wifi hotspot at each park and backhaul them
(wirelessly of course) to two additional entities designed to be
BGP-speaking backhauls. I'm such a nice guy, I'll even make the park
wifi free to park patrons. While it's running anyway; reliability
isn't my priority.

For this modest investment, each of the 16 entities is now multihomed
and, as each park could easily host 150 wifi clients, can justify a
/24. Acquire addresses from the ARIN free pool and configure them on
the equipment. Drive around and make sure each site logs enough users
at least once to justify the full /24. I now hold 16 /24's and
documentation which fulfills my justified use obligation.

Sell them outregion to an entity that can't get /24's locally and
meets it's local RIR's nominal needs-based justification. Initiate
specified recipient transfers per 2011-1.

Upon completion of the transfer (including the ARIN audits in which
the documentation shows fulfillment of all the use justification thus
no fraud) tear down the wifi hotspots and terminate the organizations
created for them.

Stand up 16 more legal entities, named after a set of shopping mall
food courts. Rinse and repeat.

At $5/address this is not practical, but if addresses go for $20 each
this grosses $82k on an investment around $40k with a 3ish month
turnaround. So, double your money in three months with a by-the-book
raid on the ARIN free pool. And I'm sure this could be refined further
to either cut the cost or increase the block size from /24 so that
even at $5/address you could come out ahead.


> Note also that this potential
> concern exists in the existing NRPM 8.3 policy with respect
> to in-region transfers.

Without draft 2011-1 it does me limited good to acquire these
addresses. Any transferee will be in the ARIN region where they have
the same access I do to the remaining free pool and have to meet the
same justified use criteria that I do in order to receive addresses
either from the free pool or from me. I present the transferee no
value as a middleman.


Note that the board recognized the related-legal-entities issue a few
years ago, but IIRC they abandoned their attempt to address it,
possibly for lack of a usable legal framework. No joy to be found down
that blind alley and I imagine the prevailing view was that with a
strong needs justification applied independently to each legal entity
there was relatively little damage that could be done.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
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 Oct 24 18:57:29 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 24 Oct 2011 18:57:29 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <735EF76B2CC947B19A7D1CF10A86D75C@video>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
Message-ID: <CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>

On Mon, Oct 24, 2011 at 6:43 PM, Mike Burns <mike at nationwideinc.com> wrote:
> How many times could you rinse/repeat this cycle before the activity became
> so evident that ARIN refused to authorize the transfer, and instead
> attempted reclamation due to fraud?

Hi Mike,

As many as you want until the Board adopts a policy which declares
defines such use illegitimate. If the policy says it isn't fraud then
it isn't fraud no matter how egregious. ARIN simply isn't allowed to
make it up as they go; they're bound by the policies. One problem with
2011-1 as presently drafted is that it takes some dubious activities
that current policy defines as "not fraud" and creates an only
moderately circuitous path to easy cash.


> I agree that protections against fraud in obtaining addresses from the free
> pool will become increasingly important, and if there was some work in the
> past related to detecting related-legal-entities, it would be prudent to
> revisit that subject.

I'll take counterpoint: protections will become unimportant relatively
quickly because we're nearly out of addresses in the ARIN free pool
too. Nevertheless, we need some protections _until_ events render
matter moot.


> Bill, what would you think about preventing those who receive addresses from
> the free pool from selling addresses for some timeframe commencing at the
> time of their last allocation?

Do we really want to lock unused or underused addresses out of play
for folks who DO meet ARIN's needs-justification when the whole point
of transfers is that we don't have enough addresses to go around?

Regards,
Bill Herrin


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


From bill at herrin.us  Mon Oct 24 19:05:44 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 24 Oct 2011 19:05:44 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
Message-ID: <CAP-guGXzHso5cEbW-7yfHDTkCyo16hPL9OMq4KoCDgKEZ5ObiA@mail.gmail.com>

On Mon, Oct 24, 2011 at 6:03 PM, John Curran <jcurran at arin.net> wrote:
>  I agree that presently this new entrant "loophole" could
>  potentially be exacerbated by an InterRIR transfer policy;
>  I just wanted to  make it clear that it may also be a serious
>  problem as we approach in-region depletion in general.

Hi John,

IMO frivolous use stockpiling is already a problem. But frankly, that
ship has sailed. We'll not find a suitable mitigation before the free
pool is gone. Every time the subject has come up, I've seen wide
disagreement as to what use is actually frivolous.


> ?Also note that having
> ?policy that allows bona fide new entrants is an fundamental
> ?expectation of any fair and equitable industry self-regulation.

I could not be in more complete agreement.

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  Mon Oct 24 19:04:45 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Oct 2011 16:04:45 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
	ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
Message-ID: <B8F1F2BA-F4EB-4ABC-B3E8-EE98B350ADF7@delong.com>

Sure, if we allow anything there will be corner cases.

Since the park scenario you describe is, also, a perfectly legitimate use of address space if the person actually intends to operate a community park wireless network, I'm not sure how you can expect to prevent such activity without also blocking legitimate activity.

I think caution is warranted, but I also believe that ARIN policy must permit all legitimate uses while precluding as many invalid uses as possible rather than prevent all invalid uses while permitting as many legitimate uses as possible.

Owen


Sent from my iPad

On Oct 24, 2011, at 2:42 PM, William Herrin <bill at herrin.us> wrote:

> On Sat, Oct 22, 2011 at 1:16 AM, John Curran <jcurran at arin.net> wrote:
>> On Oct 21, 2011, at 8:44 PM, William Herrin wrote:
>>> So to summarize: I would find it difficult to be a repeat offender,
>>> but as long as I dot my i's cross my t's and content myself with just
>>> one grab, draft policy 2011-1 as presently written would enable me to
>>> buy a Lexus by raiding the free pool and more or less immediately
>>> selling the results out-region... to someone with no access to a free
>>> pool operating under a much more permissive needs-based justification
>>> than ARIN requires. And with little risk: at worst really just the
>>> loss of the $4500 allocation fee.
>> 
>> If you follow through on using the assigned resources as
>> specified on the request, then no resource fraud would be
>> found.
> 
> Just in case there's anyone entertaining the idea that, "This isn't a
> concern because no one with 50,000 smartphone customers would risk our
> wrath," here's an alternate play that's strictly fly-by-night.
> 
> Stand up 16 legal entities, 1 each named after nearby public parks.
> Install a solar-powered wifi hotspot at each park and backhaul them
> (wirelessly of course) to two additional entities designed to be
> BGP-speaking backhauls. I'm such a nice guy, I'll even make the park
> wifi free to park patrons. While it's running anyway; reliability
> isn't my priority.
> 
> For this modest investment, each of the 16 entities is now multihomed
> and, as each park could easily host 150 wifi clients, can justify a
> /24. Acquire addresses from the ARIN free pool and configure them on
> the equipment. Drive around and make sure each site logs enough users
> at least once to justify the full /24. I now hold 16 /24's and
> documentation which fulfills my justified use obligation.
> 
> Sell them outregion to an entity that can't get /24's locally and
> meets it's local RIR's nominal needs-based justification. Initiate
> specified recipient transfers per 2011-1.
> 
> Upon completion of the transfer (including the ARIN audits in which
> the documentation shows fulfillment of all the use justification thus
> no fraud) tear down the wifi hotspots and terminate the organizations
> created for them.
> 
> Stand up 16 more legal entities, named after a set of shopping mall
> food courts. Rinse and repeat.
> 
> At $5/address this is not practical, but if addresses go for $20 each
> this grosses $82k on an investment around $40k with a 3ish month
> turnaround. So, double your money in three months with a by-the-book
> raid on the ARIN free pool. And I'm sure this could be refined further
> to either cut the cost or increase the block size from /24 so that
> even at $5/address you could come out ahead.
> 
> 
>> Note also that this potential
>> concern exists in the existing NRPM 8.3 policy with respect
>> to in-region transfers.
> 
> Without draft 2011-1 it does me limited good to acquire these
> addresses. Any transferee will be in the ARIN region where they have
> the same access I do to the remaining free pool and have to meet the
> same justified use criteria that I do in order to receive addresses
> either from the free pool or from me. I present the transferee no
> value as a middleman.
> 
> 
> Note that the board recognized the related-legal-entities issue a few
> years ago, but IIRC they abandoned their attempt to address it,
> possibly for lack of a usable legal framework. No joy to be found down
> that blind alley and I imagine the prevailing view was that with a
> strong needs justification applied independently to each legal entity
> there was relatively little damage that could be done.
> 
> Regards,
> Bill Herrin
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
> _______________________________________________
> 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 george.herbert at gmail.com  Mon Oct 24 19:10:07 2011
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 24 Oct 2011 16:10:07 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
Message-ID: <CAK__KztYwAU3V61Ce1103qzvesK_AxyqjdDFTyjWGe560LzV6Q@mail.gmail.com>

On Mon, Oct 24, 2011 at 3:57 PM, William Herrin <bill at herrin.us> wrote:
> On Mon, Oct 24, 2011 at 6:43 PM, Mike Burns <mike at nationwideinc.com> wrote:
>> How many times could you rinse/repeat this cycle before the activity became
>> so evident that ARIN refused to authorize the transfer, and instead
>> attempted reclamation due to fraud?
>
> Hi Mike,
>
> As many as you want until the Board adopts a policy which declares
> defines such use illegitimate. If the policy says it isn't fraud then
> it isn't fraud no matter how egregious. ARIN simply isn't allowed to
> make it up as they go; they're bound by the policies. One problem with
> 2011-1 as presently drafted is that it takes some dubious activities
> that current policy defines as "not fraud" and creates an only
> moderately circuitous path to easy cash.
>
>
>> I agree that protections against fraud in obtaining addresses from the free
>> pool will become increasingly important, and if there was some work in the
>> past related to detecting related-legal-entities, it would be prudent to
>> revisit that subject.
>
> I'll take counterpoint: protections will become unimportant relatively
> quickly because we're nearly out of addresses in the ARIN free pool
> too. Nevertheless, we need some protections _until_ events render
> matter moot.
>
>
>> Bill, what would you think about preventing those who receive addresses from
>> the free pool from selling addresses for some timeframe commencing at the
>> time of their last allocation?
>
> Do we really want to lock unused or underused addresses out of play
> for folks who DO meet ARIN's needs-justification when the whole point
> of transfers is that we don't have enough addresses to go around?
>
> Regards,
> Bill Herrin


Obviously locking addresses out of play a bit is the point; we're
putting up some roadblocks, nobody objects to the idea of it not being
a free-for-all.

The question is whether the roadblocks are effective and limited
(i.e., don't get in the way of those with legitimate non-speculative
needs, do at least slow down speculators just in it for a few $$$).

I am so far convinced that we don't actually know the answer; this, to
me, argues for slowing down and some more thinking about it and gaming
the scenarios some more.

Slowing down has its own costs - including potentially affecting those
with legitimate non-speculative needs.  The point at which those costs
become real and significant is perhaps a bit too late; figuring out
where we are in the understanding as we approach that point would be
optimal.  But this is a policy and business scenario debate, not a
game theory exercise per se...


-- 
-george william herbert
george.herbert at gmail.com


From owen at delong.com  Mon Oct 24 19:10:48 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Oct 2011 16:10:48 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re:
	ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
Message-ID: <04EEFC50-AFFE-43B4-ADE8-F00DD3B4A365@delong.com>



Sent from my iPad

On Oct 24, 2011, at 3:57 PM, William Herrin <bill at herrin.us> wrote:

> On Mon, Oct 24, 2011 at 6:43 PM, Mike Burns <mike at nationwideinc.com> wrote:
>> How many times could you rinse/repeat this cycle before the activity became
>> so evident that ARIN refused to authorize the transfer, and instead
>> attempted reclamation due to fraud?
> 
> Hi Mike,
> 
> As many as you want until the Board adopts a policy which declares
> defines such use illegitimate. If the policy says it isn't fraud then
> it isn't fraud no matter how egregious. ARIN simply isn't allowed to
> make it up as they go; they're bound by the policies. One problem with
> 2011-1 as presently drafted is that it takes some dubious activities
> that current policy defines as "not fraud" and creates an only
> moderately circuitous path to easy cash.
> 
That's why this draft policy has a safety valve permitting staff to make it up as they go along to the extent that they can reject the transfer such that the entity in question suddenly can't get paid.


> 
>> I agree that protections against fraud in obtaining addresses from the free
>> pool will become increasingly important, and if there was some work in the
>> past related to detecting related-legal-entities, it would be prudent to
>> revisit that subject.
> 
> I'll take counterpoint: protections will become unimportant relatively
> quickly because we're nearly out of addresses in the ARIN free pool
> too. Nevertheless, we need some protections _until_ events render
> matter moot.
> 

The fewer the protections, the sooner it will be moot. ;)

Seriously, though, I think that the RIRs agree provision provides the best avenue of protection possible in this case.

> 
>> Bill, what would you think about preventing those who receive addresses from
>> the free pool from selling addresses for some timeframe commencing at the
>> time of their last allocation?
> 
> Do we really want to lock unused or underused addresses out of play
> for folks who DO meet ARIN's needs-justification when the whole point
> of transfers is that we don't have enough addresses to go around?
> 

There's two sides to every sword that can be used to attack this issue.

Owen

> 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 paul at redbarn.org  Mon Oct 24 19:19:20 2011
From: paul at redbarn.org (Paul Vixie)
Date: Mon, 24 Oct 2011 23:19:20 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re:
	ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
Message-ID: <201110242319.21203.paul@redbarn.org>

On Monday, October 24, 2011 10:57:29 pm William Herrin wrote:
> On Mon, Oct 24, 2011 at 6:43 PM, Mike Burns <mike at nationwideinc.com> wrote:
> > How many times could you rinse/repeat this cycle before the activity
> > became so evident that ARIN refused to authorize the transfer, and
> > instead attempted reclamation due to fraud?
> 
> As many as you want until the Board adopts a policy which declares
> defines such use illegitimate.

when you speak of "board" and "policy" in the same sentence you pique my 
interest. i'm assuming you mean corporate policy not numbers policy, since 
numbers policy is made by the community and only confirmed by the board.

are you contemplating a requirement attesting to some kind of intent to 
operate a real network (rather than, in your example, simply offshoring the 
resources and starting over with a different name)? if so, how would you 
suggest that arin enforce such a thing?


From bill at herrin.us  Mon Oct 24 19:26:04 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 24 Oct 2011 19:26:04 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <04EEFC50-AFFE-43B4-ADE8-F00DD3B4A365@delong.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<04EEFC50-AFFE-43B4-ADE8-F00DD3B4A365@delong.com>
Message-ID: <CAP-guGU_4OqWcP3VDUaw2znamx2j6N3XA5Xz+ZCebr7ZMiZOQg@mail.gmail.com>

On Mon, Oct 24, 2011 at 7:10 PM, Owen DeLong <owen at delong.com> wrote:
> That's why this draft policy has a safety valve permitting
>staff to make it up as they go along to the extent that they
>can reject the transfer such that the entity in question
>suddenly can't get paid.

Owen,

Please understand: text which directs ARIN staff to "use best
judgment" is non-operative. It will always, always, always result in
the least restrictive interpretation of the whole policy document
being applied. You just saw this happen with Microsoft-Nortel where
Microsoft was allowed to sign an LRSA when any fool would understand
that the policy was intended to require the recipient to enter into
the normal RSA that any other new entrant would sign.

Regardless, the 2011-1 draft from 10/14 includes no language directing
ARIN to refuse out-region transfers based on any ARIN-region criteria,
best judgment or otherwise.

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 mike at nationwideinc.com  Mon Oct 24 19:43:02 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Mon, 24 Oct 2011 19:43:02 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
	ARIN-2011-1:ARINInter-RIRTransfers- Last Call
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com><9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com><CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.g
	mail.com><3C1442548AC24C969B810843BAF661D7@MPC>
	<D67DFABA981C4F56ADD781618C4FC246@MPC><9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net><CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
Message-ID: <47EA1CF020BC4730B3B6F26A40363B95@video>

Hi Bill,

>As many as you want until the Board adopts a policy which declares
defines such use illegitimate. If the policy says it isn't fraud then
it isn't fraud no matter how egregious. ARIN simply isn't allowed to
make it up as they go; they're bound by the policies. One problem with
2011-1 as presently drafted is that it takes some dubious activities
that current policy defines as "not fraud" and creates an only
moderately circuitous path to easy cash.


I would consider adding some language in the Declarations section 10b of the 
RSA stating that the applicant has an *intention* to use the addresses for 
the purposes stated in the application.  The officer attestation should also 
include this language.  Then, in the event that this abuse manifests itself, 
ARIN would have some ability to declare the contract fraudulent despite 
whether the allocation/transfer behavior conformed to policy.  If a pattern 
of allocation/transfer occurs, even within policy, ARIN can point to the 
activity as incompatible with the declared intention and recover under 
Section 12. I mean, it could happen that the wifi system legitimately fails, 
as most municipal wifi systems have. But if the same owner or officer tries 
again it would be easier to demonstrate bad intentions and contract fraud. 
But I'm no lawyer and perhaps such a declaration was left out for a valid 
reason.

>Do we really want to lock unused or underused addresses out of play
for folks who DO meet ARIN's needs-justification when the whole point
of transfers is that we don't have enough addresses to go around?


At the maximum, we would be locking out of the market just a year's worth of 
new allocations for a timeframe of  one year, with all prohibition dropped 
at exhaust plus a year.
 I don't think it's fair to get addresses from the free pool for the 
purposes of profiting through their sale, and I'm sure you don't either. The 
one year prohibition on sales serves to discincentivize the pillaging of the 
free pool for profit, and incentivizes efficient use of existing space for 
those who would otherwise choose to avail themselves of the free pool . In 
other words, if I could free up space instead of acquiring more from the 
pool, I would reserve my right to sell addresses at any time. For those who 
acted legitimately and acquired addresses from the free pool which quickly 
became unneeeded, their penalty would be waiting for just the balance of a 
year before they could sell, and they would probably be well-rewarded 
anyway, in the end.

Regards,
Mike




From bill at herrin.us  Mon Oct 24 19:46:17 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 24 Oct 2011 19:46:17 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <201110242319.21203.paul@redbarn.org>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<201110242319.21203.paul@redbarn.org>
Message-ID: <CAP-guGUPdsrD7sxvswTv+8mAkSKdDo8bu2X_uU83cXuJeCdtRA@mail.gmail.com>

On Mon, Oct 24, 2011 at 7:19 PM, Paul Vixie <paul at redbarn.org> wrote:
> On Monday, October 24, 2011 10:57:29 pm William Herrin wrote:
>> On Mon, Oct 24, 2011 at 6:43 PM, Mike Burns <mike at nationwideinc.com> wrote:
>> > How many times could you rinse/repeat this cycle before the activity
>> > became so evident that ARIN refused to authorize the transfer, and
>> > instead attempted reclamation due to fraud?
>>
>> As many as you want until the Board adopts a policy which declares
>> defines such use illegitimate.
>
> when you speak of "board" and "policy" in the same sentence you pique my
> interest. i'm assuming you mean corporate policy not numbers policy, since
> numbers policy is made by the community and only confirmed by the board.

Hi Paul,

I mean numbers policy. Section 5 of the numbers policy development
process says "The Board may ADOPT, reject or remand [...] draft
policies," but I understand that to mean the same as confirming the
draft policies the AC forwards for review.

The board also has (and has used) the Emergency PDP (section 7.1) to
install new numbers policy of its own when it finds a situation it
considers needful of prompt action. Under 7.2, it also has the ability
to suspend a section of numbers policy on its own prerogative. In both
cases, ex-post-facto rules would probably apply, so it would be
difficult for the board to stop a transfer which for which a
registrant had already applied.

Nevertheless, having detected a pattern of "obvious" misuse of the
numbers policy, the Board is empowered to stop it recurring while we
argue about how to implement a long-term fix.


> are you contemplating a requirement attesting to some kind of intent to
> operate a real network (rather than, in your example, simply offshoring the
> resources and starting over with a different name)? if so, how would you
> suggest that arin enforce such a thing?

No, and I don't immediately see a practical way for ARIN to enforce
such a thing. As near as I can figure, the very best ARIN can do is
ensure that an out-region transfer recipient meets at least as
stringent a needs justification criteria as an in-region one would.

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 Oct 24 19:58:43 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 24 Oct 2011 18:58:43 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
Message-ID: <CAAAwwbUye8DGrCpDKkq5zvofdNz__79TYbhWVBgdaPsTRGJr-g@mail.gmail.com>

On Mon, Oct 24, 2011 at 5:03 PM, John Curran <jcurran at arin.net> wrote:
> Bill -
> ?It's actually simpler than that... These "independent" entities
> ?with limited history are actually valid address recipients.
> ?We do our best to unveil companies which are entirely shell
> ?companies (and effectively deduplicate requests) but as long as

I think the premise was the entities wouldn't be "shell companies"
strictly speaking,
even though their ultimate owners formed them  knowing the companies' business
plan would ultimately lead them to needing IP addresses,  which could
then become
so valuable due to Inter-RIR transfer and  offshore value of IP addresses,
that the companies might be scrapped for a quick profit due to the
value of their IP addresses.

> ?I agree that presently this new entrant "loophole" could
> ?potentially be exacerbated by an InterRIR transfer policy;
> ?I just wanted to ?make it clear that it may also be a serious
> ?problem as we approach in-region depletion in general.

There is a way we could avoid InterRIR transfer policy exacerbating this...
ARIN could allow applicants from _any_  service region  to apply for
resources from the free pool,
via a  inter-RIR  "cross application" deal.

By that,  I mean  ARIN could adopt a policy permitting resources from
the ARIN free pool to be allocated to an applicant in any other
region,  and  after approval, the resources would automatically be
transferred to the local RIR on the applicant's behalf,   provided
that other region also adopted the same policy.


Then there would be no point of abusing the Inter-RIR transfer
process,  as the applicants in the
other  region could simply make their application with ARIN and  meet
the justified need
requirements under ARIN's criteria.

It would be more efficient for the applicant to obtain these IP
addresses from ARIN's free pool,
than to engage in some   'backdoor'  mechanism    requiring a US-based
company to apply
for IP addresses ultimately for the purpose of reselling them at high
margin  @  whatever
the market value is in other RIRs.

--
-JH


From mysidia at gmail.com  Mon Oct 24 20:14:42 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 24 Oct 2011 19:14:42 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGUPdsrD7sxvswTv+8mAkSKdDo8bu2X_uU83cXuJeCdtRA@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<201110242319.21203.paul@redbarn.org>
	<CAP-guGUPdsrD7sxvswTv+8mAkSKdDo8bu2X_uU83cXuJeCdtRA@mail.gmail.com>
Message-ID: <CAAAwwbU2sH6xmdxfap-TsUwg1J2aF4OuZrp7DNizw-uGwYfgCA@mail.gmail.com>

On Mon, Oct 24, 2011 at 6:46 PM, William Herrin <bill at herrin.us> wrote:
> On Mon, Oct 24, 2011 at 7:19 PM, Paul Vixie <paul at redbarn.org> wrote:
>> On Monday, October 24, 2011 10:57:29 pm William Herrin wrote:
>>> On Mon, Oct 24, 2011 at 6:43 PM, Mike Burns <mike at nationwideinc.com> wrote:
> The board also has (and has used) the Emergency PDP (section 7.1) to
> install new numbers policy of its own when it finds a situation it
> considers needful of prompt action. Under 7.2, it also has the ability
> to suspend a section of numbers policy on its own prerogative. In both
> cases, ex-post-facto rules would probably apply, so it would be

I realize this can happen,  but it should not be something that is
likely to happen by design
of the policy itself.  The transfer policy should contain some sort of
failsafe against abuse,
where abuse is likely.

It's unacceptable IMO to have some vague concept like  "the board will
probably suspend the policy
or implement an ad-hoc remedy if someone abuses it"

An example of a failsafe would be  "You can't effect a specified
transfer of any part of an allocation received
in the past X months,  or an inter-RIR transfer of any part of an
allocation received in the past Y months"


--
-JH


From bill at herrin.us  Mon Oct 24 20:37:19 2011
From: bill at herrin.us (William Herrin)
Date: Mon, 24 Oct 2011 20:37:19 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAAAwwbUye8DGrCpDKkq5zvofdNz__79TYbhWVBgdaPsTRGJr-g@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
	<CAAAwwbUye8DGrCpDKkq5zvofdNz__79TYbhWVBgdaPsTRGJr-g@mail.gmail.com>
Message-ID: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>

On Mon, Oct 24, 2011 at 7:58 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Mon, Oct 24, 2011 at 5:03 PM, John Curran <jcurran at arin.net> wrote:
>> ?I agree that presently this new entrant "loophole" could
>> ?potentially be exacerbated by an InterRIR transfer policy;
>> ?I just wanted to ?make it clear that it may also be a serious
>> ?problem as we approach in-region depletion in general.
>
> There is a way we could avoid InterRIR transfer policy exacerbating this...
> ARIN could allow applicants from _any_ ?service region ?to apply for
> resources from the free pool,
> via a ?inter-RIR ?"cross application" deal.

Jimmy,

That would be functional. But is it fair? We still have a free pool
because having learned our lessons in the Internic days, we were
restrictive with addresses when some other regions were not. We would
be allowing other regions with much less restrictive policies to
deplete the remaining resource we so carefully managed.

Regards,
Bill Herrin




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


From scottleibrand at gmail.com  Mon Oct 24 20:39:35 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 24 Oct 2011 17:39:35 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAAAwwbU2sH6xmdxfap-TsUwg1J2aF4OuZrp7DNizw-uGwYfgCA@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<201110242319.21203.paul@redbarn.org>
	<CAP-guGUPdsrD7sxvswTv+8mAkSKdDo8bu2X_uU83cXuJeCdtRA@mail.gmail.com>
	<CAAAwwbU2sH6xmdxfap-TsUwg1J2aF4OuZrp7DNizw-uGwYfgCA@mail.gmail.com>
Message-ID: <CAGkMwz4TuXRKrqANkETnxAhbna=KQ26GXRKwtOPACcqvxnQP8w@mail.gmail.com>

On Mon, Oct 24, 2011 at 5:14 PM, Jimmy Hess <mysidia at gmail.com> wrote:

>
> It's unacceptable IMO to have some vague concept like  "the board will
> probably suspend the policy
> or implement an ad-hoc remedy if someone abuses it"
>
> An example of a failsafe would be  "You can't effect a specified
> transfer of any part of an allocation received
> in the past X months,  or an inter-RIR transfer of any part of an
> allocation received in the past Y months"
>

I would encourage you (or anyone in the community) to submit a policy
proposal along these lines.  (I know Owen also had some suggested text.)  If
we get such a policy proposal moving along through the PDP now, we could
have it implemented via the normal calendar in about 6 months if there's
consensus for it.  If significant abuse materializes before then that cannot
be easily dealt with by ARIN under existing policy, it would also be good to
have something that we've already discussed and come to rough consensus on.
 That way the Board could implement a draft policy that has already had
significant community discussion (rather than creating an ad-hoc remedy or
suspending 2011-1) if it becomes necessary.

Personally, I think ARIN already has a number of tools at its disposal to
make gaming the system expensive and uncertain enough to limit abuse.   I
would also support something like the above, but I don't think we want to
hold 2011-1 up for another 6 months while we deal with that issue.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111024/5a1d38e7/attachment.htm>

From scottleibrand at gmail.com  Mon Oct 24 22:04:13 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 24 Oct 2011 19:04:13 -0700
Subject: [arin-ppml] Post PPM Revision of ARIN-2011-7: Compliance
	Requirement
In-Reply-To: <CAC1-dtkW6YU4EGkuoFNgLeDFSV+-a5e8MvxpASAX8JWFwN3+QQ@mail.gmail.com>
References: <CAC1-dtkW6YU4EGkuoFNgLeDFSV+-a5e8MvxpASAX8JWFwN3+QQ@mail.gmail.com>
Message-ID: <CAGkMwz7dqPFWOJR6eSVSoWRuFR0FOr0s63N551TNFxHPgOfFGA@mail.gmail.com>

I'm not sure we heard a consensus from the community in favor of requiring
ARIN to revoke reverse DNS for organizations out of compliance with policy.
 I don't think the transcripts are available yet, so all I have aside from
my own memory is the poll counts, which were 20-34 on the text presented,
and 57-6 in favor of continuing to work on it.

So I guess I'd like to hear from the community (particularly those 34 of you
who didn't like the presented text) as to whether you think these changes
address your concerns or not.

-Scott

On Mon, Oct 24, 2011 at 12:29 PM, Chris Grundemann <cgrundemann at gmail.com>wrote:

> Hello,
>
> As the primary shepherd of draft policy ARIN-2011-7: Compliance
> Requirement, I took your feedback from the Public Policy Meeting in
> Philadelphia and revised the text. I believe that this new text
> continues to meet the originators intentions while also addressing all
> significant concerns raised thus far. Please let me know what you
> think. If there are no major objections from the community here, I
> plan to recommend this policy for last call at the next AC meeting.
>
> New text:
>
> ----8<----8<----8<----
>
> 12.4 - Update to:
> Organizations found by ARIN to be out of compliance with current ARIN
> policy shall be required to update reassignment information or return
> resources as needed to bring them into (or reasonably close to)
> compliance.
> 1. The degree to which an organization may remain out of compliance
> shall be based on the reasonable judgment of the ARIN staff and shall
> balance all facts known, including the organization's utilization
> rate, available address pool, and other factors as appropriate so as
> to avoid forcing returns which will result in near-term additional
> requests or unnecessary route de-aggregation.
> 2. To the extent possible, entire blocks should be returned. Partial
> address blocks shall be returned in such a way that the portion
> retained will comprise a single aggregate block.
>
> 12.5 - Update to:
> Except in cases of fraud when immediate action can be taken, an
> organization shall be given thirty (30) days to respond. If an
> organization fails to respond within thirty (30) days, ARIN may cease
> providing reverse DNS services to that organization. If progress of
> resource returns or record corrections has not occurred within sixty
> (60) days after ARIN initiated contact, ARIN shall cease providing
> reverse DNS services for the resources in question. At any time ninety
> (90) days after initial ARIN contact, ARIN may initiate the revocation
> of any resources issued by ARIN as required to bring the organization
> into overall compliance. ARIN may permit a longer period of time to
> come into compliance, if ARIN believes the organization is working in
> good faith to restore compliance with policy and has a valid need for
> additional time to comply, including but not limited to renumbering
> out of the affected blocks. ARIN shall follow the same guidelines for
> revocation that are required for voluntary return in the previous
> paragraph.
>
> (leave 12.6 as is)
>
> ----8<----8<----8<----
>
> Cheers,
> ~Chris
> _______________________________________________
> 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/20111024/de8c7a6f/attachment.htm>

From mysidia at gmail.com  Mon Oct 24 23:25:59 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 24 Oct 2011 22:25:59 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
	<CAAAwwbUye8DGrCpDKkq5zvofdNz__79TYbhWVBgdaPsTRGJr-g@mail.gmail.com>
	<CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
Message-ID: <CAAAwwbUtABuRkxGWR=htQEMUdP_B3nLgcR_ruSWbRW9X+5P2rA@mail.gmail.com>

On Mon, Oct 24, 2011 at 7:37 PM, William Herrin <bill at herrin.us> wrote:
> That would be functional. But is it fair? We still have a free pool
> because having learned our lessons in the Internic days, we were
> restrictive with addresses when some other regions were not. We would

I think the reason ARIN still has a free pool has more to do with how
ARIN managed
its final allocations.   It could have been horribly efficient if it
liked with all the prior
allocations,    it was how restrictive with the final /8s  that would
matter most.
Fairness could be argued either way,  it could be stated that ARIN has
more IP address
space,  therefore ARIN has more than its fair share of addresses.

Anyways,  I don't care about fairness per se;  ARIN shouldn't do it
because it's
not good stewardship of resources on behalf of the ARIN membership.


That is also the same reason ARIN should not implement Inter-RIR
transfer as proposed.

> be allowing other regions with much less restrictive policies to
> deplete the remaining resource we so carefully managed.

It might be "fair"  for allow other regions to do so,  but ARIN should
not allow other
regions to do so.

--
-JH


From owen at delong.com  Mon Oct 24 23:56:08 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Oct 2011 20:56:08 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re:
	ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGU_4OqWcP3VDUaw2znamx2j6N3XA5Xz+ZCebr7ZMiZOQg@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<04EEFC50-AFFE-43B4-ADE8-F00DD3B4A365@delong.com>
	<CAP-guGU_4OqWcP3VDUaw2znamx2j6N3XA5Xz+ZCebr7ZMiZOQg@mail.gmail.com>
Message-ID: <C80E867A-1DCA-401C-9935-08037E351907@delong.com>


On Oct 24, 2011, at 4:26 PM, William Herrin wrote:

> On Mon, Oct 24, 2011 at 7:10 PM, Owen DeLong <owen at delong.com> wrote:
>> That's why this draft policy has a safety valve permitting
>> staff to make it up as they go along to the extent that they
>> can reject the transfer such that the entity in question
>> suddenly can't get paid.
> 
> Owen,
> 
> Please understand: text which directs ARIN staff to "use best
> judgment" is non-operative. It will always, always, always result in
> the least restrictive interpretation of the whole policy document
> being applied. You just saw this happen with Microsoft-Nortel where

This simply is not true. I've seen several instances where the staff has
applied much more restrictive interpretation than you suggest.

> Microsoft was allowed to sign an LRSA when any fool would understand
> that the policy was intended to require the recipient to enter into
> the normal RSA that any other new entrant would sign.
> 

Yes, the Micr0$0ft situation has a lot of areas that smell funny. I suspect
that ARIN's back was against the wall with the court system and pragmatism
exceeded policy idealism. Such is life. ARIN cannot really stand up to a court
and refuse to comply.

> Regardless, the 2011-1 draft from 10/14 includes no language directing
> ARIN to refuse out-region transfers based on any ARIN-region criteria,
> best judgment or otherwise.
> 

It provides a requirement that both RIRs agree to the transfer. That requirement
allows ARIN to reject a transfer on a case by case basis if necessary. I agree it
is not ideal, but, I still believe it is the best safety valve possible under the
circumstances.

Owen

> 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  Tue Oct 25 00:01:57 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Oct 2011 21:01:57 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
	ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAAAwwbUye8DGrCpDKkq5zvofdNz__79TYbhWVBgdaPsTRGJr-g@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
	<CAAAwwbUye8DGrCpDKkq5zvofdNz__79TYbhWVBgdaPsTRGJr-g@mail.gmail.com>
Message-ID: <1EDC2896-882F-42B9-B7F7-A2FF900230AA@delong.com>


On Oct 24, 2011, at 4:58 PM, Jimmy Hess wrote:

> On Mon, Oct 24, 2011 at 5:03 PM, John Curran <jcurran at arin.net> wrote:
>> Bill -
>>  It's actually simpler than that... These "independent" entities
>>  with limited history are actually valid address recipients.
>>  We do our best to unveil companies which are entirely shell
>>  companies (and effectively deduplicate requests) but as long as
> 
> I think the premise was the entities wouldn't be "shell companies"
> strictly speaking,
> even though their ultimate owners formed them  knowing the companies' business
> plan would ultimately lead them to needing IP addresses,  which could
> then become
> so valuable due to Inter-RIR transfer and  offshore value of IP addresses,
> that the companies might be scrapped for a quick profit due to the
> value of their IP addresses.
> 
>>  I agree that presently this new entrant "loophole" could
>>  potentially be exacerbated by an InterRIR transfer policy;
>>  I just wanted to  make it clear that it may also be a serious
>>  problem as we approach in-region depletion in general.
> 
> There is a way we could avoid InterRIR transfer policy exacerbating this...
> ARIN could allow applicants from _any_  service region  to apply for
> resources from the free pool,
> via a  inter-RIR  "cross application" deal.
> 
I like the idea in general, but, I believe it would require global policy and/or
a modification of the ICP-2 document which I think is infeasible in the time
remaining in the free pool.

> By that,  I mean  ARIN could adopt a policy permitting resources from
> the ARIN free pool to be allocated to an applicant in any other
> region,  and  after approval, the resources would automatically be
> transferred to the local RIR on the applicant's behalf,   provided
> that other region also adopted the same policy.
> 

I believe this would be contrary to the current ICP-2 document and would
also create interesting financial, legal, and language problems.

> 
> Then there would be no point of abusing the Inter-RIR transfer
> process,  as the applicants in the
> other  region could simply make their application with ARIN and  meet
> the justified need
> requirements under ARIN's criteria.
> 

As I said, I like the idea in principle, but, I don't think it can be implemented
within the current global policy framework.

Owen



From owen at delong.com  Tue Oct 25 00:13:28 2011
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Oct 2011 21:13:28 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
	ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
	<CAAAwwbUye8DGrCpDKkq5zvofdNz__79TYbhWVBgdaPsTRGJr-g@mail.gmail.com>
	<CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
Message-ID: <204AE0A6-E91D-4720-AD97-A9164522159A@delong.com>


On Oct 24, 2011, at 5:37 PM, William Herrin wrote:

> On Mon, Oct 24, 2011 at 7:58 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>> On Mon, Oct 24, 2011 at 5:03 PM, John Curran <jcurran at arin.net> wrote:
>>>  I agree that presently this new entrant "loophole" could
>>>  potentially be exacerbated by an InterRIR transfer policy;
>>>  I just wanted to  make it clear that it may also be a serious
>>>  problem as we approach in-region depletion in general.
>> 
>> There is a way we could avoid InterRIR transfer policy exacerbating this...
>> ARIN could allow applicants from _any_  service region  to apply for
>> resources from the free pool,
>> via a  inter-RIR  "cross application" deal.
> 
> Jimmy,
> 
> That would be functional. But is it fair? We still have a free pool
> because having learned our lessons in the Internic days, we were
> restrictive with addresses when some other regions were not. We would
> be allowing other regions with much less restrictive policies to
> deplete the remaining resource we so carefully managed.
> 

Bill, this is, frankly BS. APNIC was no less restrictive than ARIN in general,
even at the peak of their consumption rate. APNIC serves several rapidly
growing economies with relatively low internet penetration into very large
populations (India, China, et. al.),

Rapid growth in internet availability and usage in those countries is
driving address consumption in the APNIC region far more than any
differences in relative allocation policy.

The ARIN region has more address space than the APNIC region, yet,
the APNIC region includes roughly 60% of the world population.
I find it utterly absurd to try and buy into the argument that APNIC is
out of IPv4 addresses simply because they consumed them faster
than other regions. APNIC is out of addresses first because they have
vastly more internet users and significantly fewer addresses to serve
them.

(Population data: http://www.nationsonline.org/oneworld/world_population.htm)

Total world population: 6.9 Billion
Asia: 4.157 Billion
Oceania: 0.035 Billion (also mostly APNIC)
APNIC Total: ~4.1 Billion

Owen



From mysidia at gmail.com  Tue Oct 25 00:34:32 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 24 Oct 2011 23:34:32 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <204AE0A6-E91D-4720-AD97-A9164522159A@delong.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
	<CAAAwwbUye8DGrCpDKkq5zvofdNz__79TYbhWVBgdaPsTRGJr-g@mail.gmail.com>
	<CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<204AE0A6-E91D-4720-AD97-A9164522159A@delong.com>
Message-ID: <CAAAwwbX0wPGqOEs3E7WveNBUuhfd6f2foyHbLrOpjuY9K1rKwA@mail.gmail.com>

On Mon, Oct 24, 2011 at 11:13 PM, Owen DeLong <owen at delong.com> wrote:
> The ARIN region has more address space than the APNIC region, yet,
> the APNIC region includes roughly 60% of the world population.
> I find it utterly absurd to try and buy into the argument that APNIC is
> out of IPv4 addresses simply because they consumed them faster
> than other regions. APNIC is out of addresses first because they have
> vastly more internet users and significantly fewer addresses to serve
> them.

Yes.  And the APNIC region also has so vastly many users that the
entire free pools
of all the other regions combined is a drop in the bucket. There is
really nothing more
to be done with that in IPv4, as
It's clear that IPv6 is the only viable option for correcting the
issue of the lack of sufficient IPs.

Meanwhile we have a proposal that would permit inter-RIR transfers
allowing ARIN address space "from which only /22s or only /20s were
allocated" to be fragmented   across regions down to the /24 level,
which adversely impacts route filtering options.

And the inter-RIR transfer concept also introduces additional
technical issues...  for example,  making it impossible to write
simple firewall filters to block traffic originating from certain RIR
/8s,
or intelligently direct certain /8s  through a path that corresponds
to efficient routing for the destination region.

--
-JH


From bill at herrin.us  Tue Oct 25 00:37:14 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 25 Oct 2011 00:37:14 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <C80E867A-1DCA-401C-9935-08037E351907@delong.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<04EEFC50-AFFE-43B4-ADE8-F00DD3B4A365@delong.com>
	<CAP-guGU_4OqWcP3VDUaw2znamx2j6N3XA5Xz+ZCebr7ZMiZOQg@mail.gmail.com>
	<C80E867A-1DCA-401C-9935-08037E351907@delong.com>
Message-ID: <CAP-guGWOVvu9nZYuMBPpmkJ_fjHPKJLu6DYML_Co442mbiihpQ@mail.gmail.com>

On Mon, Oct 24, 2011 at 11:56 PM, Owen DeLong <owen at delong.com> wrote:
> On Oct 24, 2011, at 4:26 PM, William Herrin wrote:
>> Regardless, the 2011-1 draft from 10/14 includes no language directing
>> ARIN to refuse out-region transfers based on any ARIN-region criteria,
>> best judgment or otherwise.
>
> It provides a requirement that both RIRs agree to the transfer. That requirement
> allows ARIN to reject a transfer on a case by case basis if necessary. I agree it
> is not ideal, but, I still believe it is the best safety valve possible under the
> circumstances.

John,

How about it? Is Owen correct? Under 2011-1 where a registrant in good
standing has requested an 8.3 transfer to a RIR that had been found to
have a needs-based policy and is either not suspected of fraud or has
passed an audit, are there any circumstances not specifically written
in the NRPM in which ARIN would not "agree to the transfer?"

"Inter-regional transfers may take place only via RIRs who agree to
the transfer and share compatible, needs-based policies."

Thanks,
Bill


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


From bill at herrin.us  Tue Oct 25 01:31:58 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 25 Oct 2011 01:31:58 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers- Last Call
In-Reply-To: <47EA1CF020BC4730B3B6F26A40363B95@video>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<47EA1CF020BC4730B3B6F26A40363B95@video>
Message-ID: <CAP-guGWzEfG1A8Sscb3Up3zb7ekraAdFso13F=FZXidXgXDz0Q@mail.gmail.com>

On Mon, Oct 24, 2011 at 7:43 PM, Mike Burns <mike at nationwideinc.com> wrote:
>> Do we really want to lock unused or underused addresses out of play
>> for folks who DO meet ARIN's needs-justification when the whole point
>> of transfers is that we don't have enough addresses to go around?
>
> At the maximum, we would be locking out of the market just a year's worth of
> new allocations for a timeframe of ?one year, with all prohibition dropped
> at exhaust plus a year.

Hi Mike,

Not exactly. We'd be locking out -registrants-, not specific
registrations. No real point in locking out only the most recent
registration if you can register new addresses and then sell your old
ones.

I don't have the exact numbers, but something like the top ten ARIN
registrants hold about half the space. And those same top ten are very
likely to be the ones who take the last few addresses in ARIN's free
pool. So, you're talking about locking up half the address space for a
year as we face a critical shortage.

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  Tue Oct 25 01:58:24 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 25 Oct 2011 01:58:24 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAGkMwz4TuXRKrqANkETnxAhbna=KQ26GXRKwtOPACcqvxnQP8w@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<201110242319.21203.paul@redbarn.org>
	<CAP-guGUPdsrD7sxvswTv+8mAkSKdDo8bu2X_uU83cXuJeCdtRA@mail.gmail.com>
	<CAAAwwbU2sH6xmdxfap-TsUwg1J2aF4OuZrp7DNizw-uGwYfgCA@mail.gmail.com>
	<CAGkMwz4TuXRKrqANkETnxAhbna=KQ26GXRKwtOPACcqvxnQP8w@mail.gmail.com>
Message-ID: <CAP-guGUb3C=4xfJrLGDYWGNO+X6-4UQ6Qz03B+c=pau62qG78w@mail.gmail.com>

On Mon, Oct 24, 2011 at 8:39 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On Mon, Oct 24, 2011 at 5:14 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>> An example of a failsafe would be ?"You can't effect a specified
>> transfer of any part of an allocation received
>> in the past X months, ?or an inter-RIR transfer of any part of an
>> allocation received in the past Y months"
>
> I would encourage you (or anyone in the community) to submit a policy
> proposal along these lines. ?(I know Owen also had some suggested text.) ?If
> we get such a policy proposal moving along through the PDP now, we could
> have it implemented via the normal calendar in about 6 months if there's
> consensus for it. ?If significant abuse materializes before then that cannot
> be easily dealt with by ARIN under existing policy, it would also be good to
> have something that we've already discussed and come to rough consensus on.
> ?That way the Board could implement a draft policy that has already had
> significant community discussion (rather than creating an ad-hoc remedy or
> suspending 2011-1) if it becomes necessary.

Jimmy, I believe that's what's known as "being an enabler" for someone
engaged in undesirable behavior.

Scott, someone asked earlier in the thread what the rush to do this
now instead of in 6 months is. I'm still waiting for someone to
articulate a satisfactory answer. I don't care why it's important to
APNIC registrants, I want to know why it's important to ARIN
registrants that we do this right now.

Even if there is a good reason to rush, the conservative course of
action would be to advance 2011-1 after restoring the stronger
protections that were in the earlier text and then spend the next 6
months talking about how to tone them down to something less onerous.
That would avoid any chance of the board needing to take emergency
action and, oh by the way, it's what cautious stewardship of a
resource is all about.


> Personally, I think ARIN already has a number of tools at its disposal to
> make gaming the system expensive and uncertain enough to limit abuse.

If you have something in mind that hasn't already been acknowledged or
debunked, I'd love to hear 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 jsw at inconcepts.biz  Tue Oct 25 05:00:01 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Tue, 25 Oct 2011 05:00:01 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGUb3C=4xfJrLGDYWGNO+X6-4UQ6Qz03B+c=pau62qG78w@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<201110242319.21203.paul@redbarn.org>
	<CAP-guGUPdsrD7sxvswTv+8mAkSKdDo8bu2X_uU83cXuJeCdtRA@mail.gmail.com>
	<CAAAwwbU2sH6xmdxfap-TsUwg1J2aF4OuZrp7DNizw-uGwYfgCA@mail.gmail.com>
	<CAGkMwz4TuXRKrqANkETnxAhbna=KQ26GXRKwtOPACcqvxnQP8w@mail.gmail.com>
	<CAP-guGUb3C=4xfJrLGDYWGNO+X6-4UQ6Qz03B+c=pau62qG78w@mail.gmail.com>
Message-ID: <CAPWAtb+HMCzcBk=YTD4eji4AAYMiitwqhKxkVb=5DLXF0gFFCw@mail.gmail.com>

On Tue, Oct 25, 2011 at 1:58 AM, William Herrin <bill at herrin.us> wrote:
>> Personally, I think ARIN already has a number of tools at its disposal to
>> make gaming the system expensive and uncertain enough to limit abuse.
>
> If you have something in mind that hasn't already been acknowledged or
> debunked, I'd love to hear it.

What do you think about businesses who have operations in both APNIC
and ARIN regions?  They cannot get more IPv4 addresses from APNIC.
They can get them from ARIN.  It is certain that at least some of
these businesses, perhaps many, will simply request addresses from
ARIN and issue them to their customers in AP.

Is this good?  I don't think so, but unless you want ARIN to
aggressively police this kind of thing, it is hard to argue against
legitimizing transfers that have basically the same effect on resource
depletion.

There is already plenty of inter-region IPv4 use for no reason other
than convenience.  I don't find it easy to say that a business with
legitimate operations in both regions should not be allowed to route
their addresses wherever they please, because historically, this has
been going on for a long time.  If you don't want inter-RIR transfers,
I think you should also be in favor of directing ARIN to audit for new
IPv4 allocations being partly or wholly routed outside of the ARIN
region, identify networks doing that, and refuse to give those
networks any more IPv4 space.  Take away their PTR delegations while
you are at it, and develop some long, cumbersome process whereby ARIN
might eventually revoke their space which they will continue to
announce into BGP anyway, because they have no ability to renumber out
of it.

My point is resources are going to be "transferred" outside of the
ARIN region anyway.  Once you realize that, you might consider that
legitimizing such transfers has more benefits than running out of IPv4
earlier.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From jcurran at arin.net  Tue Oct 25 05:08:34 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 25 Oct 2011 09:08:34 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGWOVvu9nZYuMBPpmkJ_fjHPKJLu6DYML_Co442mbiihpQ@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<04EEFC50-AFFE-43B4-ADE8-F00DD3B4A365@delong.com>
	<CAP-guGU_4OqWcP3VDUaw2znamx2j6N3XA5Xz+ZCebr7ZMiZOQg@mail.gmail.com>
	<C80E867A-1DCA-401C-9935-08037E351907@delong.com>
	<CAP-guGWOVvu9nZYuMBPpmkJ_fjHPKJLu6DYML_Co442mbiihpQ@mail.gmail.com>
Message-ID: <DB8CC9B3-77C8-46E8-A700-2BA924556C3B@arin.net>

On Oct 25, 2011, at 4:37 AM, William Herrin wrote:

> On Mon, Oct 24, 2011 at 11:56 PM, Owen DeLong <owen at delong.com> wrote:
>> On Oct 24, 2011, at 4:26 PM, William Herrin wrote:
>>> Regardless, the 2011-1 draft from 10/14 includes no language directing
>>> ARIN to refuse out-region transfers based on any ARIN-region criteria,
>>> best judgment or otherwise.
>> 
>> It provides a requirement that both RIRs agree to the transfer. That requirement
>> allows ARIN to reject a transfer on a case by case basis if necessary. I agree it
>> is not ideal, but, I still believe it is the best safety valve possible under the
>> circumstances.
> 
> John,
> 
> How about it? Is Owen correct? Under 2011-1 where a registrant in good
> standing has requested an 8.3 transfer to a RIR that had been found to
> have a needs-based policy and is either not suspected of fraud or has
> passed an audit, are there any circumstances not specifically written
> in the NRPM in which ARIN would not "agree to the transfer?"
> 
> "Inter-regional transfers may take place only via RIRs who agree to
> the transfer and share compatible, needs-based policies."

The first one would be approved.  The requests that occur thereafter
would be increasingly scrutinized for potential fraud.  A consistent
pattern of address usage that is different from the documented need 
from the requests could still be found to be fraudulent, even if any 
single request was valid.

Obviously, if the community has a consensus view on how such cases
should be handled, it would be preferred to have policy language 
which expresses such.  I do not believe that it is necessary to have
such language on day one; staff will use the tools at its disposal
to detect and address fraudulent requests.

FYi,
/John

John Curran
President and CEO
ARIN




From owen at delong.com  Tue Oct 25 05:31:19 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Oct 2011 02:31:19 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
	ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAAAwwbX0wPGqOEs3E7WveNBUuhfd6f2foyHbLrOpjuY9K1rKwA@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<F8949971-25C3-42D2-9115-9C60462DECD0@rs.seastrom.com>
	<9B100DB6-F8DE-42D5-9226-91D93981E417@delong.com>
	<CAP-guGVLmQo1WVMBmqkybu8afaNooSShRDJyJZhc1xt6s16Sfw@mail.gmail.com>
	<4EA1689B.10006@umn.edu>
	<CAP-guGUdhHyMcvPOWhWC+5DduUxkREi_Dm4MCrnKC7ei4AY+gQ@mail.gmail.com>
	<3C1442548AC24C969B810843BAF661D7@MPC>
	<8190263C-9923-4CAE-8D36-9F35D379119C@arin.net>
	<D67DFABA981C4F56ADD781618C4FC246@MPC>
	<CAP-guGWPcJFU-sk=uXqKUUXrQpufBZt405oayEJzrMU-195Ejw@mail.gmail.com>
	<9B24C71C-D885-4360-BB6F-F6B539C3E2CD@arin.net>
	<CAP-guGV9Lyu01GQOw-zmTzs+waOpjHM=1ZEp8waVn-JrKa4q4Q@mail.gmail.com>
	<F1A04B4D-4A6C-449B-B105-A4BD79B311E0@arin.net>
	<CAP-guGWDVShSg8rq0zExjA_Opg1jLkcW3vM65C6y-CP5hy2Vmg@mail.gmail.com>
	<F6C23992-FB68-4884-8367-4AB333164DF0@arin.net>
	<CAAAwwbUye8DGrCpDKkq5zvofdNz__79TYbhWVBgdaPsTRGJr-g@mail.gmail.com>
	<CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<204AE0A6-E91D-4720-AD97-! A9164522159A@delong.com>
	<CAAAwwbX0wPGqOEs3E7WveNBUuhfd6f2foyHbLrOpjuY9K1rKwA@mail.gmail.com>
Message-ID: <E699B079-04EB-4A41-88FC-2E65546B2DD2@delong.com>


On Oct 24, 2011, at 9:34 PM, Jimmy Hess wrote:

> On Mon, Oct 24, 2011 at 11:13 PM, Owen DeLong <owen at delong.com> wrote:
>> The ARIN region has more address space than the APNIC region, yet,
>> the APNIC region includes roughly 60% of the world population.
>> I find it utterly absurd to try and buy into the argument that APNIC is
>> out of IPv4 addresses simply because they consumed them faster
>> than other regions. APNIC is out of addresses first because they have
>> vastly more internet users and significantly fewer addresses to serve
>> them.
> 
> Yes.  And the APNIC region also has so vastly many users that the
> entire free pools
> of all the other regions combined is a drop in the bucket. There is
> really nothing more
> to be done with that in IPv4, as
> It's clear that IPv6 is the only viable option for correcting the
> issue of the lack of sufficient IPs.
> 

That's very true, but, postponing runout in other regions while leaving
APNIC to suffer under this global shortage will not help the situation and
it is not good stewardship.

> Meanwhile we have a proposal that would permit inter-RIR transfers
> allowing ARIN address space "from which only /22s or only /20s were
> allocated" to be fragmented   across regions down to the /24 level,
> which adversely impacts route filtering options.
> 

Route filtering options are going to be impacted just as adversely by
in-region transfers, so I don't see inter-regional transfers making any
difference here. This is a red herring.

> And the inter-RIR transfer concept also introduces additional
> technical issues...  for example,  making it impossible to write
> simple firewall filters to block traffic originating from certain RIR
> /8s,
> or intelligently direct certain /8s  through a path that corresponds
> to efficient routing for the destination region.
> 

Since geography != topology, I'm having tremendous difficulty seeing
how that would actually be useful even in today's world. Further, there
are already lots of ARIN (and other RIR) recipients using addresses
in other geographies (which is perfectly legitimate use under certain
circumstances such as a US company that runs a global network and
uses ARIN addresses for all or most of their network).

So the above paragraph is also a red herring relying on assumptions
not borne out by reality.

Owen



From owen at delong.com  Tue Oct 25 05:44:02 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Oct 2011 02:44:02 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re:
	ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGUb3C=4xfJrLGDYWGNO+X6-4UQ6Qz03B+c=pau62qG78w@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<201110242319.21203.paul@redbarn.org>
	<CAP-guGUPdsrD7sxvswTv+8mAkSKdDo8bu2X_uU83cXuJeCdtRA@mail.gmail.com>
	<CAAAwwbU2sH6xmdxfap-TsUwg1J2aF4OuZrp7DNizw-uGwYfgCA@mail.gmail.com>
	<CAGkMwz4TuXRKrqANkETnxAhbna=KQ26GXRKwtOPACcqvxnQP8w@mail.gmail.com>
	<CAP-guGUb3C=4xfJrLGDYWGNO+X6-4UQ6Qz03B+c=pau62qG78w@mail.gmail.com>
Message-ID: <CB99A64B-45D4-48AD-8314-212F9F16F7DE@delong.com>


On Oct 24, 2011, at 10:58 PM, William Herrin wrote:

> On Mon, Oct 24, 2011 at 8:39 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> On Mon, Oct 24, 2011 at 5:14 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>>> An example of a failsafe would be  "You can't effect a specified
>>> transfer of any part of an allocation received
>>> in the past X months,  or an inter-RIR transfer of any part of an
>>> allocation received in the past Y months"
>> 
>> I would encourage you (or anyone in the community) to submit a policy
>> proposal along these lines.  (I know Owen also had some suggested text.)  If
>> we get such a policy proposal moving along through the PDP now, we could
>> have it implemented via the normal calendar in about 6 months if there's
>> consensus for it.  If significant abuse materializes before then that cannot
>> be easily dealt with by ARIN under existing policy, it would also be good to
>> have something that we've already discussed and come to rough consensus on.
>>  That way the Board could implement a draft policy that has already had
>> significant community discussion (rather than creating an ad-hoc remedy or
>> suspending 2011-1) if it becomes necessary.
> 
> Jimmy, I believe that's what's known as "being an enabler" for someone
> engaged in undesirable behavior.
> 
> Scott, someone asked earlier in the thread what the rush to do this
> now instead of in 6 months is. I'm still waiting for someone to
> articulate a satisfactory answer. I don't care why it's important to
> APNIC registrants, I want to know why it's important to ARIN
> registrants that we do this right now.
> 

Contrary to the opinions expressed here by some, it is important to
do this now because of need in the APNIC region. We have a
responsibility of stewardship. While our service region is defined
more narrowly, we are also part of a global community (NRO) and
we have a responsibility to work with the other members of the NRO
to accomplish good stewardship of the resources on a global scale,
not just within our region.

Hoarding resources while another region suffers under shortage
is not good global stewardship. This is a small step in the right
direction.

> Even if there is a good reason to rush, the conservative course of
> action would be to advance 2011-1 after restoring the stronger
> protections that were in the earlier text and then spend the next 6
> months talking about how to tone them down to something less onerous.
> That would avoid any chance of the board needing to take emergency
> action and, oh by the way, it's what cautious stewardship of a
> resource is all about.
> 

There are tradeoffs in either direction and there are consequences
to delay just as there may be consequences to some of the holes
in the present draft. I honestly can't say which choice carries the
bigger risk and I'm not sure that anyone has enough information
available to make an accurate judgment on the question.

Owen



From bill at herrin.us  Tue Oct 25 08:50:46 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 25 Oct 2011 08:50:46 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
 ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CB99A64B-45D4-48AD-8314-212F9F16F7DE@delong.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<201110242319.21203.paul@redbarn.org>
	<CAP-guGUPdsrD7sxvswTv+8mAkSKdDo8bu2X_uU83cXuJeCdtRA@mail.gmail.com>
	<CAAAwwbU2sH6xmdxfap-TsUwg1J2aF4OuZrp7DNizw-uGwYfgCA@mail.gmail.com>
	<CAGkMwz4TuXRKrqANkETnxAhbna=KQ26GXRKwtOPACcqvxnQP8w@mail.gmail.com>
	<CAP-guGUb3C=4xfJrLGDYWGNO+X6-4UQ6Qz03B+c=pau62qG78w@mail.gmail.com>
	<CB99A64B-45D4-48AD-8314-212F9F16F7DE@delong.com>
Message-ID: <CAP-guGV_wZtpjKkoWqtkpdCi0r3EQ48cfevsdfOLouH2FhzRng@mail.gmail.com>

On Tue, Oct 25, 2011 at 5:44 AM, Owen DeLong <owen at delong.com> wrote:
> On Oct 24, 2011, at 10:58 PM, William Herrin wrote
>> Scott, someone asked earlier in the thread what the rush to do this
>> now instead of in 6 months is. I'm still waiting for someone to
>> articulate a satisfactory answer. I don't care why it's important to
>> APNIC registrants, I want to know why it's important to ARIN
>> registrants that we do this right now.
>
> Contrary to the opinions expressed here by some, it is important to
> do this now because of need in the APNIC region.

Still waiting to hear why it's important to the *ARIN region* that we
do this now.

I don't think anyone fails to understand why APNIC is in a hurry for
ARIN to implement this sort of policy.


> We have a
> responsibility of stewardship. While our service region is defined
> more narrowly, we are also part of a global community (NRO) and
> we have a responsibility to work with the other members of the NRO
> to accomplish good stewardship of the resources on a global scale,
> not just within our region.
>
> Hoarding resources while another region suffers under shortage
> is not good global stewardship.

Owen,

Repeat after me. ARIN is not IANA. Our responsibility is first to our region.


Global cooperation benefits everybody, including our region. But the
devil is in the details and those details have to well serve our
region too. Every indication we've gotten from exploring with John
Curran the way in which ARIN would implement the current 2011-1 draft
has suggested problems in those details.



>> Even if there is a good reason to rush, the conservative course of
>> action would be to advance 2011-1 after restoring the stronger
>> protections that were in the earlier text and then spend the next 6
>> months talking about how to tone them down to something less onerous.
>> That would avoid any chance of the board needing to take emergency
>> action and, oh by the way, it's what cautious stewardship of a
>> resource is all about.
>
> There are tradeoffs in either direction and there are consequences
> to delay just as there may be consequences to some of the holes
> in the present draft. I honestly can't say which choice carries the
> bigger risk and I'm not sure that anyone has enough information
> available to make an accurate judgment on the question.

Would you articulate the RISK of consequences you see to the ARIN
region from delaying this policy for another 6-month cycle while we
hash out appropriate protections?

Would you articular the RISK of consequences you see to the ARIN
region from installing strong protections in an immediate policy (e.g.
making recipients meet ARIN justified need criteria regardless of
their region) and then toning them down with subsequent policy over
the next 6 months?

I have, I believe, expansively articulated the risk to the ARIN region
from advancing this proposal with the lack of protections in the
current draft, the main ones being:

1. Much easier and therefore unfair out-region access to ARIN
transfers than in-region access.
2. Enabling the out-region loss of the remaining ARIN free pool.
3. Likelihood of unforeseen and unintended consequences from rewriting
the in-region transfer policy when only authorship of an out-region
transfer policy was requested by the community.

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 john.sweeting at twcable.com  Tue Oct 25 09:37:06 2011
From: john.sweeting at twcable.com (Sweeting, John)
Date: Tue, 25 Oct 2011 09:37:06 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
Message-ID: <CACC32A7.BF64%john.sweeting@twcable.com>



On 10/24/11 8:37 PM, "William Herrin" <bill at herrin.us> wrote:

>On Mon, Oct 24, 2011 at 7:58 PM, Jimmy Hess <mysidia at gmail.com> wrote:
>> On Mon, Oct 24, 2011 at 5:03 PM, John Curran <jcurran at arin.net> wrote:
>>>  I agree that presently this new entrant "loophole" could
>>>  potentially be exacerbated by an InterRIR transfer policy;
>>>  I just wanted to  make it clear that it may also be a serious
>>>  problem as we approach in-region depletion in general.
>>
>> There is a way we could avoid InterRIR transfer policy exacerbating
>>this...
>> ARIN could allow applicants from _any_  service region  to apply for
>> resources from the free pool,
>> via a  inter-RIR  "cross application" deal.
>
>Jimmy,
>
>That would be functional. But is it fair? We still have a free pool
>because having learned our lessons in the Internic days, we were
>restrictive with addresses when some other regions were not.

Bill,

Would it be possible for you to back this claim up with facts? I am very
curious which regions were not restrictive and the policies that allowed
that.

Thanks,
John

> We would
>be allowing other regions with much less restrictive policies to
>deplete the remaining resource we so carefully managed.
>
>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 bill at herrin.us  Tue Oct 25 11:35:04 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 25 Oct 2011 11:35:04 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CACC32A7.BF64%john.sweeting@twcable.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
Message-ID: <CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>

On Tue, Oct 25, 2011 at 9:37 AM, Sweeting, John
<john.sweeting at twcable.com> wrote:
> On 10/24/11 8:37 PM, "William Herrin" <bill at herrin.us> wrote:
>>That would be functional. But is it fair? We still have a free pool
>>because having learned our lessons in the Internic days, we were
>>restrictive with addresses when some other regions were not.
>
> Would it be possible for you to back this claim up with facts?

John,

For a statement of opinion? Not so much. Nor do I want to get
sidetracked into a discussion about whether carelessness at APNIC is
to blame for their running out of addresses first. With the IANA free
pool gone, I depart from the view some folks hold about "compatible
needs-based policies" in that I couldn't care less about how APNIC
manages its IPv4 addresses.

I care about how our region, the ARIN region, manages OUR addresses. I
find the idea that we're going to make OUR IPv4 addresses more easily
available to folks in the APNIC region than they are to folks here at
home to be highly objectionable. And if you're not conversant with the
facts that back up my claim draft 2011-1 does precisely that, please
reread the thread.

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  Tue Oct 25 11:48:11 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Oct 2011 08:48:11 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re:
	ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGV_wZtpjKkoWqtkpdCi0r3EQ48cfevsdfOLouH2FhzRng@mail.gmail.com>
References: <CAMDXq5PiiN9-jTibfWD3ZQgCB79t6g-3cMwT_9GJncSU_214NQ@mail.gmail.com>
	<735EF76B2CC947B19A7D1CF10A86D75C@video>
	<CAP-guGX4Qh8WsuC8WdU+wriQdE4wDymEC4LO3zt=bbYZLZghtQ@mail.gmail.com>
	<201110242319.21203.paul@redbarn.org>
	<CAP-guGUPdsrD7sxvswTv+8mAkSKdDo8bu2X_uU83cXuJeCdtRA@mail.gmail.com>
	<CAAAwwbU2sH6xmdxfap-TsUwg1J2aF4OuZrp7DNizw-uGwYfgCA@mail.gmail.com>
	<CAGkMwz4TuXRKrqANkETnxAhbna=KQ26GXRKwtOPACcqvxnQP8w@mail.gmail.com>
	<CAP-guGUb3C=4xfJrLGDYWGNO+X6-4UQ6Qz03B+c=pau62qG78w@mail.gmail.com>
	<CB99A64B-45D4-48AD-8314-212F9F16F7DE@delong.com>
	<CAP-guGV_wZtpjKkoWqtkpdCi0r3EQ48cfevsdfOLouH2FhzRng@mail.gmail.com>
Message-ID: <2C8A89A8-9DA6-412B-9AA5-F5014C9D8970@delong.com>


On Oct 25, 2011, at 5:50 AM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 5:44 AM, Owen DeLong <owen at delong.com> wrote:
>> On Oct 24, 2011, at 10:58 PM, William Herrin wrote
>>> Scott, someone asked earlier in the thread what the rush to do this
>>> now instead of in 6 months is. I'm still waiting for someone to
>>> articulate a satisfactory answer. I don't care why it's important to
>>> APNIC registrants, I want to know why it's important to ARIN
>>> registrants that we do this right now.
>> 
>> Contrary to the opinions expressed here by some, it is important to
>> do this now because of need in the APNIC region.
> 
> Still waiting to hear why it's important to the *ARIN region* that we
> do this now.
> 
> I don't think anyone fails to understand why APNIC is in a hurry for
> ARIN to implement this sort of policy.
> 

Because in the end, it is a global internet and we sink or swim together.

> 
>> We have a
>> responsibility of stewardship. While our service region is defined
>> more narrowly, we are also part of a global community (NRO) and
>> we have a responsibility to work with the other members of the NRO
>> to accomplish good stewardship of the resources on a global scale,
>> not just within our region.
>> 
>> Hoarding resources while another region suffers under shortage
>> is not good global stewardship.
> 
> Owen,
> 
> Repeat after me. ARIN is not IANA. Our responsibility is first to our region.
> 
Bill, repeat after me, Jingoism is not the ideal approach to resource
stewardship.

> 
> Global cooperation benefits everybody, including our region. But the
> devil is in the details and those details have to well serve our
> region too. Every indication we've gotten from exploring with John
> Curran the way in which ARIN would implement the current 2011-1 draft
> has suggested problems in those details.
> 

Personally, I believe that having all of the regions run out as close to the
same time as possible DOES serve our region in that it reduces the
probability of entering the workaround merry-go-round track that is
nicely presented in Geoff Huston's presentation from the ARIN/NANOG
joint session. Perhaps you missed it?

> 
> 
>>> Even if there is a good reason to rush, the conservative course of
>>> action would be to advance 2011-1 after restoring the stronger
>>> protections that were in the earlier text and then spend the next 6
>>> months talking about how to tone them down to something less onerous.
>>> That would avoid any chance of the board needing to take emergency
>>> action and, oh by the way, it's what cautious stewardship of a
>>> resource is all about.
>> 
>> There are tradeoffs in either direction and there are consequences
>> to delay just as there may be consequences to some of the holes
>> in the present draft. I honestly can't say which choice carries the
>> bigger risk and I'm not sure that anyone has enough information
>> available to make an accurate judgment on the question.
> 
> Would you articulate the RISK of consequences you see to the ARIN
> region from delaying this policy for another 6-month cycle while we
> hash out appropriate protections?
> 

No. Not because I don't want to, but, because it would be difficult to
or impossible to separate what I see as a result of public information
from what I see as a result of NDA information and remove the pieces
that are covered by NDA.

> Would you articular the RISK of consequences you see to the ARIN
> region from installing strong protections in an immediate policy (e.g.
> making recipients meet ARIN justified need criteria regardless of
> their region) and then toning them down with subsequent policy over
> the next 6 months?
> 

First, your claim that the other regions have weaker justification policy
is specious at best. I suppose the easy thing to do here would be to
ask you to prove your assertion. The risk to such language is that it
would embroil the ARIN staff in a maze of language, cultural, and
other issues. Since there's no benefit to doing so as I believe that the
other RIRs already provide equivalent justification requirements and
the existing policy is an equally strong protection, it seems like a
huge unnecessary overhead and expense to ARIN.

> I have, I believe, expansively articulated the risk to the ARIN region
> from advancing this proposal with the lack of protections in the
> current draft, the main ones being:
> 
Not really. You have, however, extensively articulated an
us against them jingoistic view of the internet.

> 1. Much easier and therefore unfair out-region access to ARIN
> transfers than in-region access.

I don't see this. It appears to me that it provides nearly identical
access to transfers.

> 2. Enabling the out-region loss of the remaining ARIN free pool.

As has been pointed out, this is a relatively minimal risk. Frankly, I also
don't see this as necessarily being a bad thing overall.

> 3. Likelihood of unforeseen and unintended consequences from rewriting
> the in-region transfer policy when only authorship of an out-region
> transfer policy was requested by the community.
> 

I think this is much ado about nothing. The proposed changes have no effect
on the in-region transfer policy other than to expand it to include out-of-region
transfers. They do not weaken it or change the requirements in any way.
The removal of the single aggregate clause is the only change you could
hold up as an example of having unintended consequences and that change
has community consensus and is also in last call at this time under a different
policy number.

Owen



From jcurran at arin.net  Tue Oct 25 12:24:35 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 25 Oct 2011 16:24:35 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
Message-ID: <BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>

On Oct 25, 2011, at 3:35 PM, William Herrin wrote:

> I care about how our region, the ARIN region, manages OUR addresses.

Bill - 

 Per RFC 2050, IP address space is allocated to each of the RIRs 
 according to its established need.  Referring to such address 
 space as OUR addresses (with the implication that it is to be 
 used in region due to our imminent need) does make perfect sense.

 However, I also want to note that we collectively departed from
 RFC 2050 with both the final /8 and the cleanup of the various
 registries space.  There was never an application by ARIN to the
 IANA to receive this space, and while it may still be "OUR" space, 
 it is not a function of any need from ARIN or the application of 
 any special conservation efforts.

 I believe that we should appropriately safeguard the resources 
 assigned to this region, but wanted to note that our bounty is 
 likely more of circumstance than planning.  

 Note - another option (if the community is concerned about ARIN's 
 free pool being depleted for future xfers) would be to simply 
 disqualify all space issued henceforth from ARIN's available pool 
 from future specified transfer until the ARIN has no free space 
 remaining.  This is an imperfect control (due to the ability with
 some effort to swap out older assignments) but might be sufficient 
 under the circumstances.

FYI,
/John

John Curran
President and CEO
ARIN



From randy.whitney at verizon.com  Tue Oct 25 12:57:22 2011
From: randy.whitney at verizon.com (Randy Whitney)
Date: Tue, 25 Oct 2011 12:57:22 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
Message-ID: <4EA6EA72.5010409@verizon.com>

On 10/25/2011 12:24 PM, John Curran wrote:
>
>   Note - another option (if the community is concerned about ARIN's
>   free pool being depleted for future xfers) would be to simply
>   disqualify all space issued henceforth from ARIN's available pool
>   from future specified transfer until the ARIN has no free space
>   remaining.  This is an imperfect control (due to the ability with
>   some effort to swap out older assignments) but might be sufficient
>   under the circumstances.
>
> FYI,
> /John

I oppose this new wording. I can think of just as many hypothetical
opposite cases where this would cause future problems as those in the
vocal tiny protectionist minority against adopting the transfer policy
in the first place would, in support of this wording.

Regards,
Randy.



From jcurran at arin.net  Tue Oct 25 13:02:37 2011
From: jcurran at arin.net (John Curran)
Date: Tue, 25 Oct 2011 17:02:37 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <4EA6EA72.5010409@verizon.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<4EA6EA72.5010409@verizon.com>
Message-ID: <CDBBF5E7-3404-4927-825D-CD3EE003ADE4@arin.net>

On Oct 25, 2011, at 4:57 PM, Randy Whitney wrote:

> On 10/25/2011 12:24 PM, John Curran wrote:
>> 
>>  Note - another option (if the community is concerned about ARIN's
>>  free pool being depleted for future xfers) would be to simply
>>  disqualify all space issued henceforth from ARIN's available pool
>>  from future specified transfer until the ARIN has no free space
>>  remaining.  This is an imperfect control (due to the ability with
>>  some effort to swap out older assignments) but might be sufficient
>>  under the circumstances.
>> 
>> FYI,
>> /John
> 
> I oppose this new wording. I can think of just as many hypothetical
> opposite cases where this would cause future problems as those in the
> vocal tiny protectionist minority against adopting the transfer policy
> in the first place would, in support of this wording.

Understood.

To be clear, I definitely was not recommending such a change, but only 
pointing it out as a potential mechanism that had not had any discussion 
to date.  The need for _any_ additional controls is clearly still a matter 
of active discussion by the community.

FYI,
/John

John Curran
President, CEO, 
& Speed Typist
ARIN






From michael+ppml at burnttofu.net  Tue Oct 25 15:49:43 2011
From: michael+ppml at burnttofu.net (Michael Sinatra)
Date: Tue, 25 Oct 2011 12:49:43 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CDBBF5E7-3404-4927-825D-CD3EE003ADE4@arin.net>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<4EA6EA72.5010409@verizon.com>
	<CDBBF5E7-3404-4927-825D-CD3EE003ADE4@arin.net>
Message-ID: <4EA712D7.4070808@burnttofu.net>

On 10/25/11 10:02 AM, John Curran wrote:
> On Oct 25, 2011, at 4:57 PM, Randy Whitney wrote:
>
>> On 10/25/2011 12:24 PM, John Curran wrote:
>>>
>>>   Note - another option (if the community is concerned about ARIN's
>>>   free pool being depleted for future xfers) would be to simply
>>>   disqualify all space issued henceforth from ARIN's available pool
>>>   from future specified transfer until the ARIN has no free space
>>>   remaining.  This is an imperfect control (due to the ability with
>>>   some effort to swap out older assignments) but might be sufficient
>>>   under the circumstances.
>>>
>>> FYI,
>>> /John
>>
>> I oppose this new wording. I can think of just as many hypothetical
>> opposite cases where this would cause future problems as those in the
>> vocal tiny protectionist minority against adopting the transfer policy
>> in the first place would, in support of this wording.
>
> Understood.
>
> To be clear, I definitely was not recommending such a change, but only
> pointing it out as a potential mechanism that had not had any discussion
> to date.  The need for _any_ additional controls is clearly still a matter
> of active discussion by the community.

Part of the problem is that there are too many distortions caused by the 
uneven run-out in the various regions.  I see this discussion as an 
attempt to ensure that we are affixing the doily on the rump of IPv4 in 
the most precise manner possible.  There is a limit to the extent that 
policy tweaking can do that, as the current market distortion is 
significant.

A major way to reduce the current distortion, while continuing to 
provide IPv4 space to those who need it, is to liberalize (contra Mike 
Burns) the allocation policy from the free pool and make it consistent 
with the transfer policy.  ARIN currently has the largest free pool, and 
as long as that's the case, we will have to sit here and wring our hands 
about the last few bits of IPv4 trickling to another region while we 
shoot legitimate ISPs in the foot by making them request IPv4 space in 
three-month chunks.  I'd be all for removing this text from NRPM 4.2.4.4:

"When ARIN receives its last /8, by IANA implementing section 10.4.2.2, 
the length of supply that an organization may request will be reduced. 
An organization may choose to request up to a 3-month supply of IP 
addresses."

I continue to support 2011-1, as I did in Philadelphia, and I support 
making the needs polices consistent, transfer-vs-free-pool.

michael





From mike at nationwideinc.com  Tue Oct 25 16:40:02 2011
From: mike at nationwideinc.com (Mike Burns)
Date: Tue, 25 Oct 2011 16:40:02 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re:
	ARIN-2011-1:ARINInter-RIRTransfers - Last Call
In-Reply-To: <4EA712D7.4070808@burnttofu.net>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com><CACC32A7.BF64%john.sweeting@twcable.com><CAP-guG
	XiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com><BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net><4EA6EA72.5010409@ve
	rizon.com><CDBBF5E7-3404-4927-825D-CD3EE003ADE4@arin.net>
	<4EA712D7.4070808@burnttofu.net>
Message-ID: <6F5F4EAA57D842C9AE1B59FBE59116CD@MPC>

Hi Michael,

I simply restate my position that maintaining a needs requirement for
transfers will drive transactions off the books, particularly in the case of
legacy space which is under no agreement with ARIN.
Our highest priority is maintaining uniqueness through registration, and a
free transfer market will ensure conservation.

Your stance on keeping free-pool policy versus transfer policy the same is
at odds with your support of 2011-1 as written, because every RIR decides
its own transfer policy, which does not have to match ARIN's to allow 
recipients to receive transfers, but only ARIN decides ARIN free pool 
policy.

I have said earlier that if the issue is fairness to ARIN members who may
face higher restrictions on free pool addresses than non-ARIN  members do
through their own RIR's transfer  policy, my prescription would be to reduce
ARIN restrictions to match the other RIR's.  I am all for a race towards the
free-est transfer market.

If the issue is protecting the remaining free pool from those who would
plunder it through gamesmanship and/or fraud, then I think we should be
discussing policy which protects the free pool.
For which I have suggested banning recent free pool allocants from selling
addresses for some time, and John has suggested preventing the transfer of
addresses allocated herewith from the free pool until exhaust.

I also suggested the inclusion of a declared intention clause to the RSA
which would allow for ARIN to claim fraud based on prior bad acts by
allocants, and further work on detecting related legal entities who may be
seeking to acquire addresses through shells.

For the record I support extending the 3 month window for free pool
allocations, which I think is just too short. I don't object to making the
free pool requirements match the *current* transfer requirements, it's just
that I support dropping the needs requirement for transfers to incentivize
registration of transactions.


Regards,
Mike



-----Original Message----- 
From: Michael Sinatra
Sent: Tuesday, October 25, 2011 3:49 PM
To: arin-ppml at arin.net List
Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: 
ARIN-2011-1:ARINInter-RIRTransfers - Last Call

On 10/25/11 10:02 AM, John Curran wrote:
> On Oct 25, 2011, at 4:57 PM, Randy Whitney wrote:
>
>> On 10/25/2011 12:24 PM, John Curran wrote:
>>>
>>>   Note - another option (if the community is concerned about ARIN's
>>>   free pool being depleted for future xfers) would be to simply
>>>   disqualify all space issued henceforth from ARIN's available pool
>>>   from future specified transfer until the ARIN has no free space
>>>   remaining.  This is an imperfect control (due to the ability with
>>>   some effort to swap out older assignments) but might be sufficient
>>>   under the circumstances.
>>>
>>> FYI,
>>> /John
>>
>> I oppose this new wording. I can think of just as many hypothetical
>> opposite cases where this would cause future problems as those in the
>> vocal tiny protectionist minority against adopting the transfer policy
>> in the first place would, in support of this wording.
>
> Understood.
>
> To be clear, I definitely was not recommending such a change, but only
> pointing it out as a potential mechanism that had not had any discussion
> to date.  The need for _any_ additional controls is clearly still a matter
> of active discussion by the community.

Part of the problem is that there are too many distortions caused by the
uneven run-out in the various regions.  I see this discussion as an
attempt to ensure that we are affixing the doily on the rump of IPv4 in
the most precise manner possible.  There is a limit to the extent that
policy tweaking can do that, as the current market distortion is
significant.

A major way to reduce the current distortion, while continuing to
provide IPv4 space to those who need it, is to liberalize (contra Mike
Burns) the allocation policy from the free pool and make it consistent
with the transfer policy.  ARIN currently has the largest free pool, and
as long as that's the case, we will have to sit here and wring our hands
about the last few bits of IPv4 trickling to another region while we
shoot legitimate ISPs in the foot by making them request IPv4 space in
three-month chunks.  I'd be all for removing this text from NRPM 4.2.4.4:

"When ARIN receives its last /8, by IANA implementing section 10.4.2.2,
the length of supply that an organization may request will be reduced.
An organization may choose to request up to a 3-month supply of IP
addresses."

I continue to support 2011-1, as I did in Philadelphia, and I support
making the needs polices consistent, transfer-vs-free-pool.

michael



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



From bill at herrin.us  Tue Oct 25 18:35:00 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 25 Oct 2011 18:35:00 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
Message-ID: <CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>

On Tue, Oct 25, 2011 at 12:24 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
>> I care about how our region, the ARIN region, manages OUR addresses.
>> I find the idea that we're going to make OUR IPv4 addresses more
>> easily available to folks in the APNIC region than they are to folks
>> here at home to be highly objectionable.
>
> ?Per RFC 2050, IP address space is allocated to each of the RIRs
> ?according to its established need. ?Referring to such address
> ?space as OUR addresses (with the implication that it is to be
> ?used in region due to our imminent need) does make perfect sense.
> [...]
>  Note - another option (if the community is concerned about ARIN's
>  free pool being depleted for future xfers) would be to simply
>  disqualify all space issued henceforth from ARIN's available pool
>  from future specified transfer until the ARIN has no free space
>  remaining.

John,

I could bend on the desire to rush 2011-1 through. Rushing is usually
destructive but I can bend. I can bend on the desire to integrate the
change with section 8.3. It's certain to have unintended consequences
but who am I to tell the community not to shoot itself in the foot. I
might even be sold on the idea that allowing other regions some
limited access to our remaining free pool is a generous and worthy
thing to do. It'll be gone soon enough anyway; why not be nice guys?

I can't bend on the idea that we'll let other regions set their own,
LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
continue to apply more restrictive rules to identical registrants here
at home. That is beyond careless stewardship. If I may borrow your
turn of phrase, it violates a fundamental expectation of any fair and
equitable industry self-regulation.

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  Tue Oct 25 20:16:59 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Oct 2011 17:16:59 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
	ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
Message-ID: <886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>


On Oct 25, 2011, at 3:35 PM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 12:24 PM, John Curran <jcurran at arin.net> wrote:
>> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
>>> I care about how our region, the ARIN region, manages OUR addresses.
>>> I find the idea that we're going to make OUR IPv4 addresses more
>>> easily available to folks in the APNIC region than they are to folks
>>> here at home to be highly objectionable.
>> 
>>  Per RFC 2050, IP address space is allocated to each of the RIRs
>>  according to its established need.  Referring to such address
>>  space as OUR addresses (with the implication that it is to be
>>  used in region due to our imminent need) does make perfect sense.
>> [...]
>> Note - another option (if the community is concerned about ARIN's
>> free pool being depleted for future xfers) would be to simply
>> disqualify all space issued henceforth from ARIN's available pool
>> from future specified transfer until the ARIN has no free space
>> remaining.
> 
> John,
> 
> I could bend on the desire to rush 2011-1 through. Rushing is usually
> destructive but I can bend. I can bend on the desire to integrate the
> change with section 8.3. It's certain to have unintended consequences
> but who am I to tell the community not to shoot itself in the foot. I
> might even be sold on the idea that allowing other regions some
> limited access to our remaining free pool is a generous and worthy
> thing to do. It'll be gone soon enough anyway; why not be nice guys?
> 
> I can't bend on the idea that we'll let other regions set their own,
> LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
> continue to apply more restrictive rules to identical registrants here
> at home. That is beyond careless stewardship. If I may borrow your
> turn of phrase, it violates a fundamental expectation of any fair and
> equitable industry self-regulation.
> 

Can you back up this claim with any form of evidence or fact? I don't believe
that the other RIRs have less-stringent-than-ARIN policies as you claim. At
least not to any meaningful extent.


Owen




From bill at herrin.us  Tue Oct 25 20:25:48 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 25 Oct 2011 20:25:48 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
Message-ID: <CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>

On Tue, Oct 25, 2011 at 8:16 PM, Owen DeLong <owen at delong.com> wrote:
> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
>> I can't bend on the idea that we'll let other regions set their own,
>> LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
>> continue to apply more restrictive rules to identical registrants here
>> at home. That is beyond careless stewardship. If I may borrow your
>> turn of phrase, it violates a fundamental expectation of any fair and
>> equitable industry self-regulation.
>
> Can you back up this claim with any form of evidence or fact?

"Under the proposed policy text, it does not matter if the other RIRs
requirements are more or less strict than ARIN's" -- John Curran,
10/20/2011 explaining ARIN's interpretation of the 2011-1 text.

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 Oct 25 20:32:11 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 26 Oct 2011 00:32:11 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
Message-ID: <EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>


On Oct 26, 2011, at 12:25 AM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 8:16 PM, Owen DeLong <owen at delong.com> wrote:
>> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
>>> I can't bend on the idea that we'll let other regions set their own,
>>> LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
>>> continue to apply more restrictive rules to identical registrants here
>>> at home. That is beyond careless stewardship. If I may borrow your
>>> turn of phrase, it violates a fundamental expectation of any fair and
>>> equitable industry self-regulation.
>> 
>> Can you back up this claim with any form of evidence or fact?
> 
> "Under the proposed policy text, it does not matter if the other RIRs
> requirements are more or less strict than ARIN's" -- John Curran,
> 10/20/2011 explaining ARIN's interpretation of the 2011-1 text.

Bill - 
 
  That is simply a fact regarding the 2011-1 proposed policy; it is not a 
  statement about any particular RIRs policy being actually being more or
  less stringent today.

FYI,
/John

John Curran
President and CEO
ARIN



From owen at delong.com  Tue Oct 25 20:33:50 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Oct 2011 17:33:50 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
	ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
Message-ID: <5F17EB53-768B-4147-A611-99DDE56ED176@delong.com>


On Oct 25, 2011, at 5:25 PM, William Herrin wrote:

> On Tue, Oct 25, 2011 at 8:16 PM, Owen DeLong <owen at delong.com> wrote:
>> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
>>> I can't bend on the idea that we'll let other regions set their own,
>>> LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
>>> continue to apply more restrictive rules to identical registrants here
>>> at home. That is beyond careless stewardship. If I may borrow your
>>> turn of phrase, it violates a fundamental expectation of any fair and
>>> equitable industry self-regulation.
>> 
>> Can you back up this claim with any form of evidence or fact?
> 
> "Under the proposed policy text, it does not matter if the other RIRs
> requirements are more or less strict than ARIN's" -- John Curran,
> 10/20/2011 explaining ARIN's interpretation of the 2011-1 text.
> 

That is not the same as claiming that other RIRs have a less restrictive
policy. Can you back that claim up specifically. I do not believe it currently
holds true.

Owen



From bill at herrin.us  Tue Oct 25 20:37:11 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 25 Oct 2011 20:37:11 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
Message-ID: <CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>

On Tue, Oct 25, 2011 at 8:32 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 26, 2011, at 12:25 AM, William Herrin wrote:
>> On Tue, Oct 25, 2011 at 8:16 PM, Owen DeLong <owen at delong.com> wrote:
>>> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
>>>> I can't bend on the idea that we'll let other regions set their own,
>>>> LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
>>>> continue to apply more restrictive rules to identical registrants here
>>>> at home. That is beyond careless stewardship. If I may borrow your
>>>> turn of phrase, it violates a fundamental expectation of any fair and
>>>> equitable industry self-regulation.
>>>
>>> Can you back up this claim with any form of evidence or fact?
>>
>> "Under the proposed policy text, it does not matter if the other RIRs
>> requirements are more or less strict than ARIN's" -- John Curran,
>> 10/20/2011 explaining ARIN's interpretation of the 2011-1 text.
>
> ?That is simply a fact regarding the 2011-1 proposed policy; it is not a
> ?statement about any particular RIRs policy being actually being more or
> ?less stringent today.

As is my statement quoted above. Or is there some other interpretation
of "we'll LET other regions SET their own, less-stringent" that I'm
not aware of?

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  Tue Oct 25 21:01:36 2011
From: bill at herrin.us (William Herrin)
Date: Tue, 25 Oct 2011 21:01:36 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
Message-ID: <CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>

On Tue, Oct 25, 2011 at 8:37 PM, William Herrin <bill at herrin.us> wrote:
> On Tue, Oct 25, 2011 at 8:32 PM, John Curran <jcurran at arin.net> wrote:
>> On Oct 26, 2011, at 12:25 AM, William Herrin wrote:
>>> On Tue, Oct 25, 2011 at 8:16 PM, Owen DeLong <owen at delong.com> wrote:
>>>> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
>>>>> I can't bend on the idea that we'll let other regions set their own,
>>>>> LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
>>>>> continue to apply more restrictive rules to identical registrants here
>>>>> at home. That is beyond careless stewardship. If I may borrow your
>>>>> turn of phrase, it violates a fundamental expectation of any fair and
>>>>> equitable industry self-regulation.
>>>>
>>>> Can you back up this claim with any form of evidence or fact?
>>>
>>> "Under the proposed policy text, it does not matter if the other RIRs
>>> requirements are more or less strict than ARIN's" -- John Curran,
>>> 10/20/2011 explaining ARIN's interpretation of the 2011-1 text.
>>
>> ?That is simply a fact regarding the 2011-1 proposed policy; it is not a
>> ?statement about any particular RIRs policy being actually being more or
>> ?less stringent today.
>
> As is my statement quoted above. Or is there some other interpretation
> of "we'll LET other regions SET their own, less-stringent" that I'm
> not aware of?



But what they hey, as long as you've broached the subject:

In your view, which of the other four RIRs presently implement a
transfer policy whose minimum path through the policy-derived process
appiles as restrictive or more restrictive rules on the recipient than
ARIN's? I won't ask you to "prove it" in each case, but as few of us
here are experts in other RIRs' policies I will ask you to explain
your reasoning.

My statement looked to the horizon, to the possibilities, but I think
it might be interesting to know the immediate game on the ground as
well.

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 kevinb at thewire.ca  Tue Oct 25 23:33:55 2011
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Wed, 26 Oct 2011 03:33:55 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re:
	ARIN-2011-1:	ARINInter-RIRTransfers - Last Call
In-Reply-To: <5F17EB53-768B-4147-A611-99DDE56ED176@delong.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<5F17EB53-768B-4147-A611-99DDE56ED176@delong.com>
Message-ID: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>

Own,

This is my major issue with the rewrite. The reality is that the current text
in last call doesn't deal with another region relaxing their policies to still
fit within the word "compatible".

A policy needs to be able to be forward looking. The rewrite of 2011-1 would
now allow another RIR to modify the intent of our policy by solely relaxing their own polices.

While I believe the ARIN AC has done a lot towards cleaning up the text, the shift of 
responsibility to outside our region is deeply concerning. 

Example Policy Proposal from Region XYZ post adoption:

"Parties requesting Inter-RIR transfers may do so with 48 month justification criteria
based on 50 percent current utilization".


Kevin Blumberg
T 416.214.9473 x31
F 416.862.9473
kevinb at thewire.ca






> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Tuesday, October 25, 2011 8:34 PM
> To: William Herrin
> Cc: John Curran; arin-ppml at arin.net List
> Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARINInter-
> RIRTransfers - Last Call
> 
> 
> On Oct 25, 2011, at 5:25 PM, William Herrin wrote:
> 
> > On Tue, Oct 25, 2011 at 8:16 PM, Owen DeLong <owen at delong.com>
> wrote:
> >> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
> >>> I can't bend on the idea that we'll let other regions set their own,
> >>> LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
> >>> continue to apply more restrictive rules to identical registrants
> >>> here at home. That is beyond careless stewardship. If I may borrow
> >>> your turn of phrase, it violates a fundamental expectation of any
> >>> fair and equitable industry self-regulation.
> >>
> >> Can you back up this claim with any form of evidence or fact?
> >
> > "Under the proposed policy text, it does not matter if the other RIRs
> > requirements are more or less strict than ARIN's" -- John Curran,
> > 10/20/2011 explaining ARIN's interpretation of the 2011-1 text.
> >
> 
> That is not the same as claiming that other RIRs have a less restrictive policy.
> Can you back that claim up specifically. I do not believe it currently holds true.
> 
> 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.


From mysidia at gmail.com  Tue Oct 25 23:49:28 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 25 Oct 2011 22:49:28 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
	<CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
Message-ID: <CAAAwwbXkv=8AbO+caGTfB0Ehuki_Wa2-tis529aKWz3zP9V85A@mail.gmail.com>

[snip]> But what they hey, as long as you've broached the subject:
> In your view, which of the other four RIRs presently implement a
> transfer policy whose minimum path through the policy-derived process
> appiles as restrictive or more restrictive rules on the recipient than
> ARIN's? I won't ask you to "prove it" in each case, but as few of us
> here are experts in other RIRs' policies I will ask you to explain
[snip]
Other "RIR policies" are not fixed.   We can't say the transfer policy
is "OK" based on other RIRs' current policies, when the other RIRs'
communities can choose to change them at any time.
How could we possiblty anticipate what their rules will be when most
RIRs don't even have any kind of Inter-RIR transfer policy?


The other RIRs are free to revise their own policies, ARIN should not
have a "variable" policy
that becomes more restrictive or less restrictive,  depending on
actions other organizations take from time to time.   The other RIRs
do not have to consult with the ARIN community to make their
transfer policies more restrictive or less restrictive,  and do not
have to consult with the ARIN community
in regards to how they choose to interpret their policies.

A recent proposal @ AfriNic   to allow members to transfer addresses
(within region)  contained text like this;     I think it's safe to
say  ARIN's  8.3 is a lot more restrictive  than the draft they have :

http://www.afrinic.net/docs/policies/AFPUB-2011-v4-001-draft-01.htm
"2.1) Legacy members can transfer part or all of their IPv4 addresses
to any company under the following criteria: ....
a) The company to which the addresses are transferred may or may not
enter into agreement with AfriNIC.
b) The legacy member may or may not inform AfriNIC about the transaction.
c) AfriNIC will accord the third party all relevant access to services
and benefits normally available to legacy members.

2.2) Paying AfriNIC members can transfer part or all of their IPv4
addresses to any company under the following criteria:  ....
b) The transfer and needs analysis cannot be based on any current
policies. The only requirement for the transfer to happen should be
the contract between the member and AfriNIC.
...
"


--
-JH


From scottleibrand at gmail.com  Wed Oct 26 00:14:38 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 25 Oct 2011 21:14:38 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAAAwwbXkv=8AbO+caGTfB0Ehuki_Wa2-tis529aKWz3zP9V85A@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
	<CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
	<CAAAwwbXkv=8AbO+caGTfB0Ehuki_Wa2-tis529aKWz3zP9V85A@mail.gmail.com>
Message-ID: <1489706012370923377@unknownmsgid>

On Oct 25, 2011, at 8:49 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> [snip]> But what they hey, as long as you've broached the subject:
>> In your view, which of the other four RIRs presently implement a
>> transfer policy whose minimum path through the policy-derived process
>> appiles as restrictive or more restrictive rules on the recipient than
>> ARIN's? I won't ask you to "prove it" in each case, but as few of us
>> here are experts in other RIRs' policies I will ask you to explain
> [snip]
> Other "RIR policies" are not fixed.   We can't say the transfer policy
> is "OK" based on other RIRs' current policies, when the other RIRs'
> communities can choose to change them at any time.
> How could we possiblty anticipate what their rules will be when most
> RIRs don't even have any kind of Inter-RIR transfer policy?
>
>
> The other RIRs are free to revise their own policies, ARIN should not
> have a "variable" policy
> that becomes more restrictive or less restrictive,  depending on
> actions other organizations take from time to time.   The other RIRs
> do not have to consult with the ARIN community to make their
> transfer policies more restrictive or less restrictive,  and do not
> have to consult with the ARIN community
> in regards to how they choose to interpret their policies.
>
> A recent proposal @ AfriNic   to allow members to transfer addresses
> (within region)  contained text like this;     I think it's safe to
> say  ARIN's  8.3 is a lot more restrictive  than the draft they have :
>
> http://www.afrinic.net/docs/policies/AFPUB-2011-v4-001-draft-01.htm
> "2.1) Legacy members can transfer part or all of their IPv4 addresses
> to any company under the following criteria: ....
> a) The company to which the addresses are transferred may or may not
> enter into agreement with AfriNIC.
> b) The legacy member may or may not inform AfriNIC about the transaction.
> c) AfriNIC will accord the third party all relevant access to services
> and benefits normally available to legacy members.
>
> 2.2) Paying AfriNIC members can transfer part or all of their IPv4
> addresses to any company under the following criteria:  ....
> b) The transfer and needs analysis cannot be based on any current
> policies. The only requirement for the transfer to happen should be
> the contract between the member and AfriNIC.
> ...
> "

That proposal had almost no support.  Even if it did, it wouldn't have
qualified as a compatible needs-based transfer policy.

If another RIR does manage to come up with and get consensus for a
compatible needs-based transfer policy that has a less restrictive
needs assessment than ARIN's transfer policy, that may be an
indication we need to look at making our transfer policy less
restrictive as well.   Keep in mind that as long as we have a free
pool, it doesn't much matter if it's slightly easier or harder to
transfer addresses to another region.  The transfers will go to where
the demand is (where there are no free addresses to be had), and the
limiting factor on how much space most organizations get via transfer
will be the amount they have to pay for them, not how difficult the
needs assessment was.

That is a separate issue from whether we need additional protections
to prevent organizations from gaming the system to monetize the
remaining free pool(s) at the community's expense.

-Scott


From owen at delong.com  Wed Oct 26 00:20:43 2011
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Oct 2011 21:20:43 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
	ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAAAwwbXkv=8AbO+caGTfB0Ehuki_Wa2-tis529aKWz3zP9V85A@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
	<CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
	<CAAAwwbXkv=8AbO+caGTfB0Ehuki_Wa2-tis529aKWz3zP9V85A@mail.gmail.com>
Message-ID: <F6439098-D206-4E98-8F41-C7F1ADF4C36B@delong.com>


On Oct 25, 2011, at 8:49 PM, Jimmy Hess wrote:

> [snip]> But what they hey, as long as you've broached the subject:
>> In your view, which of the other four RIRs presently implement a
>> transfer policy whose minimum path through the policy-derived process
>> appiles as restrictive or more restrictive rules on the recipient than
>> ARIN's? I won't ask you to "prove it" in each case, but as few of us
>> here are experts in other RIRs' policies I will ask you to explain
> [snip]
> Other "RIR policies" are not fixed.   We can't say the transfer policy
> is "OK" based on other RIRs' current policies, when the other RIRs'
> communities can choose to change them at any time.
> How could we possiblty anticipate what their rules will be when most
> RIRs don't even have any kind of Inter-RIR transfer policy?
> 
> 
> The other RIRs are free to revise their own policies, ARIN should not
> have a "variable" policy
> that becomes more restrictive or less restrictive,  depending on
> actions other organizations take from time to time.   The other RIRs
> do not have to consult with the ARIN community to make their
> transfer policies more restrictive or less restrictive,  and do not
> have to consult with the ARIN community
> in regards to how they choose to interpret their policies.
> 
> A recent proposal @ AfriNic   to allow members to transfer addresses
> (within region)  contained text like this;     I think it's safe to
> say  ARIN's  8.3 is a lot more restrictive  than the draft they have :
> 
> http://www.afrinic.net/docs/policies/AFPUB-2011-v4-001-draft-01.htm
> "2.1) Legacy members can transfer part or all of their IPv4 addresses
> to any company under the following criteria: ....
> a) The company to which the addresses are transferred may or may not
> enter into agreement with AfriNIC.
> b) The legacy member may or may not inform AfriNIC about the transaction.
> c) AfriNIC will accord the third party all relevant access to services
> and benefits normally available to legacy members.
> 

> 2.2) Paying AfriNIC members can transfer part or all of their IPv4
> addresses to any company under the following criteria:  ....
> b) The transfer and needs analysis cannot be based on any current
> policies. The only requirement for the transfer to happen should be
> the contract between the member and AfriNIC.
> ...
> "
> 


This proposal fell pretty flat with the AfriNIC community and enjoyed
almost no support other than from the author. As such, I think it's also
safe to say that this proposal which didn't make it very far into the process
at all is not indicative of any likely direction for policy in the AfriNIC region.

Heck, Mike Burns proposed relatively similar policy in the ARIN region.

Owen



From jcurran at arin.net  Wed Oct 26 04:35:44 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 26 Oct 2011 08:35:44 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
	<CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
Message-ID: <1C6431DB-8242-4F17-9129-73B14151EFA2@arin.net>

On Oct 26, 2011, at 1:01 AM, William Herrin wrote:

> But what they hey, as long as you've broached the subject:
> 
> In your view, which of the other four RIRs presently implement a
> transfer policy whose minimum path through the policy-derived process
> appiles as restrictive or more restrictive rules on the recipient than
> ARIN's? I won't ask you to "prove it" in each case, but as few of us
> here are experts in other RIRs' policies I will ask you to explain
> your reasoning.
> 
> My statement looked to the horizon, to the possibilities, but I think
> it might be interesting to know the immediate game on the ground as
> well.

Bill - 

The RIRs work (via the NRO cooperation effort) to maintain a comparative 
policy overview which you make use to make such judgements based on your 
own perspective of what would qualify as more or less restrictive:

<http://www.nro.net/policies/rir-comparative-policy-overview>

Thanks,
/John

John Curran
President and CEO
ARIN





From john.sweeting at twcable.com  Wed Oct 26 08:41:46 2011
From: john.sweeting at twcable.com (Sweeting, John)
Date: Wed, 26 Oct 2011 08:41:46 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
Message-ID: <CACD75E6.C0C6%john.sweeting@twcable.com>

Hi Kevin,

Not sure if this helps but it must fit the word "compatible" according to
ARIN, that is one of the reasons for the wording "only via RIR's who agree
to the transfer" to be included.



On 10/25/11 11:33 PM, "Kevin Blumberg" <kevinb at thewire.ca> wrote:

>Own,
>
>This is my major issue with the rewrite. The reality is that the current
>text
>in last call doesn't deal with another region relaxing their policies to
>still
>fit within the word "compatible".
>
>A policy needs to be able to be forward looking. The rewrite of 2011-1
>would
>now allow another RIR to modify the intent of our policy by solely
>relaxing their own polices.
>
>While I believe the ARIN AC has done a lot towards cleaning up the text,
>the shift of
>responsibility to outside our region is deeply concerning.
>
>Example Policy Proposal from Region XYZ post adoption:
>
>"Parties requesting Inter-RIR transfers may do so with 48 month
>justification criteria
>based on 50 percent current utilization".
>
>
>Kevin Blumberg
>T 416.214.9473 x31
>F 416.862.9473
>kevinb at thewire.ca
>
>
>
>
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Owen DeLong
>> Sent: Tuesday, October 25, 2011 8:34 PM
>> To: William Herrin
>> Cc: John Curran; arin-ppml at arin.net List
>> Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARINInter-
>> RIRTransfers - Last Call
>>
>>
>> On Oct 25, 2011, at 5:25 PM, William Herrin wrote:
>>
>> > On Tue, Oct 25, 2011 at 8:16 PM, Owen DeLong <owen at delong.com>
>> wrote:
>> >> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
>> >>> I can't bend on the idea that we'll let other regions set their own,
>> >>> LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
>> >>> continue to apply more restrictive rules to identical registrants
>> >>> here at home. That is beyond careless stewardship. If I may borrow
>> >>> your turn of phrase, it violates a fundamental expectation of any
>> >>> fair and equitable industry self-regulation.
>> >>
>> >> Can you back up this claim with any form of evidence or fact?
>> >
>> > "Under the proposed policy text, it does not matter if the other RIRs
>> > requirements are more or less strict than ARIN's" -- John Curran,
>> > 10/20/2011 explaining ARIN's interpretation of the 2011-1 text.
>> >
>>
>> That is not the same as claiming that other RIRs have a less
>>restrictive policy.
>> Can you back that claim up specifically. I do not believe it currently
>>holds true.
>>
>> 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.
>_______________________________________________
>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 bill at herrin.us  Wed Oct 26 09:36:31 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 26 Oct 2011 09:36:31 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <1C6431DB-8242-4F17-9129-73B14151EFA2@arin.net>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
	<CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
	<1C6431DB-8242-4F17-9129-73B14151EFA2@arin.net>
Message-ID: <CAP-guGX0TA+CyL5+bLwtgQPyC7a7sKhi2rVxFeo8NPen3bxWWQ@mail.gmail.com>

On Wed, Oct 26, 2011 at 4:35 AM, John Curran <jcurran at arin.net> wrote:
> On Oct 26, 2011, at 1:01 AM, William Herrin wrote:
>
>> But what they hey, as long as you've broached the subject:
>>
>> In your view, which of the other four RIRs presently implement a
>> transfer policy whose minimum path through the policy-derived process
>> appiles as restrictive or more restrictive rules on the recipient than
>> ARIN's? I won't ask you to "prove it" in each case, but as few of us
>> here are experts in other RIRs' policies I will ask you to explain
>> your reasoning.
>>
>> My statement looked to the horizon, to the possibilities, but I think
>> it might be interesting to know the immediate game on the ground as
>> well.
>
> Bill -
>
> The RIRs work (via the NRO cooperation effort) to maintain a comparative
> policy overview which you make use to make such judgements based on your
> own perspective of what would qualify as more or less restrictive:
>
> <http://www.nro.net/policies/rir-comparative-policy-overview>

John,

The guidance I get from:

http://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-overview-2011-02#1-3-2

is that only LACNIC and RIPE maintain policies ARIN might consider
"compatible" under 2011-1. APNIC and AfriNIC would each need to adopt
new policy of presently unknown restrictiveness in order to have
compatible needs-based transfer policies. Each of their policies is
presently inward-looking only, so all four would need to write new
policy of presently unknown restrictiveness to take advantage of ARIN
transfers.

Actually, I'm not sure about that last sentence. We've all been
assuming that reciprocity is expected, but rereading draft 2011-1 I
find no explicit reciprocity requirement. As 2011-1 is understood by
ARIN, does an RIR which does not permit its addresses to be
transferred out-region but does apply a needs basis of unknown
stricture to transfer recipients qualify to receive addresses under
2011-1?


Would anyone care to dispute the analysis that all four RIRs will
write or rewrite transfer policies in order to be compatible with
draft 2011-1 transfers, each binding ARIN to presently unknown
restrictiveness (lower bounded in that it must be "needs based") in
the resulting out-region transfers of ARIN-managed addresses?

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  Wed Oct 26 09:48:18 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 26 Oct 2011 13:48:18 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGX0TA+CyL5+bLwtgQPyC7a7sKhi2rVxFeo8NPen3bxWWQ@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
	<CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
	<1C6431DB-8242-4F17-9129-73B14151EFA2@arin.net>
	<CAP-guGX0TA+CyL5+bLwtgQPyC7a7sKhi2rVxFeo8NPen3bxWWQ@mail.gmail.com>
Message-ID: <5A9FDFC8-D7BB-4C2D-B2FA-CC059032409B@arin.net>

On Oct 26, 2011, at 1:36 PM, William Herrin wrote:

> Actually, I'm not sure about that last sentence. We've all been
> assuming that reciprocity is expected, but rereading draft 2011-1 I
> find no explicit reciprocity requirement. As 2011-1 is understood by
> ARIN, does an RIR which does not permit its addresses to be
> transferred out-region but does apply a needs basis of unknown
> stricture to transfer recipients qualify to receive addresses under
> 2011-1?

The RIR must have a compatible, needs-based transfer policy 
which allows them to approved the request to transfer to the 
recipient; there is no reciprocity requirement in 2011-1.

> Would anyone care to dispute the analysis that all four RIRs will
> write or rewrite transfer policies in order to be compatible with
> draft 2011-1 transfers, each binding ARIN to presently unknown
> restrictiveness (lower bounded in that it must be "needs based") in
> the resulting out-region transfers of ARIN-managed addresses?

The matrix is updated twice per you; you are looking at the June 2011
version in making that analysis.  I believe that APNIC has revised
their transfer policy already as necessary to be compatible.

FYI,
/John

John Curran
President and CEO
ARIN



From owen at delong.com  Wed Oct 26 09:56:41 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 26 Oct 2011 06:56:41 -0700
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
	ARINInter-RIRTransfers - Last Call
In-Reply-To: <5A9FDFC8-D7BB-4C2D-B2FA-CC059032409B@arin.net>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
	<CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
	<1C6431DB-8242-4F17-9129-73B14151EFA2@arin.net>
	<CAP-guGX0TA+CyL5+bLwtgQPyC7a7sKhi2rVxFeo8NPen3bxWWQ@mail.gmail.com>
	<5A9FDFC8-D7BB-4C2D-B2FA-CC059032409B@arin.net>
Message-ID: <6DF594DA-D4FB-49F6-B19C-761C596B92A3@delong.com>


On Oct 26, 2011, at 6:48 AM, John Curran wrote:

> On Oct 26, 2011, at 1:36 PM, William Herrin wrote:
> 
>> Actually, I'm not sure about that last sentence. We've all been
>> assuming that reciprocity is expected, but rereading draft 2011-1 I
>> find no explicit reciprocity requirement. As 2011-1 is understood by
>> ARIN, does an RIR which does not permit its addresses to be
>> transferred out-region but does apply a needs basis of unknown
>> stricture to transfer recipients qualify to receive addresses under
>> 2011-1?
> 
> The RIR must have a compatible, needs-based transfer policy 
> which allows them to approved the request to transfer to the 
> recipient; there is no reciprocity requirement in 2011-1.
> 
>> Would anyone care to dispute the analysis that all four RIRs will
>> write or rewrite transfer policies in order to be compatible with
>> draft 2011-1 transfers, each binding ARIN to presently unknown
>> restrictiveness (lower bounded in that it must be "needs based") in
>> the resulting out-region transfers of ARIN-managed addresses?
> 
> The matrix is updated twice per you; you are looking at the June 2011
> version in making that analysis.  I believe that APNIC has revised
> their transfer policy already as necessary to be compatible.
> 
The APNIC revisions are technically not quite complete yet.

I believe last call either just closed or will close shortly.

Owen



From dogwallah at gmail.com  Wed Oct 26 10:50:02 2011
From: dogwallah at gmail.com (McTim)
Date: Wed, 26 Oct 2011 17:50:02 +0300
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAP-guGX0TA+CyL5+bLwtgQPyC7a7sKhi2rVxFeo8NPen3bxWWQ@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
	<CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
	<1C6431DB-8242-4F17-9129-73B14151EFA2@arin.net>
	<CAP-guGX0TA+CyL5+bLwtgQPyC7a7sKhi2rVxFeo8NPen3bxWWQ@mail.gmail.com>
Message-ID: <CACAaNximvjKX3FbnJcXy-_-t3_1CkAtMNW0itTeEbCwrJREhng@mail.gmail.com>

Hi,

On Wed, Oct 26, 2011 at 4:36 PM, William Herrin <bill at herrin.us>

<snip>

> Would anyone care to dispute the analysis that all four RIRs will
> write or rewrite transfer policies in order to be compatible with
> draft 2011-1 transfers, each binding ARIN to presently unknown
> restrictiveness (lower bounded in that it must be "needs based") in
> the resulting out-region transfers of ARIN-managed addresses?

<AfriNIC PDWG co-chair hat off>

I don't see that happening in the AfriNIC region anytime soon (or at all).

We've expressed our own "jingoistic" sentiment that AfriNIC resources
are for the AfriNIC region in our Soft-Landing Policy, which has just
passed LC.  I doubt we will be making much headway in agreeing to a
transfer policy that may allow our LIR to plunder your resources.  I
would be the first to point out that that would be hypocritical.  I
may be incorrect, but I don't see it in my prognostication device.

<AfriNIC PDWG co-chair hat on>
-- 
Cheers,

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


From bill at herrin.us  Wed Oct 26 11:09:50 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 26 Oct 2011 11:09:50 -0400
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CACAaNximvjKX3FbnJcXy-_-t3_1CkAtMNW0itTeEbCwrJREhng@mail.gmail.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<EF5F2444-80EF-4F1C-9AA3-ADF61FF74B8F@arin.net>
	<CAP-guGV822TLTpvXSktzrcfwkB8eM7-VPWuNYX=ZFPHGqbRe4A@mail.gmail.com>
	<CAP-guGU6BqUUNAgCDRNHLSEgkUCbAii9Q9F=1hGGxTk9YobRCg@mail.gmail.com>
	<1C6431DB-8242-4F17-9129-73B14151EFA2@arin.net>
	<CAP-guGX0TA+CyL5+bLwtgQPyC7a7sKhi2rVxFeo8NPen3bxWWQ@mail.gmail.com>
	<CACAaNximvjKX3FbnJcXy-_-t3_1CkAtMNW0itTeEbCwrJREhng@mail.gmail.com>
Message-ID: <CAP-guGX+08G4MECjyUrDYHucJFd_giQYSaC+0_f7ErmKzZ-k3g@mail.gmail.com>

On Wed, Oct 26, 2011 at 10:50 AM, McTim <dogwallah at gmail.com> wrote:
> On Wed, Oct 26, 2011 at 4:36 PM, William Herrin <bill at herrin.us>
>> Would anyone care to dispute the analysis that all four RIRs will
[if they desire any transfers with ARIN]
>> write or rewrite transfer policies in order to be compatible with
>> draft 2011-1 transfers, each binding ARIN to presently unknown
>> restrictiveness (lower bounded in that it must be "needs based") in
>> the resulting out-region transfers of ARIN-managed addresses?
>
> I don't see that happening in the AfriNIC region anytime soon (or at all).

Better?

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  Wed Oct 26 11:23:25 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 26 Oct 2011 11:23:25 -0400
Subject: [arin-ppml] 2011-1: reciprocity NOT required
Message-ID: <CAP-guGX6nJHttpB6yWGzZL=bRBUCdivBiRwmerrUVMnJFKKTcQ@mail.gmail.com>

On Wed, Oct 26, 2011 at 9:48 AM, John Curran <jcurran at arin.net> wrote:
> On Oct 26, 2011, at 1:36 PM, William Herrin wrote:
>> Actually, I'm not sure about that last sentence. We've all been
>> assuming that reciprocity is expected, but rereading draft 2011-1 I
>> find no explicit reciprocity requirement. As 2011-1 is understood by
>> ARIN, does an RIR which does not permit its addresses to be
>> transferred out-region but does apply a needs basis of unknown
>> stricture to transfer recipients qualify to receive addresses under
>> 2011-1?
>
> The RIR must have a compatible, needs-based transfer policy
> which allows them to approved the request to transfer to the
> recipient; there is no reciprocity requirement in 2011-1.

Neat! So under 2011-1 as drafted, APNIC registrants, under APNIC's
nearly completed needs-based allocation policy, may accept addresses
sold by ARIN-region registrants even as APNIC's participants merrily
debate whether and how to permit APNIC region registrants to sell
addresses to ARIN region organizations.

And correct me if I'm wrong, but APNIC uses country-level
sub-registries very differently than ARIN. So, even if APNIC up top
eventually adopts a reciprocal policy, it may be mooted by the
country-level policies.

Congratulations Scott, you've reached the public policy big time now.
You nearly created another not-really "free trade" agreement with
China.


I will now say "I told you so" in two respects:

1. This is why we send new text through parts two and three of the PDP
instead of rushing them to last call in part 4. The vetting of this
brand new text for draft 2011-1 has been inadequate and I doubt we've
yet reached the bottom of the ways in which it abjectly fails to
protect ARIN-region registrants in need of addresses.

2. Asking the board to act as an experts group which certifies the
compatibility of another region's policy, as I proposed both for this
version of the text and for prior ones, would have avoided this
problem and many others. ARIN staff does not have the Board's
latitude; they must go by exactly what the policy says even if it
obviously missed a beat.

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  Wed Oct 26 11:36:56 2011
From: owen at delong.com (Owen DeLong)
Date: Wed, 26 Oct 2011 08:36:56 -0700
Subject: [arin-ppml] 2011-1: reciprocity NOT required
In-Reply-To: <CAP-guGX6nJHttpB6yWGzZL=bRBUCdivBiRwmerrUVMnJFKKTcQ@mail.gmail.com>
References: <CAP-guGX6nJHttpB6yWGzZL=bRBUCdivBiRwmerrUVMnJFKKTcQ@mail.gmail.com>
Message-ID: <E0BD69B7-03F2-480B-9DA6-02DD490BC843@delong.com>


On Oct 26, 2011, at 8:23 AM, William Herrin wrote:

> On Wed, Oct 26, 2011 at 9:48 AM, John Curran <jcurran at arin.net> wrote:
>> On Oct 26, 2011, at 1:36 PM, William Herrin wrote:
>>> Actually, I'm not sure about that last sentence. We've all been
>>> assuming that reciprocity is expected, but rereading draft 2011-1 I
>>> find no explicit reciprocity requirement. As 2011-1 is understood by
>>> ARIN, does an RIR which does not permit its addresses to be
>>> transferred out-region but does apply a needs basis of unknown
>>> stricture to transfer recipients qualify to receive addresses under
>>> 2011-1?
>> 
>> The RIR must have a compatible, needs-based transfer policy
>> which allows them to approved the request to transfer to the
>> recipient; there is no reciprocity requirement in 2011-1.
> 
> Neat! So under 2011-1 as drafted, APNIC registrants, under APNIC's
> nearly completed needs-based allocation policy, may accept addresses
> sold by ARIN-region registrants even as APNIC's participants merrily
> debate whether and how to permit APNIC region registrants to sell
> addresses to ARIN region organizations.
> 

> And correct me if I'm wrong, but APNIC uses country-level
> sub-registries very differently than ARIN. So, even if APNIC up top
> eventually adopts a reciprocal policy, it may be mooted by the
> country-level policies.
> 
You are wrong...

Your understanding of how APNIC NIRs operate is not correct.
The NIRs are not allowed to set independent addressing policies.
They are primarily a voting block  and a language interface arrangement.
They are a local front-end to the APNIC request process.


> Congratulations Scott, you've reached the public policy big time now.
> You nearly created another not-really "free trade" agreement with
> China.
> 

Unfair characterization based on the incorrect assumption contained
above. Perhaps you would do well to go through the APNIC policy
documents and have a quick read prior to posting broad assumptions
about what their policies say or do. I am not sure whether APNICs
current policy would implement reciprocity or not. I will, however,
ask APNIC staff for guidance on this aspect. I'm inclined to believe
that it would, actually, but, rather than speculate, I'll post again when
I have an authoritative answer.

> 
> I will now say "I told you so" in two respects:
> 
Premature at best.

> 1. This is why we send new text through parts two and three of the PDP
> instead of rushing them to last call in part 4. The vetting of this
> brand new text for draft 2011-1 has been inadequate and I doubt we've
> yet reached the bottom of the ways in which it abjectly fails to
> protect ARIN-region registrants in need of addresses.
> 

Continuing to harp on this point doesn't make it any more legitimate
than it was at the start. This is a relatively lightweight modification to
the existing proposal to bring it in line with the NRPM and incorporate
the feedback received from the community. At this point, yes, I believe
it needs more modification and another last call. I do not believe it
needs to go all the way back to step 2.

> 2. Asking the board to act as an experts group which certifies the
> compatibility of another region's policy, as I proposed both for this
> version of the text and for prior ones, would have avoided this
> problem and many others. ARIN staff does not have the Board's
> latitude; they must go by exactly what the policy says even if it
> obviously missed a beat.
> 

ARIN staff is able to implement policy in virtually any way that the
board instructs them to interpret or implement it. Absent input from
the board, of course they will go with the literal meaning and resolve
ambiguities as best they can in line with the CEO's interpretation
of "the right thing". That is all that can be expected of any organization.

In reality, the current policy will result in the CEO making such
determinations and I am quite sure that he will have board guidance
in the process (whether he wants it or not).

I really don't see how what you proposed would, in fact, change
anything other than to codify additional overhead in the process
which is most likely unnecessary.

Owen



From bill at herrin.us  Wed Oct 26 11:54:09 2011
From: bill at herrin.us (William Herrin)
Date: Wed, 26 Oct 2011 11:54:09 -0400
Subject: [arin-ppml] 2011-1: reciprocity NOT required
In-Reply-To: <E0BD69B7-03F2-480B-9DA6-02DD490BC843@delong.com>
References: <CAP-guGX6nJHttpB6yWGzZL=bRBUCdivBiRwmerrUVMnJFKKTcQ@mail.gmail.com>
	<E0BD69B7-03F2-480B-9DA6-02DD490BC843@delong.com>
Message-ID: <CAP-guGWry1MKXzO3WH-To3qKAFtqk0O+YG=ku_ANohD4FU7w9A@mail.gmail.com>

On Wed, Oct 26, 2011 at 11:36 AM, Owen DeLong <owen at delong.com> wrote:
> Unfair characterization based on the incorrect assumption contained
> above. Perhaps you would do well to go through the APNIC policy
> documents and have a quick read prior to posting broad assumptions
> about what their policies say or do. I am not sure whether APNICs
> current policy would implement reciprocity or not. I will, however,
> ask APNIC staff for guidance on this aspect. I'm inclined to believe
> that it would, actually, but, rather than speculate, I'll post again when
> I have an authoritative answer.

Owen,

Whether they elect to implement reciprocity or not is largely
immaterial. 2011-1 does not require them to as a condition of buying
addresses from ARIN registrants. Nor does it require RIPE or LACNIC to
to newly implement reciprocity as a condition of buying addresses from
ARIN registrants.

And the characterization is not unfair. It's what you get from a rush job.



> This is a relatively lightweight modification to
> the existing proposal to bring it in line with the NRPM

Now who's making an unfair characterization?

> At this point, yes, I believe
> it needs more modification and another last call. I do not believe it
> needs to go all the way back to step 2.

Hard headed.

> In reality, the current policy will result in the CEO making such
> determinations and I am quite sure that he will have board guidance
> in the process (whether he wants it or not).

Thankfully we don't have to guess. We've been told how the policy will
be interpreted: as permitting much of the potential bad behavior I've
described, including the lack of reciprocity.

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  Wed Oct 26 12:39:24 2011
From: farmer at umn.edu (David Farmer)
Date: Wed, 26 Oct 2011 11:39:24 -0500
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4E9F20FF.1070203@arin.net>
References: <4E9F20FF.1070203@arin.net>
Message-ID: <4EA837BC.6050502@umn.edu>

I want to thank Bill and Owen for so vigorously, debating the issues 
surrounding 2011-1.

However, I believe the AC still needs feedback, one way or the other, 
from a much larger segment of the community.  That is where the rest of 
you come in.  This is an important issue.  Please just don't sit back 
and watch.  Please let the AC know your opinion, even if it only is to 
agree with an opinion already expressed.

If possible, it is also really helpful if you can let the AC know if you 
support, or not, the text as written and posted for this Last Call.

Thanks, and please let us know your opinion too.

-- 
===============================================
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 scottleibrand at gmail.com  Wed Oct 26 12:50:20 2011
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 26 Oct 2011 09:50:20 -0700
Subject: [arin-ppml] 2011-1: reciprocity NOT required
In-Reply-To: <CAP-guGX6nJHttpB6yWGzZL=bRBUCdivBiRwmerrUVMnJFKKTcQ@mail.gmail.com>
References: <CAP-guGX6nJHttpB6yWGzZL=bRBUCdivBiRwmerrUVMnJFKKTcQ@mail.gmail.com>
Message-ID: <CAGkMwz4oi5ZZws+Fte=69A1NMDqs43vftfT0vmTNc6zDF4dE=A@mail.gmail.com>

On Wed, Oct 26, 2011 at 8:23 AM, William Herrin <bill at herrin.us> wrote:

> On Wed, Oct 26, 2011 at 9:48 AM, John Curran <jcurran at arin.net> wrote:
> > On Oct 26, 2011, at 1:36 PM, William Herrin wrote:
> >> Actually, I'm not sure about that last sentence. We've all been
> >> assuming that reciprocity is expected, but rereading draft 2011-1 I
> >> find no explicit reciprocity requirement. As 2011-1 is understood by
> >> ARIN, does an RIR which does not permit its addresses to be
> >> transferred out-region but does apply a needs basis of unknown
> >> stricture to transfer recipients qualify to receive addresses under
> >> 2011-1?
> >
> > The RIR must have a compatible, needs-based transfer policy
> > which allows them to approved the request to transfer to the
> > recipient; there is no reciprocity requirement in 2011-1.
>
> Neat! So under 2011-1 as drafted, APNIC registrants, under APNIC's
> nearly completed needs-based allocation policy, may accept addresses
> sold by ARIN-region registrants even as APNIC's participants merrily
> debate whether and how to permit APNIC region registrants to sell
> addresses to ARIN region organizations.
>


>
> Congratulations Scott, you've reached the public policy big time now.
> You nearly created another not-really "free trade" agreement with
> China.
>

Ok, let's look at this from a trade perspective for a moment.

The ARIN region has more grain than the APNIC region.  The APNIC region has
a larger population, and therefore a larger demand for grain.  Current
policies do not ban the export of grain from anywhere in the APNIC region
that I'm aware of, but if such policy were to be introduced in the future,
the ARIN region does not have any automatic export bans that would kick in
as a result.

If you s/grain/IPv4 addresses/g the above is all true under 2011-1 as well.

I know IPv4 addresses are not grain.  My only point is that even
protectionists (who argue for import restrictions) largely agree that export
bans are generally bad trade policy.  And I've *never* seen an
*automatically triggered* export ban.

Who knows, maybe 2011-1 will help increase US exports to China and get us
closer to trade balance.

Getting back to the issue at hand, the inter-RIR portion of APNIC's transfer
policy is already in place (
http://www.apnic.net/policy/transfer-policy#rir-transfer), and to my reading
is indeed reciprocal.  The only thing we're waiting on is the re-addition of
needs basis to their transfer policy generally, which as others mentioned
has achieved consensus: http://www.apnic.net/policy/proposals/prop-096

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

From rbf+arin-ppml at panix.com  Wed Oct 26 15:05:01 2011
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Wed, 26 Oct 2011 14:05:01 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <5F17EB53-768B-4147-A611-99DDE56ED176@delong.com>
References: <CAP-guGXOAjcMjBwYU-x-WThQPn_vb7DB0jnA+nvNb5YK1ukmBA@mail.gmail.com>
	<CACC32A7.BF64%john.sweeting@twcable.com>
	<CAP-guGXiVhVWoJA_Pmsh_bCik48wX-yEMHH7zCfdcRbqHqXxRA@mail.gmail.com>
	<BA52F074-90DD-46B9-B486-23CC9EC97E3D@arin.net>
	<CAP-guGWf+6YEm5RMfGS0HJopeFJ4VigLtGGAvoaEv=VA8-vUDw@mail.gmail.com>
	<886D5DEA-0BB9-431C-8FDD-185E3F295858@delong.com>
	<CAP-guGVd75kTd_14NyF6asGL5ztBZkPTzWH=P_muASerDReRiQ@mail.gmail.com>
	<5F17EB53-768B-4147-A611-99DDE56ED176@delong.com>
Message-ID: <20111026190500.GA20711@panix.com>

On Tue, Oct 25, 2011 at 05:33:50PM -0700, Owen DeLong wrote:
> 
> On Oct 25, 2011, at 5:25 PM, William Herrin wrote:
> 
> > On Tue, Oct 25, 2011 at 8:16 PM, Owen DeLong <owen at delong.com> wrote:
> >> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
> >>> I can't bend on the idea that we'll let other regions set their own,
> >>> LESS-stringent-than-ARIN rules for consuming ARIN addresses while we
> >>> continue to apply more restrictive rules to identical registrants here
> >>> at home. That is beyond careless stewardship. If I may borrow your
> >>> turn of phrase, it violates a fundamental expectation of any fair and
> >>> equitable industry self-regulation.
> >> 
> >> Can you back up this claim with any form of evidence or fact?
> > 
> > "Under the proposed policy text, it does not matter if the other RIRs
> > requirements are more or less strict than ARIN's" -- John Curran,
> > 10/20/2011 explaining ARIN's interpretation of the 2011-1 text.
> 
> That is not the same as claiming that other RIRs have a less
> restrictive policy. Can you back that claim up specifically. I do not
> believe it currently holds true.

He didn't make that claim.  He said the policy would "let other regions
set their own, LESS-stringent-than-ARIN rules" for consuming ARIN
addresses.  He didn't say any other region had done so.

Response to David Farmer's request:  Opposed to the policy as written.  

(1) It's already been explained in other posts (by me and others) why
the transfer policy effectively allows organizations in other regions
to get ARIN free-pool resources via transfer simply by running those
addresses through an ARIN-region organization that is in a position to
temporarily put the addresses to real use.  

(2) William's point above extends #1 to potentially allowing
organizations in other regions access to ARIN's free-pool resources
*under terms less restrictive than the terms under which organizations
in ARIN's region are allowed access to ARIN's free-pool resources*.

I'm not willing to take it on faith that other regions won't
pass less-restrictive policies at some point in the future.

There's likely a limit to how less-restrictive they can be ... a
requirement for, say, 10% utilization within 25 years would probably be
considered "incompatible" with ARIN's rules.  But, say, a policy that
was the same as ARINs in most respects, but which allowed 12 month
supply of addresses, would be meaningfully less restrictive, but would
probably be considered "compatible" with ARIN's policies.

     -- Brett


From kevinb at thewire.ca  Wed Oct 26 16:19:31 2011
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Wed, 26 Oct 2011 20:19:31 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CACD75E6.C0C6%john.sweeting@twcable.com>
References: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
	<CACD75E6.C0C6%john.sweeting@twcable.com>
Message-ID: <7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>

John,

My issue is exactly what that one word :)  The word "compatible" gives to much latitude once
the bi-lateral requirements were removed. 

I guess the question is how far would ARIN staff interpret the word "compatible" or the courts for that matter.

Is 48 months justification ok? Is 50 percent utilized? 

If another region said that the minimum block they gave out for initial allocation to a new multi homed
entrant was a /18 based on a 10 year needs projection, would that be compatible?

Kevin Blumberg
T 416.214.9473 x31
F 416.862.9473
kevinb at thewire.ca






> -----Original Message-----
> From: Sweeting, John [mailto:john.sweeting at twcable.com]
> Sent: Wednesday, October 26, 2011 8:42 AM
> To: Kevin Blumberg; Owen DeLong; William Herrin
> Cc: John Curran; arin-ppml at arin.net List
> Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARINInter-
> RIRTransfers - Last Call
> 
> Hi Kevin,
> 
> Not sure if this helps but it must fit the word "compatible" according to ARIN,
> that is one of the reasons for the wording "only via RIR's who agree to the
> transfer" to be included.
> 
> 
> 
> On 10/25/11 11:33 PM, "Kevin Blumberg" <kevinb at thewire.ca> wrote:
> 
> >Own,
> >
> >This is my major issue with the rewrite. The reality is that the
> >current text in last call doesn't deal with another region relaxing
> >their policies to still fit within the word "compatible".
> >
> >A policy needs to be able to be forward looking. The rewrite of 2011-1
> >would now allow another RIR to modify the intent of our policy by
> >solely relaxing their own polices.
> >
> >While I believe the ARIN AC has done a lot towards cleaning up the
> >text, the shift of responsibility to outside our region is deeply
> >concerning.
> >
> >Example Policy Proposal from Region XYZ post adoption:
> >
> >"Parties requesting Inter-RIR transfers may do so with 48 month
> >justification criteria based on 50 percent current utilization".
> >
> >
> >Kevin Blumberg
> >T 416.214.9473 x31
> >F 416.862.9473
> >kevinb at thewire.ca
> >
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> >> On Behalf Of Owen DeLong
> >> Sent: Tuesday, October 25, 2011 8:34 PM
> >> To: William Herrin
> >> Cc: John Curran; arin-ppml at arin.net List
> >> Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
> >> ARINInter- RIRTransfers - Last Call
> >>
> >>
> >> On Oct 25, 2011, at 5:25 PM, William Herrin wrote:
> >>
> >> > On Tue, Oct 25, 2011 at 8:16 PM, Owen DeLong <owen at delong.com>
> >> wrote:
> >> >> On Oct 25, 2011, at 3:35 PM, William Herrin wrote:
> >> >>> I can't bend on the idea that we'll let other regions set their
> >> >>> own, LESS-stringent-than-ARIN rules for consuming ARIN addresses
> >> >>> while we continue to apply more restrictive rules to identical
> >> >>> registrants here at home. That is beyond careless stewardship. If
> >> >>> I may borrow your turn of phrase, it violates a fundamental
> >> >>> expectation of any fair and equitable industry self-regulation.
> >> >>
> >> >> Can you back up this claim with any form of evidence or fact?
> >> >
> >> > "Under the proposed policy text, it does not matter if the other
> >> > RIRs requirements are more or less strict than ARIN's" -- John
> >> > Curran,
> >> > 10/20/2011 explaining ARIN's interpretation of the 2011-1 text.
> >> >
> >>
> >> That is not the same as claiming that other RIRs have a less
> >>restrictive policy.
> >> Can you back that claim up specifically. I do not believe it
> >>currently holds true.
> >>
> >> 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.
> >_______________________________________________
> >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 jcurran at arin.net  Wed Oct 26 17:30:50 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 26 Oct 2011 21:30:50 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
	<CACD75E6.C0C6%john.sweeting@twcable.com>
	<7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>
Message-ID: <5F5A25B5-7720-4CDA-8715-8AF404C4D648@arin.net>

On Oct 26, 2011, at 8:19 PM, Kevin Blumberg wrote:

> If another region said that the minimum block they gave out for initial allocation to a new multi homed
> entrant was a /18 based on a 10 year needs projection, would that be compatible?

Yes.  If the policy requires the recipient to demonstrate
their operational need for the address space to their RIR,
then it is a compatible transfer policy for purposes of 
transfers going out of region.

/John




From kevinb at thewire.ca  Wed Oct 26 18:53:01 2011
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Wed, 26 Oct 2011 22:53:01 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <5F5A25B5-7720-4CDA-8715-8AF404C4D648@arin.net>
References: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
	<CACD75E6.C0C6%john.sweeting@twcable.com>
	<7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>
	<5F5A25B5-7720-4CDA-8715-8AF404C4D648@arin.net>
Message-ID: <7E7773B523E82C478734E793E58F69E7FCB39A@SBS2011.thewireinc.local>

John,

If that is the case I do not support the current text. 

I strongly support 2011-1 continue to be worked on but I feel that any needs assessment done from which ever
side does it is more closely related to that regions current policies. 

I believe that "compatible" should be replaced with a more consistent and defined criteria that matches a 
minimum agreeable needs based requirement for a transfer out of region.

Kevin Blumberg
T 416.214.9473 x31
F 416.862.9473
kevinb at thewire.ca






> -----Original Message-----
> From: John Curran [mailto:jcurran at arin.net]
> Sent: Wednesday, October 26, 2011 5:31 PM
> To: Kevin Blumberg
> Cc: Sweeting, John; Owen DeLong; William Herrin; arin-ppml at arin.net List
> Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARINInter-
> RIRTransfers - Last Call
> 
> On Oct 26, 2011, at 8:19 PM, Kevin Blumberg wrote:
> 
> > If another region said that the minimum block they gave out for
> > initial allocation to a new multi homed entrant was a /18 based on a 10 year
> needs projection, would that be compatible?
> 
> Yes.  If the policy requires the recipient to demonstrate their operational
> need for the address space to their RIR, then it is a compatible transfer policy
> for purposes of transfers going out of region.
> 
> /John
> 



From michael+ppml at burnttofu.net  Wed Oct 26 18:49:28 2011
From: michael+ppml at burnttofu.net (Michael Sinatra)
Date: Wed, 26 Oct 2011 15:49:28 -0700
Subject: [arin-ppml] Post PPM Revision of ARIN-2011-7: Compliance
	Requirement
In-Reply-To: <CAGkMwz7dqPFWOJR6eSVSoWRuFR0FOr0s63N551TNFxHPgOfFGA@mail.gmail.com>
References: <CAC1-dtkW6YU4EGkuoFNgLeDFSV+-a5e8MvxpASAX8JWFwN3+QQ@mail.gmail.com>
	<CAGkMwz7dqPFWOJR6eSVSoWRuFR0FOr0s63N551TNFxHPgOfFGA@mail.gmail.com>
Message-ID: <4EA88E78.5010506@burnttofu.net>

Now that 12.5 is getting updated and 12.6 stays the same, that fixes my 
concern about the six month revocation window being eliminated.  I think 
Chris has done a good job of working the text here.

However, I am still generally opposed to this policy (in addition to 
being one of the 34 who didn't like this policy, I was one of the 6 who 
said we shouldn't spend more time on this).  I am opposed for two reasons:

1. Disabling reverse DNS, which is one of two main forms of 
documentation that ARIN supports (the other being WHOIS) for a 
documentation-compliance violation (not maintaining RWHOIS/SWIP 
reassignment information) seems like shooting the community in the foot.

2. Building on #1, this policy wouldn't affect bad guys (those who 
haven't actually committed fraud, but may or may not be acting in good 
faith or may simply be lazy and don't care about reverse DNS), but it 
would up the ante with respect to placing burdens on those trying to 
operate in good faith.  I am mainly thinking here of large Universities 
who are reassigning IPv6 /64s to students in their residences.  Since 
such reassignments fall under section 6.5.5.3.1 (Residential Privacy), 
do we really need to worry about enforcement mechanisms for a policy 
that will create thousands of SWIP entries of the form "Private 
residential student #XXXX" and the like?  Maybe that's a corner case, 
but again, it feels like shooting in the foot to me.

Again, I understand the role of this sort of documentation in IPv4, 
where the enforcement mechanism can be withholding future allocations. 
I understand the rationale for putting teeth (however feeble) in this 
policy is for IPv6, as future allocations for the majority of LIRs may 
never be necessary.  If that's the case, how much do we care about 
proper reassignment documentation, as long as the LIR can respond to 
community and/or law enforcement requests with accurate and timely 
information?

thanks,
michael

On 10/24/11 7:04 PM, Scott Leibrand wrote:
> I'm not sure we heard a consensus from the community in favor of
> requiring ARIN to revoke reverse DNS for organizations out of compliance
> with policy.  I don't think the transcripts are available yet, so all I
> have aside from my own memory is the poll counts, which were 20-34 on
> the text presented, and 57-6 in favor of continuing to work on it.
>
> So I guess I'd like to hear from the community (particularly those 34 of
> you who didn't like the presented text) as to whether you think these
> changes address your concerns or not.
>
> -Scott
>
> On Mon, Oct 24, 2011 at 12:29 PM, Chris Grundemann
> <cgrundemann at gmail.com <mailto:cgrundemann at gmail.com>> wrote:
>
>     Hello,
>
>     As the primary shepherd of draft policy ARIN-2011-7: Compliance
>     Requirement, I took your feedback from the Public Policy Meeting in
>     Philadelphia and revised the text. I believe that this new text
>     continues to meet the originators intentions while also addressing all
>     significant concerns raised thus far. Please let me know what you
>     think. If there are no major objections from the community here, I
>     plan to recommend this policy for last call at the next AC meeting.
>
>     New text:
>
>     ----8<----8<----8<----
>
>     12.4 - Update to:
>     Organizations found by ARIN to be out of compliance with current ARIN
>     policy shall be required to update reassignment information or return
>     resources as needed to bring them into (or reasonably close to)
>     compliance.
>     1. The degree to which an organization may remain out of compliance
>     shall be based on the reasonable judgment of the ARIN staff and shall
>     balance all facts known, including the organization's utilization
>     rate, available address pool, and other factors as appropriate so as
>     to avoid forcing returns which will result in near-term additional
>     requests or unnecessary route de-aggregation.
>     2. To the extent possible, entire blocks should be returned. Partial
>     address blocks shall be returned in such a way that the portion
>     retained will comprise a single aggregate block.
>
>     12.5 - Update to:
>     Except in cases of fraud when immediate action can be taken, an
>     organization shall be given thirty (30) days to respond. If an
>     organization fails to respond within thirty (30) days, ARIN may cease
>     providing reverse DNS services to that organization. If progress of
>     resource returns or record corrections has not occurred within sixty
>     (60) days after ARIN initiated contact, ARIN shall cease providing
>     reverse DNS services for the resources in question. At any time ninety
>     (90) days after initial ARIN contact, ARIN may initiate the revocation
>     of any resources issued by ARIN as required to bring the organization
>     into overall compliance. ARIN may permit a longer period of time to
>     come into compliance, if ARIN believes the organization is working in
>     good faith to restore compliance with policy and has a valid need for
>     additional time to comply, including but not limited to renumbering
>     out of the affected blocks. ARIN shall follow the same guidelines for
>     revocation that are required for voluntary return in the previous
>     paragraph.
>
>     (leave 12.6 as is)
>
>     ----8<----8<----8<----
>
>     Cheers,
>     ~Chris
>     _______________________________________________
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto:ARIN-PPML at arin.net>).
>     Unsubscribe or manage your mailing list subscription at:
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>     Please contact info at arin.net <mailto:info at arin.net> if you
>     experience any issues.
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From jcurran at arin.net  Wed Oct 26 19:20:30 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 26 Oct 2011 23:20:30 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <7E7773B523E82C478734E793E58F69E7FCB39A@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
	<CACD75E6.C0C6%john.sweeting@twcable.com>
	<7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>
	<5F5A25B5-7720-4CDA-8715-8AF404C4D648@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB39A@SBS2011.thewireinc.local>
Message-ID: <30C82F45-456E-4EC9-9221-E957C7A6EA39@arin.net>

On Oct 26, 2011, at 10:53 PM, Kevin Blumberg wrote:

> I feel that any needs assessment done from which ever side does
> it is more closely related to that regions current policies. 

Kevin - Could you explain what you mean by the above sentence?

The other RIR has to have a needs-based transfer policy which 
requires demonstrating the operational need to that RIR in 
order to transfer addresses.  Such policies are "compatible" 
with 2011-1.

For an actual transfer request to recipient in another RIR
to be approved, that RIR needs to apply their policy to the
recipient in their region and notify ARIN they agree to the 
transfer.  

Thanks,
/John

John Curran
President and CEO
ARIN





From kevinb at thewire.ca  Wed Oct 26 19:27:52 2011
From: kevinb at thewire.ca (Kevin Blumberg)
Date: Wed, 26 Oct 2011 23:27:52 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <30C82F45-456E-4EC9-9221-E957C7A6EA39@arin.net>
References: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
	<CACD75E6.C0C6%john.sweeting@twcable.com>
	<7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>
	<5F5A25B5-7720-4CDA-8715-8AF404C4D648@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB39A@SBS2011.thewireinc.local>
	<30C82F45-456E-4EC9-9221-E957C7A6EA39@arin.net>
Message-ID: <7E7773B523E82C478734E793E58F69E7FCB3F2@SBS2011.thewireinc.local>

John,

My statement was a hope that any region that is looking at Inter-RIR  transfer policy has a needs
requirement that mimics that regions own requirements. It was more of a preamble :)

The policy currently allows for potentially a very loose interpretation of needs basis. If we have a policy
in our region that requires certain needs to be a valid request then our Inter-RIR policy should closely 
mimic those needs requirements.

Kevin Blumberg
T 416.214.9473 x31
F 416.862.9473
kevinb at thewire.ca






> -----Original Message-----
> From: John Curran [mailto:jcurran at arin.net]
> Sent: Wednesday, October 26, 2011 7:21 PM
> To: Kevin Blumberg
> Cc: arin-ppml at arin.net List
> Subject: Re: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1: ARINInter-
> RIRTransfers - Last Call
> 
> On Oct 26, 2011, at 10:53 PM, Kevin Blumberg wrote:
> 
> > I feel that any needs assessment done from which ever side does it is
> > more closely related to that regions current policies.
> 
> Kevin - Could you explain what you mean by the above sentence?
> 
> The other RIR has to have a needs-based transfer policy which requires
> demonstrating the operational need to that RIR in order to transfer
> addresses.  Such policies are "compatible"
> with 2011-1.
> 
> For an actual transfer request to recipient in another RIR to be approved,
> that RIR needs to apply their policy to the recipient in their region and notify
> ARIN they agree to the transfer.
> 
> Thanks,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 



From jcurran at arin.net  Wed Oct 26 19:38:18 2011
From: jcurran at arin.net (John Curran)
Date: Wed, 26 Oct 2011 23:38:18 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <7E7773B523E82C478734E793E58F69E7FCB3F2@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
	<CACD75E6.C0C6%john.sweeting@twcable.com>
	<7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>
	<5F5A25B5-7720-4CDA-8715-8AF404C4D648@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB39A@SBS2011.thewireinc.local>
	<30C82F45-456E-4EC9-9221-E957C7A6EA39@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB3F2@SBS2011.thewireinc.local>
Message-ID: <F1E30D76-386D-46C7-9149-604533CCB3F4@arin.net>

On Oct 26, 2011, at 11:27 PM, Kevin Blumberg wrote:

> The policy currently allows for potentially a very loose interpretation of needs basis. If we have a policy
> in our region that requires certain needs to be a valid request then our Inter-RIR policy should closely 
> mimic those needs requirements.

Hmm...  Are you suggesting that ARIN's requirements to be met by the recipient of 
a transfer in another region should be the same as whatever requirements we put on 
a transfer recipient in the ARIN region?

If yes, this means that we're holding organizations in another region not to the 
principles contained within RFC 2050, but instead to the precise policy in the 
ARIN region at any given time.  This is not for address space being issued from
ARIN's free pool, but address space received from a willing ARIN region holder?

Thanks for clarifying,
/John

John Curran
President and CEO
ARIN



From gary.buhrmaster at gmail.com  Wed Oct 26 22:25:32 2011
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Thu, 27 Oct 2011 02:25:32 +0000
Subject: [arin-ppml] ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call
In-Reply-To: <4EA837BC.6050502@umn.edu>
References: <4E9F20FF.1070203@arin.net>
	<4EA837BC.6050502@umn.edu>
Message-ID: <CAMfXtQz3owV0pOwK0T8w-pbj+xF8AVoapx-K_VARPvvpeH+3FA@mail.gmail.com>

On Wed, Oct 26, 2011 at 16:39, David Farmer <farmer at umn.edu> wrote:
> I want to thank Bill and Owen for so vigorously, debating the issues
> surrounding 2011-1.
>
> However, I believe the AC still needs feedback, one way or the other, from a
> much larger segment of the community. ?That is where the rest of you come
> in. ?This is an important issue. ?Please just don't sit back and watch.
> ?Please let the AC know your opinion, even if it only is to agree with an
> opinion already expressed.

I will (essentially) repeat my previous opinion.  I am not entirely comfortable
with the entire transfer market, nor any of the wordings of 2011-1, recognize
that any transfer policy may be able to be gamed or abused, but I believe that
this is one of those pragmatic IPv4 policies that we should pass.

Gary


From mysidia at gmail.com  Thu Oct 27 02:02:42 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 27 Oct 2011 01:02:42 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <7E7773B523E82C478734E793E58F69E7FCB3F2@SBS2011.thewireinc.local>
References: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
	<CACD75E6.C0C6%john.sweeting@twcable.com>
	<7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>
	<5F5A25B5-7720-4CDA-8715-8AF404C4D648@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB39A@SBS2011.thewireinc.local>
	<30C82F45-456E-4EC9-9221-E957C7A6EA39@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB3F2@SBS2011.thewireinc.local>
Message-ID: <CAAAwwbWBFy43Aax3eKsFpWZhRe_FY8QVM7ZyYfsJ0OWeLCC5_Q@mail.gmail.com>

On Wed, Oct 26, 2011 at 6:27 PM, Kevin Blumberg <kevinb at thewire.ca> wrote:
> The policy currently allows for potentially a very loose interpretation of needs basis. If we have a policy
> in our region that requires certain needs to be a valid request then our Inter-RIR policy should closely
> mimic those needs requirements.

Yes.    I would say that for an Inter-RIR transfer to be performed,
the receiving RIR should have to show ARIN needs-based justification
for the transfer  provided by the recipient  that would be acceptable
justified need and merit acceptance of the transfer under ARIN's
current policy for ordinary in-region transfers.


>
--
-JH


From babydr at baby-dragons.com  Thu Oct 27 14:50:23 2011
From: babydr at baby-dragons.com (Mr. James W. Laferriere)
Date: Thu, 27 Oct 2011 10:50:23 -0800 (AKDT)
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
Message-ID: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>

 	Hello All ,

 	Hopefully OPEN Comments will be accepted on this matter as I being a 
holder of said 'Legacy resources' The FEE Structure is in my opinion still WAY 
too high .

 	Please provide as an addendum the mathimatical determination that SHOWS 
that each 'Legacy Holder' will pay a FAIR Share under this structure with those 
that hold FAR LARGER 'Resources' .

 	My own /24 is by far a better example of the  predominance of the 
'Holders' in the present 'Swamp' space .  PLEASE Illucidate those of us with 
small (ie: ~= /24) 'Resources' why those of us should be paying the same amount 
for ARIN 'Services' as a 'Holder' with /20 of 'Legacy' Resources ?

 	Imo ,  A /24 holder would be paying ~= $75.00/yr .

 		Tia ,  JimL



4. FEES; PAYMENTS
...
(b) Applicable Fees, Legacy Holder shall be required to pay ARIN the currently 
applicable "Annual Legacy Maintenance Fee" as described in this Section 4(b). 
The Annual Legacy Maintenance Fee pursuant to this Legacy Agreement shall 
initially be $300 per year until January 1, 2013. ARIN will send an invoice to 
prompt such payment before the due date. ARIN may increase the Annual Legacy 
Maintenance Fee after December 31, 2013, provided that (i) the Annual Legacy 
Maintenance Fee cannot exceed the annual maintenance fee charged to comparable 
non-legacy holders for the maintenance service as set forth in the Standard Fee 
Schedule for comparable number resources, and (ii) ARIN must set these fees in 
an open and transparent manner through the ARIN community consultation process.
...

-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network&System Engineer | 3237     Holden Road |  Give me Linux  |
| babydr at baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+------------------------------------------------------------------+


From jcurran at arin.net  Thu Oct 27 15:17:55 2011
From: jcurran at arin.net (John Curran)
Date: Thu, 27 Oct 2011 19:17:55 +0000
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
Message-ID: <0003807D-24FF-45C0-A268-C87EE9E336C7@arin.net>

On Oct 27, 2011, at 6:50 PM, Mr. James W. Laferriere wrote:

> 	Hello All ,
> 
> 	Hopefully OPEN Comments will be accepted on this matter as I being a holder of said 'Legacy resources' The FEE Structure is in my opinion still WAY too high .
> 
> 	Please provide as an addendum the mathimatical determination that SHOWS that each 'Legacy Holder' will pay a FAIR Share under this structure with those that hold FAR LARGER 'Resources' .
> 
> 	My own /24 is by far a better example of the  predominance of the 'Holders' in the present 'Swamp' space .  PLEASE Illucidate those of us with small (ie: ~= /24) 'Resources' why those of us should be paying the same amount for ARIN 'Services' as a 'Holder' with /20 of 'Legacy' Resources ?
> 
> 	Imo ,  A /24 holder would be paying ~= $75.00/yr .

JimL - 
 
  Thanks for the feedback.  It will be provided to the ARIN Board 
  which is responsible for the determination of fees. 

  Note that ARIN's expenses for registry core operations are not 
  proportional to address space, per se, but much closer to the 
  number of address blocks in the registry (as that drives the 
  staff and infrastructure for serving and maintaining the those
  entries)  

  Additionally, your ability to participate in ARIN, including 
  providing feedback on consultations such as this, and the 
  basic overhead of the organization (e.g. running the annual 
  elections and holding required meetings) are not costs that
  are necessarily variable based on address space held, and may
  actually be better recovered on a per member/organization basis.

  Obviously, the fees do not need to be directly tied to the costs
  of services, but they are important to keep in mind when setting
  the fees used to recover ARIN's overall costs.  There are many
  different fee schedules that will provide for ARIN to recover
  its costs, and it will ultimately be the Board's decision on 
  how this should be structured.

  If you wish to look at the costs of ARIN, I presented last week
  a breakdown by function area during the public Member's meeting
  two weeks back.  You can find the information under "Financial
  Cost Model" at the link below:
<https://www.arin.net/participate/meetings/reports/ARIN_XXVIII/mem.html> 

Thank you for taking the time to send your suggestion; it is greatly
appreciated!

/John

John Curran
President and CEO
ARIN








From bill at herrin.us  Thu Oct 27 21:13:58 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 27 Oct 2011 21:13:58 -0400
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
Message-ID: <CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>

On Thu, Oct 27, 2011 at 2:50 PM, Mr. James W. Laferriere
<babydr at baby-dragons.com> wrote:
> 4. FEES; PAYMENTS
> (b) Applicable Fees, Legacy Holder shall be required to pay ARIN the
> currently applicable "Annual Legacy Maintenance Fee" as described in this
> Section 4(b). The Annual Legacy Maintenance Fee pursuant to this Legacy
> Agreement shall initially be $300 per year until January 1, 2013. [...]
> (i) the Annual Legacy Maintenance Fee cannot exceed the annual
> maintenance fee charged to comparable non-legacy holders for the maintenance
> service as set forth in the Standard Fee Schedule for comparable number
> resources,

I'm a little confused. The legacy maintenance fee is $300/year but for
end users not more than the end user maintenance fee (currently
$100/year)?

Which governs? Or is an increase in the end-user fee anticipated?

Thanks,
Bill


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


From jcurran at arin.net  Thu Oct 27 22:06:22 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 02:06:22 +0000
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
Message-ID: <1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>

On Oct 28, 2011, at 1:13 AM, William Herrin wrote:

> On Thu, Oct 27, 2011 at 2:50 PM, Mr. James W. Laferriere
> <babydr at baby-dragons.com> wrote:
>> 4. FEES; PAYMENTS
>> (b) Applicable Fees, Legacy Holder shall be required to pay ARIN the
>> currently applicable "Annual Legacy Maintenance Fee" as described in this
>> Section 4(b). The Annual Legacy Maintenance Fee pursuant to this Legacy
>> Agreement shall initially be $300 per year until January 1, 2013. [...]
>> (i) the Annual Legacy Maintenance Fee cannot exceed the annual
>> maintenance fee charged to comparable non-legacy holders for the maintenance
>> service as set forth in the Standard Fee Schedule for comparable number
>> resources,
> 
> I'm a little confused. The legacy maintenance fee is $300/year but for
> end users not more than the end user maintenance fee (currently
> $100/year)?
> 
> Which governs? Or is an increase in the end-user fee anticipated?

A legacy fee increase is anticipated in conjunction with the new 
LRSA.  We've been discussing simultaneously trying to lower the 
registration fees for those under RSA to match for organizations 
with similar address holdings.

At present, those with resources under RSA pay significantly more
than those under LRSA.  We've lowered fees for those under RSA 
several times, but there's no way we can responsibly get everyone
to a $100/year registration services fee base.  Those currently 
under earlier LRSA's cannot have their fees increased more than 
$25/year, so we likely would move them slowly up to match as well.  
This is all based on my best estimate; as fees are set by the 
ARIN Board, this outlook is subject to change.

Hope this helps,
/John

John Curran
President and CEO
ARIN



From bill at herrin.us  Thu Oct 27 22:46:35 2011
From: bill at herrin.us (William Herrin)
Date: Thu, 27 Oct 2011 22:46:35 -0400
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
Message-ID: <CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>

On Thu, Oct 27, 2011 at 10:06 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 28, 2011, at 1:13 AM, William Herrin wrote:
>> On Thu, Oct 27, 2011 at 2:50 PM, Mr. James W. Laferriere
>> <babydr at baby-dragons.com> wrote:
>>> 4. FEES; PAYMENTS
>>> (b) Applicable Fees, Legacy Holder shall be required to pay ARIN the
>>> currently applicable "Annual Legacy Maintenance Fee" as described in this
>>> Section 4(b). The Annual Legacy Maintenance Fee pursuant to this Legacy
>>> Agreement shall initially be $300 per year until January 1, 2013. [...]
>>> (i) the Annual Legacy Maintenance Fee cannot exceed the annual
>>> maintenance fee charged to comparable non-legacy holders for the maintenance
>>> service as set forth in the Standard Fee Schedule for comparable number
>>> resources,
>>
>> I'm a little confused. The legacy maintenance fee is $300/year but for
>> end users not more than the end user maintenance fee (currently
>> $100/year)?
>>
>> Which governs? Or is an increase in the end-user fee anticipated?
>
> A legacy fee increase is anticipated in conjunction with the new
> LRSA. ?We've been discussing simultaneously trying to lower the
> registration fees for those under RSA to match for organizations
> with similar address holdings.
>
> At present, those with resources under RSA pay significantly more
> than those under LRSA. ?We've lowered fees for those under RSA
> several times, but there's no way we can responsibly get everyone
> to a $100/year registration services fee base. ?Those currently
> under earlier LRSA's cannot have their fees increased more than
> $25/year, so we likely would move them slowly up to match as well.
> This is all based on my best estimate; as fees are set by the
> ARIN Board, this outlook is subject to change.
>
> Hope this helps,


Hi John,

One of us isn't understanding the other. I'm not sure which.

1. Under the ARIN fee schedule, a non-legacy end-user under RSA pays a
$100 annual maintenance fee.

2. Under the LRSA draft a legacy end user pays a $300 annual maintenance fee.

3. Under the LRSA draft an end user pays no more than the non-legacy
end user holding the same resources.

All three statements can not be true at the same time; it's a logical
contradiction. So, which one is falsified by the others?

Thanks,
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  Thu Oct 27 23:05:26 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 03:05:26 +0000
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
Message-ID: <C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>


On Oct 28, 2011, at 2:46 AM, William Herrin wrote:
> 
> Hi John,
> 
> One of us isn't understanding the other. I'm not sure which.
> 
> 1. Under the ARIN fee schedule, a non-legacy end-user under RSA pays a
> $100 annual maintenance fee.
> 
> 2. Under the LRSA draft a legacy end user pays a $300 annual maintenance fee.
> 
> 3. Under the LRSA draft an end user pays no more than the non-legacy
> end user holding the same resources.
> 
> All three statements can not be true at the same time; it's a logical
> contradiction. So, which one is falsified by the others?

Bill -

  We're looking into an increase in the maintenance fee for both categories. 
  Approximately 75% of ARIN?s revenue comes from recurring IPv4 and IPv4 
  registration services subscription fees; less than 20% of ARIN?s revenue 
  at present comes from maintenance fees (and the remainder is one time fees)

  Yet more than 30% of ARIN?s costs are registry services operational costs, 
  and more than 50% of ARIN?s costs are for ongoing policy development and 
  corresponding registry system maintenance and enhancement.   Such efforts 
  either directly, or indirectly to a significant extent, benefit every 
  resource holder in the ARIN registry, not simply the Internet service 
  provider community.

  Again, the Board has yet to consider any new fee schedule proposal, so the 
  Draft LRSA 3.0 includes $300 annual maintenance fee because directionally
  I believe we will need to head that way.  Obviously, we need to consider
  how AS numbers also fit into this plan, and figure out exactly whats is 
  appropriate regarding end-users vs ISPs for initial allocation fees, and
  figure out whether recurring ISP registrations result in materially more
  expense due to subassignment registrations/SWIPs, etc. 

/John

John Curran
President and CEO
ARIN



From rbf+arin-ppml at panix.com  Thu Oct 27 23:11:25 2011
From: rbf+arin-ppml at panix.com (Brett Frankenberger)
Date: Thu, 27 Oct 2011 22:11:25 -0500
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
Message-ID: <20111028031125.GA9605@panix.com>

On Thu, Oct 27, 2011 at 10:46:35PM -0400, William Herrin wrote:
> 
> Hi John,
> 
> One of us isn't understanding the other. I'm not sure which.
> 
> 1. Under the ARIN fee schedule, a non-legacy end-user under RSA pays a
> $100 annual maintenance fee.
> 
> 2. Under the LRSA draft a legacy end user pays a $300 annual maintenance fee.
> 
> 3. Under the LRSA draft an end user pays no more than the non-legacy
> end user holding the same resources.

The actual text is:
  ARIN may increase the Annual Legacy Maintenance Fee after December
  31, 2013, provided that (i) the ... Fee cannot exceed the annual
  maintenance fee charged to comparable non-legacy holders for ...
  comparable number resources.

I think the effect of the languge is that ARIN cannot increase the fee
if the resulting fee would result in the legacy holder paying more than
a similarly situated non-legacy holder.  That would mean that ARIN can
(under the proposed new LRSA) charge legacy end-users $300/year, but,
should ARIN then subsequently exercise its right to increase the fee,
they would not be able to do so for end users unless and until the
annual fee for non-legacy end users exceeded $300 (until then, end
users could continue to pay $300; providers would pay the increased
fee).

An alternate reading, which I don't think is correct, is that the "Fee
cannot exceed" cause applies not just to increases, but to the initial
fee also, which would mean that end-users would pay only $100/year, but
providers would pay $300.

(On the other hand, I think ARIN's intent -- as distinct from what I
think is the effect of the currentlu proposed language -- is to not
charge legacy holders more than similarly situated non-legacy holders
under any circumstances.  If that's the case, then I'd suggest ARIN
alter the wording to clarify that.)

> All three statements can not be true at the same time; it's a logical
> contradiction. So, which one is falsified by the others?

     -- Brett


From jcurran at arin.net  Thu Oct 27 23:19:13 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 03:19:13 +0000
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <20111028031125.GA9605@panix.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<20111028031125.GA9605@panix.com>
Message-ID: <7D1D18EF-8EFF-4417-9B62-4E66582523FB@arin.net>

On Oct 28, 2011, at 3:11 AM, Brett Frankenberger wrote:
> 
> (On the other hand, I think ARIN's intent -- as distinct from what I
> think is the effect of the currentlu proposed language -- is to not
> charge legacy holders more than similarly situated non-legacy holders
> under any circumstances.  If that's the case, then I'd suggest ARIN
> alter the wording to clarify that.)

Point taken. The intent is for comparable fees, not increases, 
and the contract language needs to be fixed accordingly.

Thanks!
/John

John Curran
President and CEO
ARIN



From narten at us.ibm.com  Fri Oct 28 00:53:03 2011
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 28 Oct 2011 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201110280453.p9S4r3ot029079@rotala.raleigh.ibm.com>

Total of 113 messages in the last 7 days.
 
script run at: Fri Oct 28 00:53:02 EDT 2011
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 26.55% |   30 | 25.00% |   215489 | bill at herrin.us
 20.35% |   23 | 17.78% |   153298 | jcurran at arin.net
 11.50% |   13 | 12.92% |   111389 | owen at delong.com
  6.19% |    7 |  8.68% |    74781 | mike at nationwideinc.com
  5.31% |    6 |  4.91% |    42325 | mysidia at gmail.com
  3.54% |    4 |  4.96% |    42755 | scottleibrand at gmail.com
  3.54% |    4 |  3.55% |    30571 | john.sweeting at twcable.com
  3.54% |    4 |  3.51% |    30224 | kevinb at thewire.ca
  2.65% |    3 |  2.57% |    22149 | rbf+arin-ppml at panix.com
  2.65% |    3 |  2.51% |    21659 | farmer at umn.edu
  1.77% |    2 |  2.19% |    18875 | michael+ppml at burnttofu.net
  1.77% |    2 |  1.63% |    14053 | randy.whitney at verizon.com
  1.77% |    2 |  1.46% |    12571 | jsw at inconcepts.biz
  0.88% |    1 |  1.38% |    11911 | cja at daydream.com
  0.88% |    1 |  0.95% |     8218 | george.herbert at gmail.com
  0.88% |    1 |  0.82% |     7099 | cgrundemann at gmail.com
  0.88% |    1 |  0.81% |     6958 | john at egh.com
  0.88% |    1 |  0.81% |     6951 | narten at us.ibm.com
  0.88% |    1 |  0.80% |     6905 | dogwallah at gmail.com
  0.88% |    1 |  0.73% |     6304 | babydr at baby-dragons.com
  0.88% |    1 |  0.70% |     5991 | springer at inlandnet.com
  0.88% |    1 |  0.68% |     5827 | gary.buhrmaster at gmail.com
  0.88% |    1 |  0.66% |     5669 | paul at redbarn.org
--------+------+--------+----------+------------------------
100.00% |  113 |100.00% |   861972 | Total



From bill at herrin.us  Fri Oct 28 01:19:45 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 28 Oct 2011 01:19:45 -0400
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
Message-ID: <CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>

On Thu, Oct 27, 2011 at 11:05 PM, John Curran <jcurran at arin.net> wrote:
> ?We're looking into an increase in the maintenance fee for both categories.

Oh ho! So what will I get for my tripled end-user maintenance fee?
Will I have a vote in board and AC elections? Or is this to be
taxation without representation?

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  Fri Oct 28 03:48:25 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 07:48:25 +0000
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
Message-ID: <67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>

On Oct 28, 2011, at 5:19 AM, William Herrin wrote:

> On Thu, Oct 27, 2011 at 11:05 PM, John Curran <jcurran at arin.net> wrote:
>>  We're looking into an increase in the maintenance fee for both categories.
>
> Oh ho! So what will I get for my tripled end-user maintenance fee?
> Will I have a vote in board and AC elections? Or is this to be
> taxation without representation?

Since there's not an actual proposal at this point, it is hard to
answer that, but the thought would be one or more of the following:

 - General Membership, i.e. ability to vote in the
   organizational elections and associated rights
   and Ability to send folks to the ARIN Public
   Policy and Member Meeting

 - RPKI services without separate fee

 - STLS services without separate fee

For clarity regarding the existing registry and membership fee
structure, please see the attached table.

Clearly, the intent would be to provide the same set of services
for the same fees to organizations in similar situations.  There
is the obvious question of whether providing registry services,
resource certification, and reverse DNS services should have fees
independent of resources under managements, or based on number of
address blocks, number of prefixes, number of individual addresses,
or a factor/table lookup of one of the above.  Non-trivial to say
the least, and I'll be working with the Board's Finance Committee
to go through permutations for recommendation to the Board.

FYI,
/John

John Curran
President and CEO
ARIN




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111028/ba5c3ee1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ARIN-fees.pdf
Type: application/pdf
Size: 82554 bytes
Desc: ARIN-fees.pdf
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20111028/ba5c3ee1/attachment.pdf>

From owen at delong.com  Fri Oct 28 04:50:20 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 28 Oct 2011 02:50:20 -0600
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
Message-ID: <C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>

Can I continue to opt out of these additional services and not have my fees increased, please.

Thanks.

Owen


Sent from my iPad

On Oct 28, 2011, at 1:48 AM, John Curran <jcurran at arin.net> wrote:

> On Oct 28, 2011, at 5:19 AM, William Herrin wrote:
> 
> > On Thu, Oct 27, 2011 at 11:05 PM, John Curran <jcurran at arin.net> wrote:
> >>  We're looking into an increase in the maintenance fee for both categories.
> > 
> > Oh ho! So what will I get for my tripled end-user maintenance fee?
> > Will I have a vote in board and AC elections? Or is this to be
> > taxation without representation?
> 
> Since there's not an actual proposal at this point, it is hard to 
> answer that, but the thought would be one or more of the following:
> 
>  - General Membership, i.e. ability to vote in the 
>    organizational elections and associated rights
>    and Ability to send folks to the ARIN Public 
>    Policy and Member Meeting
>  
>  - RPKI services without separate fee
> 
>  - STLS services without separate fee
> 
> For clarity regarding the existing registry and membership fee 
> structure, please see the attached table.
> 
> Clearly, the intent would be to provide the same set of services 
> for the same fees to organizations in similar situations.  There
> is the obvious question of whether providing registry services,
> resource certification, and reverse DNS services should have fees
> independent of resources under managements, or based on number of 
> address blocks, number of prefixes, number of individual addresses, 
> or a factor/table lookup of one of the above.  Non-trivial to say
> the least, and I'll be working with the Board's Finance Committee
> to go through permutations for recommendation to the Board.
> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> ARIN
> 
> 
> 
>  
> <ARIN-fees.pdf>
> _______________________________________________
> 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/20111028/25b8acb2/attachment.htm>

From jcurran at arin.net  Fri Oct 28 05:44:01 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 09:44:01 +0000
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
Message-ID: <B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>

On Oct 28, 2011, at 8:50 AM, Owen DeLong wrote:

> Can I continue to opt out of these additional services and not have my fees increased, please.

That is also a possibility, although this may have unintended site effects.

For example, the ready availability of additional services may have a very real 
impact on their potential for Internet-wide success.  An incremental fee can 
be a significant hurdle to deployment, and this has implications for the entire
community.  For example, we decided to absorb the costs of DNSSEC for 
resource holders under contract into the existing ARIN cost structure without
any additional fees, as having a separate fee could easily prevent some in the 
community from deploying this important technology.  We presently face the
same concern with respect to resource certification, hence the consideration 
of including these services in a similar matter for all resource holders.

Input on fees and potential fee structures is definitely welcome from the 
community, either on this mailing list or the ARIN members arin-discuss 
mailing list.

Thanks!
/John

John Curran
President and CEO
ARIN



From jcurran at arin.net  Fri Oct 28 05:57:05 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 09:57:05 +0000
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment) - errata
In-Reply-To: <B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
Message-ID: <38ED7B10-1899-4BF4-81BD-CD7F412A4E3D@arin.net>

On Oct 28, 2011, at 9:44 AM, John Curran wrote:
> That is also a possibility, although this may have unintended site effects.

Clearly, I meant "side effects" (although 'site effects' may also occur :-)
/John

John Curran
President and CEO
ARIN





From owen at delong.com  Fri Oct 28 05:55:48 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 28 Oct 2011 03:55:48 -0600
Subject: [arin-ppml] LRSA v3.0 . MWE revised 8-16-11 (Comment)
In-Reply-To: <B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
Message-ID: <6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>

But you aren't talking about including it in the current price.... You're talking about jacking everyone for more money and forcing them all to pay for it whether they want it or not.

Owen


Sent from my iPad

On Oct 28, 2011, at 3:44 AM, John Curran <jcurran at arin.net> wrote:

> On Oct 28, 2011, at 8:50 AM, Owen DeLong wrote:
> 
>> Can I continue to opt out of these additional services and not have my fees increased, please.
> 
> That is also a possibility, although this may have unintended site effects.
> 
> For example, the ready availability of additional services may have a very real 
> impact on their potential for Internet-wide success.  An incremental fee can 
> be a significant hurdle to deployment, and this has implications for the entire
> community.  For example, we decided to absorb the costs of DNSSEC for 
> resource holders under contract into the existing ARIN cost structure without
> any additional fees, as having a separate fee could easily prevent some in the 
> community from deploying this important technology.  We presently face the
> same concern with respect to resource certification, hence the consideration 
> of including these services in a similar matter for all resource holders.
> 
> Input on fees and potential fee structures is definitely welcome from the 
> community, either on this mailing list or the ARIN members arin-discuss 
> mailing list.
> 
> Thanks!
> /John
> 
> John Curran
> President and CEO
> ARIN


From jcurran at arin.net  Fri Oct 28 06:11:16 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 10:11:16 +0000
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
Message-ID: <55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>

On Oct 28, 2011, at 9:55 AM, Owen DeLong wrote:

> But you aren't talking about including it in the current price.... You're talking about jacking everyone for more money and forcing them all to pay for it whether they want it or not.

You asked:

"Can I continue to opt out of these additional services and not have my fees increased, please."

I said:

"That is also a possibility"

It requires that we not only don't include these services, but that we 
don't normalize the fee structures between ISPs, Endusers, and Legacy 
address holders whereby they pay similar fees for similar services, i.e.
if the recurring fees for ISPs go down, then the maintenance fees for
for everyone has go up.  There are some additional services that we can 
include in this process, but indeed it would still be an increase.

We don't have to change the ISP fee structure, but as a practical matter,
ISPs are paying significantly more on a recurring basis for registration
services and depending on their circumstances, may not be actually using
any significantly more or different services from end-user organizations.

FYI,
/John

John Curran
President and CEO
ARIN



From owen at delong.com  Fri Oct 28 09:51:56 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 28 Oct 2011 07:51:56 -0600
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
Message-ID: <37A82FA6-92DD-4A45-B851-564D1FCB7FA7@delong.com>



Sent from my iPad

On Oct 28, 2011, at 4:11 AM, John Curran <jcurran at arin.net> wrote:

> On Oct 28, 2011, at 9:55 AM, Owen DeLong wrote:
> 
>> But you aren't talking about including it in the current price.... You're talking about jacking everyone for more money and forcing them all to pay for it whether they want it or not.
> 
> You asked:
> 
> "Can I continue to opt out of these additional services and not have my fees increased, please."
> 
> I said:
> 
> "That is also a possibility"
> 
> It requires that we not only don't include these services, but that we 
> don't normalize the fee structures between ISPs, Endusers, and Legacy 
> address holders whereby they pay similar fees for similar services, i.e.
> if the recurring fees for ISPs go down, then the maintenance fees for
> for everyone has go up.  There are some additional services that we can 
> include in this process, but indeed it would still be an increase.
> 
I don't favor reducing the recurring fees for ISPs on the backs of end users.

> We don't have to change the ISP fee structure, but as a practical matter,
> ISPs are paying significantly more on a recurring basis for registration
> services and depending on their circumstances, may not be actually using
> any significantly more or different services from end-user organizations.
> 
If they are not doing Whois updates with reassignment and reallocation information, then, why are they paying as ISPs. If they are doing so, then, they are using resources and services that are not available to end users.

Further, end users that choose to have a voting voice in ARIN today pay not $100/year, but $600/year, so the disparity there is not as large as you are claiming.

I like the idea of a $300 voting option for end users, but, not the idea of forcing all end users to pay 2-3 times what they currently pay for the same services.

Most end users are pretty static and don't make many changes to their Whois data. They usually have three resource objects in the database (1@ ipv4, ipv6, and asn). Most ISPs are or should be doing regular updates managing many objects.

Owen

> FYI,
> /John
> 
> John Curran
> President and CEO
> ARIN


From bill at herrin.us  Fri Oct 28 10:03:26 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 28 Oct 2011 10:03:26 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
Message-ID: <CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>

On Fri, Oct 28, 2011 at 3:48 AM, John Curran <jcurran at arin.net> wrote:
> Since there's not an actual proposal at this point, it is hard to
> answer that, but the thought would be one or more of the following:

Hi John,

As you consider your recommendations to the board, I offer the
following opinions as to what I personally would find acceptable or
objectionable. I speak as someone who currently manages end-user
registrations, holds legacy address and, in the past (and likely
future), has managed an ISP registration.


>  - General Membership, i.e. ability to vote in the
>    organizational elections and associated rights
>    and Ability to send folks to the ARIN Public
>    Policy and Member Meeting

I would find this an acceptable bargain in conjunction with a fee
increase to $300. However, that opinion would change if instead of
receiving general membership I merely received a reduced price on
optional general membership: I would consider a merely reduced price
on general membership to be window dressing which still obstructs
end-users from voting as a block with similar interests.


>  - RPKI services without separate fee

I may eventually use this but would just as soon pay a separate fee
when and if I do. I would, of course, feel differently should the
process gain widespread use.


>  - STLS services without separate fee

I don't anticipate using this as a lister and don't wish to
financially support the individuals who do. Should I ever desire to
use it as a would-be recipient, I will be funded sufficiently to
afford appropriate, presumably steep costs.


I would also be willing to pay greater fees were those fees calculated
something like this:

(  # of /24 IPv4 blocks held
+ # of /48 IPv6 blocks held
+ # of ASNs held)
/ total of the same across all ARIN registrants
x ARIN's annual budget

The ongoing policy development and corresponding registry system
enhancement costs unevenly impact the holders of large quantities of
ARIN resources. Applying them evenly by registrant count vice
resources held would not strike me as especially fair.

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 Oct 28 10:11:07 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 28 Oct 2011 10:11:07 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
Message-ID: <CAP-guGWO9Mtint3TW0mJWEpYBWxSKfczrnFztCkJzxzdxoCCtg@mail.gmail.com>

On Fri, Oct 28, 2011 at 10:03 AM, William Herrin <bill at herrin.us> wrote:
> I would also be willing to pay greater fees were those fees calculated
> something like this:
>
> ( ?# of /24 IPv4 blocks held
> + # of /48 IPv6 blocks held
> + # of ASNs held)
> / total of the same across all ARIN registrants
> x ARIN's annual budget
>
> The ongoing policy development and corresponding registry system
> enhancement costs unevenly impact the holders of large quantities of
> ARIN resources. Applying them evenly by registrant count vice
> resources held would not strike me as especially fair.

I would also support something along the lines of a $10 base fee per
registrant plus the formula above so that the costs of maintaining a
registrant versus the costs of maintaining registrations is properly
accounted for. I would be most interested in a detailed accounting
that suggests the cost of maintaining my name and address in a
database exceeds $10/year.

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 jbates at brightok.net  Fri Oct 28 10:24:07 2011
From: jbates at brightok.net (Jack Bates)
Date: Fri, 28 Oct 2011 09:24:07 -0500
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
Message-ID: <4EAABB07.4070000@brightok.net>

On 10/28/2011 5:11 AM, John Curran wrote:
> We don't have to change the ISP fee structure, but as a practical 
> matter, ISPs are paying significantly more on a recurring basis for 
> registration services and depending on their circumstances, may not be 
> actually using any significantly more or different services from 
> end-user organizations.

My only issue with the ISP fee structure is that the boundaries for IPv6 
no longer match up what the ISP is forced to take. ie, You can't get a 
/27, so if you are larger than a /28, you jump to the X-Large. From my 
observations, IPv6 tier structures have always been unbalanced (though 
the waivers helped). As a practical matter, IPv6 is more costly to the 
ISP when ARIN will perform less services for it in the end.

I can't complain about the cost differences for enduser/ISP. Just fix 
IPv6 which is on it's way to making ARIN a LOT more money, and doing 
less work in exchange.


Jack


From bill at herrin.us  Fri Oct 28 10:35:50 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 28 Oct 2011 10:35:50 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
Message-ID: <CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>

On Fri, Oct 28, 2011 at 10:03 AM, William Herrin <bill at herrin.us> wrote:
> I would also be willing to pay greater fees were those fees calculated
> something like this:
>
> ( ?# of /24 IPv4 blocks held
> + # of /48 IPv6 blocks held
> + # of ASNs held)
> / total of the same across all ARIN registrants
> x ARIN's annual budget

I would also support a version of this formula which, for now, omits
IPv6 from the equation. There's something to be said for progressive
taxation which encourages healthy behavior by reducing its cost.

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  Fri Oct 28 10:46:20 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 14:46:20 +0000
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
Message-ID: <CE4D4F55-BB3D-4C68-8568-D80C2493A78B@arin.net>

On Oct 28, 2011, at 2:03 PM, William Herrin wrote:

> On Fri, Oct 28, 2011 at 3:48 AM, John Curran <jcurran at arin.net> wrote:
>> Since there's not an actual proposal at this point, it is hard to
>> answer that, but the thought would be one or more of the following:
> 
> Hi John,
> 
> As you consider your recommendations to the board, I offer the
> following opinions as to what I personally would find acceptable or
> objectionable. I speak as someone who currently manages end-user
> registrations, holds legacy address and, in the past (and likely
> future), has managed an ISP registration.
> 
> 
>> - General Membership, i.e. ability to vote in the
>>   organizational elections and associated rights
>>   and Ability to send folks to the ARIN Public
>>   Policy and Member Meeting
> 
> I would find this an acceptable bargain in conjunction with a fee
> increase to $300. However, that opinion would change if instead of
> receiving general membership I merely received a reduced price on
> optional general membership: I would consider a merely reduced price
> on general membership to be window dressing which still obstructs
> end-users from voting as a block with similar interests.

Understood.

>> - RPKI services without separate fee
> 
> I may eventually use this but would just as soon pay a separate fee
> when and if I do. I would, of course, feel differently should the
> process gain widespread use.
> 
> 
>> - STLS services without separate fee
> 
> I don't anticipate using this as a lister and don't wish to
> financially support the individuals who do. Should I ever desire to
> use it as a would-be recipient, I will be funded sufficiently to
> afford appropriate, presumably steep costs.

Ok.

> I would also be willing to pay greater fees were those fees calculated
> something like this:
> 
> (  # of /24 IPv4 blocks held
> + # of /48 IPv6 blocks held
> + # of ASNs held)
> / total of the same across all ARIN registrants
> x ARIN's annual budget
> 
> The ongoing policy development and corresponding registry system
> enhancement costs unevenly impact the holders of large quantities of
> ARIN resources. Applying them evenly by registrant count vice
> resources held would not strike me as especially fair.

Thanks for your excellent feedback; it is both clear in what you
want to see, and informative due to your included reasoning.

Thanks again,
/John

John Curran
President and CEO
ARIN


From jbates at brightok.net  Fri Oct 28 10:47:08 2011
From: jbates at brightok.net (Jack Bates)
Date: Fri, 28 Oct 2011 09:47:08 -0500
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
Message-ID: <4EAAC06C.5080205@brightok.net>


On 10/28/2011 9:03 AM, William Herrin wrote:
> (  # of /24 IPv4 blocks held
> + # of /48 IPv6 blocks held
> + # of ASNs held)
> / total of the same across all ARIN registrants
> x ARIN's annual budget

I like the math, but with a mostly IPv4 Internet, this penalizes IPv6 
users as written. I believe we'd hit a closer par to what we have if 
IPv6 is sized per nibble. Until IPv6 is widely deployed and people are 
offering the same level of service with IPv6 as IPv4, your math forces 
IPv6 deployers to pay more.


Jack


From jcurran at arin.net  Fri Oct 28 10:56:37 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 14:56:37 +0000
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
Message-ID: <B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>

On Oct 28, 2011, at 2:35 PM, William Herrin wrote:

> On Fri, Oct 28, 2011 at 10:03 AM, William Herrin <bill at herrin.us> wrote:
>> I would also be willing to pay greater fees were those fees calculated
>> something like this:
>> 
>> (  # of /24 IPv4 blocks held
>> + # of /48 IPv6 blocks held
>> + # of ASNs held)
>> / total of the same across all ARIN registrants
>> x ARIN's annual budget
> 
> I would also support a version of this formula which, for now, omits
> IPv6 from the equation. There's something to be said for progressive
> taxation which encourages healthy behavior by reducing its cost.

Presumably, legacy block holders currently receiving services without 
charge would begin paying these fees upon signing the LRSA?  I imagine
a few /8 and /16 address holders might suggest that the services they
require do not cause ARIN expenses even close to the suggested fees?
This becomes even more important if you omit IPv4 from the equation.

Thoughts?
/John

John Curran
President and CEO
ARIN





From jbates at brightok.net  Fri Oct 28 11:17:48 2011
From: jbates at brightok.net (Jack Bates)
Date: Fri, 28 Oct 2011 10:17:48 -0500
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
Message-ID: <4EAAC79C.1020307@brightok.net>



On 10/28/2011 9:56 AM, John Curran wrote:
> Presumably, legacy block holders currently receiving services without
> charge would begin paying these fees upon signing the LRSA?  I imagine
> a few /8 and /16 address holders might suggest that the services they
> require do not cause ARIN expenses even close to the suggested fees?
> This becomes even more important if you omit IPv4 from the equation.

Scope the equation. If legacy's sign an LRSA but still don't pay current 
v4 tier fees, then don't include any of their v4 in the equation. Or 
apply a weight to their holdings. As long as it is applied on both 
sides, it will still average out right.

Instead of completely dropping v6 from the equation, you could exclude 
v4 and only count v6, if # of /48 > # of /24 * modifier, otherwise only 
count v4. The modifier to to protect small ISP's who get /32 of IPv6.

It requires that you maintain for all registrants if you're putting 
their v4 or their v6 into the equation.


Jack


From jcurran at arin.net  Fri Oct 28 11:26:23 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 15:26:23 +0000
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <4EAAC79C.1020307@brightok.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
Message-ID: <C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>

On Oct 28, 2011, at 3:17 PM, Jack Bates wrote:

> On 10/28/2011 9:56 AM, John Curran wrote:
>> Presumably, legacy block holders currently receiving services without
>> charge would begin paying these fees upon signing the LRSA?  I imagine
>> a few /8 and /16 address holders might suggest that the services they
>> require do not cause ARIN expenses even close to the suggested fees?
>> This becomes even more important if you omit IPv4 from the equation.
> 
> Scope the equation. If legacy's sign an LRSA but still don't pay current v4 tier fees, then don't include any of their v4 in the equation. Or apply a weight to their holdings. As long as it is applied on both sides, it will still average out right.

I'm referencing a different problem other than balancing the equation.
Let's say that a /24 increment works out to $10/annual  A legacy holder 
with a /8 would go from paying $0/annually to paying $655,350/annually\
upon signing the LRSA?

I'm trying to understand implications of Bill's formula approach.

Thanks!
/John

John Curran 
President and CEO
ARIN



From jbates at brightok.net  Fri Oct 28 11:44:55 2011
From: jbates at brightok.net (Jack Bates)
Date: Fri, 28 Oct 2011 10:44:55 -0500
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
Message-ID: <4EAACDF6.5020706@brightok.net>



On 10/28/2011 10:26 AM, John Curran wrote:

> I'm referencing a different problem other than balancing the equation.
> Let's say that a /24 increment works out to $10/annual  A legacy holder
> with a /8 would go from paying $0/annually to paying $655,350/annually\
> upon signing the LRSA?
>
> I'm trying to understand implications of Bill's formula approach.
>

Actually, I think the larger issue, is a /24 will end up being pennies. 
ISP's hold huge sums of /24s, so averaging them out means the single /24 
end-users will have a bill too small to pay. You would have to set a 
base fee, subtract the base fee from ARIN's budget total, then apply the 
equation to average out the resource utilization.

So an end-user assignment might pay $base_fee + $0.01 for their /24.

ARIN: 37 /8
Administered by ARIN: 39

So, ARIN has 2,424,832 /24s, double if the 39 administers are LRSA.

Take your budget, subtract ($base fee ($100?) * entities), then divide 
by the appropriate /24 number. Something tells me, it is way below $1 
per /24. This is a rough estimate based on v4 alone. If the equation 
balances properly between v4 and v6 size differentials, then the value 
should still be close to the end result.


Jack


From jcurran at arin.net  Fri Oct 28 11:50:39 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 15:50:39 +0000
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <4EAACDF6.5020706@brightok.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
Message-ID: <6625EC14-7975-4506-B160-362BD9F18265@arin.net>

On Oct 28, 2011, at 3:44 PM, Jack Bates wrote:

> Actually, I think the larger issue, is a /24 will end up being pennies. ISP's hold huge sums of /24s, so averaging them out means the single /24 end-users will have a bill too small to pay. You would have to set a base fee, subtract the base fee from ARIN's budget total, then apply the equation to average out the resource utilization.
> 
> So an end-user assignment might pay $base_fee + $0.01 for their /24.
> 
> ARIN: 37 /8
> Administered by ARIN: 39
> 
> So, ARIN has 2,424,832 /24s, double if the 39 administers are LRSA.
> 
> Take your budget, subtract ($base fee ($100?) * entities), then divide by the appropriate /24 number. Something tells me, it is way below $1 per /24. This is a rough estimate based on v4 alone. If the equation balances properly between v4 and v6 size differentials, then the value should still be close to the end result.

ARIN's full budget is approx $15M annually; feel free to propose 
a fee structure that you believe is appropriate.

Thanks,
/John

John Curran
President and CEO
ARIN



From bill at herrin.us  Fri Oct 28 11:58:02 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 28 Oct 2011 11:58:02 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <4EAACDF6.5020706@brightok.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
Message-ID: <CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>

On Fri, Oct 28, 2011 at 11:44 AM, Jack Bates <jbates at brightok.net> wrote:
> Take your budget, subtract ($base fee ($100?) * entities), then divide by
> the appropriate /24 number. Something tells me, it is way below $1 per /24.
> This is a rough estimate based on v4 alone. If the equation balances
> properly between v4 and v6 size differentials, then the value should still
> be close to the end result.

Hi Jack,

My back of the envelope calculations put it more like $5 to $10 per
/24, but I haven't closely checked the math.

37*65536=2.4M. ARIN's annual budget is something like $15M? 15/2.4=$6.25.

This would mean that entities (ISP and end-user both) which find it
needful to employ IPv4 /9's would see their annual fees increase from
$36k to $200k. But having run an 18k customer ISP on a little less
than a /16 ($4500 now, $1600 with the formula) it seems to me that
wouldn't break anyone's budget.

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  Fri Oct 28 12:04:09 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 16:04:09 +0000
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
Message-ID: <49379BD0-22CB-4661-AD04-B8C4B9EC37C5@arin.net>

On Oct 28, 2011, at 3:58 PM, William Herrin wrote:

> On Fri, Oct 28, 2011 at 11:44 AM, Jack Bates <jbates at brightok.net> wrote:
>> Take your budget, subtract ($base fee ($100?) * entities), then divide by
>> the appropriate /24 number. Something tells me, it is way below $1 per /24.
>> This is a rough estimate based on v4 alone. If the equation balances
>> properly between v4 and v6 size differentials, then the value should still
>> be close to the end result.
> 
> Hi Jack,
> 
> My back of the envelope calculations put it more like $5 to $10 per
> /24, but I haven't closely checked the math.
> 
> 37*65536=2.4M. ARIN's annual budget is something like $15M? 15/2.4=$6.25.
> 
> This would mean that entities (ISP and end-user both) which find it
> needful to employ IPv4 /9's would see their annual fees increase from
> $36k to $200k. But having run an 18k customer ISP on a little less
> than a /16 ($4500 now, $1600 with the formula) it seems to me that
> wouldn't break anyone's budget.

I presume these same fees apply to end-user and/or legacy assignments,
(since they are part of the calculation)  The model seems to assume 100%
participation and yet that's highly likely _not_ to occur with such fees.

FYI,
/John

John Curran
President and CEO
ARIN



From owen at delong.com  Fri Oct 28 12:04:44 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 28 Oct 2011 09:04:44 -0700
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
Message-ID: <3788AB2B-4413-4EF7-AF0D-21A286EE1556@delong.com>


On Oct 28, 2011, at 7:56 AM, John Curran wrote:

> On Oct 28, 2011, at 2:35 PM, William Herrin wrote:
> 
>> On Fri, Oct 28, 2011 at 10:03 AM, William Herrin <bill at herrin.us> wrote:
>>> I would also be willing to pay greater fees were those fees calculated
>>> something like this:
>>> 
>>> (  # of /24 IPv4 blocks held
>>> + # of /48 IPv6 blocks held
>>> + # of ASNs held)
>>> / total of the same across all ARIN registrants
>>> x ARIN's annual budget
>> 
>> I would also support a version of this formula which, for now, omits
>> IPv6 from the equation. There's something to be said for progressive
>> taxation which encourages healthy behavior by reducing its cost.
> 
> Presumably, legacy block holders currently receiving services without 
> charge would begin paying these fees upon signing the LRSA?  I imagine
> a few /8 and /16 address holders might suggest that the services they
> require do not cause ARIN expenses even close to the suggested fees?
> This becomes even more important if you omit IPv4 from the equation.
> 
I think you mean if you omit IPv6 from the equation.

Frankly, I oppose this structure in general. ARIN's cost to administer
address space are related to three factors:

	1.	The number of resources for which ARIN is maintaining
		records.

	2.	The number of organizations conducting interactions with
		ARIN.

	3.	The number of add/update/remove transactions that ARIN
		is processing.

Nowhere in the above list does the size of the address space have
any direct effect. Size combined with nature of usage (ISP vs. end
user) may have some second-order impacts and swip vs. rwhois
may also have some impact.

I would not oppose modifying ISP fees such that those who use
rwhois pay less than those who use SWIP.

I do oppose treating end users the same as ISPs from a fee perspective
because end users as a general rule have very few interactions with
ARIN beyond requesting space and the occasional POC update (very
occasional). Additionally, end-users are generally not using the addresses
they receive in a "resale" manner and often are not making any sort of
direct profit from the possession of the addresses themselves, vs. the
ISP whose bread-and-butter is the services that they can provide using
the addresses.

Owen



From jbates at brightok.net  Fri Oct 28 12:13:19 2011
From: jbates at brightok.net (Jack Bates)
Date: Fri, 28 Oct 2011 11:13:19 -0500
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <6625EC14-7975-4506-B160-362BD9F18265@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<6625EC14-7975-4506-B160-362BD9F18265@arin.net>
Message-ID: <4EAAD49F.7040806@brightok.net>

On 10/28/2011 10:50 AM, John Curran wrote:
>
> ARIN's full budget is approx $15M annually; feel free to propose
> a fee structure that you believe is appropriate.
>

16mil - 2mil (rough $500 membership fee)

Just based on 37 /8's (ignoring the 39), that's $5.77 per /24

I'm guessing LRSA isn't in the 37 assigned, so if we discounted them 
except for membership fee, a member with a /16 of IPv4 would come out to 
$1477.12 + $500 membership fee. In general, though, I'd just set a 
special set price for legacy usage, and if their IPv6 hits a mark, 
switch them to IPv6 per /48 pricing.

If you want to run set pricing, and not some dynamic pricing scheme, I'd 
be happy if you just adjusted IPv6, as people like to see a set price, 
not one that changes:

Small	 /32
Medium   /28
Large    /24
X-Large  /20 or /16
XX-Large  /12 or larger

This would seem to more closely match current IPv6 pricing to IPv4 
pricing with current allocation policies.

Jack



From owen at delong.com  Fri Oct 28 12:16:28 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 28 Oct 2011 09:16:28 -0700
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
Message-ID: <B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>


On Oct 28, 2011, at 8:58 AM, William Herrin wrote:

> On Fri, Oct 28, 2011 at 11:44 AM, Jack Bates <jbates at brightok.net> wrote:
>> Take your budget, subtract ($base fee ($100?) * entities), then divide by
>> the appropriate /24 number. Something tells me, it is way below $1 per /24.
>> This is a rough estimate based on v4 alone. If the equation balances
>> properly between v4 and v6 size differentials, then the value should still
>> be close to the end result.
> 
> Hi Jack,
> 
> My back of the envelope calculations put it more like $5 to $10 per
> /24, but I haven't closely checked the math.
> 
> 37*65536=2.4M. ARIN's annual budget is something like $15M? 15/2.4=$6.25.
> 
> This would mean that entities (ISP and end-user both) which find it
> needful to employ IPv4 /9's would see their annual fees increase from
> $36k to $200k. But having run an 18k customer ISP on a little less
> than a /16 ($4500 now, $1600 with the formula) it seems to me that
> wouldn't break anyone's budget.
> 

While I personally like the idea of having my end-user fees reduced from $100
to $18.75, I really don't think that would be any more fair in general than having
them increased to $300.

I would find $118.75 well within tolerance if that is what you are proposing.

Owen



From jsw at inconcepts.biz  Fri Oct 28 13:46:16 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Fri, 28 Oct 2011 13:46:16 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <4EAABB07.4070000@brightok.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<4EAABB07.4070000@brightok.net>
Message-ID: <CAPWAtbKXHJ-VjsaxswwsBauw=hQHuB5y4XLv0ijFLoy5Ef2YeA@mail.gmail.com>

On Fri, Oct 28, 2011 at 10:24 AM, Jack Bates <jbates at brightok.net> wrote:
> I can't complain about the cost differences for enduser/ISP. Just fix IPv6
> which is on it's way to making ARIN a LOT more money, and doing less work in
> exchange.

I don't understand how you could forecast ARIN to generate too much
revenue from IPv6.  It should be uncommon for an organization, ISP or
otherwise, to need more than a handful of IPv6 allocations.  On the
other hand, we all know that IPv4 depletion has been hanging over our
heads since before ARIN was created, thus IPv4 policy has caused all
growing organizations to have to go back to ARIN and request more and
more address space.  Also, I would hope networks will figure out how
to put a lot more customers and services into an IPv6 allocation
within a given size/fee tier than the similarly-priced IPv4
allocations.  If not, they at least have made that choice themselves
and there is every reason to believe they think the fees are worth the
extra address space.

If I thought people would be shutting off their IPv4 anytime soon
because it isn't useful, I would worry about ARIN being able to
generate *enough* revenue given the current fee system.  Perhaps that
is a problem ARIN will have to solve ten years from now, but there
seems to be no danger of IPv4 being deprecated in the predictable
future.

I also do not understand why ISPs that SWIP address space to their
customers create substantially more cost than an end-user who does not
need to SWIP.  I know there are statistics available on the number of
SWIP requests processed automatically vs how many require some kind of
assistance from hostmaster at arin.net.  If ISPs can't figure out how to
get SWIPs handled by automation, creating significant work for the
ARIN staff, then non-automated SWIP requests should have an associated
fee based on how much ARIN thinks it costs to process them.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From bill at herrin.us  Fri Oct 28 14:07:34 2011
From: bill at herrin.us (William Herrin)
Date: Fri, 28 Oct 2011 14:07:34 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
Message-ID: <CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>

On Fri, Oct 28, 2011 at 12:16 PM, Owen DeLong <owen at delong.com> wrote:
> On Oct 28, 2011, at 8:58 AM, William Herrin wrote:
>> On Fri, Oct 28, 2011 at 11:44 AM, Jack Bates <jbates at brightok.net> wrote:
>>> Take your budget, subtract ($base fee ($100?) * entities), then divide by
>>> the appropriate /24 number. Something tells me, it is way below $1 per /24.
>>> This is a rough estimate based on v4 alone. If the equation balances
>>> properly between v4 and v6 size differentials, then the value should still
>>> be close to the end result.
>>
>> Hi Jack,
>>
>> My back of the envelope calculations put it more like $5 to $10 per
>> /24, but I haven't closely checked the math.
>>
>> 37*65536=2.4M. ARIN's annual budget is something like $15M? 15/2.4=$6.25.
>>
>> This would mean that entities (ISP and end-user both) which find it
>> needful to employ IPv4 /9's would see their annual fees increase from
>> $36k to $200k. But having run an 18k customer ISP on a little less
>> than a /16 ($4500 now, $1600 with the formula) it seems to me that
>> wouldn't break anyone's budget.
>>
>
> While I personally like the idea of having my end-user fees reduced from $100
> to $18.75, I really don't think that would be any more fair in general than having
> them increased to $300.
>
> I would find $118.75 well within tolerance if that is what you are proposing.

Hi Owen,

I could live with $base + $proportional where $base was $100 per org
regardless of org type* and $proportional was linear per /24. In
principle, I think that strikes an equitable balance between what
seems to me like two reasonable but opposing theories of fairness.

The * being that we did more or less promise, as a condition of ARIN's
creation, to leave alone those legacy IPv4 registrants who want to be
left alone. With the rise of IPv6 (and subsequent decline of IPv4) set
to moot the issue, I think it unhelpful to reopen the wound.


Back of the envelope, that pulls something like $3M of ARIN's budget
from the per-org fee with the remainder from per-/24 fees at about $5
each. So, one of the orgs I manage with a /22 would go from $100/year
to $120/year, an ISP with a /16 would go from $4500 to $1380 and a
transnational with a /9 would go from $36,000 to $164,000.

I like what it does in the middle. That looks small-business-friendly
to me, much more so than the current regime.


Though selfishly, I'm not sure but that I wouldn't rather pay $300
with the certainty that I and every other end-user org become general
members with a vote.

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 jbates at brightok.net  Fri Oct 28 14:22:40 2011
From: jbates at brightok.net (Jack Bates)
Date: Fri, 28 Oct 2011 13:22:40 -0500
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAPWAtbKXHJ-VjsaxswwsBauw=hQHuB5y4XLv0ijFLoy5Ef2YeA@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<4EAABB07.4070000@brightok.net>
	<CAPWAtbKXHJ-VjsaxswwsBauw=hQHuB5y4XLv0ijFLoy5Ef2YeA@mail.gmail.com>
Message-ID: <4EAAF2F0.4020903@brightok.net>



On 10/28/2011 12:46 PM, Jeff Wheeler wrote:

> I don't understand how you could forecast ARIN to generate too much
> revenue from IPv6.  It should be uncommon for an organization, ISP or
> otherwise, to need more than a handful of IPv6 allocations.  On the
> other hand, we all know that IPv4 depletion has been hanging over our
> heads since before ARIN was created, thus IPv4 policy has caused all
> growing organizations to have to go back to ARIN and request more and

Handful of allocations? What has that to do with anything? Many ISPs 
will have a single allocation, no matter what the size. I don't pay by 
number of allocations for IPv4. I pay for the aggregate equivalent. And 
yes, as long as we have IPv4, ARIN does more work to maintain it. 
However, I'm not sure that actual makes up a large portion of ARIN's budget.

> more address space.  Also, I would hope networks will figure out how
> to put a lot more customers and services into an IPv6 allocation
> within a given size/fee tier than the similarly-priced IPv4
> allocations.  If not, they at least have made that choice themselves
> and there is every reason to believe they think the fees are worth the
> extra address space.
>

> If I thought people would be shutting off their IPv4 anytime soon
> because it isn't useful, I would worry about ARIN being able to
> generate *enough* revenue given the current fee system.  Perhaps that
> is a problem ARIN will have to solve ten years from now, but there
> seems to be no danger of IPv4 being deprecated in the predictable
> future.
>
Actually, with the newer policy and nibble allocations, the problem is 
that a network can grow extremely large very fast. If you need a /27 of 
IPv6, you are jumping up to a /24, which is MUCH larger. If it were more 
inline with the current IPv4 Tier system, the revenue should be near the 
same. This is why I recommended the nibble boundary pricing escalation.

ARIN should only lose revenue if ISPs get extremely tight with their 
allocations. If they follow the model and don't short change their 
customers, ARIN should be fine.

> I also do not understand why ISPs that SWIP address space to their
> customers create substantially more cost than an end-user who does not
> need to SWIP.  I know there are statistics available on the number of
> SWIP requests processed automatically vs how many require some kind of
> assistance from hostmaster at arin.net.  If ISPs can't figure out how to

They aren't. The problem is, there wouldn't be an end-user if they raise 
the end-user rates too much. The ISP is subsidizing ARIN for everyone 
else. I'm okay with this.


Jack


From jsw at inconcepts.biz  Fri Oct 28 15:10:37 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Fri, 28 Oct 2011 15:10:37 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <4EAAF2F0.4020903@brightok.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<4EAABB07.4070000@brightok.net>
	<CAPWAtbKXHJ-VjsaxswwsBauw=hQHuB5y4XLv0ijFLoy5Ef2YeA@mail.gmail.com>
	<4EAAF2F0.4020903@brightok.net>
Message-ID: <CAPWAtbK6W7OD=QUH0Knn831oa+xZeB1aQ7mLtQ6B_LzeEqjbzw@mail.gmail.com>

On Fri, Oct 28, 2011 at 2:22 PM, Jack Bates <jbates at brightok.net> wrote:
> Actually, with the newer policy and nibble allocations, the problem is that
> a network can grow extremely large very fast. If you need a /27 of IPv6, you
> are jumping up to a /24, which is MUCH larger. If it were more inline with
> the current IPv4 Tier system, the revenue should be near the same. This is
> why I recommended the nibble boundary pricing escalation.

If you choose to number your network that way and liberally hand out
/48s to all customers, you are still going to have room for a lot more
customers (or services) in any given IPv6 size category than if you
spent the same amount of money on IPv4.  I agree with you that if
allocations to ISPs will be nibble-based then it makes sense to align
the fees that way as well; but the money you have to spend on IPv6
addresses for customers will be substantially smaller than the money
you need to spend on IPv4, for substantially more resources available
to hand out to the customer and more numbering / aggregation
flexibility for the ISP.

> They aren't. The problem is, there wouldn't be an end-user if they raise the
> end-user rates too much. The ISP is subsidizing ARIN for everyone else. I'm
> okay with this.

I really don't care how much Owen pays for his legacy allocations.  I
am sure its value to him is much greater than $300/year.  I am sure
I'm not the only one who would like it if there weren't any legacy
end-user allocations in the DFZ.  If the proposed change were to raise
the fees to be the same as those for ISP fees, I would absolutely
support it.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From owen at delong.com  Fri Oct 28 15:51:22 2011
From: owen at delong.com (Owen DeLong)
Date: Fri, 28 Oct 2011 13:51:22 -0600
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAPWAtbK6W7OD=QUH0Knn831oa+xZeB1aQ7mLtQ6B_LzeEqjbzw@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<4EAABB07.4070000@brightok.net>
	<CAPWAtbKXHJ-VjsaxswwsBauw=hQHuB5y4XLv0ijFLoy5Ef2YeA@mail.gmail.com>
	<4EAAF2F0.4020903@brightok.net>
	<CAPWAtbK6W7OD=QUH0Knn831oa+xZeB1aQ7mLtQ6B_LzeEqjbzw@mail.gmail.com>
Message-ID: <3C1954BD-3A72-4469-8408-4FB7F399E8D9@delong.com>

I'd be ok with that. It would trigger my ability to keep my resources and opt out of the lrsa. Stop paying v4 fees altogether. Not sure, however that lines up with your actual intent. 

Owen 


Sent from my iPhone

On Oct 28, 2011, at 13:10, Jeff Wheeler <jsw at inconcepts.biz> wrote:

> On Fri, Oct 28, 2011 at 2:22 PM, Jack Bates <jbates at brightok.net> wrote:
>> Actually, with the newer policy and nibble allocations, the problem is that
>> a network can grow extremely large very fast. If you need a /27 of IPv6, you
>> are jumping up to a /24, which is MUCH larger. If it were more inline with
>> the current IPv4 Tier system, the revenue should be near the same. This is
>> why I recommended the nibble boundary pricing escalation.
> 
> If you choose to number your network that way and liberally hand out
> /48s to all customers, you are still going to have room for a lot more
> customers (or services) in any given IPv6 size category than if you
> spent the same amount of money on IPv4.  I agree with you that if
> allocations to ISPs will be nibble-based then it makes sense to align
> the fees that way as well; but the money you have to spend on IPv6
> addresses for customers will be substantially smaller than the money
> you need to spend on IPv4, for substantially more resources available
> to hand out to the customer and more numbering / aggregation
> flexibility for the ISP.
> 
>> They aren't. The problem is, there wouldn't be an end-user if they raise the
>> end-user rates too much. The ISP is subsidizing ARIN for everyone else. I'm
>> okay with this.
> 
> I really don't care how much Owen pays for his legacy allocations.  I
> am sure its value to him is much greater than $300/year.  I am sure
> I'm not the only one who would like it if there weren't any legacy
> end-user allocations in the DFZ.  If the proposed change were to raise
> the fees to be the same as those for ISP fees, I would absolutely
> support it.
> 
> -- 
> Jeff S Wheeler <jsw at inconcepts.biz>
> Sr Network Operator  /  Innovative Network Concepts
> _______________________________________________
> 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 josmon at rigozsaurus.com  Fri Oct 28 15:48:05 2011
From: josmon at rigozsaurus.com (John Osmon)
Date: Fri, 28 Oct 2011 13:48:05 -0600
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
References: <6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
Message-ID: <20111028194805.GA28807@jeeves.rigozsaurus.com>

On Fri, Oct 28, 2011 at 09:16:28AM -0700, Owen DeLong wrote:
[...]
> While I personally like the idea of having my end-user fees reduced from $100
> to $18.75, I really don't think that would be any more fair in general than having
> them increased to $300.
> 
> I would find $118.75 well within tolerance if that is what you are proposing.

Count me among those with nearly identical thoughts.



From jcurran at arin.net  Fri Oct 28 16:43:22 2011
From: jcurran at arin.net (John Curran)
Date: Fri, 28 Oct 2011 20:43:22 +0000
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
Message-ID: <5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>

On Oct 28, 2011, at 6:07 PM, William Herrin wrote:

> The * being that we did more or less promise, as a condition of ARIN's
> creation, to leave alone those legacy IPv4 registrants who want to be
> left alone. With the rise of IPv6 (and subsequent decline of IPv4) set
> to moot the issue, I think it unhelpful to reopen the wound.

The challenge, of course, is that we're also doing addition registry 
services like ARIN Online, DNSSEC, and resource certification which
help the entire community by their deployment and weren't in the set
of services at that time.  The Internet doesn't remain still, and we
have to evolve registry services and policy in this region on behalf
of everyone, including legacy address registrations.  This is why I 
emphasize the importance for legacy address holders to get involved,
because they will be affected by the services and policies in this
region whether they participate in the decisions or not (e.g., all
organizational records in the registry now have an abuse contact.)

When it comes to something like ability to support DNSSEC records,
or use RESTful interfaces to ARIN online, or participate in RPKI,
use of these services could be claimed to be of benefit to the 
entire community, or could be considered optional.  If we provide
these services to everyone, including legacy address holders, then
we require entry into a registration services and we can either 
recover the costs "ala cart" or in the base annual maintenance fee.
This question applies to both end-user registrations and those with
legacy registration who want to make use of these services (those 
legacy users who don't want any of these services will likely just
keep the status quo and not enter into an LRSA.)  

In general, would you prefer seeing all of the $base fees be higher
(e.g. $250) or have ARIN charge separately for new service features,
even those which might improve the security or quality of registry 
data for everyone?  I can easily argue the merits of either side of
this, and really need to hear more input from the community before
preparing various fees structures for the ARIN Board to consider.

Thanks!
/John

John Curran
President and CEO
ARIN





From mysidia at gmail.com  Fri Oct 28 20:24:16 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 28 Oct 2011 19:24:16 -0500
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAAAwwbWBFy43Aax3eKsFpWZhRe_FY8QVM7ZyYfsJ0OWeLCC5_Q@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
	<CACD75E6.C0C6%john.sweeting@twcable.com>
	<7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>
	<5F5A25B5-7720-4CDA-8715-8AF404C4D648@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB39A@SBS2011.thewireinc.local>
	<30C82F45-456E-4EC9-9221-E957C7A6EA39@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB3F2@SBS2011.thewireinc.local>
	<CAAAwwbWBFy43Aax3eKsFpWZhRe_FY8QVM7ZyYfsJ0OWeLCC5_Q@mail.gmail.com>
Message-ID: <CAAAwwbVMkhW-_-CKQqSw1w+OUJegY3WYy8GR3h9LNqHfJPwifA@mail.gmail.com>

[snip]
Speaking of fees and costs for ARIN.
Inter RIR transfer results in the IP addresses leaving the scope of
ARIN management,
however,  ARIN has to create in its database, an indication that "part
of this ARIN /8"
is no longer managed by ARIN.

This means that there is a cost to effect the transfer, and a cost to
keep this entry in ARIN's database.
So who pays for the transfer cost?

Does ARIN plan to charge a special fee to request an Inter-RIR
transfer, and a recurring maintenance fee to maintain the RIR
reassignment,  or will the ARIN resource holders bear the ongoing cost
of transfers and maintaining database information  through their
annual maintenance charges?


--
-JH


From jcurran at arin.net  Fri Oct 28 20:36:07 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 29 Oct 2011 00:36:07 +0000
Subject: [arin-ppml] 2011-1 dissent Was: Re: ARIN-2011-1:
 ARINInter-RIRTransfers - Last Call
In-Reply-To: <CAAAwwbVMkhW-_-CKQqSw1w+OUJegY3WYy8GR3h9LNqHfJPwifA@mail.gmail.com>
References: <7E7773B523E82C478734E793E58F69E7FCA120@SBS2011.thewireinc.local>
	<CACD75E6.C0C6%john.sweeting@twcable.com>
	<7E7773B523E82C478734E793E58F69E7FCB104@SBS2011.thewireinc.local>
	<5F5A25B5-7720-4CDA-8715-8AF404C4D648@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB39A@SBS2011.thewireinc.local>
	<30C82F45-456E-4EC9-9221-E957C7A6EA39@arin.net>
	<7E7773B523E82C478734E793E58F69E7FCB3F2@SBS2011.thewireinc.local>
	<CAAAwwbWBFy43Aax3eKsFpWZhRe_FY8QVM7ZyYfsJ0OWeLCC5_Q@mail.gmail.com>
	<CAAAwwbVMkhW-_-CKQqSw1w+OUJegY3WYy8GR3h9LNqHfJPwifA@mail.gmail.com>
Message-ID: <5363EE2B-B0E1-40C1-A636-A6603F3EB1B1@arin.net>

On Oct 29, 2011, at 12:24 AM, Jimmy Hess wrote:

> Speaking of fees and costs for ARIN.
> Inter RIR transfer results in the IP addresses leaving the scope of
> ARIN management,
> however,  ARIN has to create in its database, an indication that "part
> of this ARIN /8" is no longer managed by ARIN.
> 
> This means that there is a cost to effect the transfer, and a cost to
> keep this entry in ARIN's database. So who pays for the transfer cost?

From: <https://www.arin.net/fees/fee_schedule.html>:
"ARIN charges $250 USD for each transfer of Internet number resources.  In subsequent years, ARIN charges a consolidated $100 USD maintenance fee for all of the resources held by an organization (per OrgID), unless the organization also has an allocation, whereas the maintenance fee does not apply."

> Does ARIN plan to charge a special fee to request an Inter-RIR
> transfer, and a recurring maintenance fee to maintain the RIR
> reassignment,  or will the ARIN resource holders bear the ongoing cost
> of transfers and maintaining database information  through their
> annual maintenance charges?

The RIRs already have to track many such "holes" in the IPv4 /8s, 
and coordinate with other RIRs regarding registration and reverse
DNS services. We do not intend to change ongoing maintenance fees
for resources registered transferred into another RIR region.

Thanks,
/John

John Curran
President and CEO
ARIN




From mysidia at gmail.com  Fri Oct 28 20:59:11 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 28 Oct 2011 19:59:11 -0500
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
Message-ID: <CAAAwwbXL5QD7VZRHBqrjk0o9zc2d-tsN+p42D54427XLQhZjrg@mail.gmail.com>

On Fri, Oct 28, 2011 at 3:43 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 28, 2011, at 6:07 PM, William Herrin wrote:
[snip]
> or use RESTful interfaces to ARIN online, or participate in RPKI,
> use of these services could be claimed to be of benefit to the
> entire community, or could be considered optional. ?If we provide
> these services to everyone, including legacy address holders, then
> we require entry into a registration services and we can either
> recover the costs "ala cart" or in the base annual maintenance fee.

I would suggest a one time "turn on charge" for an organization to start
using the service,  when it is introduced, and a smaller increase in the
base fee across the board;  in other words, some of both.

I'm not sure it's viable though.    I suspect there will not be much general
interest in RPKI or DNSSEC records in RDNS for a long time.
This is a feature that a few organizations will want,  but DNSSEC doesn't have
much worldwide deployment in forward DNS let alone reverse zones.

It may be seen as a long term benefit to the community,  but that
doesn't necessarily
mean the community wants to pay for it yet.

ARIN should not go implementing new services if they will
significantly increase
costs,  unless enough of the membership has strongly told ARIN they
want this, and
are happy to pay more for this.

That is...  before implementing a new service that will be so
expensive to develop
that member fees might increase,  ARIN should send out a poll.
If  >80% of the membership say "yes, do this",  then everyone pays.


If  50 - 79% of those polled say yes,   then ARIN charges people to
turn on the service.
The service provides something a lot of people thought beneficial,
but a significant portion
of people don't want to pay for.

--
-JH


From jsw at inconcepts.biz  Sat Oct 29 12:54:26 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Sat, 29 Oct 2011 12:54:26 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
Message-ID: <CAPWAtbJanOa=Dv5VL=qDYnJHiCn0BFZzPEXBg-smJqqQefQT0g@mail.gmail.com>

On Fri, Oct 28, 2011 at 4:43 PM, John Curran <jcurran at arin.net> wrote:
> In general, would you prefer seeing all of the $base fees be higher
> (e.g. $250) or have ARIN charge separately for new service features,
> even those which might improve the security or quality of registry
> data for everyone?

I would like better services.  If that means that fees increase, I am
fine with that.  I hope we aren't forgetting that ARIN has accumulated
a war chest of about $26M USD and continues to operate at an annual
surplus.  This is not bad, but anyone who says fees have to increase
significantly or immediately for ARIN to provide additional services
just hasn't spent five minutes reading about how much revenue ARIN
receives and what its expenses are.  Truly, if it costs a million
dollars to write some Perl scripts and provide members with better
tools, ARIN can do that without increasing anyone's fees.

As you know, my primary concern is DFZ bloat and routing stability.  I
do not think RPKI is necessarily the best way to address this, but it
is one possible technical solution.  Another would be dramatically
improving the ARIN IRR, making it more user-friendly for both
publishing routing information and querying it.  We can certainly ask
ARIN to do both these things, not just one or the other.

Eventually, we will have one too many major leaks that result in
newspaper articles about "China" "intercepting" Internet traffic,
Youtube being blackholed as a result of technical errors by
governments trying to block it within their own borders spilling over
to the larger Internet, etc.  Government already wants this to stop
(who doesn't?) and if we don't come up with a good way to do it
ourselves, legislation will eventually force a bad way upon us -- some
kind of regulation that we don't want.

We should all be asking ARIN to spend its time and money on this
problem.  As a neutral party driven by the community, ARIN can and
should be the routing table cops.  It's eventually going to be
someone, and I'd rather it be ARIN than some government entity,
VeriSign, or whatever.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From jcurran at arin.net  Sat Oct 29 13:51:15 2011
From: jcurran at arin.net (John Curran)
Date: Sat, 29 Oct 2011 17:51:15 +0000
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAPWAtbJanOa=Dv5VL=qDYnJHiCn0BFZzPEXBg-smJqqQefQT0g@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAPWAtbJanOa=Dv5VL=qDYnJHiCn0BFZzPEXBg-smJqqQefQT0g@mail.gmail.com>
Message-ID: <28A93B53-388E-4532-9E68-4CD48E3FFA9D@arin.net>

On Oct 29, 2011, at 4:54 PM, Jeff Wheeler wrote:

> As you know, my primary concern is DFZ bloat and routing stability.  I
> do not think RPKI is necessarily the best way to address this, but it
> is one possible technical solution.  Another would be dramatically
> improving the ARIN IRR, making it more user-friendly for both
> publishing routing information and querying it.  We can certainly ask
> ARIN to do both these things, not just one or the other.

Could other folks interested in ARIN improving its IRR services
(or not investing here) please speak up?   At the recent ARIN 
meeting, we heard advocates of those who want ARIN to do more 
with IRR, but also from those who believe that there's already
an abundance of routing registries out there and ARIN investing 
time and effort in this area makes little sense.  More input
from the community on this topic would certainly be helpful.

Thanks!
/John

John Curran
President and CEO
ARIN



From mysidia at gmail.com  Sat Oct 29 17:33:00 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 29 Oct 2011 16:33:00 -0500
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <28A93B53-388E-4532-9E68-4CD48E3FFA9D@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAPWAtbJanOa=Dv5VL=qDYnJHiCn0BFZzPEXBg-smJqqQefQT0g@mail.gmail.com>
	<28A93B53-388E-4532-9E68-4CD48E3FFA9D@arin.net>
Message-ID: <CAAAwwbVLaq41sBknkp9Tme6ZUka7Uvhs1CEKaEsBeCR+7ND+=Q@mail.gmail.com>

On Sat, Oct 29, 2011 at 12:51 PM, John Curran <jcurran at arin.net> wrote:
> On Oct 29, 2011, at 4:54 PM, Jeff Wheeler wrote:
> Could other folks interested in ARIN improving its IRR services
> (or not investing here) please speak up? ? At the recent ARIN
> meeting, we heard advocates of those who want ARIN to do more
> with IRR, but also from those who believe that there's already

I would like to see ARIN coordinating with other RIRs to standardize
IRR services.    It doesn't make sense to me that each  RIR should develop
its own IRR infrastructure from scratch  out of their own pocket.

There ideally ought to be community involvement in the development of IRR
services, specifically...

Software developed to provide IRR  services ought to be the joint work of
the RIRs running IRRs and the community, and costs shared across regions
rather than ARIN just paying a million$$ or so  for a couple of folks to work
on ARIN's IRR frontend.

That is, I would see the technical characteristics of all the IRRs
being standardized,
how they work, the software utilized to provide IRR service, the user
interfaces,
web forms, and user APIs utilized to acess the service and update records,
the structure of records,  the schema indicating how records are recorded in a
database, etc.

--
-JH


From bill at herrin.us  Sun Oct 30 12:46:00 2011
From: bill at herrin.us (William Herrin)
Date: Sun, 30 Oct 2011 12:46:00 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
Message-ID: <CAP-guGU++ERfrkxku3PrQrRk3nJJncq53Y-w4qrbNMBoPfgJhQ@mail.gmail.com>

On Fri, Oct 28, 2011 at 4:43 PM, John Curran <jcurran at arin.net> wrote:
> In general, would you prefer seeing all of the $base fees be higher
> (e.g. $250) or have ARIN charge separately for new service features,
> even those which might improve the security or quality of registry
> data for everyone? ?I can easily argue the merits of either side of
> this, and really need to hear more input from the community before
> preparing various fees structures for the ARIN Board to consider.

Hi John,

So there are really four moving pieces to consider here, not just two.

There are the services where everybody is going to consume them or for
some other reason everybody must stand on equal footing.

There are the capabilities where folks with larger holdings will
generate greater consumption.

There are the services where only folks with specific needs will use them.

There are the pure overhead functions which don't directly serve the
registrants in any form but are required to keep the organization
running.


We'll all maintain an org record and POCs. As a matter of fairness, we
all require access to the PPML and the public meetings.

DNSSEC (as with all RDNS) will be consumed more heavily by registrants
with large holdings. The same with RPKI, whois and the REST API -- you
can expect about the same number of queries per registered IP address,
thus far more activity attributable to a large holder than a small
one.

There are things like the STLS or ARIN on the road which only specific
users will ever engage in.

And finally we have HR, payroll, marketing, etc.


In principle, I'd like to see the first group covered by the base fee,
the second group covered by fees linearly proportional to the
registrant's holdings and the third group by a la carte fees.

Traditionally the fourth group, pure overhead tasks, are tacked on as
a uniform percentage applied to each direct source of revenue. In
other words, if ARIN's budget excluding overhead was 30% base, 60%
proportional and 10% a la carte then the overhead costs should be
divvied up with the same percentages. Treating overhead and base as
the same category would be a major accounting error.

In practice, it's far easier to categorize something as base or
overhead than to do the careful evaluation it takes to place it in one
of the other categories. Worse, accounting for it well enough to
justify the numbers adds considerable and undesirable nuisance and
expense.


I guess where I'm going with this is that I think that rather than try
to calculate the optimal $base from the individual services, I think
you'll get a "better" result by seeking consensus on a formula (e.g.
$base + $linear resource consumption + $a la carte) and then polling
the community to find out (A) what folks think an intuitively "fair"
$base should be and (B) which items folks think belong in a la carte.
Discard the outliers, average the rest and from there you can
calculate $consumption. This leaves you with a complete answer that if
not scientifically computed at least accurately reflects the
community's preference.



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 jsw at inconcepts.biz  Sun Oct 30 13:14:05 2011
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Sun, 30 Oct 2011 13:14:05 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <28A93B53-388E-4532-9E68-4CD48E3FFA9D@arin.net>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAPWAtbJanOa=Dv5VL=qDYnJHiCn0BFZzPEXBg-smJqqQefQT0g@mail.gmail.com>
	<28A93B53-388E-4532-9E68-4CD48E3FFA9D@arin.net>
Message-ID: <CAPWAtb+6OZ03tVA0WZDGqiOt=XH5n72bJ_1Yw4DZ3cST=4DLSQ@mail.gmail.com>

On Sat, Oct 29, 2011 at 1:51 PM, John Curran <jcurran at arin.net> wrote:
> Could other folks interested in ARIN improving its IRR services
> (or not investing here) please speak up? ? At the recent ARIN
> meeting, we heard advocates of those who want ARIN to do more
> with IRR, but also from those who believe that there's already
> an abundance of routing registries out there and ARIN investing
> time and effort in this area makes little sense. ?More input
> from the community on this topic would certainly be helpful.

Many folks in the ARIN region do not understand how to take advantage
of IRR, or why it is of particular benefit for the RIR to operate a
good IRR database.  You have to look at RIPE's IRR, and then compare
to the data quality in ARIN-region IRRs, to understand what's really
going on.

All the major north american IRR databases are full of out-dated proxy
records which should have been deleted but haven't been, data for
previous holders of now-defunct ASNs, and so on.  This is not the
fault of the databases, but of the users.  The operators of RADB and
friends don't have any way to authenticate users against ARIN POCs.

Earlier this year, John discussed some ideas to greatly improve the
ARIN IRR service, which would make it more user-friendly.  If this
were done, it could go a long way toward enabling ISPs to correctly
filter eBGP sessions without implementing RPKI (which has far higher
cost and risk.)  It could reduce news-making BGP leaks that wreak
havoc without router vendors having to write any new code, without a
complex certificate system, and without the political concerns that
many people have about RPKI.

It could also be a tool to combat DFZ growth, not through making rules
or telling any address-holder that they can't inject their routes into
the DFZ, but through simply preventing mistakes from propagating
outside their own AS.

On Sat, Oct 29, 2011 at 5:33 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> That is, I would see the technical characteristics of all the IRRs
> being standardized,

This is already the case.  Part of the problem is actually that IRR
databases have too much functionality which makes it more difficult
than necessary to implement (if you decide to roll your own software.)
 A subset of the defined features, which ignores RPSL, is perfectly
fine.

The trouble here is RPSL was meant to allow operators to fully express
any routing policy they might wish to configure into their network in
an abstract, vendor-neutral form, so all your route-maps or
policy-statements, ACLs / firewall filters, etc. could come from your
RPSL database, which you may choose to operate privately within your
organization, or store in a public database.  That is not needed to
simply prevent operator errors from wrecking the DFZ.

If you ignore all that extra crap, and implement only what is needed,
it is extremely easy to have a light-weight set of IRR tools.  I am
guessing this is what you mean should be standardized, and I
completely agree with you.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From owen at delong.com  Sun Oct 30 13:23:18 2011
From: owen at delong.com (Owen DeLong)
Date: Sun, 30 Oct 2011 10:23:18 -0700
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGU++ERfrkxku3PrQrRk3nJJncq53Y-w4qrbNMBoPfgJhQ@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>!
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAP-guGU++ERfrkxku3PrQrRk3nJJncq53Y-w4qrbNMBoPfgJhQ@mail.gmail.com>
Message-ID: <4668DE56-E026-451F-9ACA-209DC992DCAA@delong.com>


On Oct 30, 2011, at 9:46 AM, William Herrin wrote:

> On Fri, Oct 28, 2011 at 4:43 PM, John Curran <jcurran at arin.net> wrote:
>> In general, would you prefer seeing all of the $base fees be higher
>> (e.g. $250) or have ARIN charge separately for new service features,
>> even those which might improve the security or quality of registry
>> data for everyone?  I can easily argue the merits of either side of
>> this, and really need to hear more input from the community before
>> preparing various fees structures for the ARIN Board to consider.
> 
> Hi John,
> 
> So there are really four moving pieces to consider here, not just two.
> 
> There are the services where everybody is going to consume them or for
> some other reason everybody must stand on equal footing.
> 
> There are the capabilities where folks with larger holdings will
> generate greater consumption.
> 
> There are the services where only folks with specific needs will use them.
> 
> There are the pure overhead functions which don't directly serve the
> registrants in any form but are required to keep the organization
> running.
> 
> 
> We'll all maintain an org record and POCs. As a matter of fairness, we
> all require access to the PPML and the public meetings.
> 
> DNSSEC (as with all RDNS) will be consumed more heavily by registrants
> with large holdings. The same with RPKI, whois and the REST API -- you
> can expect about the same number of queries per registered IP address,
> thus far more activity attributable to a large holder than a small
> one.
> 

Sorry, I'm having trouble understanding here how an NS record covering
a /32 is going to consume more than an NS record covering a /48.

Can you please explain that one to me?

Seems to me that rDNS and DNSSEC are proportional to the number of
prefixes, not the size of the prefixes.

I have trouble seeing that ANY ARIN costs are actually directly or linearly
proportional to the size of the delegation vs. the number of delegation
records other than, perhaps SWIP, but, again, that's really the number of
reassignment/reallocation records, not the size of the reassignments/
reallocations, as well.
 
> There are things like the STLS or ARIN on the road which only specific
> users will ever engage in.
> 
> And finally we have HR, payroll, marketing, etc.
> 
> 
> In principle, I'd like to see the first group covered by the base fee,
> the second group covered by fees linearly proportional to the
> registrant's holdings and the third group by a la carte fees.
> 

I'd like to see this mythical second group clearly defined. In spite of your
continuing to insist that it exists and fees should be structured accordingly,
I remain unconvinced that it does, in fact, even exist.
> 

Owen




From owen at delong.com  Sun Oct 30 13:31:43 2011
From: owen at delong.com (Owen DeLong)
Date: Sun, 30 Oct 2011 10:31:43 -0700
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAPWAtb+6OZ03tVA0WZDGqiOt=XH5n72bJ_1Yw4DZ3cST=4DLSQ@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>!
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAPWAtbJanOa=Dv5VL=qDYnJHiCn0BFZzPEXBg-smJqqQefQT0g@mail.gmail.com>
	<28A93B53-388E-4532-9E68-4CD48E3FFA9D@arin.net>
	<CAPWAtb+6OZ03tVA0WZDGqiOt=XH5n72bJ_1Yw4DZ3cST=4DLSQ@mail.gmail.com>
Message-ID: <A459A13E-BC4F-4C10-91E8-E66083DC7AB7@delong.com>


On Oct 30, 2011, at 10:14 AM, Jeff Wheeler wrote:

> On Sat, Oct 29, 2011 at 1:51 PM, John Curran <jcurran at arin.net> wrote:
>> Could other folks interested in ARIN improving its IRR services
>> (or not investing here) please speak up?   At the recent ARIN
>> meeting, we heard advocates of those who want ARIN to do more
>> with IRR, but also from those who believe that there's already
>> an abundance of routing registries out there and ARIN investing
>> time and effort in this area makes little sense.  More input
>> from the community on this topic would certainly be helpful.
> 
> Many folks in the ARIN region do not understand how to take advantage
> of IRR, or why it is of particular benefit for the RIR to operate a
> good IRR database.  You have to look at RIPE's IRR, and then compare
> to the data quality in ARIN-region IRRs, to understand what's really
> going on.
> 
People that want IRR services in the ARIN region, by and large, use RADB
and don't bother with the ARIN IRR.

I, for one, am fine with this. RADB has modest fees and operates a decent
system. I wouldn't want to see all ARIN recipients forced to pony up so that
ARIN can reinvent the wheel or become more competitive with RADB.

> All the major north american IRR databases are full of out-dated proxy
> records which should have been deleted but haven't been, data for
> previous holders of now-defunct ASNs, and so on.  This is not the
> fault of the databases, but of the users.  The operators of RADB and
> friends don't have any way to authenticate users against ARIN POCs.
> 
True. I would support the idea of ARIN working to come to some form
of database maintenance arrangement with RADB or one of the other
IRRs and improving the quality of the data in that way. Such an action
could be accomplished under existing NDAs as some form of outsourcing
of the ARIN IRR to one of these third parties. That should be achievable
at little or no additional cost to resource holders. If done right, it should
pay for itself or even save money by eliminating the cost of running the
current ARIN IRR.

> Earlier this year, John discussed some ideas to greatly improve the
> ARIN IRR service, which would make it more user-friendly.  If this
> were done, it could go a long way toward enabling ISPs to correctly
> filter eBGP sessions without implementing RPKI (which has far higher
> cost and risk.)  It could reduce news-making BGP leaks that wreak
> havoc without router vendors having to write any new code, without a
> complex certificate system, and without the political concerns that
> many people have about RPKI.
> 

It could, in an ideal world do all of those things. In the real world, the
odds of most ISPs actually doing so is relatively low.

> It could also be a tool to combat DFZ growth, not through making rules
> or telling any address-holder that they can't inject their routes into
> the DFZ, but through simply preventing mistakes from propagating
> outside their own AS.
> 

I'm not sure to what extent this would help. Do you have any numerical
analysis of this?

Of course I'm also not nearly as convinced that DFZ growth from normal
causes is all that much of an issue any more. The bigger issue, I think,
will come from transfer disaggregation as the market for addresses comes
into full swing. 

Owen



From bill at herrin.us  Sun Oct 30 15:22:43 2011
From: bill at herrin.us (William Herrin)
Date: Sun, 30 Oct 2011 15:22:43 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <4668DE56-E026-451F-9ACA-209DC992DCAA@delong.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAP-guGU++ERfrkxku3PrQrRk3nJJncq53Y-w4qrbNMBoPfgJhQ@mail.gmail.com>
	<4668DE56-E026-451F-9ACA-209DC992DCAA@delong.com>
Message-ID: <CAP-guGWy4ie1r_308qruN5HX2qkLY2Gb7bN4ZWfnehcqhzb_1g@mail.gmail.com>

On Sun, Oct 30, 2011 at 1:23 PM, Owen DeLong <owen at delong.com> wrote:
> Sorry, I'm having trouble understanding here how an NS record covering
> a /32 is going to consume more than an NS record covering a /48.
>
> Can you please explain that one to me?

Which record would say is requested more frequently?

com NS or delong.com NS?
3.2.192.in-addr.arpa NS or 192.in-addr.arpa NS?

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  Sun Oct 30 15:24:45 2011
From: bill at herrin.us (William Herrin)
Date: Sun, 30 Oct 2011 15:24:45 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAPWAtbJanOa=Dv5VL=qDYnJHiCn0BFZzPEXBg-smJqqQefQT0g@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAPWAtbJanOa=Dv5VL=qDYnJHiCn0BFZzPEXBg-smJqqQefQT0g@mail.gmail.com>
Message-ID: <CAP-guGVpJXBCVU071+aC5RiYSdbLSjM3Tcrt4mj7_hKbRiM1TA@mail.gmail.com>

On Sat, Oct 29, 2011 at 12:54 PM, Jeff Wheeler <jsw at inconcepts.biz> wrote:
> As you know, my primary concern is DFZ bloat and routing stability. ?I
> do not think RPKI is necessarily the best way to address this, but it
> is one possible technical solution.

Hi Jeff,

The last time I read anything about it (which I confess was quite some
time ago), RPKI really didn't address DFZ bloat. It's main concern was
permitting a router to assess whether (A) a given AS was approved to
originate a particular address space and (B) whether two adjacent ASes
in a given BGP path are forged.


On Sat, Oct 29, 2011 at 1:51 PM, John Curran <jcurran at arin.net> wrote:
> Could other folks interested in ARIN improving its IRR services
> (or not investing here) please speak up?   At the recent ARIN
> meeting, we heard advocates of those who want ARIN to do more
> with IRR, but also from those who believe that there's already
> an abundance of routing registries out there and ARIN investing
> time and effort in this area makes little sense.  More input
> from the community on this topic would certainly be helpful.

Hi John,

While the RIRs offer a natural home for such a service once built, I
don't believe it necessary for them to spearhead or fund its initial
construction.

Google, eBay, Bank of America. These are the kinds of folks with the
most significant stake in preventing brief, generally accidental,
disruption of their Internet routing. Let them both set the priority
with which such a system is built and bear the cost of that
construction.

Certainly if I was asked to pay an extra $200/year solely to fund
RPKI, I would find it objectionable.

DNSSEC, on the other hand, deals with a protocol flaw which unlike
false route origination is not adequately resolved by remedies at law.
It also uses software whose construction is complete; ARIN's
implementation need only glue on the registration component.

I don't think DNSSEC's funding belongs in my $base because the issue
disproportionally impacts large organizations. I'd be well satisfied
to fund it from my $proportional.

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  Sun Oct 30 16:38:16 2011
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 30 Oct 2011 15:38:16 -0500
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGWy4ie1r_308qruN5HX2qkLY2Gb7bN4ZWfnehcqhzb_1g@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAP-guGU++ERfrkxku3PrQrRk3nJJncq53Y-w4qrbNMBoPfgJhQ@mail.gmail.com>
	<4668DE56-E026-451F-9ACA-209DC992DCAA@delong.com>
	<CAP-guGWy4ie1r_308qruN5HX2qkLY2Gb7bN4ZWfnehcqhzb_1g@mail.gmail.com>
Message-ID: <CAAAwwbXwUicCcjhOgL2x8E4ufrPm17VY34sCsr81PHhLKT83YA@mail.gmail.com>

On Sun, Oct 30, 2011 at 2:22 PM, William Herrin <bill at herrin.us> wrote:
> On Sun, Oct 30, 2011 at 1:23 PM, Owen DeLong <owen at delong.com> wrote:
> Which record would say is requested more frequently?
> com NS or delong.com NS?
> 3.2.192.in-addr.arpa NS or 192.in-addr.arpa NS?
[snip]
192.in-addr.arpa  is a "special" zone because it corresponds to a
reverse zone in which a popular portion of RFC1918 IP address space
resides.
For other IP address ranges, the number of  RDNS requests about those
ranges is much more complicated than merely the 'amount of resources'.

It depends on how those IP resources are actually utilized.
If the resources are utilized primarily from mail servers, then there
are likely to be a great many reverse DNS requests for the ranges.

If no outgoing TCP connections are being made from those addresses,
then, the volume of RDNS queries made from them would be quite
limited.

If you want to be "fair"  about number of RDNS queries or WHOIS
queries against a resource, then
meter them,

and add a "variable portion"  to members'  annual maintenance based on
the volume of queries that were made to ARIN  regarding their
resources.


(Cost to ARIN of providing RDNS services)   DIVIDED by   (Total Number
of  queries against RDNS servers)  =   cost per query.

Resource holder's variable portion =      (cost per query) X  (number
of queries against that  resource holder's  IP addresses)


--
-JH


From bill at herrin.us  Sun Oct 30 18:24:58 2011
From: bill at herrin.us (William Herrin)
Date: Sun, 30 Oct 2011 18:24:58 -0400
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAAAwwbXwUicCcjhOgL2x8E4ufrPm17VY34sCsr81PHhLKT83YA@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAP-guGU++ERfrkxku3PrQrRk3nJJncq53Y-w4qrbNMBoPfgJhQ@mail.gmail.com>
	<4668DE56-E026-451F-9ACA-209DC992DCAA@delong.com>
	<CAP-guGWy4ie1r_308qruN5HX2qkLY2Gb7bN4ZWfnehcqhzb_1g@mail.gmail.com>
	<CAAAwwbXwUicCcjhOgL2x8E4ufrPm17VY34sCsr81PHhLKT83YA@mail.gmail.com>
Message-ID: <CAP-guGV38PhqFuXY4MmwxD=uhwNT2o1QbM_unQxThjezvUhZsQ@mail.gmail.com>

On Sun, Oct 30, 2011 at 4:38 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> 192.in-addr.arpa ?is a "special" zone because it corresponds to a
> reverse zone in which a popular portion of RFC1918 IP address space
> resides.
> For other IP address ranges, the number of ?RDNS requests about those
> ranges is much more complicated than merely the 'amount of resources'.

Hi Jimmy,

Then for a moment, lets put aside the fact that holders with larger
ranges tend (in a complicated fashion) to consume more server
resources than those with smaller ranges and consider the matter from
another direction that's less complicated.

Quantity Discount is a very common sales feature tied to a real
effect: large customers tend to be less work (thus less cost) per unit
sold than small customers. ARIN is not an exception, it's exemplary of
the rule: with virtually no source cost to the IP address product
itself, nearly all the cost is tied up in the work done to fulfill the
product's delivery.

Were we ARIN shareholders looking to maximize ARIN's delivery of
product and revenue, quantity discount would serve us well.

But maximizing ARIN's delivery of IPv4 product DOES NOT serve us well.
We have a dire shortage of IPv4 product and zero interest in
increasing ARIN's revenue beyond what it needs to operate in the
black. As a matter of policy, we want to dissuade large consumption of
IPv4 product and encourage purchase of the IPv6 product and even the
return of the IPv4 product instead.

Quantity discount is diametrically opposed to this goal. If we want to
encourage IPv6 and discourage IPv4, the very last thing we should do
is support large quantities of IPv4 at a per-unit discount. Doing so
is contrary to good stewardship of a scarce resource.

A good move?

IPv6 as a loss-leader. Linear or even ballooning price for quantities of IPv4.


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  Mon Oct 31 01:31:12 2011
From: owen at delong.com (Owen DeLong)
Date: Sun, 30 Oct 2011 22:31:12 -0700
Subject: [arin-ppml] Fee structures for ARIN
In-Reply-To: <CAP-guGWy4ie1r_308qruN5HX2qkLY2Gb7bN4ZWfnehcqhzb_1g@mail.gmail.com>
References: <alpine.LNX.2.01.1110070930490.18595@filesrv1.baby-dragons.com>
	<CAP-guGUhmRjg=VbrVGxvTyj14x=5du85UhQp+O+z+Q7dc6i=6w@mail.gmail.com>
	<1C3526E9-781E-444C-8010-D96AEBA85D78@arin.net>
	<CAP-guGWsxESB9LRre__=t8PHPdxG0Fz8_ohk6BfknQ0HAr-SDQ@mail.gmail.com>
	<C2AE7862-E869-4C3F-AA79-1E387A19B3C0@arin.net>
	<CAP-guGXDspCgchg0TDn0grOhWnfgCjk+9TMnKqyk8d3O5_QkVQ@mail.gmail.com>
	<67A9C7EA-E184-4AD2-A816-1614A0E18A45@arin.net>
	<C6CE0E32-944B-402E-9BEC-B617F30EF6C8@delong.com>
	<B120CA37-11C3-45A6-A894-330A84F614E2@arin.net>
	<6B4A2F87-0E3C-4072-91AC-295FEF528418@delong.com>
	<55AB89C0-271B-412C-A72C-DC4C70873FDF@arin.net>
	<CAP-guGVJ6=WAVyi95NqC5utXFWDmU_2yfyHkTF7Y3i-hL_MQ=g@mail.gmail.com>
	<CAP-guGUt9z=P+P-KwvzFJeTcaqRQ_3OQi2W3fzWPwA_r42bUEQ@mail.gmail.com>
	<B2DF1C45-B112-46FF-A507-DF06FAA65B5F@arin.net>
	<4EAAC79C.1020307@brightok.net>
	<C78DC6E1-B125-412C-91AF-BF5702BF05E4@arin.net>
	<4EAACDF6.5020706@brightok.net>
	<CAP-guGX985aJzLcuqSYw-KQHGkoX34cUvR_-Jy6NAnd2UCiriA@mail.gmail.com>!
	<B3C240D6-8691-44C1-9F51-8E9D099AD848@delong.com>
	<CAP-guGVFC_6YfxFwVdK3FAMqGnN0cEUrnSGpicfO0dQA+-izUA@mail.gmail.com>
	<5B15108D-AA0C-4942-9D27-AD696927A0C1@arin.net>
	<CAP-guGU++ERfrkxku3PrQrRk3nJJncq53Y-w4qrbNMBoPfgJhQ@mail.gmail.com>
	<4668DE56-E026-451F-9ACA-209DC992DCAA@delong.com>
	<CAP-guGWy4ie1r_308qruN5HX2qkLY2Gb7bN4ZWfnehcqhzb_1g@mail.gmail.com>
Message-ID: <E1895EC4-7BB0-4A0A-B048-8D93600D3AAC@delong.com>


On Oct 30, 2011, at 12:22 PM, William Herrin wrote:

> On Sun, Oct 30, 2011 at 1:23 PM, Owen DeLong <owen at delong.com> wrote:
>> Sorry, I'm having trouble understanding here how an NS record covering
>> a /32 is going to consume more than an NS record covering a /48.
>> 
>> Can you please explain that one to me?
> 
> Which record would say is requested more frequently?
> 
> com NS or delong.com NS?

Depends on the server. My nameservers answer many more queries for
DELONG.COM. I'm guessing that the GTLD-SERVERS also answer more
queries for DELONG.COM (since they really shouldn't see queries for
COM NS most of the time). OTOH, the ROOT-SERVERS probably see
far more queries for COM and almost none for DELONG.COM.

> 3.2.192.in-addr.arpa NS or 192.in-addr.arpa NS?
> 

From ARIN's perspective, likely 3.2.192.in-addr.arpa. NS

192.in-addr.arpa is probably cached very quickly by the vast majority of
resolvers and likely ARIN sees some, but, not very many queries for this
when compared to the queries for delegated prefixes.

In a more realistic perspective, do you really believe that, for example,
the queries for 192.128.0.0/16 would somehow be significantly more load
than the queries for 192.129.128.0/17?

I would tend to bet that the queries for 192.128.0.0/16 would quite likely
be less, since the former requires only a single NS record set while
the latter requires ARIN to hold 128 NS delegation record sets each
of which must be cached individually by the resolving hosts.

In other words, yes, there is possibly some relationship to the prefix size
in terms of the DNS load, but, it is most definitely not a linear relationship
and more than likely not directly related even on a logarithmic or other
basis.

Owen