From SRyerse at eclipse-networks.com  Wed May  1 00:06:07 2013
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Wed, 1 May 2013 04:06:07 +0000
Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user
In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FC79286@CHAXCH01.corp.arin.net>
References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com><"B64177493F39B
	A4A81233AA84B50049E9B8A9684"@PACDCEXMB12.cable.comcast.com><"5B9E90747FA297
	4D91A54FCFA1B8AD1201313DA3E4"@ENI-MAIL.eclipse-networks.com><CAMApp345T9rGK
	Lo8Q8oZRdeo6NtTQA5RcWkGw0E4TrzoP6Y-UQ@mail.gmail.com><5B9E90747FA2974D91A54
	FCFA1B8AD1201313DB2BF@ENI-MAIL.eclipse-networks.com><8DA1853CE466B041B104C1
	CAEE00B3748FC79128@CHAXCH01.corp.arin.net><5B9E90747FA2974D91A54FCFA1B8AD1201313DB4AA@ENI-MAIL.eclipse-networks.com>
	<8DA1853CE466B041B104C1CAEE00B3748FC79286@CHAXCH01.corp.arin.net>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201313DB5AD@ENI-MAIL.eclipse-networks.com>

So you didn't fully answer my question.

In other words, are the needs based policies that are being enforced by Arin on organizations requesting a relatively small block - ALWAYS EQUALLY APPLIED to organizations requesting relatively larger sized blocks?  Note that I am not asking about unusual cases such as bankruptcy proceedings and such.


From: John Curran [mailto:jcurran at arin.net]
Sent: Tuesday, April 30, 2013 11:34 PM
To: Steven Ryerse
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user

On Apr 30, 2013, at 11:28 PM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>>
 wrote:


So then the logical question that I would ask is:  As a matter of current policy and practice does Arin first require an organization that requests say a /17 to request one first from a larger say /12 upstream before Arin will allocate the block, or maybe a /14 from an upstream /8, or /whatever from a larger upstream /whatever?  What if the larger upstream refuses the smaller organization the requested size block?  Does Arin require larger allocation holders to honor smaller allocation requests as a condition of their allocation?  What about an organization who runs BGP and needs an independent block but their upstream doesn't want to permanently give them what they consider a large portion of their own assigned block because it is somewhat difficult for them to get more resources from Arin?

And most importantly if this is current policy, does Arin actually enforce it every time for every organization no matter what their size or the size of their request?  If not then fair is fair and everyone should be treated equally albeit adjusted for their size and the size of their request.

Steven -

  There is an initial allocation policy (which ISPs must meet to receive their first
  allocation from ARIN), and then there is additional ISP allocation policy applies
  to all future requests.  This is regardless of the size of the request or size of the
  organization requesting.

FYI,
/John

John Curran
President and CEO
ARIN


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

From jcurran at arin.net  Wed May  1 06:14:04 2013
From: jcurran at arin.net (John Curran)
Date: Wed, 1 May 2013 10:14:04 +0000
Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201313DB5AD@ENI-MAIL.eclipse-networks.com>
References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com>
	<"B64177493F39B	A4A81233AA84B50049E9B8A9684"@PACDCEXMB12.cable.comcast.com>
	<"5B9E90747FA297
	4D91A54FCFA1B8AD1201313DA3E4"@ENI-MAIL.eclipse-networks.com>
	<"CAMApp345T9rGK Lo8Q8oZRdeo6NtTQA5RcWkGw0E4TrzoP6Y-UQ"@mail.gmail.com>
	<"5B9E90747FA2974D91A54
	FCFA1B8AD1201313DB2BF"@ENI-MAIL.eclipse-networks.com>
	<"8DA1853CE466B041B104C1 CAEE00B3748FC79128"@CHAXCH01.corp.arin.net>
	<5B9E90747FA2974D91A54FCFA1B8AD1201313DB4AA@ENI-MAIL.eclipse-networks.com>
	<8DA1853CE466B041B104C1CAEE00B3748FC79286@CHAXCH01.corp.arin.net>
	<5B9E90747FA2974D91A54FCFA1B8AD1201313DB5AD@ENI-MAIL.eclipse-networks.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC819C7@CHAXCH01.corp.arin.net>


On May 1, 2013, at 12:06 AM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>> wrote:

In other words, are the needs based policies that are being enforced by Arin on organizations requesting a relatively small block - ALWAYS EQUALLY APPLIED to organizations requesting relatively larger sized blocks?

Yes.  Per NRPM 4.2.4, an ISP requesting an additional block must have efficiently utilized
all previous allocations and at least 80% of their most recent allocation in order to receive
additional space.  It does not matter if the ISP is requesting an additional /20, /12, or any
other amount, the same criteria is applicable to all such requests.

FYI,
/John

John Curran
President and CEO
ARIN

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

From scottleibrand at gmail.com  Thu May  2 15:20:14 2013
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 2 May 2013 12:20:14 -0700
Subject: [arin-ppml] LIR/ISP and End-user definitions
Message-ID: <CAGkMwz4MO14h7yx_5ofQWmhfLiT0Oq-RE10KZP=12fKGw=9i+A@mail.gmail.com>

Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0


1. Policy Proposal Name: LIR/ISP and End-user definitions

2. Proposal Originator

a. name: Scott Leibrand

b. email: scottleibrand at gmail.com

c. telephone: 360-419-5185

d. organization: Limelight Networks

3. Date: May 2, 2013

4. Problem Statement:

At ARIN 31, the Policy Experience Report (slides at
https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdfor
https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx)
reported that, in ARIN staff's experience, the NRPM does not adequately
define ISP/LIR vs. end-user.  As currently defined, and interpreted
literally, many companies do not qualify as either LIRs or end-users.

I would propose that the primary difference between ISPs/LIRs vs.
end-users, for purposes of the NRPM, is whether an organization reassigns
address blocks to third parties.  If an organization maintains full control
of all of the equipment on its network, and doesn't need to make any
reassignments to other organizations, then it can qualify as an end-user.
 In particular, an end user organization can supply a full list of all the
IP addresses in use on its network, and know what devices are using those
addresses.

An ISP/LIR, on the other hand, should be defined by whether they delegate
that responsibility to another organization.  In that case, they need to
reassign the network space via SWIP/rwhois, which makes them an LIR.
 Additionally, there are likely some ISPs that do not (yet) need to
delegate any address blocks, but which assign address space to users
(rather than to their own equipment), which should also fall under the
definition of LIR/ISP.

5. Policy statement:

Update NRPM 2.4 and 2.6 to read:

2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)

The terms Internet Service Provider (ISP) and LIR are used interchangeably
in this document.  A Local Internet Registry (LIR) is an IR that assigns
address space to the users of the network services that it provides.
 Therefore, LIRs / ISPs are organizations that reassign addresses to end
users and/or reallocate addresses to other ISPs/LIRs.

2.6. End-user

An end-user is an organization receiving assignments of IP addresses
exclusively for use in its operational networks, and does not register any
reassignments of that space.

6. Comments:

a. Timetable for implementation: Immediate


END OF TEMPLATE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130502/8c11d2d2/attachment.htm>

From narten at us.ibm.com  Fri May  3 00:53:04 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 03 May 2013 00:53:04 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201305030453.r434r4Zm010576@rotala.raleigh.ibm.com>

Total of 38 messages in the last 7 days.
 
script run at: Fri May  3 00:53:04 EDT 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 13.16% |    5 | 30.11% |   167814 | sryerse at eclipse-networks.com
 15.79% |    6 | 14.16% |    78928 | scottleibrand at gmail.com
 13.16% |    5 | 10.66% |    59391 | owen at delong.com
  7.89% |    3 | 10.46% |    58283 | daniel_alexander at cable.comcast.com
 10.53% |    4 |  7.33% |    40880 | jcurran at arin.net
  5.26% |    2 | 10.41% |    58051 | billdarte at gmail.com
  7.89% |    3 |  3.72% |    20740 | info at arin.net
  5.26% |    2 |  3.00% |    16727 | droisman at softlayer.com
  5.26% |    2 |  2.32% |    12945 | bill at herrin.us
  2.63% |    1 |  1.87% |    10411 | stephen at sprunk.org
  2.63% |    1 |  1.48% |     8249 | rcarpen at network1.net
  2.63% |    1 |  1.25% |     6962 | alh-ietf at tndh.net
  2.63% |    1 |  1.10% |     6147 | gary.buhrmaster at gmail.com
  2.63% |    1 |  1.08% |     6002 | narten at us.ibm.com
  2.63% |    1 |  1.05% |     5859 | dogwallah at gmail.com
--------+------+--------+----------+------------------------
100.00% |   38 |100.00% |   557389 | Total



From bill at herrin.us  Fri May  3 13:17:06 2013
From: bill at herrin.us (William Herrin)
Date: Fri, 3 May 2013 13:17:06 -0400
Subject: [arin-ppml] LIR/ISP and End-user definitions
In-Reply-To: <CAGkMwz4MO14h7yx_5ofQWmhfLiT0Oq-RE10KZP=12fKGw=9i+A@mail.gmail.com>
References: <CAGkMwz4MO14h7yx_5ofQWmhfLiT0Oq-RE10KZP=12fKGw=9i+A@mail.gmail.com>
Message-ID: <CAP-guGVMfYXH+6B707pCpzRANOTUh0MU7eZOcuCCpTRS+xYgEw@mail.gmail.com>

On Thu, May 2, 2013 at 3:20 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> 2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)
>
> The terms Internet Service Provider (ISP) and LIR are used interchangeably
> in this document.  A Local Internet Registry (LIR) is an IR that assigns
> address space to the users of the network services that it provides.
> Therefore, LIRs / ISPs are organizations that reassign addresses to end
> users and/or reallocate addresses to other ISPs/LIRs.
>
> 2.6. End-user
>
> An end-user is an organization receiving assignments of IP addresses
> exclusively for use in its operational networks, and does not register any
> reassignments of that space.

Hi Scott,

To my read, these definitions offer little additional clarity versus
the existing ones in the NRPM. Consider something like:

2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)

A Local Internet Registry (LIR) is an organization, such as an
Internet Service Provider (ISP), who as a major function of the
organization or its network permanently or temporarily assigns address
space for use on equipment owned or operated by third parties. Any
ARIN registrant which is not an End User is a LIR.

The terms Internet Service Provider (ISP) and LIR are used
interchangeably in this document.

2.6. End-user

An end-user is an individual or organization receiving assignments of
IP addresses exclusively for use on equipment under the registrant's
direct control. No organization which primarily provides network
services for equipment owned or administered by a third party is an
end user.

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 narten at us.ibm.com  Fri May 10 00:53:03 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 10 May 2013 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201305100453.r4A4r4Zt021238@rotala.raleigh.ibm.com>

Total of 2 messages in the last 7 days.
 
script run at: Fri May 10 00:53:03 EDT 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    1 | 50.56% |     6965 | bill at herrin.us
 50.00% |    1 | 49.44% |     6811 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    2 |100.00% |    13776 | Total



From info at arin.net  Mon May 13 11:05:06 2013
From: info at arin.net (ARIN)
Date: Mon, 13 May 2013 11:05:06 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - April 2013
In-Reply-To: <517EBA8D.5070206@arin.net>
References: <517EBA8D.5070206@arin.net>
Message-ID: <51910122.9030504@arin.net>

> The AC abandoned ARIN-2013-3. Anyone dissatisfied with this decision may
> initiate a petition. The deadline to begin a petition will be five
> business days after the AC's draft meeting minutes are published.

The minutes from the ARIN Advisory Council's April 24 meeting have
been published:
https://www.arin.net/about_us/ac/ac2013_0424.html

The deadline to begin a petition is 17 May 2013.

For more information on starting and participating in petitions, see PDP
Petitions at: https://www.arin.net/policy/pdp_petitions.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)


On 4/29/13 2:23 PM, ARIN wrote:
> In accordance with the ARIN Policy Development Process the ARIN Advisory
> Council (AC) held a meeting on 24 April 2013 and made decisions about
> several draft policies.
>
> The AC moved the following draft policy to last call (it will be
> posted separately to last call):
>
> Recommended Draft Policy ARIN-2012-2: IPv6 Subsequent Allocations
> Utilization Requirement
>
> The following remain on the AC's docket:
>
> Recommended Draft Policy ARIN-2013-1: Section 8.4 Inter-RIR Transfers of
> ASNs
> Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy
>
> The AC abandoned the following:
>
> Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
>
> The AC provided the following statement:
> "Based on the community's input at ARIN 31 and on PPML the Advisory
> Council has abandoned ARIN-2013-3: Tiny IPv6 Allocations for ISPs.
> There was broad community consensus that /40 ISP allocations are
> technically undesirable, and that any desire for lower fees should be
> resolved within the fee structure itself, rather than by adapting policy
> to fit the current fee table."
>
> The AC abandoned ARIN-2013-3. Anyone dissatisfied with this decision may
> initiate a 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 narten at us.ibm.com  Fri May 17 00:53:02 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 17 May 2013 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201305170453.r4H4r3im007313@rotala.raleigh.ibm.com>

Total of 2 messages in the last 7 days.
 
script run at: Fri May 17 00:53:02 EDT 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 50.00% |    1 | 52.39% |     6718 | info at arin.net
 50.00% |    1 | 47.61% |     6105 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |    2 |100.00% |    12823 | Total



From info at arin.net  Fri May 17 12:53:08 2013
From: info at arin.net (ARIN)
Date: Fri, 17 May 2013 12:53:08 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - May 2013
Message-ID: <51966074.5040704@arin.net>

In accordance with the ARIN Policy Development Process, the ARIN 
Advisory Council (AC) held a meeting on 16 May 2013 and made decisions 
about draft policies and proposals.

The AC recommended the following to the ARIN Board for adoption:

   Recommended Draft Policy ARIN-2012-2: IPv6 Subsequent Allocations 
Utilization Requirement

The AC accepted the following Proposals as Draft Policies. They will be 
posted separately to the Public Policy Mailing List.

   ARIN-prop-187 RIR Principles
   ARIN-prop-188 LIR/ISP and End-user Definitions

The AC is continuing to work on the following:

   Recommended Draft Policy ARIN-2013-1: Section 8.4 Inter-RIR Transfers 
of ASNs
   Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy
   ARIN-prop-186 Section 8.2 Reorganizations

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

The AC asked for the following to be posted the list:

"The ARIN Advisory Council honors the memory of Robert Stratton.

The AC thanks Bob for many years of dedicated service to ARIN and the 
ARIN community.  Your financial leadership, good nature and good humor 
were an inspiration to us all and were vital in building ARIN into the 
organization that it is today.  We are saddened that you had to leave us 
and you are sorely missed.  You and your family will remain in our 
hearts and thoughts forever."

Regards,

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


From info at arin.net  Fri May 17 12:53:23 2013
From: info at arin.net (ARIN)
Date: Fri, 17 May 2013 12:53:23 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
Message-ID: <51966083.2010003@arin.net>

Draft Policy ARIN-2013-4
RIR Principles

On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-187 
RIR Principles" as a Draft Policy.

Draft Policy ARIN-2013-4 is below and can be found at:
https://www.arin.net/policy/proposals/2013_4.html

You are encouraged to discuss the merits and your concerns of Draft 
Policy 2013-4 on the Public Policy Mailing List. 2013-4 will also be on 
the agenda at the upcoming ARIN Public Policy Consultation at NANOG 58 
in New Orleans.

The AC will evaluate the discussion in order to assess the conformance 
of this draft policy with ARIN's Principles of Internet Number Resource 
Policy as stated in the PDP. Specifically, these principles are:

  * Enabling Fair and Impartial Number Resource Administration
  * Technically Sound
  * Supported by the Community

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

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

Regards,

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


## * ##


Draft Policy ARIN-2013-4
RIR Principles

Date: 17 May 2013

Problem Statement:

The original text in RFC 2050 both "describes the registry system for 
the distribution of globally unique Internet address space and registry 
operations" and provides "rules and guidelines [principles] governing 
the distribution of this address space."

The currently proposed update (RFC2050bis) "provides information about 
the current Internet Numbers Registry System used in the distribution of 
globally unique Internet Protocol (IP) address space and autonomous 
system (AS) numbers" and "provides information about the processes for 
further evolution of the Internet Numbers Registry System."

This means that the guiding principles of stewardship are not currently 
being carried forward into the new document. The goals of Conservation 
(efficient utilization based on need), Routability (hierarchical 
aggregation), and Registration (uniqueness) are as important, if not 
more so, now that the transition to IPv6 is upon us. This can be 
rectified by documenting these principles in RIR policy.

Policy Statement:

Section 0: Principles and Goals of the Internet Registry System

0.1. Efficient utilization based on need (Conservation)

Policies for managing Internet number resources must support 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. The registry should prevent 
stockpiling in order to maximize the conservation and efficient 
utilization of the Internet address space.

0.1.1. Documented Justified Need (Needs Based)

Assignment of Internet number resources is based on documented 
operational need. Utilization rate of address space will be a key factor 
in number resource assignment. To this end, registrants should have 
documented justified need available for each assignment. Organizations 
will be assigned resources based on immediate utilization plus expected 
utilization.

In order to promote increased usage of Internet number resources, 
resource holders will be required to provide an accounting of resources 
currently held demonstrating efficient utilization. Internet number 
resources are valid as long as the criteria continues to be met. The 
transfer of Internet number resources from one party to another must be 
approved by the regional registries. The party trying to obtain the 
resources must meet the same criteria as if they were requesting 
resources directly from the IR.

All Internet number resource requests are subject to audit and 
verification by any means deemed appropriate by the regional registry.

0.2. Hierarchical aggregation (Routability)

Policies for managing Internet number resources must support 
distribution of globally unique Internet addresses in a hierarchical 
manner, permitting the routing scalability of the addresses. This 
scalability is necessary to ensure proper operation of Internet routing, 
although it must be stressed that routability is in no way guaranteed 
with the allocation or assignment of IPv4 addresses.

0.3. Uniqueness (Registration)

Provision of a public registry documenting Internet number resource 
allocation, reallocation, assignment, and reassignment is necessary to:

a) ensure uniqueness and to to provide operational staff with 
information on who is using the number resource b) to provide a contact 
in case of operational/security problems (e.g. Law Enforcement) c) to 
ensure that a provider has exhausted a majority of its current CIDR 
allocation, thereby justifying an additional allocation d) to assist in 
IP allocation studies.

It is imperative that reassignment information be submitted in a prompt 
and efficient manner to facilitate database maintenance and ensure 
database integrity.

0.4. Stewardship

It should be noted that efficient utilization and hierarchical 
aggregation are often conflicting goals. All the above goals may 
sometimes be in conflict with the interests of individual end-users or 
Internet Service Providers. Care must be taken to ensure balance with 
these conflicting goals given the resource availability, relative size 
of the resource, and number resource specific technical dynamics, for 
each type of number resource. For example, efficient utilization becomes 
a more prominent issue than aggregation as the IPv4 free pool depletes 
and IPv4 resource availability in any transfer market decreases. 
Conversely, because the IPv6 number space is orders of magnitude larger 
than the IPv4 number space, the scale tips away from efficient 
utilization towards hierarchical aggregation for IPv6 number resources.

Comments:

a. Timetable for implementation: immediately

b. I believe that it would be beneficial for IANA to adopt these 
principles as well, and encourage the community to consider a global 
policy proposal.


From info at arin.net  Fri May 17 12:53:35 2013
From: info at arin.net (ARIN)
Date: Fri, 17 May 2013 12:53:35 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-5: LIR/ISP and End-user
	Definitions
Message-ID: <5196608F.1050006@arin.net>

Draft Policy ARIN-2013-5
LIR/ISP and End-user Definitions

On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-188 
LIR/ISP and End-user Definitions" as a Draft Policy.

Draft Policy ARIN-2013-5 is below and can be found at:
https://www.arin.net/policy/proposals/2013_5.html

You are encouraged to discuss the merits and your concerns of Draft 
Policy 2013-5 on the Public Policy Mailing List. 2013-5 will also be on 
the agenda at the upcoming ARIN Public Policy Consultation at NANOG 58 
in New Orleans.

The AC will evaluate the discussion in order to assess the conformance 
of this draft policy with ARIN's Principles of Internet Number Resource 
Policy as stated in the PDP. Specifically, these principles are:

  * Enabling Fair and Impartial Number Resource Administration
  * Technically Sound
  * Supported by the Community

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

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

Regards,

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


## * ##


Draft Policy ARIN-2013-5
LIR/ISP and End-user Definitions

Date: 17 May 2013

Problem Statement:

At ARIN 31, the Policy Experience Report (slides at 
https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf 
or 
https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) 
reported that, in ARIN staff's experience, the NRPM does not adequately 
define ISP/LIR vs. end-user. As currently defined, and interpreted 
literally, many companies do not qualify as either LIRs or end-users. I 
would propose that the primary difference between ISPs/LIRs vs. 
end-users, for purposes of the NRPM, is whether an organization 
reassigns address blocks to third parties. If an organization maintains 
full control of all of the equipment on its network, and doesn't need to 
make any reassignments to other organizations, then it can qualify as an 
end-user. In particular, an end user organization can supply a full list 
of all the IP addresses in use on its network, and know what devices are 
using those addresses.

An ISP/LIR, on the other hand, should be defined by whether they 
delegate that responsibility to another organization. In that case, they 
need to reassign the network space via SWIP/rwhois, which makes them an 
LIR. Additionally, there are likely some ISPs that do not (yet) need to 
delegate any address blocks, but which assign address space to users 
(rather than to their own equipment), which should also fall under the 
definition of LIR/ISP.

Policy statement:

Update NRPM 2.4 and 2.6 to read:

2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP) The 
terms Internet Service Provider (ISP) and LIR are used interchangeably 
in this document. A Local Internet Registry (LIR) is an IR that assigns 
address space to the users of the network services that it provides. 
Therefore, LIRs / ISPs are organizations that reassign addresses to end 
users and/or reallocate addresses to other ISPs/LIRs.

2.6. End-user An end-user is an organization receiving assignments of IP 
addresses exclusively for use in its operational networks, and does not 
register any reassignments of that space.

Timetable for implementation: Immediate


From cgrundemann at gmail.com  Fri May 17 16:08:54 2013
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Fri, 17 May 2013 21:08:54 +0100
Subject: [arin-ppml] Draft Policy ARIN-2013-5: LIR/ISP and End-user
	Definitions
In-Reply-To: <5196608F.1050006@arin.net>
References: <5196608F.1050006@arin.net>
Message-ID: <CAC1-dt=Z6Otsy1dDoBjqLxk6uO65QKO6px+q_-wC5FqP75evXQ@mail.gmail.com>

On Fri, May 17, 2013 at 5:53 PM, ARIN <info at arin.net> wrote:
[...]
> Policy statement:
>
> Update NRPM 2.4 and 2.6 to read:
>
> 2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP) The
> terms Internet Service Provider (ISP) and LIR are used interchangeably in
> this document. A Local Internet Registry (LIR) is an IR that assigns address
> space to the users of the network services that it provides. Therefore, LIRs
> / ISPs are organizations that reassign addresses to end users and/or
> reallocate addresses to other ISPs/LIRs.

I think this is a bit redundant ('a LIR is an IR') and could be made
more similar to the end-user definition thus:

"2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)
The terms Internet Service Provider (ISP) and LIR are used
interchangeably in this document. An ISP is a LIR that receives
allocations of IP addresses to provide network services to its users.
An LIR / ISP reassigns addresses to end users and/or reallocates
addresses to other ISPs / LIRs."

I'm also curious as to the community sentiment regarding using these
two terms interchangeably. It seems that it may be more clear to go
through the NRPM and make change to one or the other in all instances.

Would using a single term provide better clarity can continuity?

Which term would you prefer to use if that were the case (LIR or ISP)?


> 2.6. End-user An end-user is an organization receiving assignments of IP
> addresses exclusively for use in its operational networks, and does not
> register any reassignments of that space.

It's not the registration of the reassignment that makes an LIR/ISP
different from an end-user, but the reassignment itself. I think the
following text makes this more clear:

"2.6. End-user An end-user is an organization that receives
assignments of IP addresses exclusively for use in its operational
networks. An end-user does not reassign or reallocate addresses to any
other organization."

Cheers,
~Chris


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



--
@ChrisGrundemann
http://chrisgrundemann.com


From jschiller at google.com  Fri May 17 16:57:39 2013
From: jschiller at google.com (Jason Schiller)
Date: Fri, 17 May 2013 16:57:39 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-5: LIR/ISP and End-user
	Definitions
In-Reply-To: <CAC1-dt=Z6Otsy1dDoBjqLxk6uO65QKO6px+q_-wC5FqP75evXQ@mail.gmail.com>
References: <5196608F.1050006@arin.net>
	<CAC1-dt=Z6Otsy1dDoBjqLxk6uO65QKO6px+q_-wC5FqP75evXQ@mail.gmail.com>
Message-ID: <CAC4yj2XEk5Z7E2ry38cQNbvtu4HfLAkiwOMbnJkH_+Ft8a_pPQ@mail.gmail.com>

I know people won't like this, but if you are going to pick one term
ISP/LIR, I'd recommend LIR.

LIR shows up in the other regions, and also global polices.

For clarity I think the best thing to do is use "ISP/LIR" as the single
term everywhere.

I think Chris Grundeman's simplification of ISP/LIR is fine, and his
clarification of end-user is good.

__Jason



On Fri, May 17, 2013 at 4:08 PM, Chris Grundemann <cgrundemann at gmail.com>wrote:

> On Fri, May 17, 2013 at 5:53 PM, ARIN <info at arin.net> wrote:
> [...]
> > Policy statement:
> >
> > Update NRPM 2.4 and 2.6 to read:
> >
> > 2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP) The
> > terms Internet Service Provider (ISP) and LIR are used interchangeably in
> > this document. A Local Internet Registry (LIR) is an IR that assigns
> address
> > space to the users of the network services that it provides. Therefore,
> LIRs
> > / ISPs are organizations that reassign addresses to end users and/or
> > reallocate addresses to other ISPs/LIRs.
>
> I think this is a bit redundant ('a LIR is an IR') and could be made
> more similar to the end-user definition thus:
>
> "2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)
> The terms Internet Service Provider (ISP) and LIR are used
> interchangeably in this document. An ISP is a LIR that receives
> allocations of IP addresses to provide network services to its users.
> An LIR / ISP reassigns addresses to end users and/or reallocates
> addresses to other ISPs / LIRs."
>
> I'm also curious as to the community sentiment regarding using these
> two terms interchangeably. It seems that it may be more clear to go
> through the NRPM and make change to one or the other in all instances.
>
> Would using a single term provide better clarity can continuity?
>
> Which term would you prefer to use if that were the case (LIR or ISP)?
>
>
> > 2.6. End-user An end-user is an organization receiving assignments of IP
> > addresses exclusively for use in its operational networks, and does not
> > register any reassignments of that space.
>
> It's not the registration of the reassignment that makes an LIR/ISP
> different from an end-user, but the reassignment itself. I think the
> following text makes this more clear:
>
> "2.6. End-user An end-user is an organization that receives
> assignments of IP addresses exclusively for use in its operational
> networks. An end-user does not reassign or reallocate addresses to any
> other organization."
>
> Cheers,
> ~Chris
>
>
> > 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.
>
>
>
> --
> @ChrisGrundemann
> http://chrisgrundemann.com
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130517/f96db271/attachment.htm>

From dlundy at PACIFIC.EDU  Fri May 17 17:06:52 2013
From: dlundy at PACIFIC.EDU (David Lundy)
Date: Fri, 17 May 2013 21:06:52 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 95, Issue 7
In-Reply-To: <mailman.763.1368824281.15333.arin-ppml@arin.net>
References: <mailman.763.1368824281.15333.arin-ppml@arin.net>
Message-ID: <46DF490BF96BA7449B7B0674DA91A3365A4D2298@exmb1.stk.pacific.edu>



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of arin-ppml-request at arin.net
Sent: Friday, May 17, 2013 1:58 PM
To: arin-ppml at arin.net
Subject: ARIN-PPML Digest, Vol 95, Issue 7

Send ARIN-PPML mailing list submissions to
	arin-ppml at arin.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
	arin-ppml-request at arin.net

You can reach the person managing the list at
	arin-ppml-owner at arin.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."


Today's Topics:

   1. Advisory Council Meeting Results - May 2013 (ARIN)
   2. Draft Policy ARIN-2013-4: RIR Principles (ARIN)
   3. Draft Policy ARIN-2013-5: LIR/ISP and End-user	Definitions (ARIN)
   4. Re: Draft Policy ARIN-2013-5: LIR/ISP and End-user
      Definitions (Chris Grundemann)
   5. Re: Draft Policy ARIN-2013-5: LIR/ISP and End-user
      Definitions (Jason Schiller)


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

Message: 1
Date: Fri, 17 May 2013 12:53:08 -0400
From: ARIN <info at arin.net>
To: arin-ppml at arin.net
Subject: [arin-ppml] Advisory Council Meeting Results - May 2013
Message-ID: <51966074.5040704 at arin.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

In accordance with the ARIN Policy Development Process, the ARIN 
Advisory Council (AC) held a meeting on 16 May 2013 and made decisions 
about draft policies and proposals.

The AC recommended the following to the ARIN Board for adoption:

   Recommended Draft Policy ARIN-2012-2: IPv6 Subsequent Allocations 
Utilization Requirement

The AC accepted the following Proposals as Draft Policies. They will be 
posted separately to the Public Policy Mailing List.

   ARIN-prop-187 RIR Principles
   ARIN-prop-188 LIR/ISP and End-user Definitions

The AC is continuing to work on the following:

   Recommended Draft Policy ARIN-2013-1: Section 8.4 Inter-RIR Transfers 
of ASNs
   Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy
   ARIN-prop-186 Section 8.2 Reorganizations

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

The AC asked for the following to be posted the list:

"The ARIN Advisory Council honors the memory of Robert Stratton.

The AC thanks Bob for many years of dedicated service to ARIN and the 
ARIN community.  Your financial leadership, good nature and good humor 
were an inspiration to us all and were vital in building ARIN into the 
organization that it is today.  We are saddened that you had to leave us 
and you are sorely missed.  You and your family will remain in our 
hearts and thoughts forever."

Regards,

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


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

Message: 2
Date: Fri, 17 May 2013 12:53:23 -0400
From: ARIN <info at arin.net>
To: arin-ppml at arin.net
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
Message-ID: <51966083.2010003 at arin.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Draft Policy ARIN-2013-4
RIR Principles

On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-187 
RIR Principles" as a Draft Policy.

Draft Policy ARIN-2013-4 is below and can be found at:
https://www.arin.net/policy/proposals/2013_4.html

You are encouraged to discuss the merits and your concerns of Draft 
Policy 2013-4 on the Public Policy Mailing List. 2013-4 will also be on 
the agenda at the upcoming ARIN Public Policy Consultation at NANOG 58 
in New Orleans.

The AC will evaluate the discussion in order to assess the conformance 
of this draft policy with ARIN's Principles of Internet Number Resource 
Policy as stated in the PDP. Specifically, these principles are:

  * Enabling Fair and Impartial Number Resource Administration
  * Technically Sound
  * Supported by the Community

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

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

Regards,

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


## * ##


Draft Policy ARIN-2013-4
RIR Principles

Date: 17 May 2013

Problem Statement:

The original text in RFC 2050 both "describes the registry system for 
the distribution of globally unique Internet address space and registry 
operations" and provides "rules and guidelines [principles] governing 
the distribution of this address space."

The currently proposed update (RFC2050bis) "provides information about 
the current Internet Numbers Registry System used in the distribution of 
globally unique Internet Protocol (IP) address space and autonomous 
system (AS) numbers" and "provides information about the processes for 
further evolution of the Internet Numbers Registry System."

This means that the guiding principles of stewardship are not currently 
being carried forward into the new document. The goals of Conservation 
(efficient utilization based on need), Routability (hierarchical 
aggregation), and Registration (uniqueness) are as important, if not 
more so, now that the transition to IPv6 is upon us. This can be 
rectified by documenting these principles in RIR policy.

Policy Statement:

Section 0: Principles and Goals of the Internet Registry System

0.1. Efficient utilization based on need (Conservation)

Policies for managing Internet number resources must support 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. The registry should prevent 
stockpiling in order to maximize the conservation and efficient 
utilization of the Internet address space.

0.1.1. Documented Justified Need (Needs Based)

Assignment of Internet number resources is based on documented 
operational need. Utilization rate of address space will be a key factor 
in number resource assignment. To this end, registrants should have 
documented justified need available for each assignment. Organizations 
will be assigned resources based on immediate utilization plus expected 
utilization.

In order to promote increased usage of Internet number resources, 
resource holders will be required to provide an accounting of resources 
currently held demonstrating efficient utilization. Internet number 
resources are valid as long as the criteria continues to be met. The 
transfer of Internet number resources from one party to another must be 
approved by the regional registries. The party trying to obtain the 
resources must meet the same criteria as if they were requesting 
resources directly from the IR.

All Internet number resource requests are subject to audit and 
verification by any means deemed appropriate by the regional registry.

0.2. Hierarchical aggregation (Routability)

Policies for managing Internet number resources must support 
distribution of globally unique Internet addresses in a hierarchical 
manner, permitting the routing scalability of the addresses. This 
scalability is necessary to ensure proper operation of Internet routing, 
although it must be stressed that routability is in no way guaranteed 
with the allocation or assignment of IPv4 addresses.

0.3. Uniqueness (Registration)

Provision of a public registry documenting Internet number resource 
allocation, reallocation, assignment, and reassignment is necessary to:

a) ensure uniqueness and to to provide operational staff with 
information on who is using the number resource b) to provide a contact 
in case of operational/security problems (e.g. Law Enforcement) c) to 
ensure that a provider has exhausted a majority of its current CIDR 
allocation, thereby justifying an additional allocation d) to assist in 
IP allocation studies.

It is imperative that reassignment information be submitted in a prompt 
and efficient manner to facilitate database maintenance and ensure 
database integrity.

0.4. Stewardship

It should be noted that efficient utilization and hierarchical 
aggregation are often conflicting goals. All the above goals may 
sometimes be in conflict with the interests of individual end-users or 
Internet Service Providers. Care must be taken to ensure balance with 
these conflicting goals given the resource availability, relative size 
of the resource, and number resource specific technical dynamics, for 
each type of number resource. For example, efficient utilization becomes 
a more prominent issue than aggregation as the IPv4 free pool depletes 
and IPv4 resource availability in any transfer market decreases. 
Conversely, because the IPv6 number space is orders of magnitude larger 
than the IPv4 number space, the scale tips away from efficient 
utilization towards hierarchical aggregation for IPv6 number resources.

Comments:

a. Timetable for implementation: immediately

b. I believe that it would be beneficial for IANA to adopt these 
principles as well, and encourage the community to consider a global 
policy proposal.


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

Message: 3
Date: Fri, 17 May 2013 12:53:35 -0400
From: ARIN <info at arin.net>
To: arin-ppml at arin.net
Subject: [arin-ppml] Draft Policy ARIN-2013-5: LIR/ISP and End-user
	Definitions
Message-ID: <5196608F.1050006 at arin.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Draft Policy ARIN-2013-5
LIR/ISP and End-user Definitions

On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-188 
LIR/ISP and End-user Definitions" as a Draft Policy.

Draft Policy ARIN-2013-5 is below and can be found at:
https://www.arin.net/policy/proposals/2013_5.html

You are encouraged to discuss the merits and your concerns of Draft 
Policy 2013-5 on the Public Policy Mailing List. 2013-5 will also be on 
the agenda at the upcoming ARIN Public Policy Consultation at NANOG 58 
in New Orleans.

The AC will evaluate the discussion in order to assess the conformance 
of this draft policy with ARIN's Principles of Internet Number Resource 
Policy as stated in the PDP. Specifically, these principles are:

  * Enabling Fair and Impartial Number Resource Administration
  * Technically Sound
  * Supported by the Community

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

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

Regards,

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


## * ##


Draft Policy ARIN-2013-5
LIR/ISP and End-user Definitions

Date: 17 May 2013

Problem Statement:

At ARIN 31, the Policy Experience Report (slides at 
https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf 
or 
https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) 
reported that, in ARIN staff's experience, the NRPM does not adequately 
define ISP/LIR vs. end-user. As currently defined, and interpreted 
literally, many companies do not qualify as either LIRs or end-users. I 
would propose that the primary difference between ISPs/LIRs vs. 
end-users, for purposes of the NRPM, is whether an organization 
reassigns address blocks to third parties. If an organization maintains 
full control of all of the equipment on its network, and doesn't need to 
make any reassignments to other organizations, then it can qualify as an 
end-user. In particular, an end user organization can supply a full list 
of all the IP addresses in use on its network, and know what devices are 
using those addresses.

An ISP/LIR, on the other hand, should be defined by whether they 
delegate that responsibility to another organization. In that case, they 
need to reassign the network space via SWIP/rwhois, which makes them an 
LIR. Additionally, there are likely some ISPs that do not (yet) need to 
delegate any address blocks, but which assign address space to users 
(rather than to their own equipment), which should also fall under the 
definition of LIR/ISP.

Policy statement:

Update NRPM 2.4 and 2.6 to read:

2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP) The 
terms Internet Service Provider (ISP) and LIR are used interchangeably 
in this document. A Local Internet Registry (LIR) is an IR that assigns 
address space to the users of the network services that it provides. 
Therefore, LIRs / ISPs are organizations that reassign addresses to end 
users and/or reallocate addresses to other ISPs/LIRs.

2.6. End-user An end-user is an organization receiving assignments of IP 
addresses exclusively for use in its operational networks, and does not 
register any reassignments of that space.

Timetable for implementation: Immediate


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

Message: 4
Date: Fri, 17 May 2013 21:08:54 +0100
From: Chris Grundemann <cgrundemann at gmail.com>
To: ARIN <info at arin.net>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-5: LIR/ISP and
	End-user	Definitions
Message-ID:
	<CAC1-dt=Z6Otsy1dDoBjqLxk6uO65QKO6px+q_-wC5FqP75evXQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 17, 2013 at 5:53 PM, ARIN <info at arin.net> wrote:
[...]
> Policy statement:
>
> Update NRPM 2.4 and 2.6 to read:
>
> 2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP) The
> terms Internet Service Provider (ISP) and LIR are used interchangeably in
> this document. A Local Internet Registry (LIR) is an IR that assigns address
> space to the users of the network services that it provides. Therefore, LIRs
> / ISPs are organizations that reassign addresses to end users and/or
> reallocate addresses to other ISPs/LIRs.

I think this is a bit redundant ('a LIR is an IR') and could be made
more similar to the end-user definition thus:

"2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)
The terms Internet Service Provider (ISP) and LIR are used
interchangeably in this document. An ISP is a LIR that receives
allocations of IP addresses to provide network services to its users.
An LIR / ISP reassigns addresses to end users and/or reallocates
addresses to other ISPs / LIRs."

I'm also curious as to the community sentiment regarding using these
two terms interchangeably. It seems that it may be more clear to go
through the NRPM and make change to one or the other in all instances.

Would using a single term provide better clarity can continuity?

Which term would you prefer to use if that were the case (LIR or ISP)?


> 2.6. End-user An end-user is an organization receiving assignments of IP
> addresses exclusively for use in its operational networks, and does not
> register any reassignments of that space.

It's not the registration of the reassignment that makes an LIR/ISP
different from an end-user, but the reassignment itself. I think the
following text makes this more clear:

"2.6. End-user An end-user is an organization that receives
assignments of IP addresses exclusively for use in its operational
networks. An end-user does not reassign or reallocate addresses to any
other organization."

Cheers,
~Chris


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



--
@ChrisGrundemann
http://chrisgrundemann.com


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

Message: 5
Date: Fri, 17 May 2013 16:57:39 -0400
From: Jason Schiller <jschiller at google.com>
To: Chris Grundemann <cgrundemann at gmail.com>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-5: LIR/ISP and
	End-user	Definitions
Message-ID:
	<CAC4yj2XEk5Z7E2ry38cQNbvtu4HfLAkiwOMbnJkH_+Ft8a_pPQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I know people won't like this, but if you are going to pick one term
ISP/LIR, I'd recommend LIR.

LIR shows up in the other regions, and also global polices.

For clarity I think the best thing to do is use "ISP/LIR" as the single
term everywhere.

I think Chris Grundeman's simplification of ISP/LIR is fine, and his
clarification of end-user is good.

__Jason



On Fri, May 17, 2013 at 4:08 PM, Chris Grundemann <cgrundemann at gmail.com>wrote:

> On Fri, May 17, 2013 at 5:53 PM, ARIN <info at arin.net> wrote:
> [...]
> > Policy statement:
> >
> > Update NRPM 2.4 and 2.6 to read:
> >
> > 2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP) The
> > terms Internet Service Provider (ISP) and LIR are used interchangeably in
> > this document. A Local Internet Registry (LIR) is an IR that assigns
> address
> > space to the users of the network services that it provides. Therefore,
> LIRs
> > / ISPs are organizations that reassign addresses to end users and/or
> > reallocate addresses to other ISPs/LIRs.
>
> I think this is a bit redundant ('a LIR is an IR') and could be made
> more similar to the end-user definition thus:
>
> "2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)
> The terms Internet Service Provider (ISP) and LIR are used
> interchangeably in this document. An ISP is a LIR that receives
> allocations of IP addresses to provide network services to its users.
> An LIR / ISP reassigns addresses to end users and/or reallocates
> addresses to other ISPs / LIRs."
>
> I'm also curious as to the community sentiment regarding using these
> two terms interchangeably. It seems that it may be more clear to go
> through the NRPM and make change to one or the other in all instances.
>
> Would using a single term provide better clarity can continuity?
>
> Which term would you prefer to use if that were the case (LIR or ISP)?
>
>
> > 2.6. End-user An end-user is an organization receiving assignments of IP
> > addresses exclusively for use in its operational networks, and does not
> > register any reassignments of that space.
>
> It's not the registration of the reassignment that makes an LIR/ISP
> different from an end-user, but the reassignment itself. I think the
> following text makes this more clear:
>
> "2.6. End-user An end-user is an organization that receives
> assignments of IP addresses exclusively for use in its operational
> networks. An end-user does not reassign or reallocate addresses to any
> other organization."
>
> Cheers,
> ~Chris
>
>
> > 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.
>
>
>
> --
> @ChrisGrundemann
> http://chrisgrundemann.com
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20130517/f96db271/attachment.html>

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

_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net
http://lists.arin.net/mailman/listinfo/arin-ppml

End of ARIN-PPML Digest, Vol 95, Issue 7
****************************************



From droisman at softlayer.com  Fri May 17 17:07:31 2013
From: droisman at softlayer.com (Dani Roisman)
Date: Fri, 17 May 2013 21:07:31 +0000
Subject: [arin-ppml] ARIN-PPML Digest, Vol 95, Issue 7
In-Reply-To: <mailman.763.1368824281.15333.arin-ppml@arin.net>
References: <mailman.763.1368824281.15333.arin-ppml@arin.net>
Message-ID: <C40B18ECB19B374EBB7B033835339F1D7A3813AB@SM-DAG156.softlayer.local>

I agree with Jason - standardize on one term.  My vote goes towards a global replacement of "ISP" in ARIN policy documents with the term "LIR" in order to match the language used by the other 4 RIRs.  I would then support an brief statement early in the NRPM which explains that "The term LIR has replaced the term ISP formerly used in ARIN policy documents in order to simplify the global understanding of RIR policy documents.  The definition of LIR exactly matches the previous definition of ISP for the purpose of the ARIN NRPM."  (well, something like that, you get the point).

----
Dani Roisman
VP, Network Operations
droisman at softlayer.com
(281) 714-3714 direct 
(818) 481-5581 cell

http://www.softlayer.com


| ------------------------------
| 
| Date: Fri, 17 May 2013 16:57:39 -0400
| From: Jason Schiller <jschiller at google.com>
| To: Chris Grundemann <cgrundemann at gmail.com>
| Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
| Subject: Re: [arin-ppml] Draft Policy ARIN-2013-5: LIR/ISP and
| 	End-user	Definitions
| Message-ID:
| 	<CAC4yj2XEk5Z7E2ry38cQNbvtu4HfLAkiwOMbnJkH_+Ft8a_pPQ at ma
| il.gmail.com>
| Content-Type: text/plain; charset="iso-8859-1"
| 
| I know people won't like this, but if you are going to pick one term
| ISP/LIR, I'd recommend LIR.
| 
| LIR shows up in the other regions, and also global polices.
| 
| For clarity I think the best thing to do is use "ISP/LIR" as the single
| term everywhere.
| 
| I think Chris Grundeman's simplification of ISP/LIR is fine, and his
| clarification of end-user is good.
| 
| __Jason
| 
| 
| 
| On Fri, May 17, 2013 at 4:08 PM, Chris Grundemann
| <cgrundemann at gmail.com>wrote:
| 
| > On Fri, May 17, 2013 at 5:53 PM, ARIN <info at arin.net> wrote:
| > [...]
| > > Policy statement:
| > >
| > > Update NRPM 2.4 and 2.6 to read:
| > >
| > > 2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP) The
| > > terms Internet Service Provider (ISP) and LIR are used interchangeably in
| > > this document. A Local Internet Registry (LIR) is an IR that assigns
| > address
| > > space to the users of the network services that it provides. Therefore,
| > LIRs
| > > / ISPs are organizations that reassign addresses to end users and/or
| > > reallocate addresses to other ISPs/LIRs.
| >
| > I think this is a bit redundant ('a LIR is an IR') and could be made
| > more similar to the end-user definition thus:
| >
| > "2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)
| > The terms Internet Service Provider (ISP) and LIR are used
| > interchangeably in this document. An ISP is a LIR that receives
| > allocations of IP addresses to provide network services to its users.
| > An LIR / ISP reassigns addresses to end users and/or reallocates
| > addresses to other ISPs / LIRs."
| >
| > I'm also curious as to the community sentiment regarding using these
| > two terms interchangeably. It seems that it may be more clear to go
| > through the NRPM and make change to one or the other in all instances.
| >
| > Would using a single term provide better clarity can continuity?
| >
| > Which term would you prefer to use if that were the case (LIR or ISP)?
| >
| >
| > > 2.6. End-user An end-user is an organization receiving assignments of IP
| > > addresses exclusively for use in its operational networks, and does not
| > > register any reassignments of that space.
| >
| > It's not the registration of the reassignment that makes an LIR/ISP
| > different from an end-user, but the reassignment itself. I think the
| > following text makes this more clear:
| >
| > "2.6. End-user An end-user is an organization that receives
| > assignments of IP addresses exclusively for use in its operational
| > networks. An end-user does not reassign or reallocate addresses to any
| > other organization."
| >
| > Cheers,
| > ~Chris
| >
| >
| > > Timetable for implementation: Immediate
| > > _______________________________________________


From dogwallah at gmail.com  Fri May 17 17:53:55 2013
From: dogwallah at gmail.com (McTim)
Date: Fri, 17 May 2013 17:53:55 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-5: LIR/ISP and End-user
	Definitions
In-Reply-To: <CAC4yj2XEk5Z7E2ry38cQNbvtu4HfLAkiwOMbnJkH_+Ft8a_pPQ@mail.gmail.com>
References: <5196608F.1050006@arin.net>
	<CAC1-dt=Z6Otsy1dDoBjqLxk6uO65QKO6px+q_-wC5FqP75evXQ@mail.gmail.com>
	<CAC4yj2XEk5Z7E2ry38cQNbvtu4HfLAkiwOMbnJkH_+Ft8a_pPQ@mail.gmail.com>
Message-ID: <CACAaNxj0OZN-XuGJRL7tc5mAL46Y7+MDYFd0ekUuBt8C8Y+gPA@mail.gmail.com>

On Fri, May 17, 2013 at 4:57 PM, Jason Schiller <jschiller at google.com> wrote:
> I know people won't like this, but if you are going to pick one term
> ISP/LIR, I'd recommend LIR.

+1


-- 
Cheers,

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


From Daniel_Alexander at Cable.Comcast.com  Mon May 20 16:43:06 2013
From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel)
Date: Mon, 20 May 2013 20:43:06 +0000
Subject: [arin-ppml] Draft Policy ARIN-2013-5: LIR/ISP and End-user
 Definitions
In-Reply-To: <CAC4yj2XEk5Z7E2ry38cQNbvtu4HfLAkiwOMbnJkH_+Ft8a_pPQ@mail.gmail.com>
Message-ID: <B64177493F39BA4A81233AA84B50049E9B91CF64@PACDCEXMB12.cable.comcast.com>

I like this.

-Dan

From: Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>>
Date: Fri, 17 May 2013 16:57:39 -0400
To: Chris Grundemann <cgrundemann at gmail.com<mailto:cgrundemann at gmail.com>>
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] Draft Policy ARIN-2013-5: LIR/ISP and End-user Definitions

I know people won't like this, but if you are going to pick one term ISP/LIR, I'd recommend LIR.

LIR shows up in the other regions, and also global polices.

For clarity I think the best thing to do is use "ISP/LIR" as the single term everywhere.

I think Chris Grundeman's simplification of ISP/LIR is fine, and his clarification of end-user is good.

__Jason



On Fri, May 17, 2013 at 4:08 PM, Chris Grundemann <cgrundemann at gmail.com<mailto:cgrundemann at gmail.com>> wrote:
On Fri, May 17, 2013 at 5:53 PM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:
[...]
> Policy statement:
>
> Update NRPM 2.4 and 2.6 to read:
>
> 2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP) The
> terms Internet Service Provider (ISP) and LIR are used interchangeably in
> this document. A Local Internet Registry (LIR) is an IR that assigns address
> space to the users of the network services that it provides. Therefore, LIRs
> / ISPs are organizations that reassign addresses to end users and/or
> reallocate addresses to other ISPs/LIRs.

I think this is a bit redundant ('a LIR is an IR') and could be made
more similar to the end-user definition thus:

"2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)
The terms Internet Service Provider (ISP) and LIR are used
interchangeably in this document. An ISP is a LIR that receives
allocations of IP addresses to provide network services to its users.
An LIR / ISP reassigns addresses to end users and/or reallocates
addresses to other ISPs / LIRs."

I'm also curious as to the community sentiment regarding using these
two terms interchangeably. It seems that it may be more clear to go
through the NRPM and make change to one or the other in all instances.

Would using a single term provide better clarity can continuity?

Which term would you prefer to use if that were the case (LIR or ISP)?


> 2.6. End-user An end-user is an organization receiving assignments of IP
> addresses exclusively for use in its operational networks, and does not
> register any reassignments of that space.

It's not the registration of the reassignment that makes an LIR/ISP
different from an end-user, but the reassignment itself. I think the
following text makes this more clear:

"2.6. End-user An end-user is an organization that receives
assignments of IP addresses exclusively for use in its operational
networks. An end-user does not reassign or reallocate addresses to any
other organization."

Cheers,
~Chris


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



--
@ChrisGrundemann
http://chrisgrundemann.com
_______________________________________________
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.



--
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com<mailto:jschiller at google.com>|571-266-0006

_______________________________________________ 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130520/202ce14a/attachment.htm>

From narten at us.ibm.com  Fri May 24 00:53:03 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 24 May 2013 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201305240453.r4O4r3oc012443@rotala.raleigh.ibm.com>

Total of 10 messages in the last 7 days.
 
script run at: Fri May 24 00:53:03 EDT 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 30.00% |    3 | 21.36% |    23395 | info at arin.net
 10.00% |    1 | 23.55% |    25792 | dlundy at pacific.edu
 10.00% |    1 | 15.61% |    17099 | daniel_alexander at cable.comcast.com
 10.00% |    1 | 13.97% |    15303 | jschiller at google.com
 10.00% |    1 |  8.10% |     8872 | droisman at softlayer.com
 10.00% |    1 |  6.78% |     7421 | cgrundemann at gmail.com
 10.00% |    1 |  5.59% |     6123 | narten at us.ibm.com
 10.00% |    1 |  5.03% |     5504 | dogwallah at gmail.com
--------+------+--------+----------+------------------------
100.00% |   10 |100.00% |   109509 | Total



From info at arin.net  Tue May 28 11:54:56 2013
From: info at arin.net (ARIN)
Date: Tue, 28 May 2013 11:54:56 -0400
Subject: [arin-ppml] ARIN-prop-186 Section 8.2 Reorganizations - Notice
 of intent to make editorial update
In-Reply-To: <517EBAD0.6030504@arin.net>
References: <517EBAD0.6030504@arin.net>
Message-ID: <51A4D350.4040006@arin.net>

The review period for this suggested administrative update to the NRPM 
ends tomorrow.

> The review period will close on 29 May 2013.

Regards,

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





On 4/29/13 2:24 PM, ARIN wrote:
> The ARIN Advisory Council (AC) met on 24 April 2013 and requested that
> the following proposed editorial update to the Number Resource Policy
> Manual (NRPM) be posted for review by the community.
>
> The AC provided the following statement:
>
> ----
> "Having reviewed ARIN-prop-186 'Section 8.2 Reorganizations' the AC
> believes that the requested change is editorial in nature. This
> decision is based on the facts that the author of the current text did
> not intend to remove reorganizations, that ARIN's operational
> procedure will not change based on this update, as they currently
> consider reorganizations to be valid. It was pointed out by staff that
> unless the term were reintroduced into policy, their operational
> procedure may have to change accordingly. Based on this position, the
> ARIN AC proposes that the following editorial change be made to the
> NRPM:
>
> Re-insert the word 'reorganization' into section 8.2; the resulting
> text will read:
>
> "ARIN will consider requests for the transfer of number resources in
> the case of mergers, acquisitions, and reorganizations under the
> following conditions: ..."
>
> Please voice any concerns to the AC as soon as possible."
> ----
>
> The process for editorial updates to the NRPM is found in Part One,
> Section 3.1, paragraph 3 of the PDP:
> "Changes to policy that are purely editorial and non-substantial in
> nature are outside the scope of the full Policy Development Process and
> may only be made with 30 days public notice followed by the concurrence
> of both the ARIN Advisory Council and ARIN Board of Trustees that the
> changes are non-substantial in nature."
>
> The review period will close on 29 May 2013.
>
> ARIN-prop-186 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)
>
>
> ## * ##
>
>
> Policy Proposal Name: Section 8.2 Reorganizations
> Proposal Originator: John Springer
>
> Date: 23 April 2013
>
> Problem Statement:
>
> There is no longer a reference to corporate reorganizations in the
> policy. ARIN often sees corporate reorganizations as the basis for
> transfer.
>
> Corporate reorganizations were part of the previous version of 8.2
> policy as follows:
>
> "ARIN will consider requests for the transfer of number resources only
> upon receipt of evidence that the new entity has acquired the assets
> which had, as of the date of the acquisition or proposed reorganization,
> justified the current entity's use of the number resource."
>
> Current policy reads: "ARIN will consider requests for the transfer of
> number resources in the case of mergers and acquisitions under the
> following conditions: ..."
>
> Corporate reorganizations are currently being allowed under the
> following conditions: A parent organization can transfer resources to a
> child organization or vice versa as long as the child is a 100% wholly
> owned subsidiary. Various documentary requirements apply.
>
> Policy statement:
>
> "ARIN will consider requests for the transfer of number resources in the
> case of mergers, acquisitions and corporate reorganizations under the
> following conditions: ..."
>
> Timetable for implementation: Immediately
>
>



From cgrundemann at gmail.com  Tue May 28 12:34:57 2013
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Tue, 28 May 2013 10:34:57 -0600
Subject: [arin-ppml] ARIN-prop-186 Section 8.2 Reorganizations - Notice
 of intent to make editorial update
In-Reply-To: <51A4D350.4040006@arin.net>
References: <517EBAD0.6030504@arin.net>
	<51A4D350.4040006@arin.net>
Message-ID: <CAC1-dtkSwXKtgELu83v__aLx3iwndtZCK7rv39XT1Y1Two0RYA@mail.gmail.com>

On Tue, May 28, 2013 at 9:54 AM, ARIN <info at arin.net> wrote:
> The review period for this suggested administrative update to the NRPM ends
> tomorrow.

As such, now is the time to speak up if you have any concerns
regarding this change at all.

Thanks!
~Chris


>> The review period will close on 29 May 2013.
>
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
>
>
> On 4/29/13 2:24 PM, ARIN wrote:
>>
>> The ARIN Advisory Council (AC) met on 24 April 2013 and requested that
>> the following proposed editorial update to the Number Resource Policy
>> Manual (NRPM) be posted for review by the community.
>>
>> The AC provided the following statement:
>>
>> ----
>> "Having reviewed ARIN-prop-186 'Section 8.2 Reorganizations' the AC
>> believes that the requested change is editorial in nature. This
>> decision is based on the facts that the author of the current text did
>> not intend to remove reorganizations, that ARIN's operational
>> procedure will not change based on this update, as they currently
>> consider reorganizations to be valid. It was pointed out by staff that
>> unless the term were reintroduced into policy, their operational
>> procedure may have to change accordingly. Based on this position, the
>> ARIN AC proposes that the following editorial change be made to the
>> NRPM:
>>
>> Re-insert the word 'reorganization' into section 8.2; the resulting
>> text will read:
>>
>> "ARIN will consider requests for the transfer of number resources in
>> the case of mergers, acquisitions, and reorganizations under the
>> following conditions: ..."
>>
>> Please voice any concerns to the AC as soon as possible."
>> ----
>>
>> The process for editorial updates to the NRPM is found in Part One,
>> Section 3.1, paragraph 3 of the PDP:
>> "Changes to policy that are purely editorial and non-substantial in
>> nature are outside the scope of the full Policy Development Process and
>> may only be made with 30 days public notice followed by the concurrence
>> of both the ARIN Advisory Council and ARIN Board of Trustees that the
>> changes are non-substantial in nature."
>>
>> The review period will close on 29 May 2013.
>>
>> ARIN-prop-186 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)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: Section 8.2 Reorganizations
>> Proposal Originator: John Springer
>>
>> Date: 23 April 2013
>>
>> Problem Statement:
>>
>> There is no longer a reference to corporate reorganizations in the
>> policy. ARIN often sees corporate reorganizations as the basis for
>> transfer.
>>
>> Corporate reorganizations were part of the previous version of 8.2
>> policy as follows:
>>
>> "ARIN will consider requests for the transfer of number resources only
>> upon receipt of evidence that the new entity has acquired the assets
>> which had, as of the date of the acquisition or proposed reorganization,
>> justified the current entity's use of the number resource."
>>
>> Current policy reads: "ARIN will consider requests for the transfer of
>> number resources in the case of mergers and acquisitions under the
>> following conditions: ..."
>>
>> Corporate reorganizations are currently being allowed under the
>> following conditions: A parent organization can transfer resources to a
>> child organization or vice versa as long as the child is a 100% wholly
>> owned subsidiary. Various documentary requirements apply.
>>
>> Policy statement:
>>
>> "ARIN will consider requests for the transfer of number resources in the
>> case of mergers, acquisitions and corporate reorganizations under the
>> following conditions: ..."
>>
>> Timetable for implementation: Immediately
>>
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



--
@ChrisGrundemann
http://chrisgrundemann.com


From andrew.dul at quark.net  Tue May 28 14:19:50 2013
From: andrew.dul at quark.net (Andrew Dul)
Date: Tue, 28 May 2013 11:19:50 -0700
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <51966083.2010003@arin.net>
References: <51966083.2010003@arin.net>
Message-ID: <51A4F546.3090601@quark.net>

I support adding these guiding principles to the NRPM, furthermore I
would support efforts to introduce this policy in all RIR regions to
make this a global policy. 

Comments on the proposed text in-line below.

Andrew

On 5/17/2013 9:53 AM, ARIN wrote:
> Draft Policy ARIN-2013-4
> RIR Principles
>
> On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-187
> RIR Principles" as a Draft Policy.
>
> Draft Policy ARIN-2013-4 is below and can be found at:
> https://www.arin.net/policy/proposals/2013_4.html
>
>
> ## * ##
>
>
> Draft Policy ARIN-2013-4
> RIR Principles
>
> Date: 17 May 2013
>
> Problem Statement:
>
> The original text in RFC 2050 both "describes the registry system for
> the distribution of globally unique Internet address space and
> registry operations" and provides "rules and guidelines [principles]
> governing the distribution of this address space."
>
> The currently proposed update (RFC2050bis) "provides information about
> the current Internet Numbers Registry System used in the distribution
> of globally unique Internet Protocol (IP) address space and autonomous
> system (AS) numbers" and "provides information about the processes for
> further evolution of the Internet Numbers Registry System."
>
> This means that the guiding principles of stewardship are not
> currently being carried forward into the new document. The goals of
> Conservation (efficient utilization based on need), Routability
> (hierarchical aggregation), and Registration (uniqueness) are as
> important, if not more so, now that the transition to IPv6 is upon us.
> This can be rectified by documenting these principles in RIR policy.
>
> Policy Statement:
>
> Section 0: Principles and Goals of the Internet Registry System
>
> 0.1. Efficient utilization based on need (Conservation)
>
> Policies for managing Internet number resources must support 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. The registry should
> prevent stockpiling in order to maximize the conservation and
> efficient utilization of the Internet address space.

This section should use the new proposed convention of "LIR/ISP" as
being developed in ARIN-2013-5.

s/this address space/IP number resources/r
s/Internet address space/IP number resources/r

I think this section should have an explicit reference to the difference
in conservation techniques for IPv4 and IPv6.  A proposed sentence might
be something like this... "Conservation goals may vary due to the
technical differences between IP number resources pools, for example the
relatively limited size of the IPv4 address pool causes a desire to see
the number space more highly utilized compared to the vast availability
of IP numbers within the IPv6 address pool."

>
> 0.1.1. Documented Justified Need (Needs Based)
>
> Assignment of Internet number resources is based on documented
> operational need. Utilization rate of address space will be a key
> factor in number resource assignment. To this end, registrants should
> have documented justified need available for each assignment.
> Organizations will be assigned resources based on immediate
> utilization plus expected utilization.

Utilization rate is much more important for IPv4 than IPv6. 

Suggested revision for "Utilization rate of address space will be a key
factor in number resource assignment."

"Utilization rate of address space will be an important factor in
justifying need for IP number resources.  However, utilization rates
will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
number resource pools."

>
> In order to promote increased usage of Internet number resources,
> resource holders will be required to provide an accounting of
> resources currently held demonstrating efficient utilization. Internet
> number resources are valid as long as the criteria continues to be
> met. The transfer of Internet number resources from one party to
> another must be approved by the regional registries. The party trying
> to obtain the resources must meet the same criteria as if they were
> requesting resources directly from the IR.
>
> All Internet number resource requests are subject to audit and
> verification by any means deemed appropriate by the regional registry.
>

I suspect the above two paragraphs may be lightning rods against the
policy proposal.   May I suggest the following single paragraph in lieu 
of the above two paragraphs.

In order meet the Principles and Goals of the Internet Registry System,
resource holders may be required from time to time to provide an
accounting and current usage of resources currently held.  The RIRs
shall set policies to define these accounting mythologies as part of
their community driven policy process.


> 0.2. Hierarchical aggregation (Routability)
>
> Policies for managing Internet number resources must support
> distribution of globally unique Internet addresses in a hierarchical
> manner, permitting the routing scalability of the addresses. This
> scalability is necessary to ensure proper operation of Internet
> routing, although it must be stressed that routability is in no way
> guaranteed with the allocation or assignment of IPv4 addresses.
>

Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
predominant routing methodology in the future, one would not necessarily
expect the goals of the RIRs to change. 

Suggested change to end of first sentence.

... permitting the routing scalability of the addresses as required by
the current technical limitations of global routing protocols.

> 0.3. Uniqueness (Registration)
>
> Provision of a public registry documenting Internet number resource
> allocation, reallocation, assignment, and reassignment is necessary to:
>
> a) ensure uniqueness and to to provide operational staff with
> information on who is using the number resource b) to provide a
> contact in case of operational/security problems (e.g. Law
> Enforcement) c) to ensure that a provider has exhausted a majority of
> its current CIDR allocation, thereby justifying an additional
> allocation d) to assist in IP allocation studies.

Suggested revision for "C"

to allow a LIR to demonstrate and disclose reassignment of IP number
resources to third-parties

>
> It is imperative that reassignment information be submitted in a
> prompt and efficient manner to facilitate database maintenance and
> ensure database integrity.
>
> 0.4. Stewardship
>
> It should be noted that efficient utilization and hierarchical
> aggregation are often conflicting goals. All the above goals may
> sometimes be in conflict with the interests of individual end-users or
> Internet Service Providers. Care must be taken to ensure balance with
> these conflicting goals given the resource availability, relative size
> of the resource, and number resource specific technical dynamics, for
> each type of number resource. For example, efficient utilization
> becomes a more prominent issue than aggregation as the IPv4 free pool
> depletes and IPv4 resource availability in any transfer market
> decreases. Conversely, because the IPv6 number space is orders of
> magnitude larger than the IPv4 number space, the scale tips away from
> efficient utilization towards hierarchical aggregation for IPv6 number
> resources.

Perhaps add a statement specifically about Stewardship

"Stewardship of IP number resources is the balance of overseeing and
protecting the interests of all Internet stakeholders to further the
development and expansion of the Internet and the Internet Registry System."

Also...

justified need as a conflicting goal should be explicitly mentioned. 

"It should be noted that efficient utilization, justified need, and
hierarchical aggregation are often conflicting goals."

Use the new LIR/ISP convention instead of "Internet Service Providers"



>
> Comments:
>
> a. Timetable for implementation: immediately
>
> b. I believe that it would be beneficial for IANA to adopt these
> principles as well, and encourage the community to consider a global
> policy proposal.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 May 28 16:09:57 2013
From: bill at herrin.us (William Herrin)
Date: Tue, 28 May 2013 16:09:57 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <51966083.2010003@arin.net>
References: <51966083.2010003@arin.net>
Message-ID: <CAP-guGUCzdq=n81a9uQ7FCEZEjh_A2dmcgdFbZw8f=_5mF5_iQ@mail.gmail.com>

On Fri, May 17, 2013 at 12:53 PM, ARIN <info at arin.net> wrote:
> 0.2. Hierarchical aggregation (Routability)
>
> Policies for managing Internet number resources must support distribution of
> globally unique Internet addresses in a hierarchical manner, permitting the
> routing scalability of the addresses. This scalability is necessary to
> ensure proper operation of Internet routing, although it must be stressed
> that routability is in no way guaranteed with the allocation or assignment
> of IPv4 addresses.

This puts the cart before the horse. Scalable routing is important and
registry policies must facilitate it. Hierarchical routing is only
important indirectly in service of aggregation which itself serves
scalable routing only because of BGP's technical limitations. Where
BGP is partnered with or superseded by a scalable technology that
doesn't require aggregation, it should not be our policy to preclude
its use.

Suggest rewording as:

0.2. Encourage Scalable Internet Routing

Policies for managing Internet number resources must facilitate
scalable routing. This scalability is necessary to ensure proper
operation of the Internet. In the Border Gateway Protocol, scalability
is achieved by announcing only CIDR aggregates of downstream customer
routes which are as large as possible.

0.2.1 ARIN does not set Internet Routing Policy

While ARIN number policy is informed by current routing technologies
and routing policy choices made by Internet Service Provides, ARIN
does not make policies about how routing must or must not be done.
Allocation or assignment of addresses by ARIN in no way guarantees
that those addresses will be routeable on the public Internet.



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 May 28 16:15:26 2013
From: bill at herrin.us (William Herrin)
Date: Tue, 28 May 2013 16:15:26 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <51966083.2010003@arin.net>
References: <51966083.2010003@arin.net>
Message-ID: <CAP-guGUbX30Tig_4ef=yTtzjWjoE5pGmFGr+hpeCvML1c9QAdw@mail.gmail.com>

On Fri, May 17, 2013 at 12:53 PM, ARIN <info at arin.net> wrote:
> 0.1. Efficient utilization based on need (Conservation)
>
> Policies for managing Internet number resources must support 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. The registry should prevent stockpiling
> in order to maximize the conservation and efficient utilization of the
> Internet address space.

This is backwards. Conservation is not the goal. SUSTAINABILITY is the
goal. Depending on the circumstance, conservation may or may not
facilitate sustainability.

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 jschiller at google.com  Wed May 29 00:04:34 2013
From: jschiller at google.com (Jason Schiller)
Date: Wed, 29 May 2013 00:04:34 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <51A4F546.3090601@quark.net>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
Message-ID: <CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>

Andrew thanks for your feed back.

I want to point out that much of this language comes from either RFC-2050
or the current PDP or NRPM.  I tired to change the language as little as
possible, except where we have commonly agreed on new language such as
"efficient utilization" instead of conservation.  I thought that might be
the most uncontroversial starting point.  I am not opposed to changing it,
especially if it makes the text less controversial.

---

WRT the LIR/ISP I agree, we should adopt whatever we think the standard
term should be.

---

WRT using number resources instead of IP address space I would have to take
a careful look and make sure we are not applying principles that make sense
with respect IP addressing to ASNs if they don't make sense.   It is not
clear to me if you think these changes should be throughout the text, or
only in section 0.1.

---

Andrew writes:
> I think this section [0.1. Efficient utilization based on need
(Conservation)]
> should have an explicit reference to the difference
> in conservation techniques for IPv4 and IPv6.  A proposed sentence might
> be something like this... "Conservation goals may vary due to the
> technical differences between IP number resources pools, for example the
> relatively limited size of the IPv4 address pool causes a desire to see
> the number space more highly utilized compared to the vast availability
> of IP numbers within the IPv6 address pool."

I made a conscious effort to keep this text in section 0.4 for clarity.

>From the draf policy section 0.4:
"For example, efficient utilization becomes a more prominent issue than
aggregation as the IPv4 free pool depletes and IPv4 resource availability
in any transfer market decreases. Conversely, because the IPv6 number space
is orders of magnitude larger than the IPv4 number space, the scale tips
away from efficient utilization towards hierarchical aggregation for IPv6
number resources."

Does that text fulfill your suggestion of "Conservation goals may vary due
to the technical differences between IP number resources pools, for example
the relatively limited size of the IPv4 address pool causes a desire to see
the number space more highly utilized compared to the vast availability of
IP numbers within the IPv6 address pool."

Do you have concerns about where this text is located?

---

Andrew writes:
> "Utilization rate of address space will be an important factor in
> justifying need for IP number resources.  However, utilization rates
> will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
> number resource pools."

Again, I made a conscious effort to keep this text in section 0.4 for
clarity, and would quote the same text.

Does that meet your concern about your proposed text?

Do you have concerns about where this text is located?

Should I repeat the paragraph in 0.1, 0.1.1, and 0.4?

---
Andrew writes:
>> In order to promote increased usage of Internet number resources,
>> resource holders will be required to provide an accounting of
>> resources currently held demonstrating efficient utilization. Internet
>> number resources are valid as long as the criteria continues to be
>> met. The transfer of Internet number resources from one party to
>> another must be approved by the regional registries. The party trying
>> to obtain the resources must meet the same criteria as if they were
>> requesting resources directly from the IR.
>>
>> All Internet number resource requests are subject to audit and
>> verification by any means deemed appropriate by the regional registry.
>>
>
> I suspect the above two paragraphs may be lightning rods against the
> policy proposal.   May I suggest the following single paragraph in lieu
> of the above two paragraphs.
>
> In order meet the Principles and Goals of the Internet Registry System,
> resource holders may be required from time to time to provide an
> accounting and current usage of resources currently held.  The RIRs
> shall set policies to define these accounting mythologies as part of
> their community driven policy process.

I'm not sure why you think these two paragraphs are lightening rods.

RFC-250 3.3 says:
"To promote increased usage of address space, the registries will
  require an accounting of address space previously assigned to the
  enterprise, if any."

RFC-2050 3.1 says:

"IP addresses are valid as long as the criteria continues to be met."

RFC-2050 4.7 says

"The transfer of IP addresses from one party to another must be
  approved by the regional registries.  The party trying to obtain
  the IP address must meet the same criteria as if they were
  requesting an IP address directly from the IR."

RFC-2050 4.4 says:
"All IP address requests are subject to audit and verification
  by any means deemed appropriate by the regional registry."

And there is lots of text about conservation in RFC-2050 and
efficient utilization in the NRPM.

Can you elaborate on the lightening rod potin?

I can only guess you are suggesting that the community wants
to depart from the principles in RFC-2050, but think you must
mean something else.

What am I missing here?

---

Andrew writes:
>> 0.2. Hierarchical aggregation (Routability)
>>
>> Policies for managing Internet number resources must support
>> distribution of globally unique Internet addresses in a hierarchical
>> manner, permitting the routing scalability of the addresses.
>
> Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
> predominant routing methodology in the future, one would not necessarily
> expect the goals of the RIRs to change.
>
> Suggested change to end of first sentence.
>
> ... permitting the routing scalability of the addresses as required by
> the current technical limitations of global routing protocols.

I think this change is good even w/o considering LISP.
Imagine we have new holographic memory that can hold orders of
magnitude more data and decrease read time

---

Andrew writes:
>
>> 0.3. Uniqueness (Registration)
>>
>> c) to ensure that a provider has exhausted a majority of
>> its current CIDR allocation, thereby justifying an additional
>> allocation d) to assist in IP allocation studies.
>
> Suggested revision for "C"
>
> to allow a LIR to demonstrate and disclose reassignment of IP number
> resources to third-parties

I think the point is to demonstrate reassignment data to
demonstrate efficient utilization.
But I also think that point is covered in section 0.1.1, So the rewrite
here is ok.

---

Andrew writes:
> Perhaps add a statement specifically about Stewardship
>
> "Stewardship of IP number resources is the balance of overseeing and
> protecting the interests of all Internet stakeholders to further the
> development and expansion of the Internet and the Internet Registry
System."

I do not oppose this text.

Andrew also writes...
>
> justified need as a conflicting goal should be explicitly mentioned.
>
> "It should be noted that efficient utilization, justified need, and
>hierarchical aggregation are often conflicting goals."

I'm not sure this parses correctly...  This sounds to me like there are
conflicts between all three:

efficient utilization vs justified need vs hierarchical aggregation.

How about:
"It should be noted that efficient utilization based on justified need, and
hierarchical aggregation are often conflicting goals."



-


On Tue, May 28, 2013 at 2:19 PM, Andrew Dul <andrew.dul at quark.net> wrote:

> I support adding these guiding principles to the NRPM, furthermore I
> would support efforts to introduce this policy in all RIR regions to
> make this a global policy.
>
> Comments on the proposed text in-line below.
>
> Andrew
>
> On 5/17/2013 9:53 AM, ARIN wrote:
> > Draft Policy ARIN-2013-4
> > RIR Principles
> >
> > On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-187
> > RIR Principles" as a Draft Policy.
> >
> > Draft Policy ARIN-2013-4 is below and can be found at:
> > https://www.arin.net/policy/proposals/2013_4.html
> >
> >
> > ## * ##
> >
> >
> > Draft Policy ARIN-2013-4
> > RIR Principles
> >
> > Date: 17 May 2013
> >
> > Problem Statement:
> >
> > The original text in RFC 2050 both "describes the registry system for
> > the distribution of globally unique Internet address space and
> > registry operations" and provides "rules and guidelines [principles]
> > governing the distribution of this address space."
> >
> > The currently proposed update (RFC2050bis) "provides information about
> > the current Internet Numbers Registry System used in the distribution
> > of globally unique Internet Protocol (IP) address space and autonomous
> > system (AS) numbers" and "provides information about the processes for
> > further evolution of the Internet Numbers Registry System."
> >
> > This means that the guiding principles of stewardship are not
> > currently being carried forward into the new document. The goals of
> > Conservation (efficient utilization based on need), Routability
> > (hierarchical aggregation), and Registration (uniqueness) are as
> > important, if not more so, now that the transition to IPv6 is upon us.
> > This can be rectified by documenting these principles in RIR policy.
> >
> > Policy Statement:
> >
> > Section 0: Principles and Goals of the Internet Registry System
> >
> > 0.1. Efficient utilization based on need (Conservation)
> >
> > Policies for managing Internet number resources must support 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. The registry should
> > prevent stockpiling in order to maximize the conservation and
> > efficient utilization of the Internet address space.
>
> This section should use the new proposed convention of "LIR/ISP" as
> being developed in ARIN-2013-5.
>
> s/this address space/IP number resources/r
> s/Internet address space/IP number resources/r
>
> I think this section should have an explicit reference to the difference
> in conservation techniques for IPv4 and IPv6.  A proposed sentence might
> be something like this... "Conservation goals may vary due to the
> technical differences between IP number resources pools, for example the
> relatively limited size of the IPv4 address pool causes a desire to see
> the number space more highly utilized compared to the vast availability
> of IP numbers within the IPv6 address pool."
>
> >
> > 0.1.1. Documented Justified Need (Needs Based)
> >
> > Assignment of Internet number resources is based on documented
> > operational need. Utilization rate of address space will be a key
> > factor in number resource assignment. To this end, registrants should
> > have documented justified need available for each assignment.
> > Organizations will be assigned resources based on immediate
> > utilization plus expected utilization.
>
> Utilization rate is much more important for IPv4 than IPv6.
>
> Suggested revision for "Utilization rate of address space will be a key
> factor in number resource assignment."
>
> "Utilization rate of address space will be an important factor in
> justifying need for IP number resources.  However, utilization rates
> will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
> number resource pools."
>
> >
> > In order to promote increased usage of Internet number resources,
> > resource holders will be required to provide an accounting of
> > resources currently held demonstrating efficient utilization. Internet
> > number resources are valid as long as the criteria continues to be
> > met. The transfer of Internet number resources from one party to
> > another must be approved by the regional registries. The party trying
> > to obtain the resources must meet the same criteria as if they were
> > requesting resources directly from the IR.
> >
> > All Internet number resource requests are subject to audit and
> > verification by any means deemed appropriate by the regional registry.
> >
>
> I suspect the above two paragraphs may be lightning rods against the
> policy proposal.   May I suggest the following single paragraph in lieu
> of the above two paragraphs.
>
> In order meet the Principles and Goals of the Internet Registry System,
> resource holders may be required from time to time to provide an
> accounting and current usage of resources currently held.  The RIRs
> shall set policies to define these accounting mythologies as part of
> their community driven policy process.
>
>
> > 0.2. Hierarchical aggregation (Routability)
> >
> > Policies for managing Internet number resources must support
> > distribution of globally unique Internet addresses in a hierarchical
> > manner, permitting the routing scalability of the addresses. This
> > scalability is necessary to ensure proper operation of Internet
> > routing, although it must be stressed that routability is in no way
> > guaranteed with the allocation or assignment of IPv4 addresses.
> >
>
> Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
> predominant routing methodology in the future, one would not necessarily
> expect the goals of the RIRs to change.
>
> Suggested change to end of first sentence.
>
> ... permitting the routing scalability of the addresses as required by
> the current technical limitations of global routing protocols.
>
> > 0.3. Uniqueness (Registration)
> >
> > Provision of a public registry documenting Internet number resource
> > allocation, reallocation, assignment, and reassignment is necessary to:
> >
> > a) ensure uniqueness and to to provide operational staff with
> > information on who is using the number resource b) to provide a
> > contact in case of operational/security problems (e.g. Law
> > Enforcement) c) to ensure that a provider has exhausted a majority of
> > its current CIDR allocation, thereby justifying an additional
> > allocation d) to assist in IP allocation studies.
>
> Suggested revision for "C"
>
> to allow a LIR to demonstrate and disclose reassignment of IP number
> resources to third-parties
>
> >
> > It is imperative that reassignment information be submitted in a
> > prompt and efficient manner to facilitate database maintenance and
> > ensure database integrity.
> >
> > 0.4. Stewardship
> >
> > It should be noted that efficient utilization and hierarchical
> > aggregation are often conflicting goals. All the above goals may
> > sometimes be in conflict with the interests of individual end-users or
> > Internet Service Providers. Care must be taken to ensure balance with
> > these conflicting goals given the resource availability, relative size
> > of the resource, and number resource specific technical dynamics, for
> > each type of number resource. For example, efficient utilization
> > becomes a more prominent issue than aggregation as the IPv4 free pool
> > depletes and IPv4 resource availability in any transfer market
> > decreases. Conversely, because the IPv6 number space is orders of
> > magnitude larger than the IPv4 number space, the scale tips away from
> > efficient utilization towards hierarchical aggregation for IPv6 number
> > resources.
>
> Perhaps add a statement specifically about Stewardship
>
> "Stewardship of IP number resources is the balance of overseeing and
> protecting the interests of all Internet stakeholders to further the
> development and expansion of the Internet and the Internet Registry
> System."
>
> Also...
>
> justified need as a conflicting goal should be explicitly mentioned.
>
> "It should be noted that efficient utilization, justified need, and
> hierarchical aggregation are often conflicting goals."
>
> Use the new LIR/ISP convention instead of "Internet Service Providers"
>
>
>
> >
> > Comments:
> >
> > a. Timetable for implementation: immediately
> >
> > b. I believe that it would be beneficial for IANA to adopt these
> > principles as well, and encourage the community to consider a global
> > policy proposal.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage 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.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130529/ff1ab44f/attachment.htm>

From jschiller at google.com  Wed May 29 00:17:59 2013
From: jschiller at google.com (Jason Schiller)
Date: Wed, 29 May 2013 00:17:59 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAP-guGUbX30Tig_4ef=yTtzjWjoE5pGmFGr+hpeCvML1c9QAdw@mail.gmail.com>
References: <51966083.2010003@arin.net>
	<CAP-guGUbX30Tig_4ef=yTtzjWjoE5pGmFGr+hpeCvML1c9QAdw@mail.gmail.com>
Message-ID: <CAC4yj2X_V=A55AQ=6ka2ciLpcNrAZv1WyhRdyP=Px9XxebG4Wg@mail.gmail.com>

Bill,

Your point about aggregation is the cart before the horse is well taken.
 Andrew Dul, had a similar point, and suggested rewrite adding something
about the state of technology.  I think his rewrite is is more universal in
that it does not specifically call out BGP.  Also your rewrite loses the
importance of the numbers being unique, and properly documented.

I hope you will find Andrew's rewrite sufficient.

---

WRT sustainability as opposed to conservation, could you please expand.  I
don't think i quit grasped your point.

I used the word conservation because that is the word in RFC-2050.  We get
our principles of efficient use out of RFC-2050 section on conservation.

I hope people are not confusing the old RFC-2050 definition of conservation
with the recent attempts of soft landing, and making IPv4 last longer.

I was hoping to have a very clear line from the current draft to RFC-2050,
and tried to carry those principles forward and use much of the same
language.

If this is confusion WRT the meaning of "conservation" then maybe we need a
paragraph define what we do and don't mean by conservation?

___Jason


On Tue, May 28, 2013 at 4:15 PM, William Herrin <bill at herrin.us> wrote:

> On Fri, May 17, 2013 at 12:53 PM, ARIN <info at arin.net> wrote:
> > 0.1. Efficient utilization based on need (Conservation)
> >
> > Policies for managing Internet number resources must support 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. The registry should prevent
> stockpiling
> > in order to maximize the conservation and efficient utilization of the
> > Internet address space.
>
> This is backwards. Conservation is not the goal. SUSTAINABILITY is the
> goal. Depending on the circumstance, conservation may or may not
> facilitate sustainability.
>
> 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.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130529/694e1075/attachment.htm>

From bill at herrin.us  Wed May 29 16:27:57 2013
From: bill at herrin.us (William Herrin)
Date: Wed, 29 May 2013 16:27:57 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAC4yj2X_V=A55AQ=6ka2ciLpcNrAZv1WyhRdyP=Px9XxebG4Wg@mail.gmail.com>
References: <51966083.2010003@arin.net>
	<CAP-guGUbX30Tig_4ef=yTtzjWjoE5pGmFGr+hpeCvML1c9QAdw@mail.gmail.com>
	<CAC4yj2X_V=A55AQ=6ka2ciLpcNrAZv1WyhRdyP=Px9XxebG4Wg@mail.gmail.com>
Message-ID: <CAP-guGWL2rE2LhD-1PBVJgUmqrNbMB9CjxNKZiyUSs7Zybx3xg@mail.gmail.com>

On Wed, May 29, 2013 at 12:17 AM, Jason Schiller <jschiller at google.com> wrote:
> Also your rewrite loses the
> importance of the numbers being unique, and properly documented.

Hi Jason,

How do you figure? My rewrite spoke only to 0.2, not 0.1 or 0.3. I
don't have conceptual problems with 0.3. Maybe some wordsmithing. As
for documentation, to the extent that it serves sustainability, it's
critical. To the extent that it doesn't, it's undesirable.

> Your point about aggregation is the cart before the horse is well taken.
> Andrew Dul, had a similar point, and suggested rewrite adding something
> about the state of technology.  I think his rewrite is is more universal in
> that it does not specifically call out BGP.

Andrew's rewrite continues to focus on hierarchy and aggregation which
IMO a statement of principles shouldn't. The principle is: support
scalability, however that's achieved.

I called out BGP because BGP has been the core routing technology for
the duration of ARIN's existence and there is no end in sight. What
value lies in abstracting it out of the principles statement? Doing so
can only lead to confusion.

Aggregation is the only known tool for achieving scalability in the
current technology (BGP). That's a central point that should not be
lost to abstraction when we consider policy based on these principles:
when we're talking addresses for announcement into BGP (and we usually
are), scalability requires aggregation. Period. Full stop.

When we're talking about addresses for use with another technology, we
have to consider scalability freshly without getting hung up on
aggregation.


> I hope you will find Andrew's rewrite sufficient.

You mean adding the phrase "as required by the current technical
limitations of global routing protocols?" No, that isn't sufficient at
all. The hierarchy statement is broken at its core and hanging a brief
conditional on it doesn't fix it up.


> WRT sustainability as opposed to conservation, could you please expand.  I
> don't think i quit grasped your point.

http://www.merriam-webster.com/dictionary/sustainable

2. a : of, relating to, or being a method of harvesting or using a
resource so that the resource is not depleted or permanently damaged


It's well enough defined that I'm reluctant to expand on it but I'll
give it a shot anyway.

Basically three phases to a protocol's existence with respect to its
number pool:

Phase 1: Early. Conservation is a distant concern. The priority has to
be: don't kill the baby. IPv6 is in the Early phase and the baby looks
underfed.

Phase 2: Mainline. Conservation comes into play here. It should
discourage unduly wasteful use of the number resources and studiously
avoid practices which permanently remove the numbers from circulation.

As use increases, so should the conservation efforts. Ideally, the
conservation efforts are sufficient for the protocol to reach
obsolescence before the number assignment process leaves the mainline
phase. Didn't happen with IPv4, but that's the goal.

Phase 3: Zero sum. If the number pool approaches depletion before the
protocol reaches obsolescence then the numbers have to move from less
efficient uses to more efficient uses. Exactly how is a subject of
policy rather than a statement of principles but this is where things
like markets, resource reviews and reclamation come in to play.


Point is, conservation is only front and center during the mainline
phase of the number management process. In the early phase it's a
hindrance and in the zero sum phase it's moot. The abstract principle
of which conservation is a part, the one that applies throughout the
process, is sustainability.


> I was hoping to have a very clear line from the current draft to RFC-2050,
> and tried to carry those principles forward and use much of the same
> language.

I think that would yield a net negative result. If RFC 2050 is the
primary resource then we should incorporate it by reference without
trying to repeat it in our own words. The repetition can only confuse
matters and set up needless conflicts. If we recognize that 2050 is an
antiquated document then let's read between the lines at what its
authors were targeting and avoid getting caught up in wording and
choices that technology has passed by.

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 andrew.dul at quark.net  Thu May 30 13:25:27 2013
From: andrew.dul at quark.net (Andrew Dul)
Date: Thu, 30 May 2013 10:25:27 -0700
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
Message-ID: <51A78B87.6020901@quark.net>

Hi Jason,

On 5/28/2013 9:04 PM, Jason Schiller wrote:
> Andrew thanks for your feed back.
>
> I want to point out that much of this language comes from either
> RFC-2050 or the current PDP or NRPM.  I tired to change the language
> as little as possible, except where we have commonly agreed on new
> language such as "efficient utilization" instead of conservation.  I
> thought that might be the most uncontroversial starting point.  I am
> not opposed to changing it, especially if it makes the text less
> controversial.
>
I didn't have any of those docs in front of me when reviewing the
proposal, so I didn't specifically note they were "existing policy
text." In general, I'm in favor of reusing text where it makes sense.  I
will say that there probably always is room for improvement, and 2050 is
now pretty dated so updating the language to be more relevant to today's
practices & principles is probably a step forward.

> ---
>
> WRT the LIR/ISP I agree, we should adopt whatever we think the
> standard term should be.
>
> ---
>
> WRT using number resources instead of IP address space I would have to
> take a careful look and make sure we are not applying principles that
> make sense with respect IP addressing to ASNs if they don't make
> sense.   It is not clear to me if you think these changes should be
> throughout the text, or only in section 0.1.

I probably wasn't totally consistent in my initial comments.  Since this
is "RIR Principles" I believe this policy proposal should refer in
general to number resources unless the statements directly apply only to
a subset of Internet number resources. 

>
> ---
>
> Andrew writes:
> > I think this section [0.1. Efficient utilization based on need
> (Conservation)] 
> > should have an explicit reference to the difference
> > in conservation techniques for IPv4 and IPv6.  A proposed sentence might
> > be something like this... "Conservation goals may vary due to the
> > technical differences between IP number resources pools, for example the
> > relatively limited size of the IPv4 address pool causes a desire to see
> > the number space more highly utilized compared to the vast availability
> > of IP numbers within the IPv6 address pool."
>
> I made a conscious effort to keep this text in section 0.4 for clarity.  
>
> From the draf policy section 0.4:
> "For example, efficient utilization becomes a more prominent issue
> than aggregation as the IPv4 free pool depletes and IPv4 resource
> availability in any transfer market decreases. Conversely, because the
> IPv6 number space is orders of magnitude larger than the IPv4 number
> space, the scale tips away from efficient utilization towards
> hierarchical aggregation for IPv6 number resources."
>
> Does that text fulfill your suggestion of "Conservation goals may vary
> due to the technical differences between IP number resources pools,
> for example the relatively limited size of the IPv4 address pool
> causes a desire to see the number space more highly utilized compared
> to the vast availability of IP numbers within the IPv6 address pool."
>
> Do you have concerns about where this text is located?
>

I realized later that I inserted similar "IPv4 is different that IPv6"
into multiple sections, since I thought it applied in unique ways to
each section.  Perhaps for clarity it should only be in section 0.4
Stewardship, since this is the section that talks about balance between
different elements and goals?  I'm also OK with it being only in one
section, but I would want it to somehow illuminate specifically that
conservation varies based on number resource.

Perhaps just add the statement w/o example?  "Conservation goals may
vary due to the technical differences between IP number resources pools."

Not a showstopper for me, if it isn't in 0.1.

Building on Bill's comments in his notes, I think there might be room
toward using the term sustainability in these principles.  That term is
well known in "corporate speak" and might be closer to the RIR's goals &
principles compared with other words. 

> ---
>
> Andrew writes:
> > "Utilization rate of address space will be an important factor in
> > justifying need for IP number resources.  However, utilization rates
> > will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
> > number resource pools."
>
> Again, I made a conscious effort to keep this text in section 0.4 for
> clarity, and would quote the same text.
>
> Does that meet your concern about your proposed text?
>
> Do you have concerns about where this text is located?

Perhaps just keeping it all in 0.4 is best.

>
> Should I repeat the paragraph in 0.1, 0.1.1, and 0.4?
>
I wouldn't repeat the paragraph.

> ---
> Andrew writes:
> >> In order to promote increased usage of Internet number resources,
> >> resource holders will be required to provide an accounting of
> >> resources currently held demonstrating efficient utilization. Internet
> >> number resources are valid as long as the criteria continues to be
> >> met. The transfer of Internet number resources from one party to
> >> another must be approved by the regional registries. The party trying
> >> to obtain the resources must meet the same criteria as if they were
> >> requesting resources directly from the IR.
> >>
> >> All Internet number resource requests are subject to audit and
> >> verification by any means deemed appropriate by the regional registry.
> >>
> >
> > I suspect the above two paragraphs may be lightning rods against the
> > policy proposal.   May I suggest the following single paragraph in lieu
> > of the above two paragraphs.
> >
> > In order meet the Principles and Goals of the Internet Registry System,
> > resource holders may be required from time to time to provide an
> > accounting and current usage of resources currently held.  The RIRs
> > shall set policies to define these accounting mythologies as part of
> > their community driven policy process.
>
> I'm not sure why you think these two paragraphs are lightening rods.
>
> RFC-2050 3.3 says:
> "To promote increased usage of address space, the registries will
>   require an accounting of address space previously assigned to the
>   enterprise, if any."

I believe including text that says orgs must keep records of how the use
address space is totally appropriate.  Record keeping doesn't
necessarily "proposed increased usage" but does provide accountability
and transparency which I believe should be one of the goals of the
registry system.

>
> RFC-2050 3.1 says:
>
> "IP addresses are valid as long as the criteria continues to be met."

One might construe this statement to directly invalidate existing legacy
allocations which would now be in ARIN's policy through this policy. 
Others might be worried that this opens the door wider to changing
policy to retroactively revoke allocations or assignments by changing
"criteria".   Furthermore, I believe this idea is already handled by
existing NRPM text and the RSA.

> RFC-2050 4.7 says
>
>
> "The transfer of IP addresses from one party to another must be
>   approved by the regional registries.  The party trying to obtain
>   the IP address must meet the same criteria as if they were
>   requesting an IP address directly from the IR."
>
I believe this "policy" element is best handled in the details section
of the NRPM rather than the principles section.  ARIN's policies already
define transfers.  Having a generic "RIRs shall determine IP number
resources transfer policies through their community drive policy
development process." might be a good addition to this proposal.

> RFC-2050 4.4 says:
> "All IP address requests are subject to audit and verification
>   by any means deemed appropriate by the regional registry."
>
I just remember for multiple years discussing policy 2007-14 & others
when we put into policy existing auditing and review practices.  Since
ARIN's policies and RSA already talk about audit procedures, I also
thought this was not necessary.  The language "by any means deemed
appropriate by the regional registry" is a wide open door that many I
believe won't like.  By using text to say auditing is done by the
community through adopted policy you limit an RIR's auditing to
specifically what the community wants the registry to do.

> And there is lots of text about conservation in RFC-2050 and 
> efficient utilization in the NRPM.
>
> Can you elaborate on the lightening rod potin?
>
See above comments.
> I can only guess you are suggesting that the community wants
> to depart from the principles in RFC-2050, but think you must
> mean something else.
>
> What am I missing here?
>

Hopefully my comments above illuminate the concerns I had about the
text.  Basically it comes down to "modernizing" the 2050
text/principles, and keeping principles in the principles section and
not putting specific policy in the principles section.

>
> Andrew writes:
> >> 0.2. Hierarchical aggregation (Routability)
> >>
> >> Policies for managing Internet number resources must support
> >> distribution of globally unique Internet addresses in a hierarchical
> >> manner, permitting the routing scalability of the addresses. 
> >
> > Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
> > predominant routing methodology in the future, one would not necessarily
> > expect the goals of the RIRs to change.
> >
> > Suggested change to end of first sentence.
> >
> > ... permitting the routing scalability of the addresses as required by
> > the current technical limitations of global routing protocols.
>
> I think this change is good even w/o considering LISP.
> Imagine we have new holographic memory that can hold orders of 
> magnitude more data and decrease read time
>
> ---
>
> Andrew writes:
> >
> >> 0.3. Uniqueness (Registration)
> >>
> >> c) to ensure that a provider has exhausted a majority of
> >> its current CIDR allocation, thereby justifying an additional
> >> allocation d) to assist in IP allocation studies.
> >
> > Suggested revision for "C"
> >
> > to allow a LIR to demonstrate and disclose reassignment of IP number
> > resources to third-parties
>
> I think the point is to demonstrate reassignment data to
> demonstrate efficient utilization.  
> But I also think that point is covered in section 0.1.1, So the
> rewrite here is ok.
>
> ---
>
> Andrew writes:
> > Perhaps add a statement specifically about Stewardship
> >
> > "Stewardship of IP number resources is the balance of overseeing and
> > protecting the interests of all Internet stakeholders to further the
> > development and expansion of the Internet and the Internet Registry
> System."
>
> I do not oppose this text.
>
> Andrew also writes...
> >
> > justified need as a conflicting goal should be explicitly mentioned.
> >
> > "It should be noted that efficient utilization, justified need, and
> >hierarchical aggregation are often conflicting goals."
>
> I'm not sure this parses correctly...  This sounds to me like there are 
> conflicts between all three:
>
> efficient utilization vs justified need vs hierarchical aggregation.  
>
> How about:
> "It should be noted that efficient utilization based on justified
> need, and
> hierarchical aggregation are often conflicting goals."
>
>
>
> -
>
>
> On Tue, May 28, 2013 at 2:19 PM, Andrew Dul <andrew.dul at quark.net
> <mailto:andrew.dul at quark.net>> wrote:
>
>     I support adding these guiding principles to the NRPM, furthermore I
>     would support efforts to introduce this policy in all RIR regions to
>     make this a global policy.
>
>     Comments on the proposed text in-line below.
>
>     Andrew
>
>     On 5/17/2013 9:53 AM, ARIN wrote:
>     > Draft Policy ARIN-2013-4
>     > RIR Principles
>     >
>     > On 16 May 2013 the ARIN Advisory Council (AC) accepted
>     "ARIN-prop-187
>     > RIR Principles" as a Draft Policy.
>     >
>     > Draft Policy ARIN-2013-4 is below and can be found at:
>     > https://www.arin.net/policy/proposals/2013_4.html
>     >
>     >
>     > ## * ##
>     >
>     >
>     > Draft Policy ARIN-2013-4
>     > RIR Principles
>     >
>     > Date: 17 May 2013
>     >
>     > Problem Statement:
>     >
>     > The original text in RFC 2050 both "describes the registry
>     system for
>     > the distribution of globally unique Internet address space and
>     > registry operations" and provides "rules and guidelines [principles]
>     > governing the distribution of this address space."
>     >
>     > The currently proposed update (RFC2050bis) "provides information
>     about
>     > the current Internet Numbers Registry System used in the
>     distribution
>     > of globally unique Internet Protocol (IP) address space and
>     autonomous
>     > system (AS) numbers" and "provides information about the
>     processes for
>     > further evolution of the Internet Numbers Registry System."
>     >
>     > This means that the guiding principles of stewardship are not
>     > currently being carried forward into the new document. The goals of
>     > Conservation (efficient utilization based on need), Routability
>     > (hierarchical aggregation), and Registration (uniqueness) are as
>     > important, if not more so, now that the transition to IPv6 is
>     upon us.
>     > This can be rectified by documenting these principles in RIR policy.
>     >
>     > Policy Statement:
>     >
>     > Section 0: Principles and Goals of the Internet Registry System
>     >
>     > 0.1. Efficient utilization based on need (Conservation)
>     >
>     > Policies for managing Internet number resources must support 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. The registry should
>     > prevent stockpiling in order to maximize the conservation and
>     > efficient utilization of the Internet address space.
>
>     This section should use the new proposed convention of "LIR/ISP" as
>     being developed in ARIN-2013-5.
>
>     s/this address space/IP number resources/r
>     s/Internet address space/IP number resources/r
>
>     I think this section should have an explicit reference to the
>     difference
>     in conservation techniques for IPv4 and IPv6.  A proposed sentence
>     might
>     be something like this... "Conservation goals may vary due to the
>     technical differences between IP number resources pools, for
>     example the
>     relatively limited size of the IPv4 address pool causes a desire
>     to see
>     the number space more highly utilized compared to the vast
>     availability
>     of IP numbers within the IPv6 address pool."
>
>     >
>     > 0.1.1. Documented Justified Need (Needs Based)
>     >
>     > Assignment of Internet number resources is based on documented
>     > operational need. Utilization rate of address space will be a key
>     > factor in number resource assignment. To this end, registrants
>     should
>     > have documented justified need available for each assignment.
>     > Organizations will be assigned resources based on immediate
>     > utilization plus expected utilization.
>
>     Utilization rate is much more important for IPv4 than IPv6.
>
>     Suggested revision for "Utilization rate of address space will be
>     a key
>     factor in number resource assignment."
>
>     "Utilization rate of address space will be an important factor in
>     justifying need for IP number resources.  However, utilization rates
>     will vary due to the technical differences (e.g. IPv4 vs. IPv6)
>     between
>     number resource pools."
>
>     >
>     > In order to promote increased usage of Internet number resources,
>     > resource holders will be required to provide an accounting of
>     > resources currently held demonstrating efficient utilization.
>     Internet
>     > number resources are valid as long as the criteria continues to be
>     > met. The transfer of Internet number resources from one party to
>     > another must be approved by the regional registries. The party
>     trying
>     > to obtain the resources must meet the same criteria as if they were
>     > requesting resources directly from the IR.
>     >
>     > All Internet number resource requests are subject to audit and
>     > verification by any means deemed appropriate by the regional
>     registry.
>     >
>
>     I suspect the above two paragraphs may be lightning rods against the
>     policy proposal.   May I suggest the following single paragraph in
>     lieu
>     of the above two paragraphs.
>
>     In order meet the Principles and Goals of the Internet Registry
>     System,
>     resource holders may be required from time to time to provide an
>     accounting and current usage of resources currently held.  The RIRs
>     shall set policies to define these accounting mythologies as part of
>     their community driven policy process.
>
>
>     > 0.2. Hierarchical aggregation (Routability)
>     >
>     > Policies for managing Internet number resources must support
>     > distribution of globally unique Internet addresses in a hierarchical
>     > manner, permitting the routing scalability of the addresses. This
>     > scalability is necessary to ensure proper operation of Internet
>     > routing, although it must be stressed that routability is in no way
>     > guaranteed with the allocation or assignment of IPv4 addresses.
>     >
>
>     Should the RIR's goals be "LISP agnostic"?  That is if LISP
>     becomes the
>     predominant routing methodology in the future, one would not
>     necessarily
>     expect the goals of the RIRs to change.
>
>     Suggested change to end of first sentence.
>
>     ... permitting the routing scalability of the addresses as required by
>     the current technical limitations of global routing protocols.
>
>     > 0.3. Uniqueness (Registration)
>     >
>     > Provision of a public registry documenting Internet number resource
>     > allocation, reallocation, assignment, and reassignment is
>     necessary to:
>     >
>     > a) ensure uniqueness and to to provide operational staff with
>     > information on who is using the number resource b) to provide a
>     > contact in case of operational/security problems (e.g. Law
>     > Enforcement) c) to ensure that a provider has exhausted a
>     majority of
>     > its current CIDR allocation, thereby justifying an additional
>     > allocation d) to assist in IP allocation studies.
>
>     Suggested revision for "C"
>
>     to allow a LIR to demonstrate and disclose reassignment of IP number
>     resources to third-parties
>
>     >
>     > It is imperative that reassignment information be submitted in a
>     > prompt and efficient manner to facilitate database maintenance and
>     > ensure database integrity.
>     >
>     > 0.4. Stewardship
>     >
>     > It should be noted that efficient utilization and hierarchical
>     > aggregation are often conflicting goals. All the above goals may
>     > sometimes be in conflict with the interests of individual
>     end-users or
>     > Internet Service Providers. Care must be taken to ensure balance
>     with
>     > these conflicting goals given the resource availability,
>     relative size
>     > of the resource, and number resource specific technical
>     dynamics, for
>     > each type of number resource. For example, efficient utilization
>     > becomes a more prominent issue than aggregation as the IPv4 free
>     pool
>     > depletes and IPv4 resource availability in any transfer market
>     > decreases. Conversely, because the IPv6 number space is orders of
>     > magnitude larger than the IPv4 number space, the scale tips away
>     from
>     > efficient utilization towards hierarchical aggregation for IPv6
>     number
>     > resources.
>
>     Perhaps add a statement specifically about Stewardship
>
>     "Stewardship of IP number resources is the balance of overseeing and
>     protecting the interests of all Internet stakeholders to further the
>     development and expansion of the Internet and the Internet
>     Registry System."
>
>     Also...
>
>     justified need as a conflicting goal should be explicitly mentioned.
>
>     "It should be noted that efficient utilization, justified need, and
>     hierarchical aggregation are often conflicting goals."
>
>     Use the new LIR/ISP convention instead of "Internet Service Providers"
>
>
>
>     >
>     > Comments:
>     >
>     > a. Timetable for implementation: immediately
>     >
>     > b. I believe that it would be beneficial for IANA to adopt these
>     > principles as well, and encourage the community to consider a global
>     > policy proposal.
>     > _______________________________________________
>     > PPML
>     > You are receiving this message because you are subscribed to
>     > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto:ARIN-PPML at arin.net>).
>     > Unsubscribe or manage your mailing list subscription at:
>     > http://lists.arin.net/mailman/listinfo/arin-ppml
>     > Please contact info at arin.net <mailto:info at arin.net> if you
>     experience any issues.
>
>     _______________________________________________
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net
>     <mailto:ARIN-PPML at arin.net>).
>     Unsubscribe or manage your mailing list subscription at:
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>     Please contact info at arin.net <mailto:info at arin.net> if you
>     experience any issues.
>
>
>
>
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com
> <mailto:jschiller at google.com>|571-266-0006
>

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

From owen at delong.com  Thu May 30 13:45:10 2013
From: owen at delong.com (Owen DeLong)
Date: Thu, 30 May 2013 13:45:10 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <51A78B87.6020901@quark.net>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
Message-ID: <150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>


> 
>> 
>> RFC-2050 3.1 says:
>> 
>> "IP addresses are valid as long as the criteria continues to be met."
> 
> One might construe this statement to directly invalidate existing legacy allocations which would now be in ARIN's policy through this policy.  Others might be worried that this opens the door wider to changing policy to retroactively revoke allocations or assignments by changing "criteria".   Furthermore, I believe this idea is already handled by existing NRPM text and the RSA.
> 
>> 

Whether one construes it that way or not, the reality is that said statement has always applied to resource allocations/assignments even back when it was just kept in Jon Postel's notebook.

As such, I support preserving that statement in the ARIN policy proposal.

Owen

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

From bill at herrin.us  Thu May 30 14:21:09 2013
From: bill at herrin.us (William Herrin)
Date: Thu, 30 May 2013 14:21:09 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
Message-ID: <CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>

On Thu, May 30, 2013 at 1:45 PM, Owen DeLong <owen at delong.com> wrote:
>> RFC-2050 3.1 says:
>>
>> "IP addresses are valid as long as the criteria continues to be met."
>>
>>
>> One might construe this statement to directly invalidate existing legacy
>> allocations which would now be in ARIN's policy through this policy.  Others
>
> Whether one construes it that way or not, the reality is that said statement
> has always applied to resource allocations/assignments even back when it was
> just kept in Jon Postel's notebook.
>
> As such, I support preserving that statement in the ARIN policy proposal.

Hi Owen,

I construe the NRPM (including any changes we might make to it) to
apply to resources under an RSA and requests for ARIN action which
would require the resources to first come under RSA. Should ARIN
construe things differently, they're welcome to try their luck in
court.

I read the language in both the proposal and in 2050 to mean that
resources assigned under the registry's rules are subject to review
under the registry's rules. The legacy addresses weren't assigned
under any version of ARIN's rules. Unless there's some part of the
language that seems targeted at disrupting that status quo, take the
advice that comes out of this topic every time it's brought up: let
sleeping dogs lie.

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 May 30 15:15:51 2013
From: jcurran at arin.net (John Curran)
Date: Thu, 30 May 2013 19:15:51 +0000
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
	<CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>

On May 30, 2013, at 2:21 PM, William Herrin <bill at herrin.us> wrote:

Bill - I have no recommendation or suggestion regarding the Draft 
Policy text, but need to reply to several of your remarks for clarity.

> I construe the NRPM (including any changes we might make to it) to
> apply to resources under an RSA and requests for ARIN action which
> would require the resources to first come under RSA. 

The policies set by the community in this region (i.e. the NRPM)
apply to all resources in the registry.  ARIN will operate the
registry in accordance with such policies.

> Should ARIN
> construe things differently, they're welcome to try their luck in
> court.

As the registry does get operated in accordance with policies set 
by the community and the IP address blocks exist as entries in the 
registry, your assertion above is inverted; i.e. you would be the
one seeking appropriate counsel and legal recourse if you believe 
you have rights to the contrary of the policy set by the community.
ARIN performs a legal review on draft policies to see that they 
conform with legal requirements, but you may have innovative beliefs
that you'd like to try to assert (which is why there are courthouses.)

> I read the language in both the proposal and in 2050 to mean that
> resources assigned under the registry's rules are subject to review
> under the registry's rules. The legacy addresses weren't assigned
> under any version of ARIN's rules.

For a more in-depth consideration of this topic, I might suggest 
reviewing this recent article in the ABA Business Law Today on IP 
number transfers -

<http://apps.americanbar.org/buslaw/blt/content/2013/05/article-03-edelman.shtml>

Thanks!
/John

John Curran
President and CEO
ARIN




From jschiller at google.com  Thu May 30 16:36:36 2013
From: jschiller at google.com (Jason Schiller)
Date: Thu, 30 May 2013 16:36:36 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <51A78B87.6020901@quark.net>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
Message-ID: <CAC4yj2VYMVxyDkm-risMkjafa_4=6O9a31davVHkBg4PcCC2+w@mail.gmail.com>

Andrew,

I think there is one very important point that you make that is worth
calling out separately:

Andrew writes:

 JS> RFC-2050 3.1 says:
JS>
JS> "IP addresses are valid as long as the criteria continues to be met."


AD> One might construe this statement to directly invalidate existing
legacy allocations
AD> which would now be in ARIN's policy through this policy.  Others might
be worried
AD> that this opens the door wider to changing policy to retroactively
revoke allocations
AD> or assignments by changing "criteria".   Furthermore, I believe this
idea is already
AD> handled by existing NRPM text and the RSA.

What should we do here?

My goal was to have a "universal section" that documented the principles of
"stewardship"
originally documented in RFC-2050 and be one place people could point to
(instead of RFC-2050
in the event that the stewardship language in 2050 is deprecated).  I know
the definition of
stewardship has evolved, and documented in other places, all based on the
spirit of RFC-2050.

It felt to me like this is a current principle of stewardship.

I am not trying to invent some new restriction on legacy address holders.
 If the community feels
this creates some new ability to revoke legacy allocations, then we should
consider some language
to indicate that is not the case.

If the current RSA / NRPM text documents this principle, then I'd like for
you (or someone) to lift out
that text, and add it to this section.

The goal is to have all the principles in one section, and in the event
that this becomes global, or
adopted in multiple regions, they may lack the text you are thinking of.

So my questions to the community:

1. Does this create some new restriction on legacy address holders?
1A. if yes, should this new restriction be avoided?
       Please provide draft text on what exclusions should apply to  legacy
addresses.

2. Is there already good text in the RSA / NRPM about this principle?
2A. If yes please quote the text.
2B. What text would you lift and include here?  How would you generalize it
into a principle?

Thanks,

__Jason






On Thu, May 30, 2013 at 1:25 PM, Andrew Dul <andrew.dul at quark.net> wrote:

>  Hi Jason,
>
>
> On 5/28/2013 9:04 PM, Jason Schiller wrote:
>
> Andrew thanks for your feed back.
>
>  I want to point out that much of this language comes from either
> RFC-2050 or the current PDP or NRPM.  I tired to change the language as
> little as possible, except where we have commonly agreed on new language
> such as "efficient utilization" instead of conservation.  I thought that
> might be the most uncontroversial starting point.  I am not opposed to
> changing it, especially if it makes the text less controversial.
>
>   I didn't have any of those docs in front of me when reviewing the
> proposal, so I didn't specifically note they were "existing policy text."
> In general, I'm in favor of reusing text where it makes sense.  I will say
> that there probably always is room for improvement, and 2050 is now pretty
> dated so updating the language to be more relevant to today's practices &
> principles is probably a step forward.
>
>
>  ---
>
>  WRT the LIR/ISP I agree, we should adopt whatever we think the standard
> term should be.
>
>  ---
>
>  WRT using number resources instead of IP address space I would have to
> take a careful look and make sure we are not applying principles that make
> sense with respect IP addressing to ASNs if they don't make sense.   It is
> not clear to me if you think these changes should be throughout the text,
> or only in section 0.1.
>
>
> I probably wasn't totally consistent in my initial comments.  Since this
> is "RIR Principles" I believe this policy proposal should refer in general
> to number resources unless the statements directly apply only to a subset
> of Internet number resources.
>
>
>  ---
>
> Andrew writes:
> > I think this section [0.1. Efficient utilization based on need
> (Conservation)]
> > should have an explicit reference to the difference
> > in conservation techniques for IPv4 and IPv6.  A proposed sentence might
> > be something like this... "Conservation goals may vary due to the
> > technical differences between IP number resources pools, for example the
> > relatively limited size of the IPv4 address pool causes a desire to see
> > the number space more highly utilized compared to the vast availability
> > of IP numbers within the IPv6 address pool."
>
> I made a conscious effort to keep this text in section 0.4 for clarity.
>
>  From the draf policy section 0.4:
> "For example, efficient utilization becomes a more prominent issue than
> aggregation as the IPv4 free pool depletes and IPv4 resource availability
> in any transfer market decreases. Conversely, because the IPv6 number space
> is orders of magnitude larger than the IPv4 number space, the scale tips
> away from efficient utilization towards hierarchical aggregation for IPv6
> number resources."
>
>  Does that text fulfill your suggestion of "Conservation goals may vary
> due to the technical differences between IP number resources pools, for
> example the relatively limited size of the IPv4 address pool causes a
> desire to see the number space more highly utilized compared to the vast
> availability of IP numbers within the IPv6 address pool."
>
>  Do you have concerns about where this text is located?
>
>
> I realized later that I inserted similar "IPv4 is different that IPv6"
> into multiple sections, since I thought it applied in unique ways to each
> section.  Perhaps for clarity it should only be in section 0.4 Stewardship,
> since this is the section that talks about balance between different
> elements and goals?  I'm also OK with it being only in one section, but I
> would want it to somehow illuminate specifically that conservation varies
> based on number resource.
>
> Perhaps just add the statement w/o example?  "Conservation goals may vary
> due to the technical differences between IP number resources pools."
>
> Not a showstopper for me, if it isn't in 0.1.
>
> Building on Bill's comments in his notes, I think there might be room
> toward using the term sustainability in these principles.  That term is
> well known in "corporate speak" and might be closer to the RIR's goals &
> principles compared with other words.
>
>   ---
>
>  Andrew writes:
>  > "Utilization rate of address space will be an important factor in
> > justifying need for IP number resources.  However, utilization rates
> > will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
> > number resource pools."
>
>  Again, I made a conscious effort to keep this text in section 0.4 for
> clarity, and would quote the same text.
>
>  Does that meet your concern about your proposed text?
>
>  Do you have concerns about where this text is located?
>
>
> Perhaps just keeping it all in 0.4 is best.
>
>
>
>  Should I repeat the paragraph in 0.1, 0.1.1, and 0.4?
>
>   I wouldn't repeat the paragraph.
>
>   ---
> Andrew writes:
>  >> In order to promote increased usage of Internet number resources,
> >> resource holders will be required to provide an accounting of
> >> resources currently held demonstrating efficient utilization. Internet
> >> number resources are valid as long as the criteria continues to be
> >> met. The transfer of Internet number resources from one party to
> >> another must be approved by the regional registries. The party trying
> >> to obtain the resources must meet the same criteria as if they were
> >> requesting resources directly from the IR.
> >>
> >> All Internet number resource requests are subject to audit and
> >> verification by any means deemed appropriate by the regional registry.
> >>
> >
> > I suspect the above two paragraphs may be lightning rods against the
> > policy proposal.   May I suggest the following single paragraph in lieu
> > of the above two paragraphs.
> >
> > In order meet the Principles and Goals of the Internet Registry System,
> > resource holders may be required from time to time to provide an
> > accounting and current usage of resources currently held.  The RIRs
> > shall set policies to define these accounting mythologies as part of
> > their community driven policy process.
>
>  I'm not sure why you think these two paragraphs are lightening rods.
>
>  RFC-2050 3.3 says:
> "To promote increased usage of address space, the registries will
>   require an accounting of address space previously assigned to the
>   enterprise, if any."
>
>
> I believe including text that says orgs must keep records of how the use
> address space is totally appropriate.  Record keeping doesn't necessarily
> "proposed increased usage" but does provide accountability and transparency
> which I believe should be one of the goals of the registry system.
>
>
>
>  RFC-2050 3.1 says:
>
> "IP addresses are valid as long as the criteria continues to be met."
>
>
> One might construe this statement to directly invalidate existing legacy
> allocations which would now be in ARIN's policy through this policy.
> Others might be worried that this opens the door wider to changing policy
> to retroactively revoke allocations or assignments by changing
> "criteria".   Furthermore, I believe this idea is already handled by
> existing NRPM text and the RSA.
>
>
>   RFC-2050 4.7 says
>
>  "The transfer of IP addresses from one party to another must be
>   approved by the regional registries.  The party trying to obtain
>   the IP address must meet the same criteria as if they were
>   requesting an IP address directly from the IR."
>
>   I believe this "policy" element is best handled in the details section
> of the NRPM rather than the principles section.  ARIN's policies already
> define transfers.  Having a generic "RIRs shall determine IP number
> resources transfer policies through their community drive policy
> development process." might be a good addition to this proposal.
>
>
>   RFC-2050 4.4 says:
> "All IP address requests are subject to audit and verification
>   by any means deemed appropriate by the regional registry."
>
>   I just remember for multiple years discussing policy 2007-14 & others
> when we put into policy existing auditing and review practices.  Since
> ARIN's policies and RSA already talk about audit procedures, I also thought
> this was not necessary.  The language "by any means deemed appropriate by
> the regional registry" is a wide open door that many I believe won't like.
> By using text to say auditing is done by the community through adopted
> policy you limit an RIR's auditing to specifically what the community wants
> the registry to do.
>
>
>  And there is lots of text about conservation in RFC-2050 and
> efficient utilization in the NRPM.
>
>  Can you elaborate on the lightening rod potin?
>
>   See above comments.
>
>   I can only guess you are suggesting that the community wants
> to depart from the principles in RFC-2050, but think you must
> mean something else.
>
>  What am I missing here?
>
>
> Hopefully my comments above illuminate the concerns I had about the text.
> Basically it comes down to "modernizing" the 2050 text/principles, and
> keeping principles in the principles section and not putting specific
> policy in the principles section.
>
>
>
>  Andrew writes:
>  >> 0.2. Hierarchical aggregation (Routability)
> >>
> >> Policies for managing Internet number resources must support
> >> distribution of globally unique Internet addresses in a hierarchical
> >> manner, permitting the routing scalability of the addresses.
>  >
> > Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
> > predominant routing methodology in the future, one would not necessarily
> > expect the goals of the RIRs to change.
> >
> > Suggested change to end of first sentence.
> >
> > ... permitting the routing scalability of the addresses as required by
> > the current technical limitations of global routing protocols.
>
>  I think this change is good even w/o considering LISP.
> Imagine we have new holographic memory that can hold orders of
> magnitude more data and decrease read time
>
>  ---
>
>  Andrew writes:
> >
>  >> 0.3. Uniqueness (Registration)
> >>
> >> c) to ensure that a provider has exhausted a majority of
> >> its current CIDR allocation, thereby justifying an additional
> >> allocation d) to assist in IP allocation studies.
> >
> > Suggested revision for "C"
> >
> > to allow a LIR to demonstrate and disclose reassignment of IP number
> > resources to third-parties
>
>  I think the point is to demonstrate reassignment data to
> demonstrate efficient utilization.
> But I also think that point is covered in section 0.1.1, So the rewrite
> here is ok.
>
>  ---
>
>  Andrew writes:
> > Perhaps add a statement specifically about Stewardship
> >
> > "Stewardship of IP number resources is the balance of overseeing and
> > protecting the interests of all Internet stakeholders to further the
> > development and expansion of the Internet and the Internet Registry
> System."
>
> I do not oppose this text.
>
> Andrew also writes...
> >
> > justified need as a conflicting goal should be explicitly mentioned.
> >
> > "It should be noted that efficient utilization, justified need, and
> >hierarchical aggregation are often conflicting goals."
>
>  I'm not sure this parses correctly...  This sounds to me like there are
>  conflicts between all three:
>
>  efficient utilization vs justified need vs hierarchical aggregation.
>
>  How about:
>  "It should be noted that efficient utilization based on justified need,
> and
> hierarchical aggregation are often conflicting goals."
>
>
>
>  -
>
>
>  On Tue, May 28, 2013 at 2:19 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>
>> I support adding these guiding principles to the NRPM, furthermore I
>> would support efforts to introduce this policy in all RIR regions to
>> make this a global policy.
>>
>> Comments on the proposed text in-line below.
>>
>> Andrew
>>
>> On 5/17/2013 9:53 AM, ARIN wrote:
>> > Draft Policy ARIN-2013-4
>> > RIR Principles
>> >
>> > On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-187
>> > RIR Principles" as a Draft Policy.
>> >
>> > Draft Policy ARIN-2013-4 is below and can be found at:
>> > https://www.arin.net/policy/proposals/2013_4.html
>> >
>> >
>>  > ## * ##
>> >
>> >
>> > Draft Policy ARIN-2013-4
>> > RIR Principles
>> >
>> > Date: 17 May 2013
>> >
>> > Problem Statement:
>> >
>> > The original text in RFC 2050 both "describes the registry system for
>> > the distribution of globally unique Internet address space and
>> > registry operations" and provides "rules and guidelines [principles]
>> > governing the distribution of this address space."
>> >
>> > The currently proposed update (RFC2050bis) "provides information about
>> > the current Internet Numbers Registry System used in the distribution
>> > of globally unique Internet Protocol (IP) address space and autonomous
>> > system (AS) numbers" and "provides information about the processes for
>> > further evolution of the Internet Numbers Registry System."
>> >
>> > This means that the guiding principles of stewardship are not
>> > currently being carried forward into the new document. The goals of
>> > Conservation (efficient utilization based on need), Routability
>> > (hierarchical aggregation), and Registration (uniqueness) are as
>> > important, if not more so, now that the transition to IPv6 is upon us.
>> > This can be rectified by documenting these principles in RIR policy.
>> >
>> > Policy Statement:
>> >
>> > Section 0: Principles and Goals of the Internet Registry System
>> >
>> > 0.1. Efficient utilization based on need (Conservation)
>> >
>> > Policies for managing Internet number resources must support 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. The registry should
>> > prevent stockpiling in order to maximize the conservation and
>> > efficient utilization of the Internet address space.
>>
>>  This section should use the new proposed convention of "LIR/ISP" as
>> being developed in ARIN-2013-5.
>>
>> s/this address space/IP number resources/r
>> s/Internet address space/IP number resources/r
>>
>> I think this section should have an explicit reference to the difference
>> in conservation techniques for IPv4 and IPv6.  A proposed sentence might
>> be something like this... "Conservation goals may vary due to the
>> technical differences between IP number resources pools, for example the
>> relatively limited size of the IPv4 address pool causes a desire to see
>> the number space more highly utilized compared to the vast availability
>> of IP numbers within the IPv6 address pool."
>>
>> >
>> > 0.1.1. Documented Justified Need (Needs Based)
>> >
>> > Assignment of Internet number resources is based on documented
>> > operational need. Utilization rate of address space will be a key
>> > factor in number resource assignment. To this end, registrants should
>> > have documented justified need available for each assignment.
>> > Organizations will be assigned resources based on immediate
>> > utilization plus expected utilization.
>>
>>  Utilization rate is much more important for IPv4 than IPv6.
>>
>> Suggested revision for "Utilization rate of address space will be a key
>> factor in number resource assignment."
>>
>>  "Utilization rate of address space will be an important factor in
>> justifying need for IP number resources.  However, utilization rates
>> will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
>> number resource pools."
>>
>> >
>> > In order to promote increased usage of Internet number resources,
>> > resource holders will be required to provide an accounting of
>> > resources currently held demonstrating efficient utilization. Internet
>> > number resources are valid as long as the criteria continues to be
>> > met. The transfer of Internet number resources from one party to
>> > another must be approved by the regional registries. The party trying
>> > to obtain the resources must meet the same criteria as if they were
>> > requesting resources directly from the IR.
>> >
>> > All Internet number resource requests are subject to audit and
>> > verification by any means deemed appropriate by the regional registry.
>> >
>>
>>  I suspect the above two paragraphs may be lightning rods against the
>> policy proposal.   May I suggest the following single paragraph in lieu
>> of the above two paragraphs.
>>
>> In order meet the Principles and Goals of the Internet Registry System,
>> resource holders may be required from time to time to provide an
>> accounting and current usage of resources currently held.  The RIRs
>> shall set policies to define these accounting mythologies as part of
>> their community driven policy process.
>>
>>
>> > 0.2. Hierarchical aggregation (Routability)
>> >
>> > Policies for managing Internet number resources must support
>> > distribution of globally unique Internet addresses in a hierarchical
>> > manner, permitting the routing scalability of the addresses. This
>> > scalability is necessary to ensure proper operation of Internet
>> > routing, although it must be stressed that routability is in no way
>> > guaranteed with the allocation or assignment of IPv4 addresses.
>> >
>>
>>  Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
>> predominant routing methodology in the future, one would not necessarily
>> expect the goals of the RIRs to change.
>>
>> Suggested change to end of first sentence.
>>
>> ... permitting the routing scalability of the addresses as required by
>> the current technical limitations of global routing protocols.
>>
>> > 0.3. Uniqueness (Registration)
>> >
>> > Provision of a public registry documenting Internet number resource
>> > allocation, reallocation, assignment, and reassignment is necessary to:
>> >
>> > a) ensure uniqueness and to to provide operational staff with
>> > information on who is using the number resource b) to provide a
>> > contact in case of operational/security problems (e.g. Law
>> > Enforcement) c) to ensure that a provider has exhausted a majority of
>> > its current CIDR allocation, thereby justifying an additional
>> > allocation d) to assist in IP allocation studies.
>>
>>  Suggested revision for "C"
>>
>> to allow a LIR to demonstrate and disclose reassignment of IP number
>> resources to third-parties
>>
>> >
>> > It is imperative that reassignment information be submitted in a
>> > prompt and efficient manner to facilitate database maintenance and
>> > ensure database integrity.
>> >
>> > 0.4. Stewardship
>> >
>> > It should be noted that efficient utilization and hierarchical
>> > aggregation are often conflicting goals. All the above goals may
>> > sometimes be in conflict with the interests of individual end-users or
>> > Internet Service Providers. Care must be taken to ensure balance with
>> > these conflicting goals given the resource availability, relative size
>> > of the resource, and number resource specific technical dynamics, for
>> > each type of number resource. For example, efficient utilization
>> > becomes a more prominent issue than aggregation as the IPv4 free pool
>> > depletes and IPv4 resource availability in any transfer market
>> > decreases. Conversely, because the IPv6 number space is orders of
>> > magnitude larger than the IPv4 number space, the scale tips away from
>> > efficient utilization towards hierarchical aggregation for IPv6 number
>> > resources.
>>
>>  Perhaps add a statement specifically about Stewardship
>>
>> "Stewardship of IP number resources is the balance of overseeing and
>> protecting the interests of all Internet stakeholders to further the
>> development and expansion of the Internet and the Internet Registry
>> System."
>>
>> Also...
>>
>> justified need as a conflicting goal should be explicitly mentioned.
>>
>> "It should be noted that efficient utilization, justified need, and
>> hierarchical aggregation are often conflicting goals."
>>
>>  Use the new LIR/ISP convention instead of "Internet Service Providers"
>>
>>
>>
>> >
>> > Comments:
>> >
>> > a. Timetable for implementation: immediately
>> >
>> > b. I believe that it would be beneficial for IANA to adopt these
>> > principles as well, and encourage the community to consider a global
>> > policy proposal.
>> > _______________________________________________
>> > PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > Unsubscribe or manage 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.
>>
>
>
>
>  --
>  _______________________________________________________
>  Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>
>
>


-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130530/e77a8b59/attachment.htm>

From bill at herrin.us  Thu May 30 16:37:58 2013
From: bill at herrin.us (William Herrin)
Date: Thu, 30 May 2013 16:37:58 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
	<CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
Message-ID: <CAP-guGWnAxYEwFD0ML4gRaPxRshZiWpcCRR_JKKfQfiDFBqsFQ@mail.gmail.com>

On Thu, May 30, 2013 at 3:15 PM, John Curran <jcurran at arin.net> wrote:
> you would be the
> one seeking appropriate counsel and legal recourse if you believe
> you have rights to the contrary of the policy set by the community.
> ARIN performs a legal review on draft policies to see that they
> conform with legal requirements, but you may have innovative beliefs
> that you'd like to try to assert (which is why there are courthouses.)

Hi John,

Were ARIN ever to attempt meaningful alteration of my legacy address
registration without my consent it would find itself responding in
court, regardless of any alleged basis in policy for that action. I
doubt I'd be the only one to see you there.

Now that we agree on that, can we get back to discussing policy
principles that apply to the future of ARIN's practices rather than to
its past?


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 gary.buhrmaster at gmail.com  Thu May 30 17:22:24 2013
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Thu, 30 May 2013 21:22:24 +0000
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAP-guGWnAxYEwFD0ML4gRaPxRshZiWpcCRR_JKKfQfiDFBqsFQ@mail.gmail.com>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
	<CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
	<CAP-guGWnAxYEwFD0ML4gRaPxRshZiWpcCRR_JKKfQfiDFBqsFQ@mail.gmail.com>
Message-ID: <CAMfXtQzWjxycEPWW1Tas54xpcR_q-h=MpF8bQ4jD5_4H-+o29w@mail.gmail.com>

On Thu, May 30, 2013 at 8:37 PM, William Herrin <bill at herrin.us> wrote:
.....
> Were ARIN ever to attempt meaningful alteration of my legacy address
> registration without my consent it would find itself responding in
> court, regardless of any alleged basis in policy for that action. I
> doubt I'd be the only one to see you there.

I am sure that any policy change that resulted in "meaningful"
alteration of legacy registration would be the equivalent of the
nuclear option, and the fallout would be highly toxic to
someone (and likely everyone).

I know that I am a firm believer that the community will be
better off if we can maintain the principals of good
stewardship without heading to court (where the only
winners are the lawyers :-).

Gary


From jcurran at arin.net  Thu May 30 18:07:07 2013
From: jcurran at arin.net (John Curran)
Date: Thu, 30 May 2013 22:07:07 +0000
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAMfXtQzWjxycEPWW1Tas54xpcR_q-h=MpF8bQ4jD5_4H-+o29w@mail.gmail.com>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
	<CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
	<CAP-guGWnAxYEwFD0ML4gRaPxRshZiWpcCRR_JKKfQfiDFBqsFQ@mail.gmail.com>
	<CAMfXtQzWjxycEPWW1Tas54xpcR_q-h=MpF8bQ4jD5_4H-+o29w@mail.gmail.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B374E70526FF@CHAXCH01.corp.arin.net>

On May 30, 2013, at 5:22 PM, Gary Buhrmaster <gary.buhrmaster at gmail.com> wrote:

> On Thu, May 30, 2013 at 8:37 PM, William Herrin <bill at herrin.us> wrote:
> .....
>> Were ARIN ever to attempt meaningful alteration of my legacy address
>> registration without my consent it would find itself responding in
>> court, regardless of any alleged basis in policy for that action. I
>> doubt I'd be the only one to see you there.
> 
> I am sure that any policy change that resulted in "meaningful"
> alteration of legacy registration would be the equivalent of the
> nuclear option, and the fallout would be highly toxic to
> someone (and likely everyone).

Gary - 
 
  I imagine that very much depends on what one considers "meaningful";
  for example, the community decided that having an abuse contact on 
  each resource record was appropriate, and all resources in the registry
  were updated accordingly.  I do not know what future generations of
  Internet operators will require of the Internet numbers registry, 
  but it certainly could involve more "meaningful" changes if that 
  is what is adopted.

  On the particular language which raised this issue ("IP addresses are 
  valid as long as the criteria continues to be met"), the most likely
  change that would be anticipated by insertation of that into ARIN 
  policy would be potential "lack of validity", and it is probably fairly 
  important for the community to fully outline its expectations there,
  as could easily be a significant change compared to present operations 
  and may be preempted by ARIN's RSA/LRSA terms and conditions if it 
  involves ARIN taking action due to lack of utilization of number 
  resources.

FYI,
/John

John Curran
President and CEO
ARIN



From narten at us.ibm.com  Fri May 31 00:53:02 2013
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 31 May 2013 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201305310453.r4V4r3O2003500@rotala.raleigh.ibm.com>

Total of 17 messages in the last 7 days.
 
script run at: Fri May 31 00:53:02 EDT 2013
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 17.65% |    3 | 45.76% |   151925 | jschiller at google.com
 29.41% |    5 | 10.83% |    35957 | bill at herrin.us
 11.76% |    2 | 27.77% |    92214 | andrew.dul at quark.net
 11.76% |    2 |  4.14% |    13762 | jcurran at arin.net
  5.88% |    1 |  2.82% |     9356 | cgrundemann at gmail.com
  5.88% |    1 |  2.49% |     8270 | owen at delong.com
  5.88% |    1 |  2.38% |     7906 | info at arin.net
  5.88% |    1 |  1.94% |     6425 | narten at us.ibm.com
  5.88% |    1 |  1.87% |     6207 | gary.buhrmaster at gmail.com
--------+------+--------+----------+------------------------
100.00% |   17 |100.00% |   332022 | Total



From jschiller at google.com  Fri May 31 01:47:18 2013
From: jschiller at google.com (Jason Schiller)
Date: Fri, 31 May 2013 01:47:18 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <8DA1853CE466B041B104C1CAEE00B374E70526FF@CHAXCH01.corp.arin.net>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
	<CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
	<CAP-guGWnAxYEwFD0ML4gRaPxRshZiWpcCRR_JKKfQfiDFBqsFQ@mail.gmail.com>
	<CAMfXtQzWjxycEPWW1Tas54xpcR_q-h=MpF8bQ4jD5_4H-+o29w@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70526FF@CHAXCH01.corp.arin.net>
Message-ID: <CAC4yj2UCuhx66ofsh09=WoRj65SrqrAu2Lk+hRzyxRfVjNU+HA@mail.gmail.com>

John,

Reading your respons brings to mind a general question.

You said "the most likely change that would be anticipated
by insertation of that into ARIN policy would be ..."

In this and other cases the "that" is RFC-2050 text.

Shouldn't the text of RFC-2050 already impact ARIN policy?

(Assuming no translational issues, out of context, etc)
why would the impact differ when the text is in RFC-2050,
or in the NRPM?

(I'm not debating there is value in community being more clear
in outlining its expectations and impact on operations. I think
that point is true if this text is added to the NRPM and while this
text remains in RFC-2050.

We certainly can improve on the 2050 text, but I was trying to avoid
any updates that may be controversial, and was more interesting in
preserving the principles in 2050 in the first go around. )

__Jason

On Thu, May 30, 2013 at 6:07 PM, John Curran <jcurran at arin.net> wrote:

> On May 30, 2013, at 5:22 PM, Gary Buhrmaster <gary.buhrmaster at gmail.com>
> wrote:
>
> > On Thu, May 30, 2013 at 8:37 PM, William Herrin <bill at herrin.us> wrote:
> > .....
> >> Were ARIN ever to attempt meaningful alteration of my legacy address
> >> registration without my consent it would find itself responding in
> >> court, regardless of any alleged basis in policy for that action. I
> >> doubt I'd be the only one to see you there.
> >
> > I am sure that any policy change that resulted in "meaningful"
> > alteration of legacy registration would be the equivalent of the
> > nuclear option, and the fallout would be highly toxic to
> > someone (and likely everyone).
>
> Gary -
>
>   I imagine that very much depends on what one considers "meaningful";
>   for example, the community decided that having an abuse contact on
>   each resource record was appropriate, and all resources in the registry
>   were updated accordingly.  I do not know what future generations of
>   Internet operators will require of the Internet numbers registry,
>   but it certainly could involve more "meaningful" changes if that
>   is what is adopted.
>
>   On the particular language which raised this issue ("IP addresses are
>   valid as long as the criteria continues to be met"), the most likely
>   change that would be anticipated by insertation of that into ARIN
>   policy would be potential "lack of validity", and it is probably fairly
>   important for the community to fully outline its expectations there,
>   as could easily be a significant change compared to present operations
>   and may be preempted by ARIN's RSA/LRSA terms and conditions if it
>   involves ARIN taking action due to lack of utilization of number
>   resources.
>
> 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.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130531/053df8aa/attachment.htm>

From jschiller at google.com  Fri May 31 01:18:25 2013
From: jschiller at google.com (Jason Schiller)
Date: Fri, 31 May 2013 01:18:25 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <51A78B87.6020901@quark.net>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
Message-ID: <CAC4yj2XMe-kecYXb5_t48VdtmhVVjDkpaM0tEjyh2O8SH8c8zA@mail.gmail.com>

Andrew,

(Putting aside the RFC-2050 3.1 - does this create a new ability to revoke
legacy IPs for the other thread)

Your comments boil down to:

1. it comes down to "modernizing" the 2050 text/principles
2. keeping principles in the principles section and not putting specific
policy in the principles section.

In general I agree with both.

I tried to start with 2050 text/principles, and only attempted to go beyond
that text where it helped,
e.g. such as substituting "efficient use" for conservation (nobody uses
conservation) but still paying
homage to the conservation section that this principle stems from.

It is possible that some of the language from 2050 is to detailed or
"policy specific" and should be
stripped away and moved into other more relevant sections of the NRPM.
 This may be a bit tricky to
do in separate proposals as you want both things to happen.

I propose we ether initially adopt, then decide if certain details should
be moved elsewhere, or
figure out which specific details should be moved where,and include them in
this proposal (or both).

But just because there already is a detailed section on say transfers,
doesn't mean it shouldn't also
be included in the principles section that

"The transfer of Internet number resources from one party to another must
be approved by the regional
  registries. The party trying to obtain the resources must meet the same
criteria as if they were
  requesting resources directly from the IR."

One could image that the ARIN community decides that there should be no
transfers, and all
redistribution of addresses should be through return to IANA and split
equally among the RIRs.
In this case the ARIN community could abolish the text on transfers.
 Would we then loose the
principle that if a transfer was to happen (say a new transfer policy in
the future) it should be
governed by the same principles of getting address space directly from the
RIRs?

Specific text changes:

1. number resources

I agree we should try to use number resources as much as possible where it
makes sense.
I'm not sure who owns the text at this point, I think maybe the AC.  They
should look very
carefully at each use of IP address and see if number resource can
be substituted without
creating some strage IP address specific restriction on ASNs.

2.  IPv4/IPv6 protocol differences

I am not opposed to adding "Conservation goals may vary due to the
technical differences
between IP number resources pools."  to section 0.4 just after to
the sentence "Care must be taken
to ensure balance with these conflicting goals given the resource
availability, relative size of the
resource, and number resource specific technical dynamics, for each type of
number resource."

I felt like that was covered under "relative size of the resource, and
number resource specific
technical dynamics", and the following examples of how the balance shifts
directly illustrates that.
But if it is not clear enough, the additional text you recommend will be
helpful.

3. sustainability

I'm happy to accept some text on this... but I'm not exactly sure what it
is..

4. documentation to promote increased utilization

So I think there are a number of reasons accurate documentation is
important,
and I think one of them is so that the RIR can measure utilization and
judge
current usage prior to deciding to give additional space.  This process
causes
more efficient utilization over all.

I think this aspect is important, and should be included.  It is possible
the some
word smithing may be in order.

"Resource holders will be required to provide an accounting of resources
currently held
in order to provide the necessary transparency and accountability.  This
information provides
IRs the ability to measure efficient utilization of current space prior to
allocating or assigning
additional space."

5. transfers

I agree, the details of transfer policy should be in the "main" portion of
the NRPM, and already is,
and that is where the details of transfers should be documented.

But I also think RFC-2050 gives us some high level guiding principles wrt
transfers:
A. RIRs must approve
B. must be consistent with the criteria as if they were requesting an IP
address directly

I think these principles should be included.

I am not opposed to the text "RIRs shall determine IP number resources
transfer policies through
their community driven policy development process."  In fact all policies
(except emergency ones)
are determined by the community through the PDP...but I'm not sure that
changes anything.

6. audit

I think some guiding principle text is important here.   This text was
lifter from RFC-2050.
Again, not intending to create new capabilities here, but think this
principle (in some form is important)


If the community thinks it is superseded by text in the NRPM and RSA, I am
happy to use that text as
a basis for pulling out some high-level principles.

Is there RSA or NRPM text that is high level enough to use here?  How would
you propose to create
high level principles from the RSA and NRPM text?

___Jason






On Thu, May 30, 2013 at 1:25 PM, Andrew Dul <andrew.dul at quark.net> wrote:

>  Hi Jason,
>
>
> On 5/28/2013 9:04 PM, Jason Schiller wrote:
>
> Andrew thanks for your feed back.
>
>  I want to point out that much of this language comes from either
> RFC-2050 or the current PDP or NRPM.  I tired to change the language as
> little as possible, except where we have commonly agreed on new language
> such as "efficient utilization" instead of conservation.  I thought that
> might be the most uncontroversial starting point.  I am not opposed to
> changing it, especially if it makes the text less controversial.
>
>   I didn't have any of those docs in front of me when reviewing the
> proposal, so I didn't specifically note they were "existing policy text."
> In general, I'm in favor of reusing text where it makes sense.  I will say
> that there probably always is room for improvement, and 2050 is now pretty
> dated so updating the language to be more relevant to today's practices &
> principles is probably a step forward.
>
>
>  ---
>
>  WRT the LIR/ISP I agree, we should adopt whatever we think the standard
> term should be.
>
>  ---
>
>  WRT using number resources instead of IP address space I would have to
> take a careful look and make sure we are not applying principles that make
> sense with respect IP addressing to ASNs if they don't make sense.   It is
> not clear to me if you think these changes should be throughout the text,
> or only in section 0.1.
>
>
> I probably wasn't totally consistent in my initial comments.  Since this
> is "RIR Principles" I believe this policy proposal should refer in general
> to number resources unless the statements directly apply only to a subset
> of Internet number resources.
>
>
>  ---
>
> Andrew writes:
> > I think this section [0.1. Efficient utilization based on need
> (Conservation)]
> > should have an explicit reference to the difference
> > in conservation techniques for IPv4 and IPv6.  A proposed sentence might
> > be something like this... "Conservation goals may vary due to the
> > technical differences between IP number resources pools, for example the
> > relatively limited size of the IPv4 address pool causes a desire to see
> > the number space more highly utilized compared to the vast availability
> > of IP numbers within the IPv6 address pool."
>
> I made a conscious effort to keep this text in section 0.4 for clarity.
>
>  From the draf policy section 0.4:
> "For example, efficient utilization becomes a more prominent issue than
> aggregation as the IPv4 free pool depletes and IPv4 resource availability
> in any transfer market decreases. Conversely, because the IPv6 number space
> is orders of magnitude larger than the IPv4 number space, the scale tips
> away from efficient utilization towards hierarchical aggregation for IPv6
> number resources."
>
>  Does that text fulfill your suggestion of "Conservation goals may vary
> due to the technical differences between IP number resources pools, for
> example the relatively limited size of the IPv4 address pool causes a
> desire to see the number space more highly utilized compared to the vast
> availability of IP numbers within the IPv6 address pool."
>
>  Do you have concerns about where this text is located?
>
>
> I realized later that I inserted similar "IPv4 is different that IPv6"
> into multiple sections, since I thought it applied in unique ways to each
> section.  Perhaps for clarity it should only be in section 0.4 Stewardship,
> since this is the section that talks about balance between different
> elements and goals?  I'm also OK with it being only in one section, but I
> would want it to somehow illuminate specifically that conservation varies
> based on number resource.
>
> Perhaps just add the statement w/o example?  "Conservation goals may vary
> due to the technical differences between IP number resources pools."
>
> Not a showstopper for me, if it isn't in 0.1.
>
> Building on Bill's comments in his notes, I think there might be room
> toward using the term sustainability in these principles.  That term is
> well known in "corporate speak" and might be closer to the RIR's goals &
> principles compared with other words.
>
>   ---
>
>  Andrew writes:
>  > "Utilization rate of address space will be an important factor in
> > justifying need for IP number resources.  However, utilization rates
> > will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
> > number resource pools."
>
>  Again, I made a conscious effort to keep this text in section 0.4 for
> clarity, and would quote the same text.
>
>  Does that meet your concern about your proposed text?
>
>  Do you have concerns about where this text is located?
>
>
> Perhaps just keeping it all in 0.4 is best.
>
>
>
>  Should I repeat the paragraph in 0.1, 0.1.1, and 0.4?
>
>   I wouldn't repeat the paragraph.
>
>   ---
> Andrew writes:
>  >> In order to promote increased usage of Internet number resources,
> >> resource holders will be required to provide an accounting of
> >> resources currently held demonstrating efficient utilization. Internet
> >> number resources are valid as long as the criteria continues to be
> >> met. The transfer of Internet number resources from one party to
> >> another must be approved by the regional registries. The party trying
> >> to obtain the resources must meet the same criteria as if they were
> >> requesting resources directly from the IR.
> >>
> >> All Internet number resource requests are subject to audit and
> >> verification by any means deemed appropriate by the regional registry.
> >>
> >
> > I suspect the above two paragraphs may be lightning rods against the
> > policy proposal.   May I suggest the following single paragraph in lieu
> > of the above two paragraphs.
> >
> > In order meet the Principles and Goals of the Internet Registry System,
> > resource holders may be required from time to time to provide an
> > accounting and current usage of resources currently held.  The RIRs
> > shall set policies to define these accounting mythologies as part of
> > their community driven policy process.
>
>  I'm not sure why you think these two paragraphs are lightening rods.
>
>  RFC-2050 3.3 says:
> "To promote increased usage of address space, the registries will
>   require an accounting of address space previously assigned to the
>   enterprise, if any."
>
>
> I believe including text that says orgs must keep records of how the use
> address space is totally appropriate.  Record keeping doesn't necessarily
> "proposed increased usage" but does provide accountability and transparency
> which I believe should be one of the goals of the registry system.
>
>
>
>  RFC-2050 3.1 says:
>
> "IP addresses are valid as long as the criteria continues to be met."
>
>
> One might construe this statement to directly invalidate existing legacy
> allocations which would now be in ARIN's policy through this policy.
> Others might be worried that this opens the door wider to changing policy
> to retroactively revoke allocations or assignments by changing
> "criteria".   Furthermore, I believe this idea is already handled by
> existing NRPM text and the RSA.
>
>
>   RFC-2050 4.7 says
>
>  "The transfer of IP addresses from one party to another must be
>   approved by the regional registries.  The party trying to obtain
>   the IP address must meet the same criteria as if they were
>   requesting an IP address directly from the IR."
>
>   I believe this "policy" element is best handled in the details section
> of the NRPM rather than the principles section.  ARIN's policies already
> define transfers.  Having a generic "RIRs shall determine IP number
> resources transfer policies through their community drive policy
> development process." might be a good addition to this proposal.
>
>
>   RFC-2050 4.4 says:
> "All IP address requests are subject to audit and verification
>   by any means deemed appropriate by the regional registry."
>
>   I just remember for multiple years discussing policy 2007-14 & others
> when we put into policy existing auditing and review practices.  Since
> ARIN's policies and RSA already talk about audit procedures, I also thought
> this was not necessary.  The language "by any means deemed appropriate by
> the regional registry" is a wide open door that many I believe won't like.
> By using text to say auditing is done by the community through adopted
> policy you limit an RIR's auditing to specifically what the community wants
> the registry to do.
>
>
>  And there is lots of text about conservation in RFC-2050 and
> efficient utilization in the NRPM.
>
>  Can you elaborate on the lightening rod potin?
>
>   See above comments.
>
>   I can only guess you are suggesting that the community wants
> to depart from the principles in RFC-2050, but think you must
> mean something else.
>
>  What am I missing here?
>
>
> Hopefully my comments above illuminate the concerns I had about the text.
> Basically it comes down to "modernizing" the 2050 text/principles, and
> keeping principles in the principles section and not putting specific
> policy in the principles section.
>
>
>
>  Andrew writes:
>  >> 0.2. Hierarchical aggregation (Routability)
> >>
> >> Policies for managing Internet number resources must support
> >> distribution of globally unique Internet addresses in a hierarchical
> >> manner, permitting the routing scalability of the addresses.
>  >
> > Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
> > predominant routing methodology in the future, one would not necessarily
> > expect the goals of the RIRs to change.
> >
> > Suggested change to end of first sentence.
> >
> > ... permitting the routing scalability of the addresses as required by
> > the current technical limitations of global routing protocols.
>
>  I think this change is good even w/o considering LISP.
> Imagine we have new holographic memory that can hold orders of
> magnitude more data and decrease read time
>
>  ---
>
>  Andrew writes:
> >
>  >> 0.3. Uniqueness (Registration)
> >>
> >> c) to ensure that a provider has exhausted a majority of
> >> its current CIDR allocation, thereby justifying an additional
> >> allocation d) to assist in IP allocation studies.
> >
> > Suggested revision for "C"
> >
> > to allow a LIR to demonstrate and disclose reassignment of IP number
> > resources to third-parties
>
>  I think the point is to demonstrate reassignment data to
> demonstrate efficient utilization.
> But I also think that point is covered in section 0.1.1, So the rewrite
> here is ok.
>
>  ---
>
>  Andrew writes:
> > Perhaps add a statement specifically about Stewardship
> >
> > "Stewardship of IP number resources is the balance of overseeing and
> > protecting the interests of all Internet stakeholders to further the
> > development and expansion of the Internet and the Internet Registry
> System."
>
> I do not oppose this text.
>
> Andrew also writes...
> >
> > justified need as a conflicting goal should be explicitly mentioned.
> >
> > "It should be noted that efficient utilization, justified need, and
> >hierarchical aggregation are often conflicting goals."
>
>  I'm not sure this parses correctly...  This sounds to me like there are
>  conflicts between all three:
>
>  efficient utilization vs justified need vs hierarchical aggregation.
>
>  How about:
>  "It should be noted that efficient utilization based on justified need,
> and
> hierarchical aggregation are often conflicting goals."
>
>
>
>  -
>
>
>  On Tue, May 28, 2013 at 2:19 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>
>> I support adding these guiding principles to the NRPM, furthermore I
>> would support efforts to introduce this policy in all RIR regions to
>> make this a global policy.
>>
>> Comments on the proposed text in-line below.
>>
>> Andrew
>>
>> On 5/17/2013 9:53 AM, ARIN wrote:
>> > Draft Policy ARIN-2013-4
>> > RIR Principles
>> >
>> > On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-187
>> > RIR Principles" as a Draft Policy.
>> >
>> > Draft Policy ARIN-2013-4 is below and can be found at:
>> > https://www.arin.net/policy/proposals/2013_4.html
>> >
>> >
>>  > ## * ##
>> >
>> >
>> > Draft Policy ARIN-2013-4
>> > RIR Principles
>> >
>> > Date: 17 May 2013
>> >
>> > Problem Statement:
>> >
>> > The original text in RFC 2050 both "describes the registry system for
>> > the distribution of globally unique Internet address space and
>> > registry operations" and provides "rules and guidelines [principles]
>> > governing the distribution of this address space."
>> >
>> > The currently proposed update (RFC2050bis) "provides information about
>> > the current Internet Numbers Registry System used in the distribution
>> > of globally unique Internet Protocol (IP) address space and autonomous
>> > system (AS) numbers" and "provides information about the processes for
>> > further evolution of the Internet Numbers Registry System."
>> >
>> > This means that the guiding principles of stewardship are not
>> > currently being carried forward into the new document. The goals of
>> > Conservation (efficient utilization based on need), Routability
>> > (hierarchical aggregation), and Registration (uniqueness) are as
>> > important, if not more so, now that the transition to IPv6 is upon us.
>> > This can be rectified by documenting these principles in RIR policy.
>> >
>> > Policy Statement:
>> >
>> > Section 0: Principles and Goals of the Internet Registry System
>> >
>> > 0.1. Efficient utilization based on need (Conservation)
>> >
>> > Policies for managing Internet number resources must support 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. The registry should
>> > prevent stockpiling in order to maximize the conservation and
>> > efficient utilization of the Internet address space.
>>
>>  This section should use the new proposed convention of "LIR/ISP" as
>> being developed in ARIN-2013-5.
>>
>> s/this address space/IP number resources/r
>> s/Internet address space/IP number resources/r
>>
>> I think this section should have an explicit reference to the difference
>> in conservation techniques for IPv4 and IPv6.  A proposed sentence might
>> be something like this... "Conservation goals may vary due to the
>> technical differences between IP number resources pools, for example the
>> relatively limited size of the IPv4 address pool causes a desire to see
>> the number space more highly utilized compared to the vast availability
>> of IP numbers within the IPv6 address pool."
>>
>> >
>> > 0.1.1. Documented Justified Need (Needs Based)
>> >
>> > Assignment of Internet number resources is based on documented
>> > operational need. Utilization rate of address space will be a key
>> > factor in number resource assignment. To this end, registrants should
>> > have documented justified need available for each assignment.
>> > Organizations will be assigned resources based on immediate
>> > utilization plus expected utilization.
>>
>>  Utilization rate is much more important for IPv4 than IPv6.
>>
>> Suggested revision for "Utilization rate of address space will be a key
>> factor in number resource assignment."
>>
>>  "Utilization rate of address space will be an important factor in
>> justifying need for IP number resources.  However, utilization rates
>> will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
>> number resource pools."
>>
>> >
>> > In order to promote increased usage of Internet number resources,
>> > resource holders will be required to provide an accounting of
>> > resources currently held demonstrating efficient utilization. Internet
>> > number resources are valid as long as the criteria continues to be
>> > met. The transfer of Internet number resources from one party to
>> > another must be approved by the regional registries. The party trying
>> > to obtain the resources must meet the same criteria as if they were
>> > requesting resources directly from the IR.
>> >
>> > All Internet number resource requests are subject to audit and
>> > verification by any means deemed appropriate by the regional registry.
>> >
>>
>>  I suspect the above two paragraphs may be lightning rods against the
>> policy proposal.   May I suggest the following single paragraph in lieu
>> of the above two paragraphs.
>>
>> In order meet the Principles and Goals of the Internet Registry System,
>> resource holders may be required from time to time to provide an
>> accounting and current usage of resources currently held.  The RIRs
>> shall set policies to define these accounting mythologies as part of
>> their community driven policy process.
>>
>>
>> > 0.2. Hierarchical aggregation (Routability)
>> >
>> > Policies for managing Internet number resources must support
>> > distribution of globally unique Internet addresses in a hierarchical
>> > manner, permitting the routing scalability of the addresses. This
>> > scalability is necessary to ensure proper operation of Internet
>> > routing, although it must be stressed that routability is in no way
>> > guaranteed with the allocation or assignment of IPv4 addresses.
>> >
>>
>>  Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
>> predominant routing methodology in the future, one would not necessarily
>> expect the goals of the RIRs to change.
>>
>> Suggested change to end of first sentence.
>>
>> ... permitting the routing scalability of the addresses as required by
>> the current technical limitations of global routing protocols.
>>
>> > 0.3. Uniqueness (Registration)
>> >
>> > Provision of a public registry documenting Internet number resource
>> > allocation, reallocation, assignment, and reassignment is necessary to:
>> >
>> > a) ensure uniqueness and to to provide operational staff with
>> > information on who is using the number resource b) to provide a
>> > contact in case of operational/security problems (e.g. Law
>> > Enforcement) c) to ensure that a provider has exhausted a majority of
>> > its current CIDR allocation, thereby justifying an additional
>> > allocation d) to assist in IP allocation studies.
>>
>>  Suggested revision for "C"
>>
>> to allow a LIR to demonstrate and disclose reassignment of IP number
>> resources to third-parties
>>
>> >
>> > It is imperative that reassignment information be submitted in a
>> > prompt and efficient manner to facilitate database maintenance and
>> > ensure database integrity.
>> >
>> > 0.4. Stewardship
>> >
>> > It should be noted that efficient utilization and hierarchical
>> > aggregation are often conflicting goals. All the above goals may
>> > sometimes be in conflict with the interests of individual end-users or
>> > Internet Service Providers. Care must be taken to ensure balance with
>> > these conflicting goals given the resource availability, relative size
>> > of the resource, and number resource specific technical dynamics, for
>> > each type of number resource. For example, efficient utilization
>> > becomes a more prominent issue than aggregation as the IPv4 free pool
>> > depletes and IPv4 resource availability in any transfer market
>> > decreases. Conversely, because the IPv6 number space is orders of
>> > magnitude larger than the IPv4 number space, the scale tips away from
>> > efficient utilization towards hierarchical aggregation for IPv6 number
>> > resources.
>>
>>  Perhaps add a statement specifically about Stewardship
>>
>> "Stewardship of IP number resources is the balance of overseeing and
>> protecting the interests of all Internet stakeholders to further the
>> development and expansion of the Internet and the Internet Registry
>> System."
>>
>> Also...
>>
>> justified need as a conflicting goal should be explicitly mentioned.
>>
>> "It should be noted that efficient utilization, justified need, and
>> hierarchical aggregation are often conflicting goals."
>>
>>  Use the new LIR/ISP convention instead of "Internet Service Providers"
>>
>>
>>
>> >
>> > Comments:
>> >
>> > a. Timetable for implementation: immediately
>> >
>> > b. I believe that it would be beneficial for IANA to adopt these
>> > principles as well, and encourage the community to consider a global
>> > policy proposal.
>> > _______________________________________________
>> > PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > Unsubscribe or manage 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.
>>
>
>
>
>  --
>  _______________________________________________________
>  Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>
>
>


-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130531/7a7d1c82/attachment.htm>

From jcurran at arin.net  Fri May 31 06:54:43 2013
From: jcurran at arin.net (John Curran)
Date: Fri, 31 May 2013 10:54:43 +0000
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAC4yj2UCuhx66ofsh09=WoRj65SrqrAu2Lk+hRzyxRfVjNU+HA@mail.gmail.com>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
	<CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
	<CAP-guGWnAxYEwFD0ML4gRaPxRshZiWpcCRR_JKKfQfiDFBqsFQ@mail.gmail.com>
	<CAMfXtQzWjxycEPWW1Tas54xpcR_q-h=MpF8bQ4jD5_4H-+o29w@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70526FF@CHAXCH01.corp.arin.net>
	<CAC4yj2UCuhx66ofsh09=WoRj65SrqrAu2Lk+hRzyxRfVjNU+HA@mail.gmail.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B374E70582F3@CHAXCH01.corp.arin.net>

On May 31, 2013, at 1:47 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>>
 wrote:

John,

Reading your respons brings to mind a general question.

You said "the most likely change that would be anticipated
by insertation of that into ARIN policy would be ..."

In this and other cases the "that" is RFC-2050 text.

Shouldn't the text of RFC-2050 already impact ARIN policy?

At the time of publication more than 15 years ago, RFC 2050 was a baseline
of operational guidelines for all of the regional registries, with each RIR free
to establish any additional guidelines as appropriate.   Since that time, both
individual RIRs have evolved, as well as the entire structure of the Internet
Number Registry System.  This is one of the key reasons why it was felt
that RFC2050 was long overdue to be refreshed, as many material issues
have changed since that time (e.g. Jon Postel no longer available as IANA,
formation of ICANN, introduction of additional RIRs, IPv6, etc.)  RFC 2050
was operational guidelines from a single point in time, with it made clear
that the policies followed by an RIR could be supplemented with additional
policy and/or these global operational guidelines themselves could be
amended by the IANA to reflect changing requirements.

The reality is that the entire system has so extensively changed that each
RIR has its own adopted policy, has contractual relations with its members,
and we have a formal process with ICANN for adoption of global policy.  There
is quite a bit in RFC 2050 operational guidelines which has been preempted
by these events, and hence the reason why the RFC2050bis effort has
focused on primarily describing the Internet Number Registry System, and
calling out those technical considerations from RFC 2050 which are inherent
to use of the the Internet Protocol and should be considered in establishing
registry policy.

I would say that the underlying concepts in RFC 2050 should indeed be
considered when setting ARIN registry policy, but how exactly that is done,
and how much weight is given to individual principles is very much up to this
community.

(Assuming no translational issues, out of context, etc)
why would the impact differ when the text is in RFC-2050,
or in the NRPM?

See above.  ARIN must follow NRPM in operation of the registry, whereas
RFC 2050 is a 15 year-old base set of operational guidelines and technical
principles for consideration in establishing registry policy for this region.

(I'm not debating there is value in community being more clear
in outlining its expectations and impact on operations. I think
that point is true if this text is added to the NRPM and while this
text remains in RFC-2050.

As there is language in RFC 2050 which is clearly obsoleted by events,
it is necessary for the community to discuss and determine what aspects
should be considered current and incorporated into ARIN registry policy.

We certainly can improve on the 2050 text, but I was trying to avoid
any updates that may be controversial, and was more interesting in
preserving the principles in 2050 in the first go around. )

A very admirable goal, but you are conflicted between the implied goals
of "avoiding updates" versus "producing something which is both current
and accurate."  I'm not sure that the latter is achievable without quite a
bit of debate on what should be adopted.

Best wishes on your effort!
/John

John Curran
President and CEO
ARIN



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

From jcurran at arin.net  Fri May 31 08:15:19 2013
From: jcurran at arin.net (John Curran)
Date: Fri, 31 May 2013 12:15:19 +0000
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAC4yj2XMe-kecYXb5_t48VdtmhVVjDkpaM0tEjyh2O8SH8c8zA@mail.gmail.com>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<CAC4yj2XMe-kecYXb5_t48VdtmhVVjDkpaM0tEjyh2O8SH8c8zA@mail.gmail.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B374E7058895@CHAXCH01.corp.arin.net>

On May 31, 2013, at 1:18 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:

I'm not sure who owns the text at this point, I think maybe the AC.

Indeed; once a policy proposal has been accepted as a Draft Policy, then the
Advisory Council further develops the Draft Policy, working in cooperation with
the policy originator if available.

FYI,
/John

John Curran
President and CEO
ARIN

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

From jschiller at google.com  Fri May 31 10:21:25 2013
From: jschiller at google.com (Jason Schiller)
Date: Fri, 31 May 2013 10:21:25 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <8DA1853CE466B041B104C1CAEE00B374E70582F3@CHAXCH01.corp.arin.net>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
	<CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
	<CAP-guGWnAxYEwFD0ML4gRaPxRshZiWpcCRR_JKKfQfiDFBqsFQ@mail.gmail.com>
	<CAMfXtQzWjxycEPWW1Tas54xpcR_q-h=MpF8bQ4jD5_4H-+o29w@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70526FF@CHAXCH01.corp.arin.net>
	<CAC4yj2UCuhx66ofsh09=WoRj65SrqrAu2Lk+hRzyxRfVjNU+HA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70582F3@CHAXCH01.corp.arin.net>
Message-ID: <CAC4yj2Xxh4UGizFNn=A8F8L94NeeHQDWnwwo8UcEfOtvKcjqXw@mail.gmail.com>

John,

Thank you for your careful consideration.

My intention certainly is not to undermine current NRPM policy or RSA text
or change RIR operations.  Ideally all of the things taken from RFC 2050 are
high level principles, and are still as true today as they were then.

It seems things may not be that simple.

First let me say this is not my effort, but rather our effort, where our is
both the
community, the AC, and ARIN staff.

To that end, would it be unreasonable to ask for something different in the
staff assessment?

Certainly a standard staff assessment should be done, but could staff also
publish
a separate assessment, of each of the snippets of the draft policy that
would
impact ARIN operations, how it would impact ARIN operations, and if there
are other
events (text) that have superseded this text.

The community will then have:

1. the original principle
2. the history about the departure
3. the now current policy
4. how that might be changed if we reassert the principle in RFC 2050

The community can the first decide if the current policy / ARIN practice
should remain

Assuming it should remain, the community should judge if this is:
A: Consistant with the original principle - should have no ARIN policy
impact
B: The original principle is still true, but need to be modified to support
current policy
C: Inconsistent with the original principle, but the original principle
still holds true,
      current NRPM text should change, but resulting ARIN policy should be
the same
D: Inconsistent with the original principle, but the original principle
still holds true,
      current ARIN policy should change
E: Inconsistent with the original principle, but the original principle
still holds true,
      current ARIN policy is an artifact of other events but should not
change
F: Inconsistent with the original principle, and the community has
concluded that it
      should depart from this original principle, as it is no longer valid.

For example wrt the text:
"IP addresses are valid as long as the criteria continues to be met"
the community may decide that:
- Yes this is a general principle that is still true
- No we don't think it should mean ARIN should start reclaiming legacy space
   that is under 80% utilized.
- No we don't think this should challenge the current RSA
- Yes we need some clarifying text asserting this
Conclusion ARIN AC (working with the community should work on text
asserting this)

For example wrt 0.1.1 text:

"Assignment of Internet number resources is based on documented operational
need.
Utilization rate of address space will be a key factor in number resource
assignment.
To this end, registrants should have documented justified need available
for each assignment.
Organizations will be assigned resources based on immediate utilization
plus expected utilization."

The community might decide that:
- Yes this is a general principle that is still true, IPs should be given
on a needs basis
- No we don't think ARIN should start giving out less IPv6 addresses, or
make it harder to get
- Yes this does conflict with IPv6 allocation / assignment policy which is
currently not based on need
- The conflicting IPv6 allocation / assignment policy should still be used
by ARIN
- The community concludes IPv6 allocation / assignment policy should have
always be based on need
- The community should work to modify the NRPM to
   1. Make IPv6 allocation / assignment policy based on need
   2. point out the balance between aggregation and efficient utilization
much more favors the former
   3. ensure the needs based policy still results in the same allocation
/ assignment size


If we proceed in this fashion, we can identify
- the non-controversial (non-ARIN policy changing) text,
- the community can deal with each piece of text that might change ARIN
policy, and decide at a high
level to what extent the particular policy should impact ARIN policy
- decide what sort of changes is needed to what (this draft, other NRPM
text, RSA, ARIN policy, etc)
- begin crafting those changes

My apologies to staff for the added work, but if done well, this
will truly be something to be proud of.

__Jason




On Fri, May 31, 2013 at 6:54 AM, John Curran <jcurran at arin.net> wrote:

>  On May 31, 2013, at 1:47 AM, Jason Schiller <jschiller at google.com>
>  wrote:
>
>  John,
>
>  Reading your respons brings to mind a general question.
>
>  You said "the most likely change that would be anticipated
> by insertation of that into ARIN policy would be ..."
>
>  In this and other cases the "that" is RFC-2050 text.
>
>  Shouldn't the text of RFC-2050 already impact ARIN policy?
>
>
>  At the time of publication more than 15 years ago, RFC 2050 was a
> baseline
> of operational guidelines for all of the regional registries, with each
> RIR free
> to establish any additional guidelines as appropriate.   Since that time,
> both
> individual RIRs have evolved, as well as the entire structure of the
> Internet
> Number Registry System.  This is one of the key reasons why it was felt
> that RFC2050 was long overdue to be refreshed, as many material issues
> have changed since that time (e.g. Jon Postel no longer available as IANA,
> formation of ICANN, introduction of additional RIRs, IPv6, etc.)  RFC 2050
> was operational guidelines from a single point in time, with it made clear
> that the policies followed by an RIR could be supplemented with additional
> policy and/or these global operational guidelines themselves could be
> amended by the IANA to reflect changing requirements.
>
>  The reality is that the entire system has so extensively changed that
> each
> RIR has its own adopted policy, has contractual relations with its members,
> and we have a formal process with ICANN for adoption of global policy.
>  There
> is quite a bit in RFC 2050 operational guidelines which has been preempted
> by these events, and hence the reason why the RFC2050bis effort has
> focused on primarily describing the Internet Number Registry System, and
> calling out those technical considerations from RFC 2050 which are inherent
> to use of the the Internet Protocol and should be considered in
> establishing
> registry policy.
>
>  I would say that the underlying concepts in RFC 2050 should indeed be
> considered when setting ARIN registry policy, but how exactly that is done,
> and how much weight is given to individual principles is very much up to
> this
> community.
>
>   (Assuming no translational issues, out of context, etc)
> why would the impact differ when the text is in RFC-2050,
> or in the NRPM?
>
>
>  See above.  ARIN must follow NRPM in operation of the registry, whereas
> RFC 2050 is a 15 year-old base set of operational guidelines and technical
> principles for consideration in establishing registry policy for
> this region.
>
>    (I'm not debating there is value in community being more clear
> in outlining its expectations and impact on operations. I think
> that point is true if this text is added to the NRPM and while this
> text remains in RFC-2050.
>
>
>  As there is language in RFC 2050 which is clearly obsoleted by events,
> it is necessary for the community to discuss and determine what aspects
> should be considered current and incorporated into ARIN registry policy.
>
>  We certainly can improve on the 2050 text, but I was trying to avoid
> any updates that may be controversial, and was more interesting in
> preserving the principles in 2050 in the first go around. )
>
>
>  A very admirable goal, but you are conflicted between the implied goals
> of "avoiding updates" versus "producing something which is both current
> and accurate."  I'm not sure that the latter is achievable without quite a
> bit of debate on what should be adopted.
>
>  Best wishes on your effort!
> /John
>
>  John Curran
> President and CEO
> ARIN
>
>
>
>


-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130531/0b23a79c/attachment.htm>

From jcurran at arin.net  Fri May 31 11:54:03 2013
From: jcurran at arin.net (John Curran)
Date: Fri, 31 May 2013 15:54:03 +0000
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAC4yj2Xxh4UGizFNn=A8F8L94NeeHQDWnwwo8UcEfOtvKcjqXw@mail.gmail.com>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
	<CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
	<CAP-guGWnAxYEwFD0ML4gRaPxRshZiWpcCRR_JKKfQfiDFBqsFQ@mail.gmail.com>
	<CAMfXtQzWjxycEPWW1Tas54xpcR_q-h=MpF8bQ4jD5_4H-+o29w@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70526FF@CHAXCH01.corp.arin.net>
	<CAC4yj2UCuhx66ofsh09=WoRj65SrqrAu2Lk+hRzyxRfVjNU+HA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70582F3@CHAXCH01.corp.arin.net>
	<CAC4yj2Xxh4UGizFNn=A8F8L94NeeHQDWnwwo8UcEfOtvKcjqXw@mail.gmail.com>
Message-ID: <8DA1853CE466B041B104C1CAEE00B374E7059340@CHAXCH01.corp.arin.net>

On May 31, 2013, at 10:21 AM, Jason Schiller <jschiller at google.com<mailto:jschiller at google.com>> wrote:
To that end, would it be unreasonable to ask for something different in the staff assessment?

Certainly a standard staff assessment should be done, but could staff also publish
a separate assessment, of each of the snippets of the draft policy that would
impact ARIN operations, how it would impact ARIN operations, and if there are other
events (text) that have superseded this text.

The community will then have:

1. the original principle
2. the history about the departure
3. the now current policy
4. how that might be changed if we reassert the principle in RFC 2050

The community can the first decide if the current policy / ARIN practice should remain

Assuming it should remain, the community should judge if this is:
A: Consistant with the original principle - should have no ARIN policy impact
B: The original principle is still true, but need to be modified to support current policy
C: Inconsistent with the original principle, but the original principle still holds true,
      current NRPM text should change, but resulting ARIN policy should be the same
D: Inconsistent with the original principle, but the original principle still holds true,
      current ARIN policy should change
E: Inconsistent with the original principle, but the original principle still holds true,
      current ARIN policy is an artifact of other events but should not change
F: Inconsistent with the original principle, and the community has concluded that it
      should depart from this original principle, as it is no longer valid.

For example wrt the text:
"IP addresses are valid as long as the criteria continues to be met"
the community may decide that:
- Yes this is a general principle that is still true
- No we don't think it should mean ARIN should start reclaiming legacy space
   that is under 80% utilized.
- No we don't think this should challenge the current RSA
- Yes we need some clarifying text asserting this
Conclusion ARIN AC (working with the community should work on text asserting this)

For example wrt 0.1.1 text:

"Assignment of Internet number resources is based on documented operational need.
Utilization rate of address space will be a key factor in number resource assignment.
To this end, registrants should have documented justified need available for each assignment.
Organizations will be assigned resources based on immediate utilization plus expected utilization."

The community might decide that:
- Yes this is a general principle that is still true, IPs should be given on a needs basis
- No we don't think ARIN should start giving out less IPv6 addresses, or make it harder to get
- Yes this does conflict with IPv6 allocation / assignment policy which is currently not based on need
- The conflicting IPv6 allocation / assignment policy should still be used by ARIN
- The community concludes IPv6 allocation / assignment policy should have always be based on need
- The community should work to modify the NRPM to
   1. Make IPv6 allocation / assignment policy based on need
   2. point out the balance between aggregation and efficient utilization much more favors the former
   3. ensure the needs based policy still results in the same allocation / assignment size


If we proceed in this fashion, we can identify
- the non-controversial (non-ARIN policy changing) text,
- the community can deal with each piece of text that might change ARIN policy, and decide at a high
level to what extent the particular policy should impact ARIN policy
- decide what sort of changes is needed to what (this draft, other NRPM text, RSA, ARIN policy, etc)
- begin crafting those changes

My apologies to staff for the added work, but if done well, this will truly be something to be proud of.

Jason -

   We work for you (the collective "you" being the entire community) and as such
   are happy to do any additional work which will help the community in consideration
   of draft policies.  We normally would note any conflicts with existing practices
   during staff and legal review (once requested by the AC) if it is not clear from
   the policy text that the intent is to change those practices as well at adoption.

   I will note that performing this sort of assessment may identify some clearly
   impacting aspects of the proposed text with existing registry practices, but not
   as many as you might expect, as the inherent conflict between the various
   proposed principles means that they can only be considered as a whole and
   not "snippet by snippet" as you suggest.

   Your example is a perfect illustration of this, in that you suggest that we might cite
   the existing IPv6 allocation/assignment policy as impacted by proposed principle
   "0.1.1. Documented Justified Need", but that is not possible because the policy is
   set by the community is based on the balance between justified need and the need
   for aggregation (i.e. proposed principle "0.2. Hierarchical Aggregation")...  To the
   extent that the balance is not optimum, that is ultimately for the community to
   decide that and not the ARIN staff.

   Phrases in the proposed principles such as "Internet number resources are valid as
   long as the criteria continues to be met", "All Internet number resource requests are
   subject to audit and verification by any means deemed appropriate by the regional
   registry", and "The party trying to obtain the resources must meet the same criteria
   as if they were requesting resources directly from the IR" (among others) will indeed
   be highlighted in any staff and legal review due to conflicts with existing ARIN registry
   operational practices, but it is up to the community to decide if, and to what extent,
   existing policy does not align with balance inherent to these proposed principles.

FYI,
/John

John Curran
President and CEO
ARIN


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

From dogwallah at gmail.com  Fri May 31 18:35:09 2013
From: dogwallah at gmail.com (McTim)
Date: Fri, 31 May 2013 18:35:09 -0400
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<150F08C2-AB2E-4590-B36D-5A7B26D74C2E@delong.com>
	<CAP-guGU377APvxAbW3ETpBVmP8Hpa5xi2tOW87fDhX_WMzEihA@mail.gmail.com>
	<8DA1853CE466B041B104C1CAEE00B374E70505D4@CHAXCH01.corp.arin.net>
Message-ID: <CACAaNxhT4RFJGVgh_EvEEvd2JH6Q7Qs7UAHF1g-6B7phK6+kXw@mail.gmail.com>

On Thu, May 30, 2013 at 3:15 PM, John Curran <jcurran at arin.net> wrote:

<snip>

> For a more in-depth consideration of this topic, I might suggest
> reviewing this recent article in the ABA Business Law Today on IP
> number transfers -
>
> <http://apps.americanbar.org/buslaw/blt/content/2013/05/article-03-edelman.shtml>

thanks John, a good read indeed!

-- 
Cheers,

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


From owen at delong.com  Fri May 31 22:33:19 2013
From: owen at delong.com (Owen DeLong)
Date: Fri, 31 May 2013 19:33:19 -0700
Subject: [arin-ppml] Draft Policy ARIN-2013-4: RIR Principles
In-Reply-To: <CAC4yj2VYMVxyDkm-risMkjafa_4=6O9a31davVHkBg4PcCC2+w@mail.gmail.com>
References: <51966083.2010003@arin.net> <51A4F546.3090601@quark.net>
	<CAC4yj2X5RemO1rMQ35Q-LWBAri4Vim41Y4OuEwaV6BhANq6jyQ@mail.gmail.com>
	<51A78B87.6020901@quark.net>
	<CAC4yj2VYMVxyDkm-risMkjafa_4=6O9a31davVHkBg4PcCC2+w@mail.gmail.com>
Message-ID: <94EE69F6-F7AF-4423-8EAC-2E23A4396C05@delong.com>

I oppose watering it down. Those principles applied before ARIN existed, so it's really
not a problem to apply them to ARIN as well.

Owen

On May 30, 2013, at 1:36 PM, Jason Schiller <jschiller at google.com> wrote:

> Andrew,
> 
> I think there is one very important point that you make that is worth calling out separately:
> 
> Andrew writes:
> 
>> JS> RFC-2050 3.1 says:
>> JS>
>> JS> "IP addresses are valid as long as the criteria continues to be met."
> 
> AD> One might construe this statement to directly invalidate existing legacy allocations 
> AD> which would now be in ARIN's policy through this policy.  Others might be worried 
> AD> that this opens the door wider to changing policy to retroactively revoke allocations 
> AD> or assignments by changing "criteria".   Furthermore, I believe this idea is already 
> AD> handled by existing NRPM text and the RSA.
> 
> What should we do here?
> 
> My goal was to have a "universal section" that documented the principles of "stewardship" 
> originally documented in RFC-2050 and be one place people could point to (instead of RFC-2050
> in the event that the stewardship language in 2050 is deprecated).  I know the definition of 
> stewardship has evolved, and documented in other places, all based on the spirit of RFC-2050.
> 
> It felt to me like this is a current principle of stewardship.
> 
> I am not trying to invent some new restriction on legacy address holders.  If the community feels
> this creates some new ability to revoke legacy allocations, then we should consider some language
> to indicate that is not the case.
> 
> If the current RSA / NRPM text documents this principle, then I'd like for you (or someone) to lift out 
> that text, and add it to this section.  
> 
> The goal is to have all the principles in one section, and in the event that this becomes global, or 
> adopted in multiple regions, they may lack the text you are thinking of.  
> 
> So my questions to the community:
> 
> 1. Does this create some new restriction on legacy address holders?
> 1A. if yes, should this new restriction be avoided?  
>        Please provide draft text on what exclusions should apply to  legacy addresses.
> 
> 2. Is there already good text in the RSA / NRPM about this principle?
> 2A. If yes please quote the text.
> 2B. What text would you lift and include here?  How would you generalize it into a principle?
> 
> Thanks,
> 
> __Jason
> 
> 
> 
> 
> 
> 
> On Thu, May 30, 2013 at 1:25 PM, Andrew Dul <andrew.dul at quark.net> wrote:
> Hi Jason,
> 
> 
> On 5/28/2013 9:04 PM, Jason Schiller wrote:
>> Andrew thanks for your feed back.
>> 
>> I want to point out that much of this language comes from either RFC-2050 or the current PDP or NRPM.  I tired to change the language as little as possible, except where we have commonly agreed on new language such as "efficient utilization" instead of conservation.  I thought that might be the most uncontroversial starting point.  I am not opposed to changing it, especially if it makes the text less controversial.
>> 
> I didn't have any of those docs in front of me when reviewing the proposal, so I didn't specifically note they were "existing policy text." In general, I'm in favor of reusing text where it makes sense.  I will say that there probably always is room for     improvement, and 2050 is now pretty dated so updating the language to be more relevant to today's practices & principles is probably a step forward.
> 
> 
>> ---
>> 
>> WRT the LIR/ISP I agree, we should adopt whatever we think the standard term should be.
>> 
>> ---
>> 
>> WRT using number resources instead of IP address space I would have to take a careful look and make sure we are not applying principles that make sense with respect IP addressing to ASNs if they don't make sense.   It is not clear to me if you think these changes should be throughout the text, or only in section 0.1. 
> 
> I probably wasn't totally consistent in my initial comments.  Since this is "RIR Principles" I believe this policy proposal should refer in general to number resources unless the statements directly apply only to a subset of Internet number resources.  
> 
>> 
>> ---
>> 
>> Andrew writes:
>> > I think this section [0.1. Efficient utilization based on need (Conservation)] 
>> > should have an explicit reference to the difference
>> > in conservation techniques for IPv4 and IPv6.  A proposed sentence might
>> > be something like this... "Conservation goals may vary due to the
>> > technical differences between IP number resources pools, for example the
>> > relatively limited size of the IPv4 address pool causes a desire to see
>> > the number space more highly utilized compared to the vast availability
>> > of IP numbers within the IPv6 address pool."
>> 
>> I made a conscious effort to keep this text in section 0.4 for clarity.  
>> 
>> From the draf policy section 0.4:
>> "For example, efficient utilization becomes a more prominent issue than aggregation as the IPv4 free pool depletes and IPv4 resource availability in any transfer market decreases. Conversely, because the IPv6 number space is orders of magnitude larger than the IPv4 number space, the scale tips away from efficient utilization towards hierarchical aggregation for IPv6 number resources."
>> 
>> Does that text fulfill your suggestion of "Conservation goals may vary due to the technical differences between IP number resources pools, for example the relatively limited size of the IPv4 address pool causes a desire to see the number space more highly utilized compared to the vast availability of IP numbers within the IPv6 address pool."
>> 
>> Do you have concerns about where this text is located?
>> 
> 
> I realized later that I inserted similar "IPv4 is different that IPv6" into multiple sections, since I thought it applied in unique     ways to each section.  Perhaps for clarity it should only be in section 0.4 Stewardship, since this is the section that talks about balance between different elements and goals?  I'm also OK with it being only in one section, but I would want it to somehow illuminate specifically that conservation varies based on number resource. 
> 
> Perhaps just add the statement w/o example?  "Conservation goals may vary due to the technical differences between IP number resources pools." 
> 
> Not a showstopper for me, if it isn't in 0.1.
> 
> Building on Bill's comments in his notes, I think there might be room toward using the term sustainability in these principles.  That term is well known in "corporate speak" and might be closer to the RIR's goals & principles compared with other words.  
> 
>> ---
>> 
>> Andrew writes:
>> > "Utilization rate of address space will be an important factor in
>> > justifying need for IP number resources.  However, utilization rates
>> > will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
>> > number resource pools."
>> 
>> Again, I made a conscious effort to keep this text in section 0.4 for clarity, and would quote the same text.
>> 
>> Does that meet your concern about your proposed text?
>> 
>> Do you have concerns about where this text is located?
> 
> Perhaps just keeping it all in 0.4 is best.
> 
> 
>> 
>> Should I repeat the paragraph in 0.1, 0.1.1, and 0.4?
>> 
> I wouldn't repeat the paragraph.
> 
>> ---
>> Andrew writes:
>> >> In order to promote increased usage of Internet number resources,
>> >> resource holders will be required to provide an accounting of
>> >> resources currently held demonstrating efficient utilization. Internet
>> >> number resources are valid as long as the criteria continues to be
>> >> met. The transfer of Internet number resources from one party to
>> >> another must be approved by the regional registries. The party trying
>> >> to obtain the resources must meet the same criteria as if they were
>> >> requesting resources directly from the IR.
>> >>
>> >> All Internet number resource requests are subject to audit and
>> >> verification by any means deemed appropriate by the regional registry.
>> >>
>> >
>> > I suspect the above two paragraphs may be lightning rods against the
>> > policy proposal.   May I suggest the following single paragraph in lieu
>> > of the above two paragraphs.
>> >
>> > In order meet the Principles and Goals of the Internet Registry System,
>> > resource holders may be required from time to time to provide an
>> > accounting and current usage of resources currently held.  The RIRs
>> > shall set policies to define these accounting mythologies as part of
>> > their community driven policy process.
>> 
>> I'm not sure why you think these two paragraphs are lightening rods.
>> 
>> RFC-2050 3.3 says:
>> "To promote increased usage of address space, the registries will
>>   require an accounting of address space previously assigned to the
>>   enterprise, if any."
> 
> I believe including text that says orgs must keep records of how the use address space is totally appropriate.  Record keeping doesn't necessarily "proposed increased usage" but does provide accountability and transparency which I believe should be one of the goals of the registry system.
> 
> 
>> 
>> RFC-2050 3.1 says:
>> 
>> "IP addresses are valid as long as the criteria continues to be met."
> 
> One might construe this statement to directly invalidate existing legacy allocations which would now be in ARIN's policy through this policy.  Others might be worried that this opens the door wider to changing policy to retroactively revoke allocations or assignments by changing "criteria".   Furthermore, I believe this idea is already handled by existing NRPM text and the RSA.
> 
> 
>> RFC-2050 4.7 says
>> 
>> 
>> "The transfer
>>               of IP addresses from one party to another must be
>>   approved by the regional registries.  The party trying to obtain
>>   the IP address must meet the same criteria as if they were
>>   requesting an IP address directly from the IR."
>> 
> I believe this "policy" element is best handled in the details section of the NRPM rather than the principles section.  ARIN's policies already define transfers.  Having a generic "RIRs shall determine IP number resources transfer policies through their community drive policy development process." might be a good addition to this proposal.
> 
> 
>> RFC-2050 4.4 says:
>> "All IP address requests are subject to audit and verification
>>   by any means deemed appropriate by the regional registry."
>> 
> I just remember for multiple years discussing policy 2007-14 & others when we put into policy existing auditing and review practices.  Since ARIN's policies and RSA already talk about audit procedures, I also thought this was not necessary.  The language "by any means deemed appropriate by the regional registry" is a wide open door that many I believe won't like.  By using text to say auditing is done by the community through adopted policy you limit an RIR's auditing to specifically what the community wants the registry to do.
> 
> 
>> And there is lots of text about conservation in RFC-2050 and 
>> efficient utilization in the NRPM.
>> 
>> Can you elaborate on the lightening rod potin?
>> 
> See above comments.
> 
>> I can only guess you are suggesting that the community wants
>> to depart from the principles in RFC-2050, but think you must
>> mean something else.
>> 
>> What am I missing here?
>> 
> 
> Hopefully my comments above illuminate the concerns I had about the text.  Basically it comes down to "modernizing" the 2050 text/principles, and keeping principles in the principles section and not putting specific policy in the principles section.
> 
> 
>> 
>> Andrew writes:
>> >> 0.2. Hierarchical aggregation (Routability)
>> >>
>> >> Policies for managing Internet number resources must support
>> >> distribution of globally unique Internet addresses in a hierarchical
>> >> manner, permitting the routing scalability of the addresses. 
>> >
>> > Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
>> > predominant routing methodology in the future, one would not necessarily
>> > expect the goals of the RIRs to change.
>> >
>> > Suggested change to end of first sentence.
>> >
>> > ... permitting the routing scalability of the addresses as required by
>> > the current technical limitations of global routing protocols.
>> 
>> I think this change is good even w/o considering LISP.
>> Imagine we have new holographic memory that can hold orders of 
>> magnitude more data and decrease read time
>> 
>> ---
>> 
>> Andrew writes:
>> >
>> >> 0.3. Uniqueness (Registration)
>> >>
>> >> c) to ensure that a provider has exhausted a majority of
>> >> its current CIDR allocation, thereby justifying an additional
>> >> allocation d) to assist in IP allocation studies.
>> >
>> > Suggested revision for "C"
>> >
>> > to allow a LIR to demonstrate and disclose reassignment of IP number
>> > resources to third-parties
>> 
>> I think the point is to demonstrate reassignment data to demonstrate efficient utilization.  
>> But I also think that point is covered in section 0.1.1, So the rewrite here is ok.
>> 
>> ---
>> 
>> Andrew writes:
>> > Perhaps add a statement specifically about Stewardship
>> >
>> > "Stewardship of IP number resources is the balance of overseeing and
>> > protecting the interests of all Internet stakeholders to further the
>> > development and expansion of the Internet and the Internet Registry System."
>> 
>> I do not oppose this text.
>> 
>> Andrew also writes...
>> >
>> > justified need as a conflicting goal should be explicitly mentioned.
>> >
>> > "It should be noted that efficient utilization, justified need, and
>> >hierarchical aggregation are often conflicting goals."
>> 
>> I'm not sure this parses correctly...  This sounds to me like there are 
>> conflicts between all three:
>> 
>> efficient utilization vs justified need vs hierarchical aggregation.  
>> 
>> How about:
>> "It should be noted that efficient utilization based on justified need, and
>> hierarchical aggregation are often conflicting goals."
>> 
>> 
>> 
>> -
>> 
>> 
>> On Tue, May 28, 2013 at 2:19 PM, Andrew Dul <andrew.dul at quark.net> wrote:
>> I support adding these guiding principles to the NRPM, furthermore I
>> would support efforts to introduce this policy in all RIR regions to
>> make this a global policy.
>> 
>> Comments on the proposed text in-line below.
>> 
>> Andrew
>> 
>> On 5/17/2013 9:53 AM, ARIN wrote:
>> > Draft Policy ARIN-2013-4
>> > RIR Principles
>> >
>> > On 16 May 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-187
>> > RIR Principles" as a Draft Policy.
>> >
>> > Draft Policy ARIN-2013-4 is below and can be found at:
>> > https://www.arin.net/policy/proposals/2013_4.html
>> >
>> >
>> > ## * ##
>> >
>> >
>> > Draft Policy ARIN-2013-4
>> > RIR Principles
>> >
>> > Date: 17 May 2013
>> >
>> > Problem Statement:
>> >
>> > The original text in RFC 2050 both "describes the registry system for
>> > the distribution of globally unique Internet address space and
>> > registry operations" and provides "rules and guidelines [principles]
>> > governing the distribution of this address space."
>> >
>> > The currently proposed update (RFC2050bis) "provides information about
>> > the current Internet Numbers Registry System used in the distribution
>> > of globally unique Internet Protocol (IP) address space and autonomous
>> > system (AS) numbers" and "provides information about the processes for
>> > further evolution of the Internet Numbers Registry System."
>> >
>> > This means that the guiding principles of stewardship are not
>> > currently being carried forward into the new document. The goals of
>> > Conservation (efficient utilization based on need), Routability
>> > (hierarchical aggregation), and Registration (uniqueness) are as
>> > important, if not more so, now that the transition to IPv6 is upon us.
>> > This can be rectified by documenting these principles in RIR policy.
>> >
>> > Policy Statement:
>> >
>> > Section 0: Principles and Goals of the Internet Registry System
>> >
>> > 0.1. Efficient utilization based on need (Conservation)
>> >
>> > Policies for managing Internet number resources must support 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. The registry should
>> > prevent stockpiling in order to maximize the conservation and
>> > efficient utilization of the Internet address space.
>> 
>> This section should use the new proposed convention of "LIR/ISP" as
>> being developed in ARIN-2013-5.
>> 
>> s/this address space/IP number resources/r
>> s/Internet address space/IP number resources/r
>> 
>> I think this section should have an explicit reference to the difference
>> in conservation techniques for IPv4 and IPv6.  A proposed sentence might
>> be something like this... "Conservation goals may vary due to the
>> technical differences between IP number resources pools, for example the
>> relatively limited size of the IPv4 address pool causes a desire to see
>> the number space more highly utilized compared to the vast availability
>> of IP numbers within the IPv6 address pool."
>> 
>> >
>> > 0.1.1. Documented Justified Need (Needs Based)
>> >
>> > Assignment of Internet number resources is based on documented
>> > operational need. Utilization rate of address space will be a key
>> > factor in number resource assignment. To this end, registrants should
>> > have documented justified need available for each assignment.
>> > Organizations will be assigned resources based on immediate
>> > utilization plus expected utilization.
>> 
>> Utilization rate is much more important for IPv4 than IPv6.
>> 
>> Suggested revision for "Utilization rate of address space will be a key
>> factor in number resource assignment."
>> 
>> "Utilization rate of address space will be an important factor in
>> justifying need for IP number resources.  However, utilization rates
>> will vary due to the technical differences (e.g. IPv4 vs. IPv6) between
>> number resource pools."
>> 
>> >
>> > In order to promote increased usage of Internet number resources,
>> > resource holders will be required to provide an accounting of
>> > resources currently held demonstrating efficient utilization. Internet
>> > number resources are valid as long as the criteria continues to be
>> > met. The transfer of Internet number resources from one party to
>> > another must be approved by the regional registries. The party trying
>> > to obtain the resources must meet the same criteria as if they were
>> > requesting resources directly from the IR.
>> >
>> > All Internet number resource requests are subject to audit and
>> > verification by any means deemed appropriate by the regional registry.
>> >
>> 
>> I suspect the above two paragraphs may be lightning rods against the
>> policy proposal.   May I suggest the following single paragraph in lieu
>> of the above two paragraphs.
>> 
>> In order meet the Principles and Goals of the Internet Registry System,
>> resource holders may be required from time to time to provide an
>> accounting and current usage of resources currently held.  The RIRs
>> shall set policies to define these accounting mythologies as part of
>> their community driven policy process.
>> 
>> 
>> > 0.2. Hierarchical aggregation (Routability)
>> >
>> > Policies for managing Internet number resources must support
>> > distribution of globally unique Internet addresses in a hierarchical
>> > manner, permitting the routing scalability of the addresses. This
>> > scalability is necessary to ensure proper operation of Internet
>> > routing, although it must be stressed that routability is in no way
>> > guaranteed with the allocation or assignment of IPv4 addresses.
>> >
>> 
>> Should the RIR's goals be "LISP agnostic"?  That is if LISP becomes the
>> predominant routing methodology in the future, one would not necessarily
>> expect the goals of the RIRs to change.
>> 
>> Suggested change to end of first sentence.
>> 
>> ... permitting the routing scalability of the addresses as required by
>> the current technical limitations of global routing protocols.
>> 
>> > 0.3. Uniqueness (Registration)
>> >
>> > Provision of a public registry documenting Internet number resource
>> > allocation, reallocation, assignment, and reassignment is necessary to:
>> >
>> > a) ensure uniqueness and to to provide operational staff with
>> > information on who is using the number resource b) to provide a
>> > contact in case of operational/security problems (e.g. Law
>> > Enforcement) c) to ensure that a provider has exhausted a majority of
>> > its current CIDR allocation, thereby justifying an additional
>> > allocation d) to assist in IP allocation studies.
>> 
>> Suggested revision for "C"
>> 
>> to allow a LIR to demonstrate and disclose reassignment of IP number
>> resources to third-parties
>> 
>> >
>> > It is imperative that reassignment information be submitted in a
>> > prompt and efficient manner to facilitate database maintenance and
>> > ensure database integrity.
>> >
>> > 0.4. Stewardship
>> >
>> > It should be noted that efficient utilization and hierarchical
>> > aggregation are often conflicting goals. All the above goals may
>> > sometimes be in conflict with the interests of individual end-users or
>> > Internet Service Providers. Care must be taken to ensure balance with
>> > these conflicting goals given the resource availability, relative size
>> > of the resource, and number resource specific technical dynamics, for
>> > each type of number resource. For example, efficient utilization
>> > becomes a more prominent issue than aggregation as the IPv4 free pool
>> > depletes and IPv4 resource availability in any transfer market
>> > decreases. Conversely, because the IPv6 number space is orders of
>> > magnitude larger than the IPv4 number space, the scale tips away from
>> > efficient utilization towards hierarchical aggregation for IPv6 number
>> > resources.
>> 
>> Perhaps add a statement specifically about Stewardship
>> 
>> "Stewardship of IP number resources is the balance of overseeing and
>> protecting the interests of all Internet stakeholders to further the
>> development and expansion of the Internet and the Internet Registry System."
>> 
>> Also...
>> 
>> justified need as a conflicting goal should be explicitly mentioned.
>> 
>> "It should be noted that efficient utilization, justified need, and
>> hierarchical aggregation are often conflicting goals."
>> 
>> Use the new LIR/ISP convention instead of "Internet Service Providers"
>> 
>> 
>> 
>> >
>> > Comments:
>> >
>> > a. Timetable for implementation: immediately
>> >
>> > b. I believe that it would be beneficial for IANA to adopt these
>> > principles as well, and encourage the community to consider a global
>> > policy proposal.
>> > _______________________________________________
>> > PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > Unsubscribe or manage 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.
>> 
>> 
>> 
>> -- 
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>> 
> 
> 
> 
> 
> -- 
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20130531/011cf19c/attachment.htm>