From hannigan at gmail.com  Mon Mar  3 22:59:45 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 3 Mar 2014 22:59:45 -0500
Subject: [arin-ppml] Potentially credible v4 number pricing data
Message-ID: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>

FYI

It would be more credible if the actual block was published, but this
is interesting regardless.

http://www.ipv4auctions.com/

Best,

-M<


From jcurran at arin.net  Tue Mar  4 00:08:04 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 4 Mar 2014 05:08:04 +0000
Subject: [arin-ppml] Potentially credible v4 number pricing data
In-Reply-To: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>
References: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>
Message-ID: <845369AC-F115-4757-83F4-CFB785CAA69B@arin.net>

On Mar 4, 2014, at 7:59 AM, Martin Hannigan <hannigan at gmail.com> wrote:

> It would be more credible if the actual block was published, but this
> is interesting regardless.
> 
> http://www.ipv4auctions.com/

Marty - 
 
Thanks for pointing out that information!

While it may not be possible to correlate any given transfer, it may also
be worth noting that ARIN does publish a list of all blocks transferred -
<https://www.arin.net/knowledge/statistics/transfers.html>

FYI,
/John

John Curran
President and CEO
ARIN


From michel at arneill-py.sacramento.ca.us  Tue Mar  4 01:45:28 2014
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Mon, 3 Mar 2014 22:45:28 -0800
Subject: [arin-ppml] Potentially credible v4 number pricing data
In-Reply-To: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>
References: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>
Message-ID: <69B9BA3779753A49865BB9010D560EBB6E9B@newserver.arneill-py.local>

> Martin Hannigan wrote :
> It would be more credible if the actual block was
> published, but this is interesting regardless.
> http://www.ipv4auctions.com/

About 6 weeks ago, I came up with the following:

+--------+-------+--------+-------+
! Prefix !  #IPs ! Per IP !  Cost !
+--------+-------+--------+-------+
!    /16 ! 65536 !    $10 ! $655K !
!    /18 ! 16384 !    $12 ! $196K !
!    /20 !  4096 !    $15 !  $61K !
!    /22 !  1024 !    $22 !  $22K !
+--------+-------+--------+-------+

I don't have any scientific pretentions about the validity of this data,
YMMV, blah blah. What is advertised is not what is sold, at this point
in time though I don't think that it matters much to the debate if an IP
is $7 per pop or $15 per pop.

My files here: http://ipvii.com/

Michel.



From jeffrey.lyon at blacklotus.net  Tue Mar  4 01:49:56 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Tue, 4 Mar 2014 15:49:56 +0900
Subject: [arin-ppml] Potentially credible v4 number pricing data
In-Reply-To: <69B9BA3779753A49865BB9010D560EBB6E9B@newserver.arneill-py.local>
References: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>
	<69B9BA3779753A49865BB9010D560EBB6E9B@newserver.arneill-py.local>
Message-ID: <CACrmG8fXF1M9PHff_xvGma4LFABk6_HdvTjuH6XUP+u0Zs9C=w@mail.gmail.com>

Michel,

I personally disagree that smaller assignments have market value. As
the prefixes get shorter, the aftermarket appeal is likely much
higher. (note: I do have some experience in this space in working with
private equity on M&A proposals for our company).

Thanks, Jeff

On Tue, Mar 4, 2014 at 3:45 PM, Michel Py
<michel at arneill-py.sacramento.ca.us> wrote:
>> Martin Hannigan wrote :
>> It would be more credible if the actual block was
>> published, but this is interesting regardless.
>> http://www.ipv4auctions.com/
>
> About 6 weeks ago, I came up with the following:
>
> +--------+-------+--------+-------+
> ! Prefix !  #IPs ! Per IP !  Cost !
> +--------+-------+--------+-------+
> !    /16 ! 65536 !    $10 ! $655K !
> !    /18 ! 16384 !    $12 ! $196K !
> !    /20 !  4096 !    $15 !  $61K !
> !    /22 !  1024 !    $22 !  $22K !
> +--------+-------+--------+-------+
>
> I don't have any scientific pretentions about the validity of this data,
> YMMV, blah blah. What is advertised is not what is sold, at this point
> in time though I don't think that it matters much to the debate if an IP
> is $7 per pop or $15 per pop.
>
> My files here: http://ipvii.com/
>
> Michel.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From hannigan at gmail.com  Tue Mar  4 08:56:03 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 4 Mar 2014 08:56:03 -0500
Subject: [arin-ppml] Potentially credible v4 number pricing data
In-Reply-To: <CACrmG8fXF1M9PHff_xvGma4LFABk6_HdvTjuH6XUP+u0Zs9C=w@mail.gmail.com>
References: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>
	<69B9BA3779753A49865BB9010D560EBB6E9B@newserver.arneill-py.local>
	<CACrmG8fXF1M9PHff_xvGma4LFABk6_HdvTjuH6XUP+u0Zs9C=w@mail.gmail.com>
Message-ID: <CAMDXq5NeOFKBU8KBMbFSntevRjeayiq6mPpkPk7o0rxjh24K=A@mail.gmail.com>

What does private equity and M&A have to do with longer or shorter prefix value?

There's a market for all lengths/sizes. Clearly, the Hilco data
demonstrates that. The "value" is higher for smaller (and larger to
some extent) prefixes because of the overhead and abundance of
unpredictable risk dealing with ARIN.

Best,

-M<



On Tue, Mar 4, 2014 at 1:49 AM, Jeffrey Lyon
<jeffrey.lyon at blacklotus.net> wrote:
> Michel,
>
> I personally disagree that smaller assignments have market value. As
> the prefixes get shorter, the aftermarket appeal is likely much
> higher. (note: I do have some experience in this space in working with
> private equity on M&A proposals for our company).
>
> Thanks, Jeff
>
> On Tue, Mar 4, 2014 at 3:45 PM, Michel Py
> <michel at arneill-py.sacramento.ca.us> wrote:
>>> Martin Hannigan wrote :
>>> It would be more credible if the actual block was
>>> published, but this is interesting regardless.
>>> http://www.ipv4auctions.com/
>>
>> About 6 weeks ago, I came up with the following:
>>
>> +--------+-------+--------+-------+
>> ! Prefix !  #IPs ! Per IP !  Cost !
>> +--------+-------+--------+-------+
>> !    /16 ! 65536 !    $10 ! $655K !
>> !    /18 ! 16384 !    $12 ! $196K !
>> !    /20 !  4096 !    $15 !  $61K !
>> !    /22 !  1024 !    $22 !  $22K !
>> +--------+-------+--------+-------+
>>
>> I don't have any scientific pretentions about the validity of this data,
>> YMMV, blah blah. What is advertised is not what is sold, at this point
>> in time though I don't think that it matters much to the debate if an IP
>> is $7 per pop or $15 per pop.
>>
>> My files here: http://ipvii.com/
>>
>> Michel.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>
>
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From jeffrey.lyon at blacklotus.net  Tue Mar  4 09:09:49 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Tue, 4 Mar 2014 23:09:49 +0900
Subject: [arin-ppml] Potentially credible v4 number pricing data
In-Reply-To: <CAMDXq5NeOFKBU8KBMbFSntevRjeayiq6mPpkPk7o0rxjh24K=A@mail.gmail.com>
References: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>
	<69B9BA3779753A49865BB9010D560EBB6E9B@newserver.arneill-py.local>
	<CACrmG8fXF1M9PHff_xvGma4LFABk6_HdvTjuH6XUP+u0Zs9C=w@mail.gmail.com>
	<CAMDXq5NeOFKBU8KBMbFSntevRjeayiq6mPpkPk7o0rxjh24K=A@mail.gmail.com>
Message-ID: <CACrmG8fUqfFg8_WrmiBWiohw1MjEzpVmBuYpkcCQtFsR=vUvxA@mail.gmail.com>

Money comes from somewhere, right?
On Mar 4, 2014 10:56 PM, "Martin Hannigan" <hannigan at gmail.com> wrote:

> What does private equity and M&A have to do with longer or shorter prefix
> value?
>
> There's a market for all lengths/sizes. Clearly, the Hilco data
> demonstrates that. The "value" is higher for smaller (and larger to
> some extent) prefixes because of the overhead and abundance of
> unpredictable risk dealing with ARIN.
>
> Best,
>
> -M<
>
>
>
> On Tue, Mar 4, 2014 at 1:49 AM, Jeffrey Lyon
> <jeffrey.lyon at blacklotus.net> wrote:
> > Michel,
> >
> > I personally disagree that smaller assignments have market value. As
> > the prefixes get shorter, the aftermarket appeal is likely much
> > higher. (note: I do have some experience in this space in working with
> > private equity on M&A proposals for our company).
> >
> > Thanks, Jeff
> >
> > On Tue, Mar 4, 2014 at 3:45 PM, Michel Py
> > <michel at arneill-py.sacramento.ca.us> wrote:
> >>> Martin Hannigan wrote :
> >>> It would be more credible if the actual block was
> >>> published, but this is interesting regardless.
> >>> http://www.ipv4auctions.com/
> >>
> >> About 6 weeks ago, I came up with the following:
> >>
> >> +--------+-------+--------+-------+
> >> ! Prefix !  #IPs ! Per IP !  Cost !
> >> +--------+-------+--------+-------+
> >> !    /16 ! 65536 !    $10 ! $655K !
> >> !    /18 ! 16384 !    $12 ! $196K !
> >> !    /20 !  4096 !    $15 !  $61K !
> >> !    /22 !  1024 !    $22 !  $22K !
> >> +--------+-------+--------+-------+
> >>
> >> I don't have any scientific pretentions about the validity of this data,
> >> YMMV, blah blah. What is advertised is not what is sold, at this point
> >> in time though I don't think that it matters much to the debate if an IP
> >> is $7 per pop or $15 per pop.
> >>
> >> My files here: http://ipvii.com/
> >>
> >> Michel.
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> >
> >
> >
> > --
> > Jeffrey A. Lyon, CISSP-ISSMP
> > Fellow, Black Lotus Communications
> > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
> blacklotus.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140304/9920232b/attachment.htm>

From spamauditor at linuxmagic.com  Tue Mar  4 11:03:44 2014
From: spamauditor at linuxmagic.com (Spam Auditor)
Date: Tue, 04 Mar 2014 08:03:44 -0800
Subject: [arin-ppml] Does ARIN do any follow-up on usage after granting
	IP(s)?
Message-ID: <5315F960.6010001@linuxmagic.com>

inetnum:     191.97.0/20
status:      allocated
aut-num:     N/A
owner:       PC Group PTY S.A.
created:     20140106

232.4.97.191.in-addr.arpa domain name pointer 
undertle83.oneandonlylinksite.com.
233.4.97.191.in-addr.arpa domain name pointer 
chrawaios30.oneandonlylinksite.com.
234.4.97.191.in-addr.arpa domain name pointer 
taiochu56.oneandonlylinksite.com.
235.4.97.191.in-addr.arpa domain name pointer 
smadios22.oneandonlylinksite.com.
236.4.97.191.in-addr.arpa domain name pointer 
snarkachu99.oneandonlylinksite.com.
237.4.97.191.in-addr.arpa domain name pointer 
oritia70.oneandonlylinksite.com.
238.4.97.191.in-addr.arpa domain name pointer 
cripios40.oneandonlylinksite.com.
239.4.97.191.in-addr.arpa domain name pointer 
lyeazard47.oneandonlylinksite.com.
240.4.97.191.in-addr.arpa domain name pointer 
doltortle53.oneandonlylinksite.com.

When you see that a /20 gets used immediately for outbound spam, 
randomized domain names, affiliate bulk email marketing.. hookupfinder..

Is this an appropriate use of IP Space?


From pauldotwall at gmail.com  Tue Mar  4 11:09:36 2014
From: pauldotwall at gmail.com (Paul WALL)
Date: Tue, 4 Mar 2014 11:09:36 -0500
Subject: [arin-ppml] Potentially credible v4 number pricing data
In-Reply-To: <CACrmG8fUqfFg8_WrmiBWiohw1MjEzpVmBuYpkcCQtFsR=vUvxA@mail.gmail.com>
References: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>
	<69B9BA3779753A49865BB9010D560EBB6E9B@newserver.arneill-py.local>
	<CACrmG8fXF1M9PHff_xvGma4LFABk6_HdvTjuH6XUP+u0Zs9C=w@mail.gmail.com>
	<CAMDXq5NeOFKBU8KBMbFSntevRjeayiq6mPpkPk7o0rxjh24K=A@mail.gmail.com>
	<CACrmG8fUqfFg8_WrmiBWiohw1MjEzpVmBuYpkcCQtFsR=vUvxA@mail.gmail.com>
Message-ID: <CAHnQ7e+MFHsv6TtzVTSNWYWkqSYup+QnKAig+Aokzy9rUd5UOA@mail.gmail.com>

Customers.

On Tuesday, March 4, 2014, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:

> Money comes from somewhere, right?
> On Mar 4, 2014 10:56 PM, "Martin Hannigan" <hannigan at gmail.com<javascript:_e(%7B%7D,'cvml','hannigan at gmail.com');>>
> wrote:
>
>> What does private equity and M&A have to do with longer or shorter prefix
>> value?
>>
>> There's a market for all lengths/sizes. Clearly, the Hilco data
>> demonstrates that. The "value" is higher for smaller (and larger to
>> some extent) prefixes because of the overhead and abundance of
>> unpredictable risk dealing with ARIN.
>>
>> Best,
>>
>> -M<
>>
>>
>>
>> On Tue, Mar 4, 2014 at 1:49 AM, Jeffrey Lyon
>> <jeffrey.lyon at blacklotus.net<javascript:_e(%7B%7D,'cvml','jeffrey.lyon at blacklotus.net');>>
>> wrote:
>> > Michel,
>> >
>> > I personally disagree that smaller assignments have market value. As
>> > the prefixes get shorter, the aftermarket appeal is likely much
>> > higher. (note: I do have some experience in this space in working with
>> > private equity on M&A proposals for our company).
>> >
>> > Thanks, Jeff
>> >
>> > On Tue, Mar 4, 2014 at 3:45 PM, Michel Py
>> > <michel at arneill-py.sacramento.ca.us<javascript:_e(%7B%7D,'cvml','michel at arneill-py.sacramento.ca.us');>>
>> wrote:
>> >>> Martin Hannigan wrote :
>> >>> It would be more credible if the actual block was
>> >>> published, but this is interesting regardless.
>> >>> http://www.ipv4auctions.com/
>> >>
>> >> About 6 weeks ago, I came up with the following:
>> >>
>> >> +--------+-------+--------+-------+
>> >> ! Prefix !  #IPs ! Per IP !  Cost !
>> >> +--------+-------+--------+-------+
>> >> !    /16 ! 65536 !    $10 ! $655K !
>> >> !    /18 ! 16384 !    $12 ! $196K !
>> >> !    /20 !  4096 !    $15 !  $61K !
>> >> !    /22 !  1024 !    $22 !  $22K !
>> >> +--------+-------+--------+-------+
>> >>
>> >> I don't have any scientific pretentions about the validity of this
>> data,
>> >> YMMV, blah blah. What is advertised is not what is sold, at this point
>> >> in time though I don't think that it matters much to the debate if an
>> IP
>> >> is $7 per pop or $15 per pop.
>> >>
>> >> My files here: http://ipvii.com/
>> >>
>> >> Michel.
>> >>
>> >> _______________________________________________
>> >> PPML
>> >> You are receiving this message because you are subscribed to
>> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','ARIN-PPML at arin.net');>
>> ).
>> >> Unsubscribe or manage your mailing list subscription at:
>> >> http://lists.arin.net/mailman/listinfo/arin-ppml
>> >> Please contact info at arin.net<javascript:_e(%7B%7D,'cvml','info at arin.net');>if you experience any issues.
>> >
>> >
>> >
>> > --
>> > Jeffrey A. Lyon, CISSP-ISSMP
>> > Fellow, Black Lotus Communications
>> > mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com<javascript:_e(%7B%7D,'cvml','jeffrey.lyon at gmail.com');>| skype:
>> blacklotus.net
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140304/25e33612/attachment.htm>

From jcurran at arin.net  Tue Mar  4 11:37:37 2014
From: jcurran at arin.net (John Curran)
Date: Tue, 4 Mar 2014 16:37:37 +0000
Subject: [arin-ppml] Does ARIN do any follow-up on usage after
	granting	IP(s)?
In-Reply-To: <5315F960.6010001@linuxmagic.com>
References: <5315F960.6010001@linuxmagic.com>
Message-ID: <06E48775-8947-4FA1-99B3-50B5C0B8E8FD@arin.net>

On Mar 4, 2014, at 8:03 PM, Spam Auditor <spamauditor at linuxmagic.com> wrote:

> inetnum:     191.97.0/20
> status:      allocated
> aut-num:     N/A
> owner:       PC Group PTY S.A.
> created:     20140106
> ...
> When you see that a /20 gets used immediately for outbound spam, randomized domain names, affiliate bulk email marketing.. hookupfinder..
> 
> Is this an appropriate use of IP Space?

It appears that the IP address space is being assigned to various 
computer systems that need to be connected to the Internet, which does
match the IP address policy in this region.  If you'd like different 
address policy which considers specific types of usage "invalid" then 
you should consider submitting a policy proposal suggesting such - 
<https://www.arin.net/policy/pdp_appendix_b.html>

I dislike spam as much as anyone, but ARIN must operate according to the 
adopted policy and the type of enforcement that you suggest would need 
to be carefully considered as it would result in a significant expansion 
of ARIN's current mission.

Thanks,
/John

John Curran
President and CEO
ARIN






From David.Huberman at microsoft.com  Tue Mar  4 11:38:29 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Tue, 4 Mar 2014 16:38:29 +0000
Subject: [arin-ppml] Does ARIN do any follow-up on usage after
	granting	IP(s)?
In-Reply-To: <5315F960.6010001@linuxmagic.com>
References: <5315F960.6010001@linuxmagic.com>
Message-ID: <fd5bcc4baac140f8a93da22a294bfa59@DM2PR03MB398.namprd03.prod.outlook.com>

Hello anonymous internet person,

191.97.0.0/20 is not issued by ARIN. It is issued by LACNIC, an organization just like ARIN which serves the Central and South America continent (as ARIN does the North America continent).

	http://www.lacnic.net

/david

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Spam Auditor
Sent: Tuesday, March 4, 2014 8:04 AM
To: arin-ppml at arin.net; mailop
Subject: [arin-ppml] Does ARIN do any follow-up on usage after granting IP(s)?

inetnum:     191.97.0/20
status:      allocated
aut-num:     N/A
owner:       PC Group PTY S.A.
created:     20140106

232.4.97.191.in-addr.arpa domain name pointer undertle83.oneandonlylinksite.com.
233.4.97.191.in-addr.arpa domain name pointer chrawaios30.oneandonlylinksite.com.
234.4.97.191.in-addr.arpa domain name pointer taiochu56.oneandonlylinksite.com.
235.4.97.191.in-addr.arpa domain name pointer smadios22.oneandonlylinksite.com.
236.4.97.191.in-addr.arpa domain name pointer snarkachu99.oneandonlylinksite.com.
237.4.97.191.in-addr.arpa domain name pointer oritia70.oneandonlylinksite.com.
238.4.97.191.in-addr.arpa domain name pointer cripios40.oneandonlylinksite.com.
239.4.97.191.in-addr.arpa domain name pointer lyeazard47.oneandonlylinksite.com.
240.4.97.191.in-addr.arpa domain name pointer doltortle53.oneandonlylinksite.com.

When you see that a /20 gets used immediately for outbound spam, randomized domain names, affiliate bulk email marketing.. hookupfinder..

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


From michel at arneill-py.sacramento.ca.us  Tue Mar  4 13:33:02 2014
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Tue, 4 Mar 2014 10:33:02 -0800
Subject: [arin-ppml] Potentially credible v4 number pricing data
In-Reply-To: <CACrmG8fXF1M9PHff_xvGma4LFABk6_HdvTjuH6XUP+u0Zs9C=w@mail.gmail.com>
References: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com><69B9BA3779753A49865BB9010D560EBB6E9B@newserver.arneill-py.local>
	<CACrmG8fXF1M9PHff_xvGma4LFABk6_HdvTjuH6XUP+u0Zs9C=w@mail.gmail.com>
Message-ID: <69B9BA3779753A49865BB9010D560EBB6E9D@newserver.arneill-py.local>

Jeff,

> Jeffrey Lyon wrote :
> I personally disagree that smaller assignments have market value.

We don't disagree much. Put it in context: it was a large scale
production talk where a /20 is a toy, and the point I was trying to make
then is that there is not much of a speculation market.

For that audience who turns out to have deep pockets, it would indeed
make sense to pay MORE per IP to have a short, contiguous prefix rather
than a boatload of scattered /24s from all over the swamp.

My personal view is that it's still a market where cold heads prevails
and buyers are coming to it with a specific need, purpose or project.
The Microsoft / Nortel deal has set the baseline price at $10 a pop, and
more or less market fluctuations and other factors this is what we are
still seeing.

That being said, it's a new market, with a very large FUD potential.
Some people out there are getting excited about the idea of buying a
/16, carving it up into /24s to resell / lease, and making a buck out of
it. These wheeler-dealers don't understand the value of a large
allocation, they think retail where one buys bulk and packages it small.
I don't see that happening, but never say never.

Michel.


>> Michel Py wrote :
>> About 6 weeks ago, I came up with the following:
>>
>> +--------+-------+--------+-------+
>> ! Prefix !  #IPs ! Per IP !  Cost !
>> +--------+-------+--------+-------+
>> !    /16 ! 65536 !    $10 ! $655K !
>> !    /18 ! 16384 !    $12 ! $196K !
>> !    /20 !  4096 !    $15 !  $61K !
>> !    /22 !  1024 !    $22 !  $22K !
>> +--------+-------+--------+-------+
>> My files here: http://ipvii.com/


From sm at resistor.net  Tue Mar  4 14:19:20 2014
From: sm at resistor.net (SM)
Date: Tue, 04 Mar 2014 11:19:20 -0800
Subject: [arin-ppml] [mailop] Does ARIN do any follow-up on usage after
 granting IP(s)?
In-Reply-To: <5315F960.6010001@linuxmagic.com>
References: <5315F960.6010001@linuxmagic.com>
Message-ID: <6.2.5.6.2.20140304111650.0c5fee90@resistor.net>

At 08:03 04-03-2014, Spam Auditor wrote:
>inetnum:     191.97.0/20
>status:      allocated
>aut-num:     N/A
>owner:       PC Group PTY S.A.
>created:     20140106

The above IPv4 address space is under LACNIC.

Regards,
-sm 



From info at arin.net  Tue Mar  4 15:12:07 2014
From: info at arin.net (ARIN)
Date: Tue, 04 Mar 2014 15:12:07 -0500
Subject: [arin-ppml] Advisory Council Meeting Results - February 2014
Message-ID: <53163397.7040405@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 20 February 2014.

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

   ARIN-prop-193 Alignment of 8.3 Needs Requirements to Reality of Business
   ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization 
Requirements
   ARIN-prop-201 Remove Sections 4.6 and 4.7
   ARIN-prop-203 Improved Registry Accuracy Proposal

The AC is continuing to work on the following:

   Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup
   Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New 
Multiple Discrete Networks
   Draft Policy ARIN-2014-1: Out of Region Use
   Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip Language
   Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 
Block Size Requirements
   Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy
   Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations
   Draft Policy ARIN-2014-6: Remove 7.1
   Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation Conservation 
Update
   ARIN-prop-202 Anti-hijack Policy

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

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



From info at arin.net  Tue Mar  4 15:12:28 2014
From: info at arin.net (ARIN)
Date: Tue, 04 Mar 2014 15:12:28 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-8: Alignment of 8.3 Needs
 Requirements to Reality of Business
Message-ID: <531633AC.6050000@arin.net>

On 20 February 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-193 Alignment of 8.3 Needs Requirements to Reality of 
Business" as a Draft Policy.

Draft Policy ARIN-2014-8 is below and can be found at:
https://www.arin.net/policy/proposals/2014_8.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-8 on the Public Policy Mailing List.

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-2014-8
Alignment of 8.3 Needs Requirements to Reality of Business

Date: 4 March 2014

Problem Statement:

8.3 Transfer Policy states: "The recipient must
demonstrate the need for up to a 24-month supply of IP address
resources under current ARIN policies and sign an RSA." This is
problematic post-exhaustion for two reasons:

1) Existing IPv4 policy for end-users requires that the organization
demonstrate they will use TWENTY-FIVE PERCENT of the space immediately.
ARIN staff interpret "immediately" to mean "within 30 days of obtaining
new numbers." NRPM 8.3, however, allows networks to obtain a 2-year 
supply of
addresses. It is, therefore, not rational to expect businesses to use
25% of the space obtained for a 2-year need within 30 days. Such a
requirement has, consistently, prompted requestors to bend the truth in
their dealings with ARIN in order to qualify for the space they need to
operate their network.

2) IPv4 policy for ISPs requires existing utilization of some number of
IPv4 addresses. There is a barrier to entry for new ISPs, designed in
1996 to ensure that DFZ slots were utilized by bona fide networks.
This requirement freezes out new ISP entrants from the 8.3 transfer
market. This formally disallows new ISPs to obtain properly-sized
blocks for their future needs from the market.

This proposal aims to easily fix the math problem in 1), and the
blocker to business in 2).

Policy statement:

Replace in 8.3:
"The recipient must demonstrate the need for up to a 24-month supply of
IP address resources under current ARIN policies and sign an RSA."
with
"The recipient must demonstrate their 24 month needs for number
resources. The transferred block(s) plus the amount of free addresses
currently registered to the organization, must together not be larger
than the demonstrated need. The recipient must sign an RSA."

Comments:
a.Timetable for implementation: Immediate

b.Anything else: Request that ARIN STAFF analyze whether the third
sentence of the proposed text ("The recipient must sign an RSA.") needs
to be in ARIN policy. If not, let's work together to modify this proposal to
remove it.


From info at arin.net  Tue Mar  4 15:12:45 2014
From: info at arin.net (ARIN)
Date: Tue, 04 Mar 2014 15:12:45 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
 and 8.2 Utilization Requirements
Message-ID: <531633BD.1010109@arin.net>

On 20 February 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization 
Requirements" as a Draft Policy.

Draft Policy ARIN-2014-9 is below and can be found at:
https://www.arin.net/policy/proposals/2014_9.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-9 on the Public Policy Mailing List.

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-2014-9
Resolve Conflict Between RSA and 8.2 Utilization Requirements

Date: 4 March 2014

Problem Statement:

8.2 transfer policy has utilization requirements at the time of the 
review of the transfer request.

The RSA section 6 expressly forbids ARIN from de-registering blocks (in 
whole or in part) due to under-utilization or no-justification during 
transfer requests.

This is a direct conflict.

Return and aggregate are not done in collaboration; they are coerced by 
policy without the willing consent of the transfer parties.

We should remove all utilization references from 8.2 language to ensure 
the policy is compliant with the RSA.

Policy statement:

Remove from 8.2:
"In the event that number resources of the combined organizations are no 
longer justified under ARIN policy at the time ARIN becomes aware of the 
transaction, through a transfer request or otherwise, ARIN will work 
with the resource holder(s) to return, aggregate, transfer, or reclaim 
resources as needed to restore compliance via the processes outlined in 
current ARIN policy."

Comments:
a.Timetable for implementation: Immediate
b.Anything else:







From info at arin.net  Tue Mar  4 15:12:59 2014
From: info at arin.net (ARIN)
Date: Tue, 04 Mar 2014 15:12:59 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-10: Remove Sections 4.6 and 4.7
Message-ID: <531633CB.7070600@arin.net>

On 20 February 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-201 Remove Sections 4.6 and 4.7" as a Draft Policy.

Draft Policy ARIN-2014-10 is below and can be found at:
https://www.arin.net/policy/proposals/2014_10.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-10 on the Public Policy Mailing List.

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-2014-10
Remove Sections 4.6 and 4.7

Date: 4 March 2014

Problem Statement:

The ARIN Board of Trustees has suspended sections 4.6 and 4.7 of the 
Number Resource Policy Manual at their January 6, 2014 meeting. This was 
done in response to the potential for abuse of these sections as the 
IPv4 free pool approaches runout.

The last request to use section 4.6, amnesty and aggregation requests, 
was in 2004. The last request to use section 4.7, aggregation requests, 
was in 2008. These sections have not been used to request resources in 
more than five years.

There are a number of organizations who could use these sections as 
justification to request an allocation or assignment that could deplete 
the remaining ARIN IPv4 free pool. This could have unintended 
consequences with ARIN running out so unexpectedly, that outweigh the 
intended benefits the sections were meant to provide.

These sections could also be used to justify large transfers, that would 
put ARIN in an undesirable position trying to reclaim previous 
resources, when the IPv4 pool is depleted. This risk also outweighs the 
intended benefits the sections were meant to provide.

Efforts could be made to patch these sections, and provide additional 
measures to limit abuse. There does not appear to be a need, however, 
given how little the sections have been utilized. As we become aware of 
other implications it may be best to try and deal with them through a 
separate, independent proposal.

Policy statement:

Remove sections 4.6 and 4.7.

Comments:
a.Timetable for implementation: Immediate
b.Anything else:

4.6. Amnesty and Aggregation Requests

4.6.1 Intent of this policy

This policy is intended to allow the community and ARIN staff to work
together with holders of address resources in the best interests of the
community by facilitating the return of unused address space and the
aggregation of existing space in a manner which is in the best interests
of both parties.

All transactions under this policy must either create greater
aggregation (a reduction in the number of prefixes) or the return of
address space. Transactions should only be accepted under this policy if
they are in the interests of the community (e.g. they improve
aggregation or result in a net reclamation of space).


4.6.2 No penalty for returning or aggregating

ARIN shall seek to make the return of address space as convenient and
risk-free to the returning organization as possible. An organization
with several non-contiguous blocks seeking to aggregate and return space
at the same time should be accommodated if possible. If it is possible
to expand one block, for example, to facilitate the return of other
blocks, ARIN should do that.


4.6.3 Return should not force renumbering

An organization shall be allowed to return a partial block of any size
to ARIN. For any return larger than a /24, ARIN shall not require that
the non-returned portion of the block be renumbered unless the returning
organization wishes to do so.


4.6.4 Timeframe for return

Any organization which is returning addresses under this policy shall
negotiate with ARIN an appropriate timeframe in which to return the
addresses after any new resources are received under this policy. In the
case of a simple return, the timeframe shall be immediate. In the case
where renumbering into new addresses out of existing addresses to be
returned is required, the returning organization shall sign a contract
with ARIN which stipulates a final return date not less than 6 months
nor more than 18 months after the receipt of new addresses. If an
organization misses this return date, but, ARIN believes the
organization is working in good faith to complete the renumbering, ARIN
may grant a single extension of 6-12 months as staff deems appropriate
to the situation. Such an extension must be requested in writing (email
to hostmaster at arin.net) by the organization at least 15 days prior to
the original expiration date.


4.6.5 RSA Required if new addresses received

Any organization which receives any additional addresses under this
policy shall be required to sign an ARIN RSA which will apply to all new
addresses issued and to any retained blocks which are expanded under
this policy.


4.6.6 Annual contact required

Any organization which participates in this policy shall be required to
sign an agreement stipulating that ARIN will attempt contact at least
once per year via the contact mechanisms registered for the organization
in Whois. Should ARIN fail to make contact, after reasonable effort the
organization shall be flagged as "unreachable" in Whois. After six
months in "unreachable" status, the organization agrees that ARIN may
consider all resources held by the organization to be abandoned and
reclaim such resources. Should the organization make contact with ARIN
prior to the end of the aforementioned six month period and update their
contact information appropriately, ARIN shall remove the "unreachable"
status and the annual contact cycle shall continue as normal. If the
organization pays annual fees to ARIN, the payment of annual fees shall
be considered sufficient contact.


4.7. Aggregation Requests

If an organization, whether a member or non-member, ISP or end-user,
relinquishes a group of portable, non-aggregatable address blocks to
ARIN, they shall be allowed to receive a block in exchange, /24 or
larger, but no more than the largest block that could contain all of the
returned blocks. Exchanged space shall be returned within 12 months. If
the gain in the number of addresses is greater than 4096, the
aggregation request must be evaluated by the ARIN in accordance with the
current IPv4 allocation policy. If all of the previous address blocks
were maintained in the ARIN database without maintenance fees, the
replacement space shall be as well, but if any one of the returned
blocks had associated maintenance fees, then the replacement block shall
also be subject to maintenance fees.





From info at arin.net  Tue Mar  4 15:13:20 2014
From: info at arin.net (ARIN)
Date: Tue, 04 Mar 2014 15:13:20 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-11: Improved Registry Accuracy
	Proposal
Message-ID: <531633E0.50901@arin.net>

On 20 February 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-203 Improved Registry Accuracy Proposal" as a Draft Policy.

Draft Policy ARIN-2014-11 is below and can be found at:
https://www.arin.net/policy/proposals/2014_11.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-11 on the Public Policy Mailing List.

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-2014-11
Improved Registry Accuracy Proposal

Date: 4 March 2014

Problem Statement

The importance of maintaining accurate records in the ARIN database is
recognized as the Registries principal task and is not being debated.
The Registry is unable to responsibly fulfill this task. Many resource
holders are not incented through mutual benefits to participate in the
registry, the process or the community and instead operate
successfully outside of its bounds further hampering the mission of
accuracy.

Intent

To create a sustainable RIPE 605-like environment in the ARIN region that
provides mutual benefits to legacy holders and ARIN and in support of
vastly improved and accurate registry service.

Policy Changes

Section 1, Adds to "Principles"

Accuracy

The principle of Accuracy guarantees stakeholders that all reasonable
and mutually beneficial steps will be take to insure that the Registry
is as accurate as possible.

Fairness

The principle of Fairness guarantees stakeholders that they will be
treated fairly with respect to whatever class of resources they hold,
whether they are pre or post RIR assigned addresses.

Value Add

The principle of Value Add guarantees that the Registry, in its effort
to insure that all of the principles are applied equitably, will seek
to add value to all resource holders regardless of class by insuring
such thing as rapid update functionalities and reasonably easy
transfer administration.

Mutual Benefit

The principle of Mutual Benefit guarantees that ARIN will enter into
or dissolve contracts related to legacy resource holders in like
fashion of comparable Registries.


Section 2, Adds to "Definitions"

Legacy Internet Resource

Any Internet Resource obtained prior to or otherwise outside the
current system of hierarchical distribution (by allocation or
assignment) through the Regional Internet Registries.

Legacy Internet Resource Holder

The holder of a Legacy Internet Resource. Either by receiving these
resources directly or by receiving (part of) Legacy Internet Resources
from a Legacy Internet Resource Holder.

Registry Service Element

In practice, any Legacy Resource Holder actually avails of a subset of
the Registry Services mentioned above. Where it is necessary to
distinguish between the entire class of Registry Services and the
specific Registry Services actually provided in a particular case, the
latter are described as Registry Service Elements.





From info at arin.net  Tue Mar  4 15:13:36 2014
From: info at arin.net (ARIN)
Date: Tue, 04 Mar 2014 15:13:36 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
Message-ID: <531633F0.3000403@arin.net>

Recommended Draft Policy ARIN-2013-8
Subsequent Allocations for New Multiple Discrete Networks

Revised text for ARIN-2013-8 is below and can be found at:
https://www.arin.net/policy/proposals/2013_8.html

You are encouraged to discuss Draft Policy 2013-8 on the PPML prior to
the upcoming Public Policy Consultation at ARIN 33. Both the discussion 
on the list and at the meeting will be used by the ARIN Advisory Council 
to determine the community consensus for adopting this as policy.

The ARIN Policy Development Process (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)


## * ##


Recommended Draft Policy ARIN-2013-8
Subsequent Allocations for New Multiple Discrete Networks

Date: 4 March 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"Subsequent Allocations for Additional Discrete Network Sites This 
policy enables fair and impartial number resource administration by 
documenting the current practice regarding allocations for additional 
discrete network sites. The ARIN staff has been following a procedure 
that has not been documented until now. By documenting this process the 
community has clear understanding of how to get address space for 
additional network sites.

This is a technically sound proposal that has been in practice for some 
time. It had just not been documented.

This proposal has received several notes of support on the PPML and to 
date has received no negative feedback."

Policy Statement:

IPv4:

Add the following statement to section 4.5.4.

Upon verification that the organization has demonstrated need at its new
discrete network site, the new networks shall be allocated the minimum 
allocation size under section 4.2.1.5 unless the organization can 
demonstrate additional need using the immediate need criteria (4.2.1.6).

IPv6:

Add an additional reference to section 6.11.5.b such that it references 
both the initial allocation and subsequent allocation sections of the 
IPv6 LIR policy.

"Each network will be judged against the existing utilization criteria 
specified in 6.5.2 and 6.5.3 as if it were a separate organization..."



Comments:

a. Timetable for implementation: immediate

b. This policy is being proposed based upon the Policy Implementation & 
Experience Report from ARIN 32.

https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf

c: Older versions of the MDN policy did contain new network criteria. 
This criteria appears to have been dropped during subsequent rewrites of 
the MDN policy. "The organization must not allocate a CIDR block larger 
than the current minimum assignment size of the RIR (currently /20 for 
ARIN) to a new network." 
(https://www.arin.net/policy/archive/nrpm_20041015.pdf)


From info at arin.net  Tue Mar  4 15:13:50 2014
From: info at arin.net (ARIN)
Date: Tue, 04 Mar 2014 15:13:50 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation
 Conservation Update - Revised
Message-ID: <531633FE.8010604@arin.net>

Draft Policy ARIN-2014-7
Section 4.4 Micro Allocation Conservation Update

Revised text for ARIN-2014-7 is below and can be found at:
https://www.arin.net/policy/proposals/2014_7.html

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-2014-7
Section 4.4 Micro Allocation Conservation Update

Date: 4 March 2014

Problem Statement:

Two networks interconnecting are generally considered to be private 
peers. The current policy allows an IXP to receive a micro-allocation 
with only two devices. Given IPv4 exhaustion and the growth of IXPs in 
North America it is prudent to raise the minimum criteria so that 
micro-allocation space is not wasted.

Policy statement:

Change the following paragraph in Section 4.4 from:

Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
two total), ASN, and contact information.

To:

Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
three total), ASN, and contact information.

Comments:
a.Timetable for implementation: Immediate
b.Anything else:


From andrew.dul at quark.net  Tue Mar  4 21:18:24 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Tue, 04 Mar 2014 18:18:24 -0800
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <531633F0.3000403@arin.net>
References: <531633F0.3000403@arin.net>
Message-ID: <53168970.2010909@quark.net>

I support this new version of the policy.  I believe the new text
successfully deals with the issues raised and discussed at the Atlanta
nanog PPC.

Andrew

On 3/4/2014 12:13 PM, ARIN wrote:
> ## * ##
>
>
> Recommended Draft Policy ARIN-2013-8
> Subsequent Allocations for New Multiple Discrete Networks
>
> Date: 4 March 2014
>
> AC's assessment of conformance with the Principles of Internet Number
> Resource Policy:
>
> "Subsequent Allocations for Additional Discrete Network Sites This
> policy enables fair and impartial number resource administration by
> documenting the current practice regarding allocations for additional
> discrete network sites. The ARIN staff has been following a procedure
> that has not been documented until now. By documenting this process
> the community has clear understanding of how to get address space for
> additional network sites.
>
> This is a technically sound proposal that has been in practice for
> some time. It had just not been documented.
>
> This proposal has received several notes of support on the PPML and to
> date has received no negative feedback."
>
> Policy Statement:
>
> IPv4:
>
> Add the following statement to section 4.5.4.
>
> Upon verification that the organization has demonstrated need at its new
> discrete network site, the new networks shall be allocated the minimum
> allocation size under section 4.2.1.5 unless the organization can
> demonstrate additional need using the immediate need criteria (4.2.1.6).
>
> IPv6:
>
> Add an additional reference to section 6.11.5.b such that it
> references both the initial allocation and subsequent allocation
> sections of the IPv6 LIR policy.
>
> "Each network will be judged against the existing utilization criteria
> specified in 6.5.2 and 6.5.3 as if it were a separate organization..."
>
>
>
> Comments:
>
> a. Timetable for implementation: immediate
>
> b. This policy is being proposed based upon the Policy Implementation
> & Experience Report from ARIN 32.
>
> https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
>
>
> c: Older versions of the MDN policy did contain new network criteria.
> This criteria appears to have been dropped during subsequent rewrites
> of the MDN policy. "The organization must not allocate a CIDR block
> larger than the current minimum assignment size of the RIR (currently
> /20 for ARIN) to a new network."
> (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From cja at daydream.com  Wed Mar  5 04:16:45 2014
From: cja at daydream.com (CJ Aronson)
Date: Wed, 5 Mar 2014 09:16:45 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <53168970.2010909@quark.net>
References: <531633F0.3000403@arin.net>
	<53168970.2010909@quark.net>
Message-ID: <CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>

Does anyone else have comments about this proposal?  The text has been
changed slightly based on feedback from the PPC at NANOG.  The change was

from

Upon verification that the organization has already obtained
connectivity at its new discrete network site

to

Upon verification that the organization has demonstrated need at its new
discrete network site

Please send your comments on this change and on the proposal.

Thanks!
-----Cathy


On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net> wrote:

> I support this new version of the policy.  I believe the new text
> successfully deals with the issues raised and discussed at the Atlanta
> nanog PPC.
>
> Andrew
>
> On 3/4/2014 12:13 PM, ARIN wrote:
> > ## * ##
> >
> >
> > Recommended Draft Policy ARIN-2013-8
> > Subsequent Allocations for New Multiple Discrete Networks
> >
> > Date: 4 March 2014
> >
> > AC's assessment of conformance with the Principles of Internet Number
> > Resource Policy:
> >
> > "Subsequent Allocations for Additional Discrete Network Sites This
> > policy enables fair and impartial number resource administration by
> > documenting the current practice regarding allocations for additional
> > discrete network sites. The ARIN staff has been following a procedure
> > that has not been documented until now. By documenting this process
> > the community has clear understanding of how to get address space for
> > additional network sites.
> >
> > This is a technically sound proposal that has been in practice for
> > some time. It had just not been documented.
> >
> > This proposal has received several notes of support on the PPML and to
> > date has received no negative feedback."
> >
> > Policy Statement:
> >
> > IPv4:
> >
> > Add the following statement to section 4.5.4.
> >
> > Upon verification that the organization has demonstrated need at its new
> > discrete network site, the new networks shall be allocated the minimum
> > allocation size under section 4.2.1.5 unless the organization can
> > demonstrate additional need using the immediate need criteria (4.2.1.6).
> >
> > IPv6:
> >
> > Add an additional reference to section 6.11.5.b such that it
> > references both the initial allocation and subsequent allocation
> > sections of the IPv6 LIR policy.
> >
> > "Each network will be judged against the existing utilization criteria
> > specified in 6.5.2 and 6.5.3 as if it were a separate organization..."
> >
> >
> >
> > Comments:
> >
> > a. Timetable for implementation: immediate
> >
> > b. This policy is being proposed based upon the Policy Implementation
> > & Experience Report from ARIN 32.
> >
> >
> https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
> >
> >
> > c: Older versions of the MDN policy did contain new network criteria.
> > This criteria appears to have been dropped during subsequent rewrites
> > of the MDN policy. "The organization must not allocate a CIDR block
> > larger than the current minimum assignment size of the RIR (currently
> > /20 for ARIN) to a new network."
> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20140305/320ecd0a/attachment.htm>

From owen at delong.com  Wed Mar  5 04:24:22 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 5 Mar 2014 01:24:22 -0800
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
	Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>
References: <531633F0.3000403@arin.net> <53168970.2010909@quark.net>
	<CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>
Message-ID: <7D0EEB86-44E6-476B-9470-EEAA9F8828CE@delong.com>

I support the new wording. I consider it a change which is clerical in nature and believe that the proposal is ready for advancement. I believe the community has demonstrated consensus for the draft. However, since it has not seen a PPM, but only the NANOG PPC, I do support bringing it to the wider audience in Chicago before moving it to last call.

Owen

On Mar 5, 2014, at 01:16 , CJ Aronson <cja at daydream.com> wrote:

> Does anyone else have comments about this proposal?  The text has been changed slightly based on feedback from the PPC at NANOG.  The change was
> 
> from
> 
> Upon verification that the organization has already obtained
> connectivity at its new discrete network site
> 
> to
> 
> Upon verification that the organization has demonstrated need at its new
> discrete network site
> 
> Please send your comments on this change and on the proposal.  
> 
> Thanks! 
> -----Cathy
> 
> 
> On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net> wrote:
> I support this new version of the policy.  I believe the new text
> successfully deals with the issues raised and discussed at the Atlanta
> nanog PPC.
> 
> Andrew
> 
> On 3/4/2014 12:13 PM, ARIN wrote:
> > ## * ##
> >
> >
> > Recommended Draft Policy ARIN-2013-8
> > Subsequent Allocations for New Multiple Discrete Networks
> >
> > Date: 4 March 2014
> >
> > AC's assessment of conformance with the Principles of Internet Number
> > Resource Policy:
> >
> > "Subsequent Allocations for Additional Discrete Network Sites This
> > policy enables fair and impartial number resource administration by
> > documenting the current practice regarding allocations for additional
> > discrete network sites. The ARIN staff has been following a procedure
> > that has not been documented until now. By documenting this process
> > the community has clear understanding of how to get address space for
> > additional network sites.
> >
> > This is a technically sound proposal that has been in practice for
> > some time. It had just not been documented.
> >
> > This proposal has received several notes of support on the PPML and to
> > date has received no negative feedback."
> >
> > Policy Statement:
> >
> > IPv4:
> >
> > Add the following statement to section 4.5.4.
> >
> > Upon verification that the organization has demonstrated need at its new
> > discrete network site, the new networks shall be allocated the minimum
> > allocation size under section 4.2.1.5 unless the organization can
> > demonstrate additional need using the immediate need criteria (4.2.1.6).
> >
> > IPv6:
> >
> > Add an additional reference to section 6.11.5.b such that it
> > references both the initial allocation and subsequent allocation
> > sections of the IPv6 LIR policy.
> >
> > "Each network will be judged against the existing utilization criteria
> > specified in 6.5.2 and 6.5.3 as if it were a separate organization..."
> >
> >
> >
> > Comments:
> >
> > a. Timetable for implementation: immediate
> >
> > b. This policy is being proposed based upon the Policy Implementation
> > & Experience Report from ARIN 32.
> >
> > https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
> >
> >
> > c: Older versions of the MDN policy did contain new network criteria.
> > This criteria appears to have been dropped during subsequent rewrites
> > of the MDN policy. "The organization must not allocate a CIDR block
> > larger than the current minimum assignment size of the RIR (currently
> > /20 for ARIN) to a new network."
> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

From hannigan at gmail.com  Wed Mar  5 07:55:04 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 5 Mar 2014 07:55:04 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <531633F0.3000403@arin.net>
References: <531633F0.3000403@arin.net>
Message-ID: <CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>

On Tue, Mar 4, 2014 at 3:13 PM, ARIN <info at arin.net> wrote:


[ clip ]


>
> "Subsequent Allocations for Additional Discrete Network Sites This policy
> enables fair and impartial number resource administration by documenting the
> current practice regarding allocations for additional discrete network
> sites. The ARIN staff has been following a procedure that has not been
> documented until now. By documenting this process the community has clear
> understanding of how to get address space for additional network sites.
>
> This is a technically sound proposal that has been in practice for some
> time. It had just not been documented.
>
> This proposal has received several notes of support on the PPML and to date
> has received no negative feedback."

You must not have been at the aforementioned consultation.


> Add the following statement to section 4.5.4.
>
> Upon verification that the organization has demonstrated need at its new
> discrete network site, the new networks shall be allocated the minimum
> allocation size under section 4.2.1.5 unless the organization can
> demonstrate additional need using the immediate need criteria (4.2.1.6).

Talk about locking someone out of a policy lock, stock and barrel and
flushing "stewardship" down the drain completely. Most MDN users are
going to go straight to 4.2.1.6 only to find that they are locked out
because they aren't contracted as an ISP. They could buy another
OrgID... and pay another exorbitant fee if qualified I guess. If we
really want to limit users to a /22 why not do it across the board?

I'm glad we moved beyond ARIN trying to define business terms between
networks and ARIN customers, but we should move beyond this entirely
and abandon it.

Best,

-M<


From jeffrey.lyon at blacklotus.net  Wed Mar  5 08:12:20 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Wed, 5 Mar 2014 22:12:20 +0900
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>
References: <531633F0.3000403@arin.net> <53168970.2010909@quark.net>
	<CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>
Message-ID: <CACrmG8c3WLA1=g1Z_Q_=o8O2Rt=2rOON_=59o5SrLGZ7hAAkow@mail.gmail.com>

I am opposed to the rewording as the new discrete site is in itself
demonstration of need. There is a technical requirement to provide at
least a /24 of space at any discrete site.

Thanks, Jeff

On Wed, Mar 5, 2014 at 6:16 PM, CJ Aronson <cja at daydream.com> wrote:
> Does anyone else have comments about this proposal?  The text has been
> changed slightly based on feedback from the PPC at NANOG.  The change was
>
> from
>
> Upon verification that the organization has already obtained
> connectivity at its new discrete network site
>
> to
>
>
> Upon verification that the organization has demonstrated need at its new
> discrete network site
>
> Please send your comments on this change and on the proposal.
>
> Thanks!
> -----Cathy
>
>
> On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net> wrote:
>>
>> I support this new version of the policy.  I believe the new text
>> successfully deals with the issues raised and discussed at the Atlanta
>> nanog PPC.
>>
>> Andrew
>>
>> On 3/4/2014 12:13 PM, ARIN wrote:
>> > ## * ##
>> >
>> >
>> > Recommended Draft Policy ARIN-2013-8
>> > Subsequent Allocations for New Multiple Discrete Networks
>> >
>> > Date: 4 March 2014
>> >
>> > AC's assessment of conformance with the Principles of Internet Number
>> > Resource Policy:
>> >
>> > "Subsequent Allocations for Additional Discrete Network Sites This
>> > policy enables fair and impartial number resource administration by
>> > documenting the current practice regarding allocations for additional
>> > discrete network sites. The ARIN staff has been following a procedure
>> > that has not been documented until now. By documenting this process
>> > the community has clear understanding of how to get address space for
>> > additional network sites.
>> >
>> > This is a technically sound proposal that has been in practice for
>> > some time. It had just not been documented.
>> >
>> > This proposal has received several notes of support on the PPML and to
>> > date has received no negative feedback."
>> >
>> > Policy Statement:
>> >
>> > IPv4:
>> >
>> > Add the following statement to section 4.5.4.
>> >
>> > Upon verification that the organization has demonstrated need at its new
>> > discrete network site, the new networks shall be allocated the minimum
>> > allocation size under section 4.2.1.5 unless the organization can
>> > demonstrate additional need using the immediate need criteria (4.2.1.6).
>> >
>> > IPv6:
>> >
>> > Add an additional reference to section 6.11.5.b such that it
>> > references both the initial allocation and subsequent allocation
>> > sections of the IPv6 LIR policy.
>> >
>> > "Each network will be judged against the existing utilization criteria
>> > specified in 6.5.2 and 6.5.3 as if it were a separate organization..."
>> >
>> >
>> >
>> > Comments:
>> >
>> > a. Timetable for implementation: immediate
>> >
>> > b. This policy is being proposed based upon the Policy Implementation
>> > & Experience Report from ARIN 32.
>> >
>> >
>> > https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
>> >
>> >
>> > c: Older versions of the MDN policy did contain new network criteria.
>> > This criteria appears to have been dropped during subsequent rewrites
>> > of the MDN policy. "The organization must not allocate a CIDR block
>> > larger than the current minimum assignment size of the RIR (currently
>> > /20 for ARIN) to a new network."
>> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
>> > _______________________________________________
>> > PPML
>> > You are receiving this message because you are subscribed to
>> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> > Unsubscribe or manage your mailing list subscription at:
>> > http://lists.arin.net/mailman/listinfo/arin-ppml
>> > Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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.



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From cja at daydream.com  Wed Mar  5 08:17:07 2014
From: cja at daydream.com (CJ Aronson)
Date: Wed, 5 Mar 2014 13:17:07 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
References: <531633F0.3000403@arin.net>
	<CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
Message-ID: <CAC6JZKRm=XOB7AGPpedCpG_0p6E9KAx3uaYq7Cynp+sEOxPYGg@mail.gmail.com>

Martin,

See below


On Wed, Mar 5, 2014 at 12:55 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> On Tue, Mar 4, 2014 at 3:13 PM, ARIN <info at arin.net> wrote:
>
>
> [ clip ]
>
>
> >
> > "Subsequent Allocations for Additional Discrete Network Sites This policy
> > enables fair and impartial number resource administration by documenting
> the
> > current practice regarding allocations for additional discrete network
> > sites. The ARIN staff has been following a procedure that has not been
> > documented until now. By documenting this process the community has clear
> > understanding of how to get address space for additional network sites.
> >
> > This is a technically sound proposal that has been in practice for some
> > time. It had just not been documented.
> >
> > This proposal has received several notes of support on the PPML and to
> date
> > has received no negative feedback."
>
> You must not have been at the aforementioned consultation.
>
> First of all I was online listening to the PPC.  Second I didn't write the
changes but I do agree with them and belleve they reflect the concerns that
came up at that meeting.  Third perhaps you should elaborate why you feel
they aren't appropriate changes. The concern at the PPC was that
jusfication of need is already defined in the NRPM and that is what should
be used to justify need.

>
> > Add the following statement to section 4.5.4.
> >
> > Upon verification that the organization has demonstrated need at its new
> > discrete network site, the new networks shall be allocated the minimum
> > allocation size under section 4.2.1.5 unless the organization can
> > demonstrate additional need using the immediate need criteria (4.2.1.6).
>
> Talk about locking someone out of a policy lock, stock and barrel and
> flushing "stewardship" down the drain completely. Most MDN users are
> going to go straight to 4.2.1.6 only to find that they are locked out
> because they aren't contracted as an ISP. They could buy another
> OrgID... and pay another exorbitant fee if qualified I guess. If we
> really want to limit users to a /22 why not do it across the board?
>

There is nothing in this policy that isn't currently happening in practice
with MDN allocations.  I am not sure what "contracted as an ISP" means.

---Cathy

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

From jeffrey.lyon at blacklotus.net  Wed Mar  5 08:17:21 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Wed, 5 Mar 2014 22:17:21 +0900
Subject: [arin-ppml] Potentially credible v4 number pricing data
In-Reply-To: <69B9BA3779753A49865BB9010D560EBB6E9D@newserver.arneill-py.local>
References: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com>
	<69B9BA3779753A49865BB9010D560EBB6E9B@newserver.arneill-py.local>
	<CACrmG8fXF1M9PHff_xvGma4LFABk6_HdvTjuH6XUP+u0Zs9C=w@mail.gmail.com>
	<69B9BA3779753A49865BB9010D560EBB6E9D@newserver.arneill-py.local>
Message-ID: <CACrmG8efZsy_rjVGFqVPX0GOqteFrk1O7MmuDsviL+3HPiJWSQ@mail.gmail.com>

Michel,

>From your explanation, we do not disagree at all :). It is easy to
obtain small allocations from ARIN (for now) but quite difficult to
find contiguous space in the much shorter prefixes. These are the ones
that would have market value. I've requested several /21's and /22's
from ARIN. This observation, of course, would not hold true for APNIC
or RIPE.

Thanks, Jeff

On Wed, Mar 5, 2014 at 3:33 AM, Michel Py
<michel at arneill-py.sacramento.ca.us> wrote:
> Jeff,
>
>> Jeffrey Lyon wrote :
>> I personally disagree that smaller assignments have market value.
>
> We don't disagree much. Put it in context: it was a large scale
> production talk where a /20 is a toy, and the point I was trying to make
> then is that there is not much of a speculation market.
>
> For that audience who turns out to have deep pockets, it would indeed
> make sense to pay MORE per IP to have a short, contiguous prefix rather
> than a boatload of scattered /24s from all over the swamp.
>
> My personal view is that it's still a market where cold heads prevails
> and buyers are coming to it with a specific need, purpose or project.
> The Microsoft / Nortel deal has set the baseline price at $10 a pop, and
> more or less market fluctuations and other factors this is what we are
> still seeing.
>
> That being said, it's a new market, with a very large FUD potential.
> Some people out there are getting excited about the idea of buying a
> /16, carving it up into /24s to resell / lease, and making a buck out of
> it. These wheeler-dealers don't understand the value of a large
> allocation, they think retail where one buys bulk and packages it small.
> I don't see that happening, but never say never.
>
> Michel.
>
>
>>> Michel Py wrote :
>>> About 6 weeks ago, I came up with the following:
>>>
>>> +--------+-------+--------+-------+
>>> ! Prefix !  #IPs ! Per IP !  Cost !
>>> +--------+-------+--------+-------+
>>> !    /16 ! 65536 !    $10 ! $655K !
>>> !    /18 ! 16384 !    $12 ! $196K !
>>> !    /20 !  4096 !    $15 !  $61K !
>>> !    /22 !  1024 !    $22 !  $22K !
>>> +--------+-------+--------+-------+
>>> My files here: http://ipvii.com/



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From cja at daydream.com  Wed Mar  5 08:42:43 2014
From: cja at daydream.com (CJ Aronson)
Date: Wed, 5 Mar 2014 13:42:43 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CACrmG8c3WLA1=g1Z_Q_=o8O2Rt=2rOON_=59o5SrLGZ7hAAkow@mail.gmail.com>
References: <531633F0.3000403@arin.net> <53168970.2010909@quark.net>
	<CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>
	<CACrmG8c3WLA1=g1Z_Q_=o8O2Rt=2rOON_=59o5SrLGZ7hAAkow@mail.gmail.com>
Message-ID: <CAC6JZKRJ9rtn_7X_5QCeKjGKfLuk2VXswZdX0u3asZF01ySfSA@mail.gmail.com>

Jeffrey,

The text was changed from "Upon verification that the organization has
already obtained connectivity at its new discrete network site"  because
folks felt that this meant the connection had to be up and running, not
just under contract.   I believe there is more justification required than
just "having a new site".   I see nothing in the current policy that states
an automatic /24.  Here is the policy text as it stands today from NRPM
(see below)

Thanks!
----Cathy

4.5. Multiple Discrete Networks

Organizations with multiple discrete networks desiring to request new or
additional address space under a single Organization ID must meet the
following criteria:

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



On Wed, Mar 5, 2014 at 1:12 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>wrote:

> I am opposed to the rewording as the new discrete site is in itself
> demonstration of need. There is a technical requirement to provide at
> least a /24 of space at any discrete site.
>
> Thanks, Jeff
>
> On Wed, Mar 5, 2014 at 6:16 PM, CJ Aronson <cja at daydream.com> wrote:
> > Does anyone else have comments about this proposal?  The text has been
> > changed slightly based on feedback from the PPC at NANOG.  The change was
> >
> > from
> >
> > Upon verification that the organization has already obtained
> > connectivity at its new discrete network site
> >
> > to
> >
> >
> > Upon verification that the organization has demonstrated need at its new
> > discrete network site
> >
> > Please send your comments on this change and on the proposal.
> >
> > Thanks!
> > -----Cathy
> >
> >
> > On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net> wrote:
> >>
> >> I support this new version of the policy.  I believe the new text
> >> successfully deals with the issues raised and discussed at the Atlanta
> >> nanog PPC.
> >>
> >> Andrew
> >>
> >> On 3/4/2014 12:13 PM, ARIN wrote:
> >> > ## * ##
> >> >
> >> >
> >> > Recommended Draft Policy ARIN-2013-8
> >> > Subsequent Allocations for New Multiple Discrete Networks
> >> >
> >> > Date: 4 March 2014
> >> >
> >> > AC's assessment of conformance with the Principles of Internet Number
> >> > Resource Policy:
> >> >
> >> > "Subsequent Allocations for Additional Discrete Network Sites This
> >> > policy enables fair and impartial number resource administration by
> >> > documenting the current practice regarding allocations for additional
> >> > discrete network sites. The ARIN staff has been following a procedure
> >> > that has not been documented until now. By documenting this process
> >> > the community has clear understanding of how to get address space for
> >> > additional network sites.
> >> >
> >> > This is a technically sound proposal that has been in practice for
> >> > some time. It had just not been documented.
> >> >
> >> > This proposal has received several notes of support on the PPML and to
> >> > date has received no negative feedback."
> >> >
> >> > Policy Statement:
> >> >
> >> > IPv4:
> >> >
> >> > Add the following statement to section 4.5.4.
> >> >
> >> > Upon verification that the organization has demonstrated need at its
> new
> >> > discrete network site, the new networks shall be allocated the minimum
> >> > allocation size under section 4.2.1.5 unless the organization can
> >> > demonstrate additional need using the immediate need criteria
> (4.2.1.6).
> >> >
> >> > IPv6:
> >> >
> >> > Add an additional reference to section 6.11.5.b such that it
> >> > references both the initial allocation and subsequent allocation
> >> > sections of the IPv6 LIR policy.
> >> >
> >> > "Each network will be judged against the existing utilization criteria
> >> > specified in 6.5.2 and 6.5.3 as if it were a separate organization..."
> >> >
> >> >
> >> >
> >> > Comments:
> >> >
> >> > a. Timetable for implementation: immediate
> >> >
> >> > b. This policy is being proposed based upon the Policy Implementation
> >> > & Experience Report from ARIN 32.
> >> >
> >> >
> >> >
> https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
> >> >
> >> >
> >> > c: Older versions of the MDN policy did contain new network criteria.
> >> > This criteria appears to have been dropped during subsequent rewrites
> >> > of the MDN policy. "The organization must not allocate a CIDR block
> >> > larger than the current minimum assignment size of the RIR (currently
> >> > /20 for ARIN) to a new network."
> >> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
> >> > _______________________________________________
> >> > PPML
> >> > You are receiving this message because you are subscribed to
> >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> > Unsubscribe or manage your mailing list subscription at:
> >> > http://lists.arin.net/mailman/listinfo/arin-ppml
> >> > Please contact info at arin.net if you experience any issues.
> >>
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage 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.
>
>
>
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
> blacklotus.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140305/ef4c1dde/attachment.htm>

From jeffrey.lyon at blacklotus.net  Wed Mar  5 08:45:29 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Wed, 5 Mar 2014 22:45:29 +0900
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAC6JZKRJ9rtn_7X_5QCeKjGKfLuk2VXswZdX0u3asZF01ySfSA@mail.gmail.com>
References: <531633F0.3000403@arin.net> <53168970.2010909@quark.net>
	<CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>
	<CACrmG8c3WLA1=g1Z_Q_=o8O2Rt=2rOON_=59o5SrLGZ7hAAkow@mail.gmail.com>
	<CAC6JZKRJ9rtn_7X_5QCeKjGKfLuk2VXswZdX0u3asZF01ySfSA@mail.gmail.com>
Message-ID: <CACrmG8fBY-jAEh1cBwtVVtKeaNJN-=sTd=Vp_O8LTB4Q4Gdwmg@mail.gmail.com>

Cathy,

I actually find it reasonable that the live connectivity be the
prerequisite for requesting space under 4.5.

Thanks, Jeff

On Wed, Mar 5, 2014 at 10:42 PM, CJ Aronson <cja at daydream.com> wrote:
> Jeffrey,
>
> The text was changed from "Upon verification that the organization has
> already obtained connectivity at its new discrete network site"  because
> folks felt that this meant the connection had to be up and running, not just
> under contract.   I believe there is more justification required than just
> "having a new site".   I see nothing in the current policy that states an
> automatic /24.  Here is the policy text as it stands today from NRPM (see
> below)
>
> Thanks!
> ----Cathy
>
> 4.5. Multiple Discrete Networks
>
> Organizations with multiple discrete networks desiring to request new or
> additional address space under a single Organization ID must meet the
> following criteria:
>
> The organization shall be a single entity and not a consortium of smaller
> independent entities.
> The organization must have compelling criteria for creating discrete
> networks. Examples of a discrete network might include:
>
> Regulatory restrictions for data transmission,
> Geographic distance and diversity between networks,
> Autonomous multihomed discrete networks.
>
> The organization must keep detailed records on how it has allocated space to
> each location, including the date of each allocation.
> When applying for additional internet address registrations from ARIN, the
> organization must demonstrate utilization greater than 50% of both the last
> block allocated and the aggregate sum of all blocks allocated from ARIN to
> that organization. If an organization is unable to satisfy this 50% minimum
> utilization criteria, the organization may alternatively qualify for
> additional internet address registrations by having all unallocated blocks
> of addresses smaller than ARIN's current minimum allocation size.
> The organization may not allocate additional address space to a location
> until each of that location's address blocks are 80% utilized.
> The organization should notify ARIN at the time of the request their desire
> to apply this policy to their account.
>
>
>
> On Wed, Mar 5, 2014 at 1:12 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
> wrote:
>>
>> I am opposed to the rewording as the new discrete site is in itself
>> demonstration of need. There is a technical requirement to provide at
>> least a /24 of space at any discrete site.
>>
>> Thanks, Jeff
>>
>> On Wed, Mar 5, 2014 at 6:16 PM, CJ Aronson <cja at daydream.com> wrote:
>> > Does anyone else have comments about this proposal?  The text has been
>> > changed slightly based on feedback from the PPC at NANOG.  The change
>> > was
>> >
>> > from
>> >
>> > Upon verification that the organization has already obtained
>> > connectivity at its new discrete network site
>> >
>> > to
>> >
>> >
>> > Upon verification that the organization has demonstrated need at its new
>> > discrete network site
>> >
>> > Please send your comments on this change and on the proposal.
>> >
>> > Thanks!
>> > -----Cathy
>> >
>> >
>> > On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net> wrote:
>> >>
>> >> I support this new version of the policy.  I believe the new text
>> >> successfully deals with the issues raised and discussed at the Atlanta
>> >> nanog PPC.
>> >>
>> >> Andrew
>> >>
>> >> On 3/4/2014 12:13 PM, ARIN wrote:
>> >> > ## * ##
>> >> >
>> >> >
>> >> > Recommended Draft Policy ARIN-2013-8
>> >> > Subsequent Allocations for New Multiple Discrete Networks
>> >> >
>> >> > Date: 4 March 2014
>> >> >
>> >> > AC's assessment of conformance with the Principles of Internet Number
>> >> > Resource Policy:
>> >> >
>> >> > "Subsequent Allocations for Additional Discrete Network Sites This
>> >> > policy enables fair and impartial number resource administration by
>> >> > documenting the current practice regarding allocations for additional
>> >> > discrete network sites. The ARIN staff has been following a procedure
>> >> > that has not been documented until now. By documenting this process
>> >> > the community has clear understanding of how to get address space for
>> >> > additional network sites.
>> >> >
>> >> > This is a technically sound proposal that has been in practice for
>> >> > some time. It had just not been documented.
>> >> >
>> >> > This proposal has received several notes of support on the PPML and
>> >> > to
>> >> > date has received no negative feedback."
>> >> >
>> >> > Policy Statement:
>> >> >
>> >> > IPv4:
>> >> >
>> >> > Add the following statement to section 4.5.4.
>> >> >
>> >> > Upon verification that the organization has demonstrated need at its
>> >> > new
>> >> > discrete network site, the new networks shall be allocated the
>> >> > minimum
>> >> > allocation size under section 4.2.1.5 unless the organization can
>> >> > demonstrate additional need using the immediate need criteria
>> >> > (4.2.1.6).
>> >> >
>> >> > IPv6:
>> >> >
>> >> > Add an additional reference to section 6.11.5.b such that it
>> >> > references both the initial allocation and subsequent allocation
>> >> > sections of the IPv6 LIR policy.
>> >> >
>> >> > "Each network will be judged against the existing utilization
>> >> > criteria
>> >> > specified in 6.5.2 and 6.5.3 as if it were a separate
>> >> > organization..."
>> >> >
>> >> >
>> >> >
>> >> > Comments:
>> >> >
>> >> > a. Timetable for implementation: immediate
>> >> >
>> >> > b. This policy is being proposed based upon the Policy Implementation
>> >> > & Experience Report from ARIN 32.
>> >> >
>> >> >
>> >> >
>> >> > https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
>> >> >
>> >> >
>> >> > c: Older versions of the MDN policy did contain new network criteria.
>> >> > This criteria appears to have been dropped during subsequent rewrites
>> >> > of the MDN policy. "The organization must not allocate a CIDR block
>> >> > larger than the current minimum assignment size of the RIR (currently
>> >> > /20 for ARIN) to a new network."
>> >> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
>> >> > _______________________________________________
>> >> > PPML
>> >> > You are receiving this message because you are subscribed to
>> >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> >> > Unsubscribe or manage your mailing list subscription at:
>> >> > http://lists.arin.net/mailman/listinfo/arin-ppml
>> >> > Please contact info at arin.net if you experience any issues.
>> >>
>> >> _______________________________________________
>> >> PPML
>> >> You are receiving this message because you are subscribed to
>> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> >> Unsubscribe or manage 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.
>>
>>
>>
>> --
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>> blacklotus.net
>
>



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From cja at daydream.com  Wed Mar  5 08:50:52 2014
From: cja at daydream.com (CJ Aronson)
Date: Wed, 5 Mar 2014 13:50:52 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CACrmG8fBY-jAEh1cBwtVVtKeaNJN-=sTd=Vp_O8LTB4Q4Gdwmg@mail.gmail.com>
References: <531633F0.3000403@arin.net> <53168970.2010909@quark.net>
	<CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>
	<CACrmG8c3WLA1=g1Z_Q_=o8O2Rt=2rOON_=59o5SrLGZ7hAAkow@mail.gmail.com>
	<CAC6JZKRJ9rtn_7X_5QCeKjGKfLuk2VXswZdX0u3asZF01ySfSA@mail.gmail.com>
	<CACrmG8fBY-jAEh1cBwtVVtKeaNJN-=sTd=Vp_O8LTB4Q4Gdwmg@mail.gmail.com>
Message-ID: <CAC6JZKR+c=0K574rPAaxuap7QeHdyUpJBC4GC9f6yYKBtq7Hzg@mail.gmail.com>

Okay thanks for the feedback.  Can you tell me.. how should the ISP set up
the live connection without address space for it?  Should they have to use
some other block and then readdress it when they get the allocation from
ARIN?   What if the ISP doesn't have a block to use temporarily?

This requirement would be something that is not required right now.

Thanks!
-----Cathy


On Wed, Mar 5, 2014 at 1:45 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>wrote:

> Cathy,
>
> I actually find it reasonable that the live connectivity be the
> prerequisite for requesting space under 4.5.
>
> Thanks, Jeff
>
> On Wed, Mar 5, 2014 at 10:42 PM, CJ Aronson <cja at daydream.com> wrote:
> > Jeffrey,
> >
> > The text was changed from "Upon verification that the organization has
> > already obtained connectivity at its new discrete network site"  because
> > folks felt that this meant the connection had to be up and running, not
> just
> > under contract.   I believe there is more justification required than
> just
> > "having a new site".   I see nothing in the current policy that states an
> > automatic /24.  Here is the policy text as it stands today from NRPM (see
> > below)
> >
> > Thanks!
> > ----Cathy
> >
> > 4.5. Multiple Discrete Networks
> >
> > Organizations with multiple discrete networks desiring to request new or
> > additional address space under a single Organization ID must meet the
> > following criteria:
> >
> > The organization shall be a single entity and not a consortium of smaller
> > independent entities.
> > The organization must have compelling criteria for creating discrete
> > networks. Examples of a discrete network might include:
> >
> > Regulatory restrictions for data transmission,
> > Geographic distance and diversity between networks,
> > Autonomous multihomed discrete networks.
> >
> > The organization must keep detailed records on how it has allocated
> space to
> > each location, including the date of each allocation.
> > When applying for additional internet address registrations from ARIN,
> the
> > organization must demonstrate utilization greater than 50% of both the
> last
> > block allocated and the aggregate sum of all blocks allocated from ARIN
> to
> > that organization. If an organization is unable to satisfy this 50%
> minimum
> > utilization criteria, the organization may alternatively qualify for
> > additional internet address registrations by having all unallocated
> blocks
> > of addresses smaller than ARIN's current minimum allocation size.
> > The organization may not allocate additional address space to a location
> > until each of that location's address blocks are 80% utilized.
> > The organization should notify ARIN at the time of the request their
> desire
> > to apply this policy to their account.
> >
> >
> >
> > On Wed, Mar 5, 2014 at 1:12 PM, Jeffrey Lyon <
> jeffrey.lyon at blacklotus.net>
> > wrote:
> >>
> >> I am opposed to the rewording as the new discrete site is in itself
> >> demonstration of need. There is a technical requirement to provide at
> >> least a /24 of space at any discrete site.
> >>
> >> Thanks, Jeff
> >>
> >> On Wed, Mar 5, 2014 at 6:16 PM, CJ Aronson <cja at daydream.com> wrote:
> >> > Does anyone else have comments about this proposal?  The text has been
> >> > changed slightly based on feedback from the PPC at NANOG.  The change
> >> > was
> >> >
> >> > from
> >> >
> >> > Upon verification that the organization has already obtained
> >> > connectivity at its new discrete network site
> >> >
> >> > to
> >> >
> >> >
> >> > Upon verification that the organization has demonstrated need at its
> new
> >> > discrete network site
> >> >
> >> > Please send your comments on this change and on the proposal.
> >> >
> >> > Thanks!
> >> > -----Cathy
> >> >
> >> >
> >> > On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net>
> wrote:
> >> >>
> >> >> I support this new version of the policy.  I believe the new text
> >> >> successfully deals with the issues raised and discussed at the
> Atlanta
> >> >> nanog PPC.
> >> >>
> >> >> Andrew
> >> >>
> >> >> On 3/4/2014 12:13 PM, ARIN wrote:
> >> >> > ## * ##
> >> >> >
> >> >> >
> >> >> > Recommended Draft Policy ARIN-2013-8
> >> >> > Subsequent Allocations for New Multiple Discrete Networks
> >> >> >
> >> >> > Date: 4 March 2014
> >> >> >
> >> >> > AC's assessment of conformance with the Principles of Internet
> Number
> >> >> > Resource Policy:
> >> >> >
> >> >> > "Subsequent Allocations for Additional Discrete Network Sites This
> >> >> > policy enables fair and impartial number resource administration by
> >> >> > documenting the current practice regarding allocations for
> additional
> >> >> > discrete network sites. The ARIN staff has been following a
> procedure
> >> >> > that has not been documented until now. By documenting this process
> >> >> > the community has clear understanding of how to get address space
> for
> >> >> > additional network sites.
> >> >> >
> >> >> > This is a technically sound proposal that has been in practice for
> >> >> > some time. It had just not been documented.
> >> >> >
> >> >> > This proposal has received several notes of support on the PPML and
> >> >> > to
> >> >> > date has received no negative feedback."
> >> >> >
> >> >> > Policy Statement:
> >> >> >
> >> >> > IPv4:
> >> >> >
> >> >> > Add the following statement to section 4.5.4.
> >> >> >
> >> >> > Upon verification that the organization has demonstrated need at
> its
> >> >> > new
> >> >> > discrete network site, the new networks shall be allocated the
> >> >> > minimum
> >> >> > allocation size under section 4.2.1.5 unless the organization can
> >> >> > demonstrate additional need using the immediate need criteria
> >> >> > (4.2.1.6).
> >> >> >
> >> >> > IPv6:
> >> >> >
> >> >> > Add an additional reference to section 6.11.5.b such that it
> >> >> > references both the initial allocation and subsequent allocation
> >> >> > sections of the IPv6 LIR policy.
> >> >> >
> >> >> > "Each network will be judged against the existing utilization
> >> >> > criteria
> >> >> > specified in 6.5.2 and 6.5.3 as if it were a separate
> >> >> > organization..."
> >> >> >
> >> >> >
> >> >> >
> >> >> > Comments:
> >> >> >
> >> >> > a. Timetable for implementation: immediate
> >> >> >
> >> >> > b. This policy is being proposed based upon the Policy
> Implementation
> >> >> > & Experience Report from ARIN 32.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
> >> >> >
> >> >> >
> >> >> > c: Older versions of the MDN policy did contain new network
> criteria.
> >> >> > This criteria appears to have been dropped during subsequent
> rewrites
> >> >> > of the MDN policy. "The organization must not allocate a CIDR block
> >> >> > larger than the current minimum assignment size of the RIR
> (currently
> >> >> > /20 for ARIN) to a new network."
> >> >> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
> >> >> > _______________________________________________
> >> >> > PPML
> >> >> > You are receiving this message because you are subscribed to
> >> >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> >> > Unsubscribe or manage your mailing list subscription at:
> >> >> > http://lists.arin.net/mailman/listinfo/arin-ppml
> >> >> > Please contact info at arin.net if you experience any issues.
> >> >>
> >> >> _______________________________________________
> >> >> PPML
> >> >> You are receiving this message because you are subscribed to
> >> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> >> Unsubscribe or manage 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.
> >>
> >>
> >>
> >> --
> >> Jeffrey A. Lyon, CISSP-ISSMP
> >> Fellow, Black Lotus Communications
> >> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
> >> blacklotus.net
> >
> >
>
>
>
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
> blacklotus.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140305/60b2f37f/attachment.htm>

From jeffrey.lyon at blacklotus.net  Wed Mar  5 08:54:40 2014
From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon)
Date: Wed, 5 Mar 2014 22:54:40 +0900
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAC6JZKR+c=0K574rPAaxuap7QeHdyUpJBC4GC9f6yYKBtq7Hzg@mail.gmail.com>
References: <531633F0.3000403@arin.net> <53168970.2010909@quark.net>
	<CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>
	<CACrmG8c3WLA1=g1Z_Q_=o8O2Rt=2rOON_=59o5SrLGZ7hAAkow@mail.gmail.com>
	<CAC6JZKRJ9rtn_7X_5QCeKjGKfLuk2VXswZdX0u3asZF01ySfSA@mail.gmail.com>
	<CACrmG8fBY-jAEh1cBwtVVtKeaNJN-=sTd=Vp_O8LTB4Q4Gdwmg@mail.gmail.com>
	<CAC6JZKR+c=0K574rPAaxuap7QeHdyUpJBC4GC9f6yYKBtq7Hzg@mail.gmail.com>
Message-ID: <CACrmG8cBFFyKA=Hou+AgAnEQ_RLg1iA-GBD-CwRK1DR2RM3+PQ@mail.gmail.com>

Cathy,

In my own recent experience, Black Lotus obtained a /22 under 4.5 for
a new location in Ashburn. The circuits were all purchased and BGP
established using /30's provided by the carrier. No announcements were
made until after this was done and ARIN space was requested.

Thanks, Jeff

On Wed, Mar 5, 2014 at 10:50 PM, CJ Aronson <cja at daydream.com> wrote:
> Okay thanks for the feedback.  Can you tell me.. how should the ISP set up
> the live connection without address space for it?  Should they have to use
> some other block and then readdress it when they get the allocation from
> ARIN?   What if the ISP doesn't have a block to use temporarily?
>
> This requirement would be something that is not required right now.
>
> Thanks!
> -----Cathy
>
>
> On Wed, Mar 5, 2014 at 1:45 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
> wrote:
>>
>> Cathy,
>>
>> I actually find it reasonable that the live connectivity be the
>> prerequisite for requesting space under 4.5.
>>
>> Thanks, Jeff
>>
>> On Wed, Mar 5, 2014 at 10:42 PM, CJ Aronson <cja at daydream.com> wrote:
>> > Jeffrey,
>> >
>> > The text was changed from "Upon verification that the organization has
>> > already obtained connectivity at its new discrete network site"  because
>> > folks felt that this meant the connection had to be up and running, not
>> > just
>> > under contract.   I believe there is more justification required than
>> > just
>> > "having a new site".   I see nothing in the current policy that states
>> > an
>> > automatic /24.  Here is the policy text as it stands today from NRPM
>> > (see
>> > below)
>> >
>> > Thanks!
>> > ----Cathy
>> >
>> > 4.5. Multiple Discrete Networks
>> >
>> > Organizations with multiple discrete networks desiring to request new or
>> > additional address space under a single Organization ID must meet the
>> > following criteria:
>> >
>> > The organization shall be a single entity and not a consortium of
>> > smaller
>> > independent entities.
>> > The organization must have compelling criteria for creating discrete
>> > networks. Examples of a discrete network might include:
>> >
>> > Regulatory restrictions for data transmission,
>> > Geographic distance and diversity between networks,
>> > Autonomous multihomed discrete networks.
>> >
>> > The organization must keep detailed records on how it has allocated
>> > space to
>> > each location, including the date of each allocation.
>> > When applying for additional internet address registrations from ARIN,
>> > the
>> > organization must demonstrate utilization greater than 50% of both the
>> > last
>> > block allocated and the aggregate sum of all blocks allocated from ARIN
>> > to
>> > that organization. If an organization is unable to satisfy this 50%
>> > minimum
>> > utilization criteria, the organization may alternatively qualify for
>> > additional internet address registrations by having all unallocated
>> > blocks
>> > of addresses smaller than ARIN's current minimum allocation size.
>> > The organization may not allocate additional address space to a location
>> > until each of that location's address blocks are 80% utilized.
>> > The organization should notify ARIN at the time of the request their
>> > desire
>> > to apply this policy to their account.
>> >
>> >
>> >
>> > On Wed, Mar 5, 2014 at 1:12 PM, Jeffrey Lyon
>> > <jeffrey.lyon at blacklotus.net>
>> > wrote:
>> >>
>> >> I am opposed to the rewording as the new discrete site is in itself
>> >> demonstration of need. There is a technical requirement to provide at
>> >> least a /24 of space at any discrete site.
>> >>
>> >> Thanks, Jeff
>> >>
>> >> On Wed, Mar 5, 2014 at 6:16 PM, CJ Aronson <cja at daydream.com> wrote:
>> >> > Does anyone else have comments about this proposal?  The text has
>> >> > been
>> >> > changed slightly based on feedback from the PPC at NANOG.  The change
>> >> > was
>> >> >
>> >> > from
>> >> >
>> >> > Upon verification that the organization has already obtained
>> >> > connectivity at its new discrete network site
>> >> >
>> >> > to
>> >> >
>> >> >
>> >> > Upon verification that the organization has demonstrated need at its
>> >> > new
>> >> > discrete network site
>> >> >
>> >> > Please send your comments on this change and on the proposal.
>> >> >
>> >> > Thanks!
>> >> > -----Cathy
>> >> >
>> >> >
>> >> > On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net>
>> >> > wrote:
>> >> >>
>> >> >> I support this new version of the policy.  I believe the new text
>> >> >> successfully deals with the issues raised and discussed at the
>> >> >> Atlanta
>> >> >> nanog PPC.
>> >> >>
>> >> >> Andrew
>> >> >>
>> >> >> On 3/4/2014 12:13 PM, ARIN wrote:
>> >> >> > ## * ##
>> >> >> >
>> >> >> >
>> >> >> > Recommended Draft Policy ARIN-2013-8
>> >> >> > Subsequent Allocations for New Multiple Discrete Networks
>> >> >> >
>> >> >> > Date: 4 March 2014
>> >> >> >
>> >> >> > AC's assessment of conformance with the Principles of Internet
>> >> >> > Number
>> >> >> > Resource Policy:
>> >> >> >
>> >> >> > "Subsequent Allocations for Additional Discrete Network Sites This
>> >> >> > policy enables fair and impartial number resource administration
>> >> >> > by
>> >> >> > documenting the current practice regarding allocations for
>> >> >> > additional
>> >> >> > discrete network sites. The ARIN staff has been following a
>> >> >> > procedure
>> >> >> > that has not been documented until now. By documenting this
>> >> >> > process
>> >> >> > the community has clear understanding of how to get address space
>> >> >> > for
>> >> >> > additional network sites.
>> >> >> >
>> >> >> > This is a technically sound proposal that has been in practice for
>> >> >> > some time. It had just not been documented.
>> >> >> >
>> >> >> > This proposal has received several notes of support on the PPML
>> >> >> > and
>> >> >> > to
>> >> >> > date has received no negative feedback."
>> >> >> >
>> >> >> > Policy Statement:
>> >> >> >
>> >> >> > IPv4:
>> >> >> >
>> >> >> > Add the following statement to section 4.5.4.
>> >> >> >
>> >> >> > Upon verification that the organization has demonstrated need at
>> >> >> > its
>> >> >> > new
>> >> >> > discrete network site, the new networks shall be allocated the
>> >> >> > minimum
>> >> >> > allocation size under section 4.2.1.5 unless the organization can
>> >> >> > demonstrate additional need using the immediate need criteria
>> >> >> > (4.2.1.6).
>> >> >> >
>> >> >> > IPv6:
>> >> >> >
>> >> >> > Add an additional reference to section 6.11.5.b such that it
>> >> >> > references both the initial allocation and subsequent allocation
>> >> >> > sections of the IPv6 LIR policy.
>> >> >> >
>> >> >> > "Each network will be judged against the existing utilization
>> >> >> > criteria
>> >> >> > specified in 6.5.2 and 6.5.3 as if it were a separate
>> >> >> > organization..."
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Comments:
>> >> >> >
>> >> >> > a. Timetable for implementation: immediate
>> >> >> >
>> >> >> > b. This policy is being proposed based upon the Policy
>> >> >> > Implementation
>> >> >> > & Experience Report from ARIN 32.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
>> >> >> >
>> >> >> >
>> >> >> > c: Older versions of the MDN policy did contain new network
>> >> >> > criteria.
>> >> >> > This criteria appears to have been dropped during subsequent
>> >> >> > rewrites
>> >> >> > of the MDN policy. "The organization must not allocate a CIDR
>> >> >> > block
>> >> >> > larger than the current minimum assignment size of the RIR
>> >> >> > (currently
>> >> >> > /20 for ARIN) to a new network."
>> >> >> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
>> >> >> > _______________________________________________
>> >> >> > PPML
>> >> >> > You are receiving this message because you are subscribed to
>> >> >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> >> >> > Unsubscribe or manage your mailing list subscription at:
>> >> >> > http://lists.arin.net/mailman/listinfo/arin-ppml
>> >> >> > Please contact info at arin.net if you experience any issues.
>> >> >>
>> >> >> _______________________________________________
>> >> >> PPML
>> >> >> You are receiving this message because you are subscribed to
>> >> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> >> >> Unsubscribe or manage 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.
>> >>
>> >>
>> >>
>> >> --
>> >> Jeffrey A. Lyon, CISSP-ISSMP
>> >> Fellow, Black Lotus Communications
>> >> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>> >> blacklotus.net
>> >
>> >
>>
>>
>>
>> --
>> Jeffrey A. Lyon, CISSP-ISSMP
>> Fellow, Black Lotus Communications
>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>> blacklotus.net
>
>



-- 
Jeffrey A. Lyon, CISSP-ISSMP
Fellow, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net


From hannigan at gmail.com  Wed Mar  5 08:54:50 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 5 Mar 2014 08:54:50 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAC6JZKRm=XOB7AGPpedCpG_0p6E9KAx3uaYq7Cynp+sEOxPYGg@mail.gmail.com>
References: <531633F0.3000403@arin.net>
	<CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
	<CAC6JZKRm=XOB7AGPpedCpG_0p6E9KAx3uaYq7Cynp+sEOxPYGg@mail.gmail.com>
Message-ID: <CAMDXq5M1xhcr66_JMZxW-5vtG056FTqMu8CDL13gEaXoWn9UOg@mail.gmail.com>

On Wed, Mar 5, 2014 at 8:17 AM, CJ Aronson <cja at daydream.com> wrote:


[ clip ]

>> You must not have been at the aforementioned consultation.
>>
> First of all I was online listening to the PPC.  Second I didn't write the

You were registered:

http://bit.ly/1dqQhdF

But you didn't say a word during the entire discussion and you are the
shepherd. And considering that I spoke specifically on this topic at
the PPC, that is outright shocking! :-)

> changes but I do agree with them and belleve they reflect the concerns that
> came up at that meeting.

Once you scrub the AC cheer leading, there was no support for these
changes. No change would support that context.

You can see for yourself here:

http://bit.ly/1g9Wg3T


>>
>> > Add the following statement to section 4.5.4.
>> >
>> > Upon verification that the organization has demonstrated need at its new
>> > discrete network site, the new networks shall be allocated the minimum
>> > allocation size under section 4.2.1.5 unless the organization can
>> > demonstrate additional need using the immediate need criteria (4.2.1.6).
>>
>> Talk about locking someone out of a policy lock, stock and barrel and
>> flushing "stewardship" down the drain completely. Most MDN users are
>> going to go straight to 4.2.1.6 only to find that they are locked out
>> because they aren't contracted as an ISP. They could buy another
>> OrgID... and pay another exorbitant fee if qualified I guess. If we
>> really want to limit users to a /22 why not do it across the board?
>
>
> There is nothing in this policy that isn't currently happening in practice
> with MDN allocations.  I am not sure what "contracted as an ISP" means.
>

If an end-user attempts to use 4.2.1.6 they won't be turned away?

4.2.1.6 --- "If an ISP has an immediate need for address space, "

Force feeding accomplishes at least one parties objectives, but always
result in an unhappy patient. The AC needs to leave this alone
considering that, according to multiple AC members now, it changes
nothing.


Best,

-M<


From hannigan at gmail.com  Wed Mar  5 08:59:49 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 5 Mar 2014 08:59:49 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CACrmG8fBY-jAEh1cBwtVVtKeaNJN-=sTd=Vp_O8LTB4Q4Gdwmg@mail.gmail.com>
References: <531633F0.3000403@arin.net> <53168970.2010909@quark.net>
	<CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3XpBNHWw@mail.gmail.com>
	<CACrmG8c3WLA1=g1Z_Q_=o8O2Rt=2rOON_=59o5SrLGZ7hAAkow@mail.gmail.com>
	<CAC6JZKRJ9rtn_7X_5QCeKjGKfLuk2VXswZdX0u3asZF01ySfSA@mail.gmail.com>
	<CACrmG8fBY-jAEh1cBwtVVtKeaNJN-=sTd=Vp_O8LTB4Q4Gdwmg@mail.gmail.com>
Message-ID: <CAMDXq5M3ouwYa71Vm29ikHrVxkpk0TUyy60FTKvXvEUewuv3-w@mail.gmail.com>

Do explain. So a network operator should enter into a bandwidth
contract anticipating that it might get addresses from ARIN and if it
doesnt or doesn't get an adequate amount to fully utilize their
capacity they should eat that cost or loss so that it's "good for
ARIN"?

Not sure how that's good for anyone.


Best,

-M<


On Wed, Mar 5, 2014 at 8:45 AM, Jeffrey Lyon
<jeffrey.lyon at blacklotus.net> wrote:
> Cathy,
>
> I actually find it reasonable that the live connectivity be the
> prerequisite for requesting space under 4.5.
>
> Thanks, Jeff
>
> On Wed, Mar 5, 2014 at 10:42 PM, CJ Aronson <cja at daydream.com> wrote:
>> Jeffrey,
>>
>> The text was changed from "Upon verification that the organization has
>> already obtained connectivity at its new discrete network site"  because
>> folks felt that this meant the connection had to be up and running, not just
>> under contract.   I believe there is more justification required than just
>> "having a new site".   I see nothing in the current policy that states an
>> automatic /24.  Here is the policy text as it stands today from NRPM (see
>> below)
>>
>> Thanks!
>> ----Cathy
>>
>> 4.5. Multiple Discrete Networks
>>
>> Organizations with multiple discrete networks desiring to request new or
>> additional address space under a single Organization ID must meet the
>> following criteria:
>>
>> The organization shall be a single entity and not a consortium of smaller
>> independent entities.
>> The organization must have compelling criteria for creating discrete
>> networks. Examples of a discrete network might include:
>>
>> Regulatory restrictions for data transmission,
>> Geographic distance and diversity between networks,
>> Autonomous multihomed discrete networks.
>>
>> The organization must keep detailed records on how it has allocated space to
>> each location, including the date of each allocation.
>> When applying for additional internet address registrations from ARIN, the
>> organization must demonstrate utilization greater than 50% of both the last
>> block allocated and the aggregate sum of all blocks allocated from ARIN to
>> that organization. If an organization is unable to satisfy this 50% minimum
>> utilization criteria, the organization may alternatively qualify for
>> additional internet address registrations by having all unallocated blocks
>> of addresses smaller than ARIN's current minimum allocation size.
>> The organization may not allocate additional address space to a location
>> until each of that location's address blocks are 80% utilized.
>> The organization should notify ARIN at the time of the request their desire
>> to apply this policy to their account.
>>
>>
>>
>> On Wed, Mar 5, 2014 at 1:12 PM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net>
>> wrote:
>>>
>>> I am opposed to the rewording as the new discrete site is in itself
>>> demonstration of need. There is a technical requirement to provide at
>>> least a /24 of space at any discrete site.
>>>
>>> Thanks, Jeff
>>>
>>> On Wed, Mar 5, 2014 at 6:16 PM, CJ Aronson <cja at daydream.com> wrote:
>>> > Does anyone else have comments about this proposal?  The text has been
>>> > changed slightly based on feedback from the PPC at NANOG.  The change
>>> > was
>>> >
>>> > from
>>> >
>>> > Upon verification that the organization has already obtained
>>> > connectivity at its new discrete network site
>>> >
>>> > to
>>> >
>>> >
>>> > Upon verification that the organization has demonstrated need at its new
>>> > discrete network site
>>> >
>>> > Please send your comments on this change and on the proposal.
>>> >
>>> > Thanks!
>>> > -----Cathy
>>> >
>>> >
>>> > On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net> wrote:
>>> >>
>>> >> I support this new version of the policy.  I believe the new text
>>> >> successfully deals with the issues raised and discussed at the Atlanta
>>> >> nanog PPC.
>>> >>
>>> >> Andrew
>>> >>
>>> >> On 3/4/2014 12:13 PM, ARIN wrote:
>>> >> > ## * ##
>>> >> >
>>> >> >
>>> >> > Recommended Draft Policy ARIN-2013-8
>>> >> > Subsequent Allocations for New Multiple Discrete Networks
>>> >> >
>>> >> > Date: 4 March 2014
>>> >> >
>>> >> > AC's assessment of conformance with the Principles of Internet Number
>>> >> > Resource Policy:
>>> >> >
>>> >> > "Subsequent Allocations for Additional Discrete Network Sites This
>>> >> > policy enables fair and impartial number resource administration by
>>> >> > documenting the current practice regarding allocations for additional
>>> >> > discrete network sites. The ARIN staff has been following a procedure
>>> >> > that has not been documented until now. By documenting this process
>>> >> > the community has clear understanding of how to get address space for
>>> >> > additional network sites.
>>> >> >
>>> >> > This is a technically sound proposal that has been in practice for
>>> >> > some time. It had just not been documented.
>>> >> >
>>> >> > This proposal has received several notes of support on the PPML and
>>> >> > to
>>> >> > date has received no negative feedback."
>>> >> >
>>> >> > Policy Statement:
>>> >> >
>>> >> > IPv4:
>>> >> >
>>> >> > Add the following statement to section 4.5.4.
>>> >> >
>>> >> > Upon verification that the organization has demonstrated need at its
>>> >> > new
>>> >> > discrete network site, the new networks shall be allocated the
>>> >> > minimum
>>> >> > allocation size under section 4.2.1.5 unless the organization can
>>> >> > demonstrate additional need using the immediate need criteria
>>> >> > (4.2.1.6).
>>> >> >
>>> >> > IPv6:
>>> >> >
>>> >> > Add an additional reference to section 6.11.5.b such that it
>>> >> > references both the initial allocation and subsequent allocation
>>> >> > sections of the IPv6 LIR policy.
>>> >> >
>>> >> > "Each network will be judged against the existing utilization
>>> >> > criteria
>>> >> > specified in 6.5.2 and 6.5.3 as if it were a separate
>>> >> > organization..."
>>> >> >
>>> >> >
>>> >> >
>>> >> > Comments:
>>> >> >
>>> >> > a. Timetable for implementation: immediate
>>> >> >
>>> >> > b. This policy is being proposed based upon the Policy Implementation
>>> >> > & Experience Report from ARIN 32.
>>> >> >
>>> >> >
>>> >> >
>>> >> > https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
>>> >> >
>>> >> >
>>> >> > c: Older versions of the MDN policy did contain new network criteria.
>>> >> > This criteria appears to have been dropped during subsequent rewrites
>>> >> > of the MDN policy. "The organization must not allocate a CIDR block
>>> >> > larger than the current minimum assignment size of the RIR (currently
>>> >> > /20 for ARIN) to a new network."
>>> >> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
>>> >> > _______________________________________________
>>> >> > PPML
>>> >> > You are receiving this message because you are subscribed to
>>> >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> >> > Unsubscribe or manage your mailing list subscription at:
>>> >> > http://lists.arin.net/mailman/listinfo/arin-ppml
>>> >> > Please contact info at arin.net if you experience any issues.
>>> >>
>>> >> _______________________________________________
>>> >> PPML
>>> >> You are receiving this message because you are subscribed to
>>> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> >> Unsubscribe or manage 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.
>>>
>>>
>>>
>>> --
>>> Jeffrey A. Lyon, CISSP-ISSMP
>>> Fellow, Black Lotus Communications
>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>> blacklotus.net
>>
>>
>
>
>
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: blacklotus.net
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 cja at daydream.com  Wed Mar  5 09:01:24 2014
From: cja at daydream.com (CJ Aronson)
Date: Wed, 5 Mar 2014 14:01:24 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAMDXq5M1xhcr66_JMZxW-5vtG056FTqMu8CDL13gEaXoWn9UOg@mail.gmail.com>
References: <531633F0.3000403@arin.net>
	<CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
	<CAC6JZKRm=XOB7AGPpedCpG_0p6E9KAx3uaYq7Cynp+sEOxPYGg@mail.gmail.com>
	<CAMDXq5M1xhcr66_JMZxW-5vtG056FTqMu8CDL13gEaXoWn9UOg@mail.gmail.com>
Message-ID: <CAC6JZKQBOz6g5EH=BOAn50owS6hB1PQuWBRdbsiyuptF1GrzKQ@mail.gmail.com>

Martin..

My fellow AC members who were at the meeting handled the discussion well
and I didn't feel the need to speak on the subject.  Mostly I listen to the
community and that is what I did during the PPC. That is not shocking  :-)

Further.. this does change nothing but it also documents current practice
and the ARIN staff requested in a policy experience report that this be
documented so that it is clear what the current practice is.

----Cathy


On Wed, Mar 5, 2014 at 1:54 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> On Wed, Mar 5, 2014 at 8:17 AM, CJ Aronson <cja at daydream.com> wrote:
>
>
> [ clip ]
>
> >> You must not have been at the aforementioned consultation.
> >>
> > First of all I was online listening to the PPC.  Second I didn't write
> the
>
> You were registered:
>
> http://bit.ly/1dqQhdF
>
> But you didn't say a word during the entire discussion and you are the
> shepherd. And considering that I spoke specifically on this topic at
> the PPC, that is outright shocking! :-)
>
> > changes but I do agree with them and belleve they reflect the concerns
> that
> > came up at that meeting.
>
> Once you scrub the AC cheer leading, there was no support for these
> changes. No change would support that context.
>
> You can see for yourself here:
>
> http://bit.ly/1g9Wg3T
>
>
> >>
> >> > Add the following statement to section 4.5.4.
> >> >
> >> > Upon verification that the organization has demonstrated need at its
> new
> >> > discrete network site, the new networks shall be allocated the minimum
> >> > allocation size under section 4.2.1.5 unless the organization can
> >> > demonstrate additional need using the immediate need criteria
> (4.2.1.6).
> >>
> >> Talk about locking someone out of a policy lock, stock and barrel and
> >> flushing "stewardship" down the drain completely. Most MDN users are
> >> going to go straight to 4.2.1.6 only to find that they are locked out
> >> because they aren't contracted as an ISP. They could buy another
> >> OrgID... and pay another exorbitant fee if qualified I guess. If we
> >> really want to limit users to a /22 why not do it across the board?
> >
> >
> > There is nothing in this policy that isn't currently happening in
> practice
> > with MDN allocations.  I am not sure what "contracted as an ISP" means.
> >
>
> If an end-user attempts to use 4.2.1.6 they won't be turned away?
>
> 4.2.1.6 --- "If an ISP has an immediate need for address space, "
>
> Force feeding accomplishes at least one parties objectives, but always
> result in an unhappy patient. The AC needs to leave this alone
> considering that, according to multiple AC members now, it changes
> nothing.
>
>
> Best,
>
> -M<
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140305/ae5022e9/attachment.htm>

From hannigan at gmail.com  Wed Mar  5 09:08:41 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 5 Mar 2014 09:08:41 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAC6JZKQBOz6g5EH=BOAn50owS6hB1PQuWBRdbsiyuptF1GrzKQ@mail.gmail.com>
References: <531633F0.3000403@arin.net>
	<CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
	<CAC6JZKRm=XOB7AGPpedCpG_0p6E9KAx3uaYq7Cynp+sEOxPYGg@mail.gmail.com>
	<CAMDXq5M1xhcr66_JMZxW-5vtG056FTqMu8CDL13gEaXoWn9UOg@mail.gmail.com>
	<CAC6JZKQBOz6g5EH=BOAn50owS6hB1PQuWBRdbsiyuptF1GrzKQ@mail.gmail.com>
Message-ID: <CAMDXq5PA_QQ0=F3jh4VTdooXRbmb=+2LweAvbXswB_RFete57Q@mail.gmail.com>

On Wed, Mar 5, 2014 at 9:01 AM, CJ Aronson <cja at daydream.com> wrote:
> Martin..
>
> My fellow AC members who were at the meeting handled the discussion well and
> I didn't feel the need to speak on the subject.  Mostly I listen to the
> community and that is what I did during the PPC. That is not shocking  :-)

If you say so. :-) The registration was inaccurate anyhow. There were
AC members there that were not registered.

>
> Further.. this does change nothing

But it does. It creates an inferior class of member with respect to
the policy, the end user, which may only be rectified by paying ARIN
more money. See ARIN's IRS 990 lately? They don't need any more of our
money.


>but it also documents current practice
> and the ARIN staff requested in a policy experience report that this be
> documented so that it is clear what the current practice is.
>

The community takes priority over the staff where there is a conflict.
There are checks and balances in place that allow the organization to
react otherwise and if needed.

Best,

-M<


From cja at daydream.com  Wed Mar  5 09:15:35 2014
From: cja at daydream.com (CJ Aronson)
Date: Wed, 5 Mar 2014 14:15:35 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAMDXq5PA_QQ0=F3jh4VTdooXRbmb=+2LweAvbXswB_RFete57Q@mail.gmail.com>
References: <531633F0.3000403@arin.net>
	<CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
	<CAC6JZKRm=XOB7AGPpedCpG_0p6E9KAx3uaYq7Cynp+sEOxPYGg@mail.gmail.com>
	<CAMDXq5M1xhcr66_JMZxW-5vtG056FTqMu8CDL13gEaXoWn9UOg@mail.gmail.com>
	<CAC6JZKQBOz6g5EH=BOAn50owS6hB1PQuWBRdbsiyuptF1GrzKQ@mail.gmail.com>
	<CAMDXq5PA_QQ0=F3jh4VTdooXRbmb=+2LweAvbXswB_RFete57Q@mail.gmail.com>
Message-ID: <CAC6JZKSZFjc_Y0ZF0sQH-+HuCLMO_gBLyrrg5NWW9FYs0+jiPQ@mail.gmail.com>

Thanks to Jeffrey and Martin for their feedback on 2013-8, Does anyone else
have feedback on this proposal?

Thanks!
----Cathy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140305/d7d7ab1c/attachment.htm>

From billdarte at gmail.com  Wed Mar  5 10:00:03 2014
From: billdarte at gmail.com (Bill Darte)
Date: Wed, 5 Mar 2014 09:00:03 -0600
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip Language
Message-ID: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>

On Feb. 21 I sent the message (far below) to PPML asking the community to
support one of 3 alternatives or propose new language which makes one or
the other better, or a completely new wording which they believe
accomplishes the goal of producing policy language that is needed,
technically sound and improves existing policy in the 8.4 Inter-RIR
transfer realm.

Summary of feedback so far:
2 persons supporting #2 with the removal of "and its subsidiaries".  There
was some support for the extended language of "and its subsidiaries having
been operational for a minimum of xx months" in order to mitigate the
rinse-repeat abuse that might accrue through new shell subsidiaries.

There was some support for the alternative language expressed in #3 at the
PPC in Atlanta and at the ARIN AC meeting on Feb 20.  This language simply
restricts the transfer of the block having been received...which would
allow other existing blocks or components to be transferred.  One view
against #3 was expressed as "An org that currently has a /8 can obtain the
resources it needs and sell off the /8 out of region a few chunks at a time
by backfilling with new space from the ARIN region.". A rejoinder to this
was expressed pointing out that other existing language in 8.4
states...."Source
entities within the ARIN region will not be eligible to receive any further
IPv4 address allocations or assignments from ARIN for a period of 12 months
after a transfer approval, or until the exhaustion of ARIN's IPv4 space,
whichever occurs first."
<<< end summary >>>>


It is important that I receive a significant measure of support FOR or
AGAINST continuing to work on this Draft and before the ARIN AC meeting on
Mar 20, I would like to have better language to propose if we are to make
this Draft a Recommended Draft prior to the April PPM in Chicago.

I would be grateful for your feedback as early as possible.

bd

<<<<<<<<< earlier email sent to PPML on Feb 21 >>>>>>>>>>>>>>>
At the Advisory Council's meeting of Feb 20, discussion about Draft Policy
2014-2 concluded that there is a real issue with transfer restrictions of
address blocks between RIR jurisdictions for organizations having received
a different block of addresses from ARIN within the last 12 months (per
existing policy).

The current Draft Policy language is as follows with only the last sentence
being added from what is current ARIN policy:
"Source entities within the ARIN region must not have received a transfer,
allocation, or assignment of IPv4 number resources from ARIN for the 12
months prior to the approval of a transfer request. This restriction does
not include M&A transfers. Restrictions related to recent receipt of blocks
shall not apply to inter-RIR transfers within the same organization and its
subsidiaries."

The last sentence of this language was added to mitigate the problems
related by the author in the problem statement and from experience. The
author supported this change, however, some concern has been expressed on
the PPML and within the AC about the possibility of 'rinse and repeat'
abuse associated with the ease of establishing new subsidiaries and using
those transfers to get around the restrictions of the existing transfer
policy.

Three alternatives were primarily discussed and I wish to elicit feedback
from the community relative to each.

1. Use the existing last sentence as is and ask ARIN staff to be
particularly watchful for seeming abuse and to bring such back to the
community through regular Policy Experience Reports.  There was discussion
about this option suggesting that by the time abuse was recognized and
reported, and given limited existing free pool stocks and the extended
policy development cycle....this option may be moot.

2. Remove the clause 'and its subsidiaries' or modify it in such a way as
to mitigate the risk of a laundering of addresses through fraudulent
transfers, but this may still potentially limit the utility to
organizations who may have complex organizational structures in use
internationally.

3. Take an alternative tack and simply restrict transfers on a per-block
rather than a per-organization basis. e.g. 'No block acquired within the
past 24 months would be eligible for transfer.' (The time frame is of
course an arbitrary number at this point.)

If you believe this Draft Policy is improved most significantly by one of
the above alternatives, or through another alternative you can pose....I,
and the community would benefit from your input. Thanks,

Bill Darte
Policy Shepherd for 2014-2 and
Advisory Council member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140305/2ca90bbc/attachment.htm>

From andrew.dul at quark.net  Wed Mar  5 11:50:58 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 05 Mar 2014 08:50:58 -0800
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
References: <531633F0.3000403@arin.net>
	<CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
Message-ID: <531755F2.5010009@quark.net>

On 3/5/2014 4:55 AM, Martin Hannigan wrote:
> On Tue, Mar 4, 2014 at 3:13 PM, ARIN <info at arin.net> wrote:
>
>
> [ clip ]
>
>
>
>> Add the following statement to section 4.5.4.
>>
>> Upon verification that the organization has demonstrated need at its new
>> discrete network site, the new networks shall be allocated the minimum
>> allocation size under section 4.2.1.5 unless the organization can
>> demonstrate additional need using the immediate need criteria (4.2.1.6).
> Talk about locking someone out of a policy lock, stock and barrel and
> flushing "stewardship" down the drain completely. Most MDN users are
> going to go straight to 4.2.1.6 only to find that they are locked out
> because they aren't contracted as an ISP. They could buy another
> OrgID... and pay another exorbitant fee if qualified I guess. If we
> really want to limit users to a /22 why not do it across the board?
>
> I'm glad we moved beyond ARIN trying to define business terms between
> networks and ARIN customers, but we should move beyond this entirely
> and abandon it.
>
>

I disagree that this new text is a no-op or that it makes MDN user's
requests more difficult.  This policy is intended to make it _easier_
for orgs to get address space for new sites.

Under ARIN's current operational practice, ARIN is forcing MDN orgs to
use immediate need to get address space for a new site.  This policy is
intended to make it as easy as...Do you have a new site?  Yes> Does it
need address space (e.g. does it meet the original critieria already in
MDN 4.5.2) Yes>, then you can allocate the minimum allocation size
(currently /22) to the new site.  Done.

This policy does not limit you to a /22 per site, it only says that you
start with a /22 unless you can actually show that you need more right
away, then you can use a 30 day need to justify what size block to
allocate to a new site.

Andrew




From hannigan at gmail.com  Wed Mar  5 12:11:56 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 5 Mar 2014 12:11:56 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
	Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <531755F2.5010009@quark.net>
References: <531633F0.3000403@arin.net>
	<CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
	<531755F2.5010009@quark.net>
Message-ID: <6043EDD2-6B94-4EBE-B2E0-163FE45986ED@gmail.com>


You get AC airline status upgrade karma points if you can tell me that this is meaningless then. 

From immediate need text :

"These cases are exceptional."

That doesn't sound easier. And is not current "undocumented" practice. 

And end users are still excluded. 

Abandon. Thanks.

Best,

Martin 

> On Mar 5, 2014, at 11:50, Andrew Dul <andrew.dul at quark.net> wrote:
> 
>> On 3/5/2014 4:55 AM, Martin Hannigan wrote:
>> On Tue, Mar 4, 2014 at 3:13 PM, ARIN <info at arin.net> wrote:
>> 
>> 
>> [ clip ]
>> 
>> 
>> 
>>> Add the following statement to section 4.5.4.
>>> 
>>> Upon verification that the organization has demonstrated need at its new
>>> discrete network site, the new networks shall be allocated the minimum
>>> allocation size under section 4.2.1.5 unless the organization can
>>> demonstrate additional need using the immediate need criteria (4.2.1.6).
>> Talk about locking someone out of a policy lock, stock and barrel and
>> flushing "stewardship" down the drain completely. Most MDN users are
>> going to go straight to 4.2.1.6 only to find that they are locked out
>> because they aren't contracted as an ISP. They could buy another
>> OrgID... and pay another exorbitant fee if qualified I guess. If we
>> really want to limit users to a /22 why not do it across the board?
>> 
>> I'm glad we moved beyond ARIN trying to define business terms between
>> networks and ARIN customers, but we should move beyond this entirely
>> and abandon it.
> 
> I disagree that this new text is a no-op or that it makes MDN user's
> requests more difficult.  This policy is intended to make it _easier_
> for orgs to get address space for new sites.
> 
> Under ARIN's current operational practice, ARIN is forcing MDN orgs to
> use immediate need to get address space for a new site.  This policy is
> intended to make it as easy as...Do you have a new site?  Yes> Does it
> need address space (e.g. does it meet the original critieria already in
> MDN 4.5.2) Yes>, then you can allocate the minimum allocation size
> (currently /22) to the new site.  Done.
> 
> This policy does not limit you to a /22 per site, it only says that you
> start with a /22 unless you can actually show that you need more right
> away, then you can use a 30 day need to justify what size block to
> allocate to a new site.
> 
> Andrew
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 andrew.dul at quark.net  Wed Mar  5 12:23:34 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Wed, 05 Mar 2014 09:23:34 -0800
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <6043EDD2-6B94-4EBE-B2E0-163FE45986ED@gmail.com>
References: <531633F0.3000403@arin.net>
	<CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
	<531755F2.5010009@quark.net>
	<6043EDD2-6B94-4EBE-B2E0-163FE45986ED@gmail.com>
Message-ID: <53175D96.7000106@quark.net>

On 3/5/2014 9:11 AM, Martin Hannigan wrote:
> You get AC airline status upgrade karma points if you can tell me that this is meaningless then. 
>
> From immediate need text :
>
> "These cases are exceptional."

I'd agree the immediate need text is old and probably doesn't make as
much sense as it used to, but that isn't what we are debating here.  We
are trying to make it easier for orgs to allocate address space to new
MDN sites.

> That doesn't sound easier. And is not current "undocumented" practice. 

https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf

Slide 7, Is the current "undocumented new site MDN practice" which says
ARIN uses the immediate need text.


>
> And end users are still excluded. 

I'll agree, but MDN was never designed for end-users, I'm not opposed to
bringing end-users and ISPs closer together in policy, but again we're
trying to fix a specific issue here with MDN. 


>
> Abandon. Thanks.
>
> Best,
>
> Martin 
>
>> On Mar 5, 2014, at 11:50, Andrew Dul <andrew.dul at quark.net> wrote:
>>
>>> On 3/5/2014 4:55 AM, Martin Hannigan wrote:
>>> On Tue, Mar 4, 2014 at 3:13 PM, ARIN <info at arin.net> wrote:
>>>
>>>
>>> [ clip ]
>>>
>>>
>>>
>>>> Add the following statement to section 4.5.4.
>>>>
>>>> Upon verification that the organization has demonstrated need at its new
>>>> discrete network site, the new networks shall be allocated the minimum
>>>> allocation size under section 4.2.1.5 unless the organization can
>>>> demonstrate additional need using the immediate need criteria (4.2.1.6).
>>> Talk about locking someone out of a policy lock, stock and barrel and
>>> flushing "stewardship" down the drain completely. Most MDN users are
>>> going to go straight to 4.2.1.6 only to find that they are locked out
>>> because they aren't contracted as an ISP. They could buy another
>>> OrgID... and pay another exorbitant fee if qualified I guess. If we
>>> really want to limit users to a /22 why not do it across the board?
>>>
>>> I'm glad we moved beyond ARIN trying to define business terms between
>>> networks and ARIN customers, but we should move beyond this entirely
>>> and abandon it.
>> I disagree that this new text is a no-op or that it makes MDN user's
>> requests more difficult.  This policy is intended to make it _easier_
>> for orgs to get address space for new sites.
>>
>> Under ARIN's current operational practice, ARIN is forcing MDN orgs to
>> use immediate need to get address space for a new site.  This policy is
>> intended to make it as easy as...Do you have a new site?  Yes> Does it
>> need address space (e.g. does it meet the original critieria already in
>> MDN 4.5.2) Yes>, then you can allocate the minimum allocation size
>> (currently /22) to the new site.  Done.
>>
>> This policy does not limit you to a /22 per site, it only says that you
>> start with a /22 unless you can actually show that you need more right
>> away, then you can use a 30 day need to justify what size block to
>> allocate to a new site.
>>
>> Andrew
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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 michel at arneill-py.sacramento.ca.us  Wed Mar  5 14:05:53 2014
From: michel at arneill-py.sacramento.ca.us (Michel Py)
Date: Wed, 5 Mar 2014 11:05:53 -0800
Subject: [arin-ppml] Potentially credible v4 number pricing data
In-Reply-To: <CACrmG8efZsy_rjVGFqVPX0GOqteFrk1O7MmuDsviL+3HPiJWSQ@mail.gmail.com>
References: <CAMDXq5OBJQpX6MSX0SG=h4E2RtWyvMiJN=0Wo9eqZFfqEnNqKQ@mail.gmail.com><69B9BA3779753A49865BB9010D560EBB6E9B@newserver.arneill-py.local><CACrmG8fXF1M9PHff_xvGma4LFABk6_HdvTjuH6XUP+u0Zs9C=w@mail.gmail.com><69B9BA3779753A49865BB9010D560EBB6E9D@newserver.arneill-py.local>
	<CACrmG8efZsy_rjVGFqVPX0GOqteFrk1O7MmuDsviL+3HPiJWSQ@mail.gmail.com>
Message-ID: <69B9BA3779753A49865BB9010D560EBB6EA0@newserver.arneill-py.local>

> Jeffrey Lyon wrote :
> It is easy to obtain small allocations from ARIN (for now) but quite
> difficult to find contiguous space in the much shorter prefixes.
> These are the ones that would have market value.

You'll have to adapt, the million prefixes routing table is coming. Not
everyone is unhappy about it: the guys who write scripts, the TCAM
manufacturers, the router vendors and everyone in their ecosystem sees
that as a new business opportunity.

<humor>
For what I understand of your business, you must have scripts all over
the place already, so it's just a matter of adapting them to deal with
multiple prefix use, right :P
</humor>

Michel.



From SRyerse at eclipse-networks.com  Wed Mar  5 14:20:26 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Wed, 5 Mar 2014 19:20:26 +0000
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8:
 SubsequentAllocations for New Multiple Discrete Networks - Revised
In-Reply-To: <CAMDXq5M3ouwYa71Vm29ikHrVxkpk0TUyy60FTKvXvEUewuv3-w@mail.gmail.com>
References: <531633F0.3000403@arin.net>
	<53168970.2010909@quark.net><CAC6JZKQOMKZ6B-j2xycaPzcfdcxj21RvCA9R+P-ezy3Xp
	BNHWw@mail.gmail.com><CACrmG8c3WLA1=g1Z_Q_=o8O2Rt=2rOON_=59o5SrLGZ7hAAkow@m
	ail.gmail.com><CAC6JZKRJ9rtn_7X_5QCeKjGKfLuk2VXswZdX0u3asZF01ySfSA@mail.gma
	il.com><CACrmG8fBY-jAEh1cBwtVVtKeaNJN-=sTd=Vp_O8LTB4Q4Gdwmg@mail.gmail.com>
	<CAMDXq5M3ouwYa71Vm29ikHrVxkpk0TUyy60FTKvXvEUewuv3-w@mail.gmail.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD120152864363@ENI-MAIL.eclipse-networks.com>

Jeffrey's comment below is an example of real life that frequently is ignored in existing ARIN policies, as signing contracts with Internet providers and even construction of data centers or smaller spaces take lots of money - and it is difficult to be absolutely certain that an allocation from ARIN will be available after the money is spent and contracts are signed.  If you are a big org would you spend a billion dollars on a data center only to have ARIN refuse to allocate any resources because the brand new data center doesn't have any business yet?  The equivalent goes for a smaller org.  Real life says that orgs should be able to count on securing right sized allocations of resources if ARIN has them to allocate.  

I believe this is an unreasonable situation to force new organizations to go thru solely because they are asking for an allocation in 2014 instead of 1994, or 1997, or 2005 or whatever date in the past.  Other than making sure that ARIN can pay its bills and that they can reasonably administrate allocation requests, why should new applicants be discriminated against because of the date they request allocations.  Is it because the haves don't want the have nots to set up shop and compete with them?  Might there be other unreasonable reasons as well?  As I've said many many times before, every organization should at least be able to get a minimum size (/22 or /24 or whatever) no matter what - as long as ARIN has resources to allocate.  

There are thousands of organizations that have received allocations over the years including Legacy holders.   For the most part they weren't subject to these kind of needs policies and can pretty much reasonably use their allocation as they wish,  but some think that only new requests for allocations should be forced to comply with the many arbitrary policies that are now on the books, even though some of the existing allocation holders may not have had to comply with these policies when they got their allocations.  Fair is fair and I strongly believe that we as a community need to be just as fair to new requests as older request.  I would paraphrase that by saying do unto others what you would have done to you - is a good guide to follow.  

Given the definition of Ethernet routing, certainly multiple locations should be enough to justify a right sized allocation.  Thus, I am against the change in policy as it makes it harder to get an allocation rather than easier.  Instead, we ought to fix the underlying policy(s) to make it easier to get an allocation and not harder.  -1

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan
Sent: Wednesday, March 05, 2014 9:00 AM
To: Jeffrey Lyon
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2013-8: SubsequentAllocations for New Multiple Discrete Networks - Revised

Do explain. So a network operator should enter into a bandwidth contract anticipating that it might get addresses from ARIN and if it doesnt or doesn't get an adequate amount to fully utilize their capacity they should eat that cost or loss so that it's "good for ARIN"?

Not sure how that's good for anyone.


Best,

-M<


On Wed, Mar 5, 2014 at 8:45 AM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
> Cathy,
>
> I actually find it reasonable that the live connectivity be the 
> prerequisite for requesting space under 4.5.
>
> Thanks, Jeff
>
> On Wed, Mar 5, 2014 at 10:42 PM, CJ Aronson <cja at daydream.com> wrote:
>> Jeffrey,
>>
>> The text was changed from "Upon verification that the organization 
>> has already obtained connectivity at its new discrete network site"  
>> because folks felt that this meant the connection had to be up and running, not just
>> under contract.   I believe there is more justification required than just
>> "having a new site".   I see nothing in the current policy that states an
>> automatic /24.  Here is the policy text as it stands today from NRPM 
>> (see
>> below)
>>
>> Thanks!
>> ----Cathy
>>
>> 4.5. Multiple Discrete Networks
>>
>> Organizations with multiple discrete networks desiring to request new 
>> or additional address space under a single Organization ID must meet 
>> the following criteria:
>>
>> The organization shall be a single entity and not a consortium of 
>> smaller independent entities.
>> The organization must have compelling criteria for creating discrete 
>> networks. Examples of a discrete network might include:
>>
>> Regulatory restrictions for data transmission, Geographic distance 
>> and diversity between networks, Autonomous multihomed discrete 
>> networks.
>>
>> The organization must keep detailed records on how it has allocated 
>> space to each location, including the date of each allocation.
>> When applying for additional internet address registrations from 
>> ARIN, the organization must demonstrate utilization greater than 50% 
>> of both the last block allocated and the aggregate sum of all blocks 
>> allocated from ARIN to that organization. If an organization is 
>> unable to satisfy this 50% minimum utilization criteria, the 
>> organization may alternatively qualify for additional internet 
>> address registrations by having all unallocated blocks of addresses smaller than ARIN's current minimum allocation size.
>> The organization may not allocate additional address space to a 
>> location until each of that location's address blocks are 80% utilized.
>> The organization should notify ARIN at the time of the request their 
>> desire to apply this policy to their account.
>>
>>
>>
>> On Wed, Mar 5, 2014 at 1:12 PM, Jeffrey Lyon 
>> <jeffrey.lyon at blacklotus.net>
>> wrote:
>>>
>>> I am opposed to the rewording as the new discrete site is in itself 
>>> demonstration of need. There is a technical requirement to provide 
>>> at least a /24 of space at any discrete site.
>>>
>>> Thanks, Jeff
>>>
>>> On Wed, Mar 5, 2014 at 6:16 PM, CJ Aronson <cja at daydream.com> wrote:
>>> > Does anyone else have comments about this proposal?  The text has 
>>> > been changed slightly based on feedback from the PPC at NANOG.  
>>> > The change was
>>> >
>>> > from
>>> >
>>> > Upon verification that the organization has already obtained 
>>> > connectivity at its new discrete network site
>>> >
>>> > to
>>> >
>>> >
>>> > Upon verification that the organization has demonstrated need at 
>>> > its new discrete network site
>>> >
>>> > Please send your comments on this change and on the proposal.
>>> >
>>> > Thanks!
>>> > -----Cathy
>>> >
>>> >
>>> > On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net> wrote:
>>> >>
>>> >> I support this new version of the policy.  I believe the new text 
>>> >> successfully deals with the issues raised and discussed at the 
>>> >> Atlanta nanog PPC.
>>> >>
>>> >> Andrew
>>> >>
>>> >> On 3/4/2014 12:13 PM, ARIN wrote:
>>> >> > ## * ##
>>> >> >
>>> >> >
>>> >> > Recommended Draft Policy ARIN-2013-8 Subsequent Allocations for 
>>> >> > New Multiple Discrete Networks
>>> >> >
>>> >> > Date: 4 March 2014
>>> >> >
>>> >> > AC's assessment of conformance with the Principles of Internet 
>>> >> > Number Resource Policy:
>>> >> >
>>> >> > "Subsequent Allocations for Additional Discrete Network Sites 
>>> >> > This policy enables fair and impartial number resource 
>>> >> > administration by documenting the current practice regarding 
>>> >> > allocations for additional discrete network sites. The ARIN 
>>> >> > staff has been following a procedure that has not been 
>>> >> > documented until now. By documenting this process the community 
>>> >> > has clear understanding of how to get address space for additional network sites.
>>> >> >
>>> >> > This is a technically sound proposal that has been in practice 
>>> >> > for some time. It had just not been documented.
>>> >> >
>>> >> > This proposal has received several notes of support on the PPML 
>>> >> > and to date has received no negative feedback."
>>> >> >
>>> >> > Policy Statement:
>>> >> >
>>> >> > IPv4:
>>> >> >
>>> >> > Add the following statement to section 4.5.4.
>>> >> >
>>> >> > Upon verification that the organization has demonstrated need 
>>> >> > at its new discrete network site, the new networks shall be 
>>> >> > allocated the minimum allocation size under section 4.2.1.5 
>>> >> > unless the organization can demonstrate additional need using 
>>> >> > the immediate need criteria (4.2.1.6).
>>> >> >
>>> >> > IPv6:
>>> >> >
>>> >> > Add an additional reference to section 6.11.5.b such that it 
>>> >> > references both the initial allocation and subsequent 
>>> >> > allocation sections of the IPv6 LIR policy.
>>> >> >
>>> >> > "Each network will be judged against the existing utilization 
>>> >> > criteria specified in 6.5.2 and 6.5.3 as if it were a separate 
>>> >> > organization..."
>>> >> >
>>> >> >
>>> >> >
>>> >> > Comments:
>>> >> >
>>> >> > a. Timetable for implementation: immediate
>>> >> >
>>> >> > b. This policy is being proposed based upon the Policy 
>>> >> > Implementation & Experience Report from ARIN 32.
>>> >> >
>>> >> >
>>> >> >
>>> >> > https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/t
>>> >> > hursday/nobile-policy.pdf
>>> >> >
>>> >> >
>>> >> > c: Older versions of the MDN policy did contain new network criteria.
>>> >> > This criteria appears to have been dropped during subsequent 
>>> >> > rewrites of the MDN policy. "The organization must not allocate 
>>> >> > a CIDR block larger than the current minimum assignment size of 
>>> >> > the RIR (currently
>>> >> > /20 for ARIN) to a new network."
>>> >> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
>>> >> > _______________________________________________
>>> >> > PPML
>>> >> > You are receiving this message because you are subscribed to 
>>> >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> >> > Unsubscribe or manage your mailing list subscription at:
>>> >> > http://lists.arin.net/mailman/listinfo/arin-ppml
>>> >> > Please contact info at arin.net if you experience any issues.
>>> >>
>>> >> _______________________________________________
>>> >> PPML
>>> >> You are receiving this message because you are subscribed to the 
>>> >> ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> >> Unsubscribe or manage 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.
>>>
>>>
>>>
>>> --
>>> Jeffrey A. Lyon, CISSP-ISSMP
>>> Fellow, Black Lotus Communications
>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>> blacklotus.net
>>
>>
>
>
>
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: 
> blacklotus.net _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.

From hannigan at gmail.com  Wed Mar  5 15:22:04 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 5 Mar 2014 15:22:04 -0500
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-8: Subsequent
 Allocations for New Multiple Discrete Networks - Revised
In-Reply-To: <53175D96.7000106@quark.net>
References: <531633F0.3000403@arin.net>
	<CAMDXq5OXa=m0KBdabrNFXwbPoGcGzxAjdtLq6miQS3tKQs1FEA@mail.gmail.com>
	<531755F2.5010009@quark.net>
	<6043EDD2-6B94-4EBE-B2E0-163FE45986ED@gmail.com>
	<53175D96.7000106@quark.net>
Message-ID: <CAMDXq5P_pdYFwBip=-W9CGtdE1YZ2LxiqZ39CWwUfvskP0J0NQ@mail.gmail.com>

On Wed, Mar 5, 2014 at 12:23 PM, Andrew Dul <andrew.dul at quark.net> wrote:
> On 3/5/2014 9:11 AM, Martin Hannigan wrote:
>> You get AC airline status upgrade karma points if you can tell me that this is meaningless then.
>>
>> From immediate need text :
>>
>> "These cases are exceptional."
>
> I'd agree the immediate need text is old and probably doesn't make as
> much sense as it used to

[ ...]


>> That doesn't sound easier. And is not current "undocumented" practice.
>
> https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/thursday/nobile-policy.pdf
>
> Slide 7, Is the current "undocumented new site MDN practice" which says
> ARIN uses the immediate need text.
>

That doesn't mean it's easier.



>> And end users are still excluded.
>
> I'll agree, but MDN was never designed for end-users,

[ ... ]

It does not preclude them.


>I'm not opposed to
> bringing end-users and ISPs closer together in policy, but again we're
> trying to fix a specific issue here with MDN.
>

What you and your colleagues have ultimately done is put lipstick on a pig.

Best,

-M<


From owen at delong.com  Wed Mar  5 16:02:21 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 5 Mar 2014 13:02:21 -0800
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
	Language
In-Reply-To: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
Message-ID: <92D57CAE-61E2-4A8F-8D29-001C8B6A0369@delong.com>

I still have concerns in spite of said rejoinder. The rejoinder doesn't address the ability to use this as a way to flip less expensive addresses into higher profits by transferring out of region. All it does is protect a free pool which likely won't exist by the time this becomes policy anyway.

Owen

On Mar 5, 2014, at 07:00 , Bill Darte <billdarte at gmail.com> wrote:

> On Feb. 21 I sent the message (far below) to PPML asking the community to support one of 3 alternatives or propose new language which makes one or the other better, or a completely new wording which they believe accomplishes the goal of producing policy language that is needed, technically sound and improves existing policy in the 8.4 Inter-RIR transfer realm.
> 
> Summary of feedback so far:
> 2 persons supporting #2 with the removal of "and its subsidiaries".  There was some support for the extended language of "and its subsidiaries having been operational for a minimum of xx months" in order to mitigate the rinse-repeat abuse that might accrue through new shell subsidiaries.
> 
> There was some support for the alternative language expressed in #3 at the PPC in Atlanta and at the ARIN AC meeting on Feb 20.  This language simply restricts the transfer of the block having been received...which would allow other existing blocks or components to be transferred.  One view against #3 was expressed as "An org that currently has a /8 can obtain the resources it needs and sell off the /8 out of region a few chunks at a time by backfilling with new space from the ARIN region.". A rejoinder to this was expressed pointing out that other existing language in 8.4 states...."Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first."
> <<< end summary >>>>
> 
> 
> It is important that I receive a significant measure of support FOR or AGAINST continuing to work on this Draft and before the ARIN AC meeting on Mar 20, I would like to have better language to propose if we are to make this Draft a Recommended Draft prior to the April PPM in Chicago. 
> 
> I would be grateful for your feedback as early as possible.
> 
> bd
> 
> <<<<<<<<< earlier email sent to PPML on Feb 21 >>>>>>>>>>>>>>>
> At the Advisory Council's meeting of Feb 20, discussion about Draft Policy 2014-2 concluded that there is a real issue with transfer restrictions of address blocks between RIR jurisdictions for organizations having received a different block of addresses from ARIN within the last 12 months (per existing policy).
> 
> The current Draft Policy language is as follows with only the last sentence being added from what is current ARIN policy:
> "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. Restrictions related to recent receipt of blocks shall not apply to inter-RIR transfers within the same organization and its subsidiaries."
> 
> The last sentence of this language was added to mitigate the problems related by the author in the problem statement and from experience. The author supported this change, however, some concern has been expressed on the PPML and within the AC about the possibility of 'rinse and repeat' abuse associated with the ease of establishing new subsidiaries and using those transfers to get around the restrictions of the existing transfer policy.
> 
> Three alternatives were primarily discussed and I wish to elicit feedback from the community relative to each.
> 
> 1. Use the existing last sentence as is and ask ARIN staff to be particularly watchful for seeming abuse and to bring such back to the community through regular Policy Experience Reports.  There was discussion about this option suggesting that by the time abuse was recognized and reported, and given limited existing free pool stocks and the extended policy development cycle....this option may be moot.
> 
> 2. Remove the clause 'and its subsidiaries' or modify it in such a way as to mitigate the risk of a laundering of addresses through fraudulent transfers, but this may still potentially limit the utility to organizations who may have complex organizational structures in use internationally.
> 
> 3. Take an alternative tack and simply restrict transfers on a per-block rather than a per-organization basis. e.g. 'No block acquired within the past 24 months would be eligible for transfer.' (The time frame is of course an arbitrary number at this point.)
> 
> If you believe this Draft Policy is improved most significantly by one of the above alternatives, or through another alternative you can pose....I, and the community would benefit from your input. Thanks,
> 
> Bill Darte
> Policy Shepherd for 2014-2 and 
> Advisory Council member

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

From scottleibrand at gmail.com  Wed Mar  5 16:17:46 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 5 Mar 2014 13:17:46 -0800
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
	Language
In-Reply-To: <92D57CAE-61E2-4A8F-8D29-001C8B6A0369@delong.com>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
	<92D57CAE-61E2-4A8F-8D29-001C8B6A0369@delong.com>
Message-ID: <CAGkMwz4ac4mef3dHwy8w6TxPPo6BcVRqb93qLe=Djk2ammZVxg@mail.gmail.com>

Why would someone buy a block in ARIN and resell it into APNIC, if the
original seller could've just sold their block to the APNIC buyer?  I don't
see the arbitrage opportunity here, except with regards to the
soon-to-be-exhausted free pool.

-Scott


On Wed, Mar 5, 2014 at 1:02 PM, Owen DeLong <owen at delong.com> wrote:

> I still have concerns in spite of said rejoinder. The rejoinder doesn't
> address the ability to use this as a way to flip less expensive addresses
> into higher profits by transferring out of region. All it does is protect a
> free pool which likely won't exist by the time this becomes policy anyway.
>
> Owen
>
> On Mar 5, 2014, at 07:00 , Bill Darte <billdarte at gmail.com> wrote:
>
> On Feb. 21 I sent the message (far below) to PPML asking the community to
> support one of 3 alternatives or propose new language which makes one or
> the other better, or a completely new wording which they believe
> accomplishes the goal of producing policy language that is needed,
> technically sound and improves existing policy in the 8.4 Inter-RIR
> transfer realm.
>
> Summary of feedback so far:
> 2 persons supporting #2 with the removal of "and its subsidiaries".  There
> was some support for the extended language of "and its subsidiaries having
> been operational for a minimum of xx months" in order to mitigate the
> rinse-repeat abuse that might accrue through new shell subsidiaries.
>
> There was some support for the alternative language expressed in #3 at the
> PPC in Atlanta and at the ARIN AC meeting on Feb 20.  This language simply
> restricts the transfer of the block having been received...which would
> allow other existing blocks or components to be transferred.  One view
> against #3 was expressed as "An org that currently has a /8 can obtain
> the resources it needs and sell off the /8 out of region a few chunks at a
> time by backfilling with new space from the ARIN region.". A rejoinder to
> this was expressed pointing out that other existing language in 8.4
> states...."Source entities within the ARIN region will not be eligible to
> receive any further IPv4 address allocations or assignments from ARIN for a
> period of 12 months after a transfer approval, or until the exhaustion of
> ARIN's IPv4 space, whichever occurs first."
> <<< end summary >>>>
>
>
> It is important that I receive a significant measure of support FOR or
> AGAINST continuing to work on this Draft and before the ARIN AC meeting on
> Mar 20, I would like to have better language to propose if we are to make
> this Draft a Recommended Draft prior to the April PPM in Chicago.
>
> I would be grateful for your feedback as early as possible.
>
> bd
>
> <<<<<<<<< earlier email sent to PPML on Feb 21 >>>>>>>>>>>>>>>
> At the Advisory Council's meeting of Feb 20, discussion about Draft Policy
> 2014-2 concluded that there is a real issue with transfer restrictions of
> address blocks between RIR jurisdictions for organizations having received
> a different block of addresses from ARIN within the last 12 months (per
> existing policy).
>
> The current Draft Policy language is as follows with only the last
> sentence being added from what is current ARIN policy:
> "Source entities within the ARIN region must not have received a transfer,
> allocation, or assignment of IPv4 number resources from ARIN for the 12
> months prior to the approval of a transfer request. This restriction does
> not include M&A transfers. Restrictions related to recent receipt of blocks
> shall not apply to inter-RIR transfers within the same organization and its
> subsidiaries."
>
> The last sentence of this language was added to mitigate the problems
> related by the author in the problem statement and from experience. The
> author supported this change, however, some concern has been expressed on
> the PPML and within the AC about the possibility of 'rinse and repeat'
> abuse associated with the ease of establishing new subsidiaries and using
> those transfers to get around the restrictions of the existing transfer
> policy.
>
> Three alternatives were primarily discussed and I wish to elicit feedback
> from the community relative to each.
>
> 1. Use the existing last sentence as is and ask ARIN staff to be
> particularly watchful for seeming abuse and to bring such back to the
> community through regular Policy Experience Reports.  There was discussion
> about this option suggesting that by the time abuse was recognized and
> reported, and given limited existing free pool stocks and the extended
> policy development cycle....this option may be moot.
>
> 2. Remove the clause 'and its subsidiaries' or modify it in such a way as
> to mitigate the risk of a laundering of addresses through fraudulent
> transfers, but this may still potentially limit the utility to
> organizations who may have complex organizational structures in use
> internationally.
>
> 3. Take an alternative tack and simply restrict transfers on a per-block
> rather than a per-organization basis. e.g. 'No block acquired within the
> past 24 months would be eligible for transfer.' (The time frame is of
> course an arbitrary number at this point.)
>
> If you believe this Draft Policy is improved most significantly by one of
> the above alternatives, or through another alternative you can pose....I,
> and the community would benefit from your input. Thanks,
>
> Bill Darte
> Policy Shepherd for 2014-2 and
> Advisory Council member
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20140305/7cfec355/attachment.htm>

From David.Huberman at microsoft.com  Wed Mar  5 16:17:58 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 5 Mar 2014 21:17:58 +0000
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
	Language
In-Reply-To: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
Message-ID: <87b03e32ad2743559958047e94c94044@DM2PR03MB398.namprd03.prod.outlook.com>

As the author of this proposal, and having encountered the real-world consequences of existing 8.4 anti-flip language, I support #3 as the cleanest, simplest approach that best promotes Whois accuracy.



ARIN is a registry, not a regulator.  Let's write policy that promotes accuracy in Whois, please.



David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
________________________________
From: Bill Darte <billdarte at gmail.com>
Sent: Wednesday, March 5, 2014 7:00 AM
To: arin-ppml at arin.net; David Huberman; Owen DeLong
Subject: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip Language

On Feb. 21 I sent the message (far below) to PPML asking the community to support one of 3 alternatives or propose new language which makes one or the other better, or a completely new wording which they believe accomplishes the goal of producing policy language that is needed, technically sound and improves existing policy in the 8.4 Inter-RIR transfer realm.


Summary of feedback so far:
2 persons supporting #2 with the removal of "and its subsidiaries".  There was some support for the extended language of "and its subsidiaries having been operational for a minimum of xx months" in order to mitigate the rinse-repeat abuse that might accrue through new shell subsidiaries.


There was some support for the alternative language expressed in #3 at the PPC in Atlanta and at the ARIN AC meeting on Feb 20.  This language simply restricts the transfer of the block having been received...which would allow other existing blocks or components to be transferred.  One view against #3 was expressed as "An org that currently has a /8 can obtain the resources it needs and sell off the /8 out of region a few chunks at a time by backfilling with new space from the ARIN region.". A rejoinder to this was expressed pointing out that other existing language in 8.4 states...."Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first."
<<< end summary >>>>




It is important that I receive a significant measure of support FOR or AGAINST continuing to work on this Draft and before the ARIN AC meeting on Mar 20, I would like to have better language to propose if we are to make this Draft a Recommended Draft prior to the April PPM in Chicago.


I would be grateful for your feedback as early as possible.


bd


<<<<<<<<< earlier email sent to PPML on Feb 21 >>>>>>>>>>>>>>>
At the Advisory Council's meeting of Feb 20, discussion about Draft Policy 2014-2 concluded that there is a real issue with transfer restrictions of address blocks between RIR jurisdictions for organizations having received a different block of addresses from ARIN within the last 12 months (per existing policy).


The current Draft Policy language is as follows with only the last sentence being added from what is current ARIN policy:
"Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers. Restrictions related to recent receipt of blocks shall not apply to inter-RIR transfers within the same organization and its subsidiaries."


The last sentence of this language was added to mitigate the problems related by the author in the problem statement and from experience. The author supported this change, however, some concern has been expressed on the PPML and within the AC about the possibility of 'rinse and repeat' abuse associated with the ease of establishing new subsidiaries and using those transfers to get around the restrictions of the existing transfer policy.


Three alternatives were primarily discussed and I wish to elicit feedback from the community relative to each.


1. Use the existing last sentence as is and ask ARIN staff to be particularly watchful for seeming abuse and to bring such back to the community through regular Policy Experience Reports.  There was discussion about this option suggesting that by the time abuse was recognized and reported, and given limited existing free pool stocks and the extended policy development cycle....this option may be moot.


2. Remove the clause 'and its subsidiaries' or modify it in such a way as to mitigate the risk of a laundering of addresses through fraudulent transfers, but this may still potentially limit the utility to organizations who may have complex organizational structures in use internationally.


3. Take an alternative tack and simply restrict transfers on a per-block rather than a per-organization basis. e.g. 'No block acquired within the past 24 months would be eligible for transfer.' (The time frame is of course an arbitrary number at this point.)


If you believe this Draft Policy is improved most significantly by one of the above alternatives, or through another alternative you can pose....I, and the community would benefit from your input. Thanks,


Bill Darte
Policy Shepherd for 2014-2 and
Advisory Council member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140305/629d8e4f/attachment.htm>

From spamauditor at linuxmagic.com  Wed Mar  5 20:54:34 2014
From: spamauditor at linuxmagic.com (Spam Auditor)
Date: Wed, 05 Mar 2014 17:54:34 -0800
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
	Language
In-Reply-To: <87b03e32ad2743559958047e94c94044@DM2PR03MB398.namprd03.prod.outlook.com>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
	<87b03e32ad2743559958047e94c94044@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <5317D55A.1030302@linuxmagic.com>

On 14-03-05 01:17 PM, David Huberman wrote:
> As the author of this proposal, and having encountered the real-world
> consequences of existing 8.4 anti-flip language, I support #3 as the
> cleanest, simplest approach that best promotes Whois accuracy.
>
> ARIN is a registry, not a regulator.  Let's write policy that promotes
> accuracy in Whois, please.
>
> *David R Huberman*
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)

Here, Here...

However, even though it isn't a regulator, there should be enforcement 
considerations, especially when IP Space is granted and used for 
purposes contrary to the application..




From billdarte at gmail.com  Wed Mar  5 20:58:50 2014
From: billdarte at gmail.com (Bill Darte)
Date: Wed, 5 Mar 2014 19:58:50 -0600
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
	Language
In-Reply-To: <5317D55A.1030302@linuxmagic.com>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
	<87b03e32ad2743559958047e94c94044@DM2PR03MB398.namprd03.prod.outlook.com>
	<5317D55A.1030302@linuxmagic.com>
Message-ID: <CAMApp35hhh=djm_6j0mh-F2MNxWt4GMGLz771JHDUg+zYs0cag@mail.gmail.com>

Spam Auditor....
Are you FOR or AGAINST the proposal in general....and does your 'Hear,
Here' include David's support for option #3?
Thanks,
bd


On Wed, Mar 5, 2014 at 7:54 PM, Spam Auditor <spamauditor at linuxmagic.com>wrote:

> On 14-03-05 01:17 PM, David Huberman wrote:
>
>> As the author of this proposal, and having encountered the real-world
>> consequences of existing 8.4 anti-flip language, I support #3 as the
>> cleanest, simplest approach that best promotes Whois accuracy.
>>
>> ARIN is a registry, not a regulator.  Let's write policy that promotes
>> accuracy in Whois, please.
>>
>> *David R Huberman*
>> Microsoft Corporation
>> Senior IT/OPS Program Manager (GFS)
>>
>
> Here, Here...
>
> However, even though it isn't a regulator, there should be enforcement
> considerations, especially when IP Space is granted and used for purposes
> contrary to the application..
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20140305/378b9d59/attachment.htm>

From jcurran at arin.net  Thu Mar  6 11:01:15 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 6 Mar 2014 16:01:15 +0000
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
 Language
In-Reply-To: <5317D55A.1030302@linuxmagic.com>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
	<87b03e32ad2743559958047e94c94044@DM2PR03MB398.namprd03.prod.outlook.com>
	<5317D55A.1030302@linuxmagic.com>
Message-ID: <D858C5A6-3C47-41E1-96B4-AED12F0EEE04@arin.net>

"Spam Auditor" - 

   Thank you for participating in the PPML mailing list!  We definitely encourage
   participation and your thoughts on the direction that ARIN number resource policy
   should take!  I do have a request, however - 
  
   Can you please a more representative "From" address or a signature block when 
   participating on the list?  (There's an appropriate usage policy (ARIN AUP) 
   which requires such - <https://www.arin.net/participate/mailing_lists/aup.html>

Thanks!
/John

John Curran
President and CEO
ARIN



From spamauditor at linuxmagic.com  Thu Mar  6 11:20:57 2014
From: spamauditor at linuxmagic.com (Spam Auditor)
Date: Thu, 06 Mar 2014 08:20:57 -0800
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
	Language
In-Reply-To: <D858C5A6-3C47-41E1-96B4-AED12F0EEE04@arin.net>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
	<87b03e32ad2743559958047e94c94044@DM2PR03MB398.namprd03.prod.outlook.com>
	<5317D55A.1030302@linuxmagic.com>
	<D858C5A6-3C47-41E1-96B4-AED12F0EEE04@arin.net>
Message-ID: <5318A069.3000600@linuxmagic.com>

On 14-03-06 08:01 AM, John Curran wrote:
> "Spam Auditor" -
>
>     Thank you for participating in the PPML mailing list!  We definitely encourage
>     participation and your thoughts on the direction that ARIN number resource policy
>     should take!  I do have a request, however -
>
>     Can you please a more representative "From" address or a signature block when
>     participating on the list?  (There's an appropriate usage policy (ARIN AUP)
>     which requires such - <https://www.arin.net/participate/mailing_lists/aup.html>
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> ARIN
>

Sorry, this address was used, as it is the perspective of Spam Abusers, 
and the granting of IP Space, and enforcement that we were interested in 
participating.

Please reply off-list if this isn't acceptable, and we will have another 
address involved in this discussion.


From narten at us.ibm.com  Fri Mar  7 00:53:02 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 07 Mar 2014 00:53:02 -0500
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201403070553.s275r29t024050@rotala.raleigh.ibm.com>

Total of 50 messages in the last 7 days.
 
script run at: Fri Mar  7 00:53:02 EST 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 12.00% |    6 | 19.39% |   101361 | cja at daydream.com
 16.00% |    8 | 11.94% |    62415 | hannigan at gmail.com
 12.00% |    6 | 12.67% |    66217 | jeffrey.lyon at blacklotus.net
 14.00% |    7 | 10.03% |    52435 | info at arin.net
  4.00% |    2 |  7.53% |    39386 | owen at delong.com
  6.00% |    3 |  4.66% |    24342 | andrew.dul at quark.net
  4.00% |    2 |  6.27% |    32780 | david.huberman at microsoft.com
  6.00% |    3 |  3.29% |    17211 | jcurran at arin.net
  6.00% |    3 |  3.28% |    17169 | spamauditor at linuxmagic.com
  4.00% |    2 |  5.26% |    27520 | billdarte at gmail.com
  6.00% |    3 |  3.26% |    17019 | michel at arneill-py.sacramento.ca.us
  2.00% |    1 |  4.14% |    21616 | scottleibrand at gmail.com
  2.00% |    1 |  3.32% |    17366 | sryerse at eclipse-networks.com
  2.00% |    1 |  2.54% |    13268 | pauldotwall at gmail.com
  2.00% |    1 |  1.33% |     6969 | narten at us.ibm.com
  2.00% |    1 |  1.08% |     5660 | sm at resistor.net
--------+------+--------+----------+------------------------
100.00% |   50 |100.00% |   522734 | Total



From rudi.daniel at gmail.com  Fri Mar  7 12:03:32 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Fri, 7 Mar 2014 13:03:32 -0400
Subject: [arin-ppml] anti- flip Draft 2014-2
Message-ID: <CA+uaoiWCB8OoCf0CYKAyebxOeSx_tNeKF0KgavSJcxWLLdh7yw@mail.gmail.com>

I can see the logic of supporting "3". I am going inclined to agree with
David. We have to promote accuracy in whois as a policy priority.

I support No. 3

Rudi Daniel
(information technologist)
784 430 9235
On Mar 5, 2014 10:02 PM, <arin-ppml-request at arin.net> wrote:

> 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. Re: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip       Language
>       (David Huberman)
>    2. Re: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip       Language
>       (Spam Auditor)
>    3. Re: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip       Language
>       (Bill Darte)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 5 Mar 2014 21:17:58 +0000
> From: David Huberman <David.Huberman at microsoft.com>
> To: Bill Darte <billdarte at gmail.com>, "arin-ppml at arin.net"
>         <arin-ppml at arin.net>, Owen DeLong <owen at delong.com>
> Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
>         Anti-Flip       Language
> Message-ID:
>         <
> 87b03e32ad2743559958047e94c94044 at DM2PR03MB398.namprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> As the author of this proposal, and having encountered the real-world
> consequences of existing 8.4 anti-flip language, I support #3 as the
> cleanest, simplest approach that best promotes Whois accuracy.
>
>
>
> ARIN is a registry, not a regulator.  Let's write policy that promotes
> accuracy in Whois, please.
>
>
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> ________________________________
> From: Bill Darte <billdarte at gmail.com>
> Sent: Wednesday, March 5, 2014 7:00 AM
> To: arin-ppml at arin.net; David Huberman; Owen DeLong
> Subject: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip Language
>
> On Feb. 21 I sent the message (far below) to PPML asking the community to
> support one of 3 alternatives or propose new language which makes one or
> the other better, or a completely new wording which they believe
> accomplishes the goal of producing policy language that is needed,
> technically sound and improves existing policy in the 8.4 Inter-RIR
> transfer realm.
>
>
> Summary of feedback so far:
> 2 persons supporting #2 with the removal of "and its subsidiaries".  There
> was some support for the extended language of "and its subsidiaries having
> been operational for a minimum of xx months" in order to mitigate the
> rinse-repeat abuse that might accrue through new shell subsidiaries.
>
>
> There was some support for the alternative language expressed in #3 at the
> PPC in Atlanta and at the ARIN AC meeting on Feb 20.  This language simply
> restricts the transfer of the block having been received...which would
> allow other existing blocks or components to be transferred.  One view
> against #3 was expressed as "An org that currently has a /8 can obtain the
> resources it needs and sell off the /8 out of region a few chunks at a time
> by backfilling with new space from the ARIN region.". A rejoinder to this
> was expressed pointing out that other existing language in 8.4
> states...."Source entities within the ARIN region will not be eligible to
> receive any further IPv4 address allocations or assignments from ARIN for a
> period of 12 months after a transfer approval, or until the exhaustion of
> ARIN's IPv4 space, whichever occurs first."
> <<< end summary >>>>
>
>
>
>
> It is important that I receive a significant measure of support FOR or
> AGAINST continuing to work on this Draft and before the ARIN AC meeting on
> Mar 20, I would like to have better language to propose if we are to make
> this Draft a Recommended Draft prior to the April PPM in Chicago.
>
>
> I would be grateful for your feedback as early as possible.
>
>
> bd
>
>
> <<<<<<<<< earlier email sent to PPML on Feb 21 >>>>>>>>>>>>>>>
> At the Advisory Council's meeting of Feb 20, discussion about Draft Policy
> 2014-2 concluded that there is a real issue with transfer restrictions of
> address blocks between RIR jurisdictions for organizations having received
> a different block of addresses from ARIN within the last 12 months (per
> existing policy).
>
>
> The current Draft Policy language is as follows with only the last
> sentence being added from what is current ARIN policy:
> "Source entities within the ARIN region must not have received a transfer,
> allocation, or assignment of IPv4 number resources from ARIN for the 12
> months prior to the approval of a transfer request. This restriction does
> not include M&A transfers. Restrictions related to recent receipt of blocks
> shall not apply to inter-RIR transfers within the same organization and its
> subsidiaries."
>
>
> The last sentence of this language was added to mitigate the problems
> related by the author in the problem statement and from experience. The
> author supported this change, however, some concern has been expressed on
> the PPML and within the AC about the possibility of 'rinse and repeat'
> abuse associated with the ease of establishing new subsidiaries and using
> those transfers to get around the restrictions of the existing transfer
> policy.
>
>
> Three alternatives were primarily discussed and I wish to elicit feedback
> from the community relative to each.
>
>
> 1. Use the existing last sentence as is and ask ARIN staff to be
> particularly watchful for seeming abuse and to bring such back to the
> community through regular Policy Experience Reports.  There was discussion
> about this option suggesting that by the time abuse was recognized and
> reported, and given limited existing free pool stocks and the extended
> policy development cycle....this option may be moot.
>
>
> 2. Remove the clause 'and its subsidiaries' or modify it in such a way as
> to mitigate the risk of a laundering of addresses through fraudulent
> transfers, but this may still potentially limit the utility to
> organizations who may have complex organizational structures in use
> internationally.
>
>
> 3. Take an alternative tack and simply restrict transfers on a per-block
> rather than a per-organization basis. e.g. 'No block acquired within the
> past 24 months would be eligible for transfer.' (The time frame is of
> course an arbitrary number at this point.)
>
>
> If you believe this Draft Policy is improved most significantly by one of
> the above alternatives, or through another alternative you can pose....I,
> and the community would benefit from your input. Thanks,
>
>
> Bill Darte
> Policy Shepherd for 2014-2 and
> Advisory Council member
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140305/629d8e4f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 05 Mar 2014 17:54:34 -0800
> From: Spam Auditor <spamauditor at linuxmagic.com>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
>         Anti-Flip       Language
> Message-ID: <5317D55A.1030302 at linuxmagic.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 14-03-05 01:17 PM, David Huberman wrote:
> > As the author of this proposal, and having encountered the real-world
> > consequences of existing 8.4 anti-flip language, I support #3 as the
> > cleanest, simplest approach that best promotes Whois accuracy.
> >
> > ARIN is a registry, not a regulator.  Let's write policy that promotes
> > accuracy in Whois, please.
> >
> > *David R Huberman*
> > Microsoft Corporation
> > Senior IT/OPS Program Manager (GFS)
>
> Here, Here...
>
> However, even though it isn't a regulator, there should be enforcement
> considerations, especially when IP Space is granted and used for
> purposes contrary to the application..
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 5 Mar 2014 19:58:50 -0600
> From: Bill Darte <billdarte at gmail.com>
> To: Spam Auditor <spamauditor at linuxmagic.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
>         Anti-Flip       Language
> Message-ID:
>         <CAMApp35hhh=
> djm_6j0mh-F2MNxWt4GMGLz771JHDUg+zYs0cag at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Spam Auditor....
> Are you FOR or AGAINST the proposal in general....and does your 'Hear,
> Here' include David's support for option #3?
> Thanks,
> bd
>
>
> On Wed, Mar 5, 2014 at 7:54 PM, Spam Auditor <spamauditor at linuxmagic.com
> >wrote:
>
> > On 14-03-05 01:17 PM, David Huberman wrote:
> >
> >> As the author of this proposal, and having encountered the real-world
> >> consequences of existing 8.4 anti-flip language, I support #3 as the
> >> cleanest, simplest approach that best promotes Whois accuracy.
> >>
> >> ARIN is a registry, not a regulator.  Let's write policy that promotes
> >> accuracy in Whois, please.
> >>
> >> *David R Huberman*
> >> Microsoft Corporation
> >> Senior IT/OPS Program Manager (GFS)
> >>
> >
> > Here, Here...
> >
> > However, even though it isn't a regulator, there should be enforcement
> > considerations, especially when IP Space is granted and used for purposes
> > contrary to the application..
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage 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: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140305/378b9d59/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 105, Issue 11
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140307/02c2a32a/attachment.htm>

From skylar at crissic.net  Fri Mar  7 12:09:48 2014
From: skylar at crissic.net (Skylar MacMinn)
Date: Fri, 7 Mar 2014 11:09:48 -0600
Subject: [arin-ppml] anti- flip Draft 2014-2
In-Reply-To: <CA+uaoiWCB8OoCf0CYKAyebxOeSx_tNeKF0KgavSJcxWLLdh7yw@mail.gmail.com>
References: <CA+uaoiWCB8OoCf0CYKAyebxOeSx_tNeKF0KgavSJcxWLLdh7yw@mail.gmail.com>
Message-ID: <011a01cf3a28$0c5ba830$2512f890$@crissic.net>

I support No. 3

 

Cordially Yours,

 

Skylar MacMinn
www.crissic.net
<https://bay170.mail.live.com/mail/17.1.6521.6000/Compose/www.crissic.net> 
Crissic Solutions, LLC

 

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Rudolph Daniel
Sent: Friday, March 7, 2014 11:04 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] anti- flip Draft 2014-2

 

I can see the logic of supporting "3". I am going inclined to agree with
David. We have to promote accuracy in whois as a policy priority.

I support No. 3

Rudi Daniel 
(information technologist)
784 430 9235

On Mar 5, 2014 10:02 PM, <arin-ppml-request at arin.net
<mailto:arin-ppml-request at arin.net> > wrote:

Send ARIN-PPML mailing list submissions to
        arin-ppml at arin.net <mailto: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 <mailto:arin-ppml-request at arin.net> 

You can reach the person managing the list at
        arin-ppml-owner at arin.net <mailto: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. Re: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip       Language
      (David Huberman)
   2. Re: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip       Language
      (Spam Auditor)
   3. Re: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip       Language
      (Bill Darte)


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

Message: 1
Date: Wed, 5 Mar 2014 21:17:58 +0000
From: David Huberman <David.Huberman at microsoft.com
<mailto:David.Huberman at microsoft.com> >
To: Bill Darte <billdarte at gmail.com <mailto:billdarte at gmail.com> >,
"arin-ppml at arin.net <mailto:arin-ppml at arin.net> "
        <arin-ppml at arin.net <mailto:arin-ppml at arin.net> >, Owen DeLong
<owen at delong.com <mailto:owen at delong.com> >
Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
        Anti-Flip       Language
Message-ID:
 
<87b03e32ad2743559958047e94c94044 at DM2PR03MB398.namprd03.prod.outlook.com
<mailto:87b03e32ad2743559958047e94c94044 at DM2PR03MB398.namprd03.prod.outlook.
com> >

Content-Type: text/plain; charset="us-ascii"

As the author of this proposal, and having encountered the real-world
consequences of existing 8.4 anti-flip language, I support #3 as the
cleanest, simplest approach that best promotes Whois accuracy.



ARIN is a registry, not a regulator.  Let's write policy that promotes
accuracy in Whois, please.



David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
________________________________
From: Bill Darte <billdarte at gmail.com <mailto:billdarte at gmail.com> >
Sent: Wednesday, March 5, 2014 7:00 AM
To: arin-ppml at arin.net <mailto:arin-ppml at arin.net> ; David Huberman; Owen
DeLong
Subject: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip Language

On Feb. 21 I sent the message (far below) to PPML asking the community to
support one of 3 alternatives or propose new language which makes one or the
other better, or a completely new wording which they believe accomplishes
the goal of producing policy language that is needed, technically sound and
improves existing policy in the 8.4 Inter-RIR transfer realm.


Summary of feedback so far:
2 persons supporting #2 with the removal of "and its subsidiaries".  There
was some support for the extended language of "and its subsidiaries having
been operational for a minimum of xx months" in order to mitigate the
rinse-repeat abuse that might accrue through new shell subsidiaries.


There was some support for the alternative language expressed in #3 at the
PPC in Atlanta and at the ARIN AC meeting on Feb 20.  This language simply
restricts the transfer of the block having been received...which would allow
other existing blocks or components to be transferred.  One view against #3
was expressed as "An org that currently has a /8 can obtain the resources it
needs and sell off the /8 out of region a few chunks at a time by
backfilling with new space from the ARIN region.". A rejoinder to this was
expressed pointing out that other existing language in 8.4 states...."Source
entities within the ARIN region will not be eligible to receive any further
IPv4 address allocations or assignments from ARIN for a period of 12 months
after a transfer approval, or until the exhaustion of ARIN's IPv4 space,
whichever occurs first."
<<< end summary >>>>




It is important that I receive a significant measure of support FOR or
AGAINST continuing to work on this Draft and before the ARIN AC meeting on
Mar 20, I would like to have better language to propose if we are to make
this Draft a Recommended Draft prior to the April PPM in Chicago.


I would be grateful for your feedback as early as possible.


bd


<<<<<<<<< earlier email sent to PPML on Feb 21 >>>>>>>>>>>>>>>
At the Advisory Council's meeting of Feb 20, discussion about Draft Policy
2014-2 concluded that there is a real issue with transfer restrictions of
address blocks between RIR jurisdictions for organizations having received a
different block of addresses from ARIN within the last 12 months (per
existing policy).


The current Draft Policy language is as follows with only the last sentence
being added from what is current ARIN policy:
"Source entities within the ARIN region must not have received a transfer,
allocation, or assignment of IPv4 number resources from ARIN for the 12
months prior to the approval of a transfer request. This restriction does
not include M&A transfers. Restrictions related to recent receipt of blocks
shall not apply to inter-RIR transfers within the same organization and its
subsidiaries."


The last sentence of this language was added to mitigate the problems
related by the author in the problem statement and from experience. The
author supported this change, however, some concern has been expressed on
the PPML and within the AC about the possibility of 'rinse and repeat' abuse
associated with the ease of establishing new subsidiaries and using those
transfers to get around the restrictions of the existing transfer policy.


Three alternatives were primarily discussed and I wish to elicit feedback
from the community relative to each.


1. Use the existing last sentence as is and ask ARIN staff to be
particularly watchful for seeming abuse and to bring such back to the
community through regular Policy Experience Reports.  There was discussion
about this option suggesting that by the time abuse was recognized and
reported, and given limited existing free pool stocks and the extended
policy development cycle....this option may be moot.


2. Remove the clause 'and its subsidiaries' or modify it in such a way as to
mitigate the risk of a laundering of addresses through fraudulent transfers,
but this may still potentially limit the utility to organizations who may
have complex organizational structures in use internationally.


3. Take an alternative tack and simply restrict transfers on a per-block
rather than a per-organization basis. e.g. 'No block acquired within the
past 24 months would be eligible for transfer.' (The time frame is of course
an arbitrary number at this point.)


If you believe this Draft Policy is improved most significantly by one of
the above alternatives, or through another alternative you can pose....I,
and the community would benefit from your input. Thanks,


Bill Darte
Policy Shepherd for 2014-2 and
Advisory Council member
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20140305/629d8e4f/att
achment-0001.html>

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

Message: 2
Date: Wed, 05 Mar 2014 17:54:34 -0800
From: Spam Auditor <spamauditor at linuxmagic.com
<mailto:spamauditor at linuxmagic.com> >
To: arin-ppml at arin.net <mailto:arin-ppml at arin.net> 
Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
        Anti-Flip       Language
Message-ID: <5317D55A.1030302 at linuxmagic.com
<mailto:5317D55A.1030302 at linuxmagic.com> >
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 14-03-05 01:17 PM, David Huberman wrote:
> As the author of this proposal, and having encountered the real-world
> consequences of existing 8.4 anti-flip language, I support #3 as the
> cleanest, simplest approach that best promotes Whois accuracy.
>
> ARIN is a registry, not a regulator.  Let's write policy that promotes
> accuracy in Whois, please.
>
> *David R Huberman*
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)

Here, Here...

However, even though it isn't a regulator, there should be enforcement
considerations, especially when IP Space is granted and used for
purposes contrary to the application..




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

Message: 3
Date: Wed, 5 Mar 2014 19:58:50 -0600
From: Bill Darte <billdarte at gmail.com <mailto:billdarte at gmail.com> >
To: Spam Auditor <spamauditor at linuxmagic.com
<mailto:spamauditor at linuxmagic.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] ARIN Draft Policy 2014-2 Improved 8.4
        Anti-Flip       Language
Message-ID:
        <CAMApp35hhh=djm_6j0mh-F2MNxWt4GMGLz771JHDUg+zYs0cag at mail.gmail.com
<mailto:djm_6j0mh-F2MNxWt4GMGLz771JHDUg%2BzYs0cag at mail.gmail.com> >
Content-Type: text/plain; charset="iso-8859-1"

Spam Auditor....
Are you FOR or AGAINST the proposal in general....and does your 'Hear,
Here' include David's support for option #3?
Thanks,
bd


On Wed, Mar 5, 2014 at 7:54 PM, Spam Auditor <spamauditor at linuxmagic.com
<mailto:spamauditor at linuxmagic.com> >wrote:

> On 14-03-05 01:17 PM, David Huberman wrote:
>
>> As the author of this proposal, and having encountered the real-world
>> consequences of existing 8.4 anti-flip language, I support #3 as the
>> cleanest, simplest approach that best promotes Whois accuracy.
>>
>> ARIN is a registry, not a regulator.  Let's write policy that promotes
>> accuracy in Whois, please.
>>
>> *David R Huberman*
>> Microsoft Corporation
>> Senior IT/OPS Program Manager (GFS)
>>
>
> Here, Here...
>
> However, even though it isn't a regulator, there should be enforcement
> considerations, especially when IP Space is granted and used for purposes
> contrary to the application..
>
>
> _______________________________________________
> 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:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20140305/378b9d59/att
achment.html>

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

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

End of ARIN-PPML Digest, Vol 105, Issue 11
******************************************

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

From jay-ARIN at tp.org  Fri Mar  7 12:18:34 2014
From: jay-ARIN at tp.org (Jay Moran (AOL))
Date: Fri, 7 Mar 2014 12:18:34 -0500
Subject: [arin-ppml] anti- flip Draft 2014-2
In-Reply-To: <011a01cf3a28$0c5ba830$2512f890$@crissic.net>
References: <CA+uaoiWCB8OoCf0CYKAyebxOeSx_tNeKF0KgavSJcxWLLdh7yw@mail.gmail.com>
	<011a01cf3a28$0c5ba830$2512f890$@crissic.net>
Message-ID: <CA+Ld8r8JfJxcSuVAZ0dAgA5afeoR2Fy--RSpyfKH9NqN-2pgqA@mail.gmail.com>

I support #3 as well.

Jay Moran
AOL, Inc.
--
Jay Moran
http://linkedin.com/in/jaycmoran


On Fri, Mar 7, 2014 at 12:09 PM, Skylar MacMinn <skylar at crissic.net> wrote:

> I support No. 3
>
>
>
> Cordially Yours,
>
>
>
> Skylar MacMinn
> www.crissic.net<https://bay170.mail.live.com/mail/17.1.6521.6000/Compose/www.crissic.net>
> Crissic Solutions, LLC
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *Rudolph Daniel
> *Sent:* Friday, March 7, 2014 11:04 AM
> *To:* arin-ppml at arin.net
> *Subject:* Re: [arin-ppml] anti- flip Draft 2014-2
>
>
>
> I can see the logic of supporting "3". I am going inclined to agree with
> David. We have to promote accuracy in whois as a policy priority.
>
> I support No. 3
>
> Rudi Daniel
> (information technologist)
> 784 430 9235
>
> On Mar 5, 2014 10:02 PM, <arin-ppml-request at arin.net> wrote:
>
> 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. Re: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip       Language
>       (David Huberman)
>    2. Re: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip       Language
>       (Spam Auditor)
>    3. Re: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip       Language
>       (Bill Darte)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 5 Mar 2014 21:17:58 +0000
> From: David Huberman <David.Huberman at microsoft.com>
> To: Bill Darte <billdarte at gmail.com>, "arin-ppml at arin.net"
>         <arin-ppml at arin.net>, Owen DeLong <owen at delong.com>
> Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
>         Anti-Flip       Language
> Message-ID:
>         <
> 87b03e32ad2743559958047e94c94044 at DM2PR03MB398.namprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> As the author of this proposal, and having encountered the real-world
> consequences of existing 8.4 anti-flip language, I support #3 as the
> cleanest, simplest approach that best promotes Whois accuracy.
>
>
>
> ARIN is a registry, not a regulator.  Let's write policy that promotes
> accuracy in Whois, please.
>
>
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> ________________________________
> From: Bill Darte <billdarte at gmail.com>
> Sent: Wednesday, March 5, 2014 7:00 AM
> To: arin-ppml at arin.net; David Huberman; Owen DeLong
> Subject: ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip Language
>
> On Feb. 21 I sent the message (far below) to PPML asking the community to
> support one of 3 alternatives or propose new language which makes one or
> the other better, or a completely new wording which they believe
> accomplishes the goal of producing policy language that is needed,
> technically sound and improves existing policy in the 8.4 Inter-RIR
> transfer realm.
>
>
> Summary of feedback so far:
> 2 persons supporting #2 with the removal of "and its subsidiaries".  There
> was some support for the extended language of "and its subsidiaries having
> been operational for a minimum of xx months" in order to mitigate the
> rinse-repeat abuse that might accrue through new shell subsidiaries.
>
>
> There was some support for the alternative language expressed in #3 at the
> PPC in Atlanta and at the ARIN AC meeting on Feb 20.  This language simply
> restricts the transfer of the block having been received...which would
> allow other existing blocks or components to be transferred.  One view
> against #3 was expressed as "An org that currently has a /8 can obtain the
> resources it needs and sell off the /8 out of region a few chunks at a time
> by backfilling with new space from the ARIN region.". A rejoinder to this
> was expressed pointing out that other existing language in 8.4
> states...."Source entities within the ARIN region will not be eligible to
> receive any further IPv4 address allocations or assignments from ARIN for a
> period of 12 months after a transfer approval, or until the exhaustion of
> ARIN's IPv4 space, whichever occurs first."
> <<< end summary >>>>
>
>
>
>
> It is important that I receive a significant measure of support FOR or
> AGAINST continuing to work on this Draft and before the ARIN AC meeting on
> Mar 20, I would like to have better language to propose if we are to make
> this Draft a Recommended Draft prior to the April PPM in Chicago.
>
>
> I would be grateful for your feedback as early as possible.
>
>
> bd
>
>
> <<<<<<<<< earlier email sent to PPML on Feb 21 >>>>>>>>>>>>>>>
> At the Advisory Council's meeting of Feb 20, discussion about Draft Policy
> 2014-2 concluded that there is a real issue with transfer restrictions of
> address blocks between RIR jurisdictions for organizations having received
> a different block of addresses from ARIN within the last 12 months (per
> existing policy).
>
>
> The current Draft Policy language is as follows with only the last
> sentence being added from what is current ARIN policy:
> "Source entities within the ARIN region must not have received a transfer,
> allocation, or assignment of IPv4 number resources from ARIN for the 12
> months prior to the approval of a transfer request. This restriction does
> not include M&A transfers. Restrictions related to recent receipt of blocks
> shall not apply to inter-RIR transfers within the same organization and its
> subsidiaries."
>
>
> The last sentence of this language was added to mitigate the problems
> related by the author in the problem statement and from experience. The
> author supported this change, however, some concern has been expressed on
> the PPML and within the AC about the possibility of 'rinse and repeat'
> abuse associated with the ease of establishing new subsidiaries and using
> those transfers to get around the restrictions of the existing transfer
> policy.
>
>
> Three alternatives were primarily discussed and I wish to elicit feedback
> from the community relative to each.
>
>
> 1. Use the existing last sentence as is and ask ARIN staff to be
> particularly watchful for seeming abuse and to bring such back to the
> community through regular Policy Experience Reports.  There was discussion
> about this option suggesting that by the time abuse was recognized and
> reported, and given limited existing free pool stocks and the extended
> policy development cycle....this option may be moot.
>
>
> 2. Remove the clause 'and its subsidiaries' or modify it in such a way as
> to mitigate the risk of a laundering of addresses through fraudulent
> transfers, but this may still potentially limit the utility to
> organizations who may have complex organizational structures in use
> internationally.
>
>
> 3. Take an alternative tack and simply restrict transfers on a per-block
> rather than a per-organization basis. e.g. 'No block acquired within the
> past 24 months would be eligible for transfer.' (The time frame is of
> course an arbitrary number at this point.)
>
>
> If you believe this Draft Policy is improved most significantly by one of
> the above alternatives, or through another alternative you can pose....I,
> and the community would benefit from your input. Thanks,
>
>
> Bill Darte
> Policy Shepherd for 2014-2 and
> Advisory Council member
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140305/629d8e4f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 05 Mar 2014 17:54:34 -0800
> From: Spam Auditor <spamauditor at linuxmagic.com>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
>         Anti-Flip       Language
> Message-ID: <5317D55A.1030302 at linuxmagic.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 14-03-05 01:17 PM, David Huberman wrote:
> > As the author of this proposal, and having encountered the real-world
> > consequences of existing 8.4 anti-flip language, I support #3 as the
> > cleanest, simplest approach that best promotes Whois accuracy.
> >
> > ARIN is a registry, not a regulator.  Let's write policy that promotes
> > accuracy in Whois, please.
> >
> > *David R Huberman*
> > Microsoft Corporation
> > Senior IT/OPS Program Manager (GFS)
>
> Here, Here...
>
> However, even though it isn't a regulator, there should be enforcement
> considerations, especially when IP Space is granted and used for
> purposes contrary to the application..
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 5 Mar 2014 19:58:50 -0600
> From: Bill Darte <billdarte at gmail.com>
> To: Spam Auditor <spamauditor at linuxmagic.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4
>         Anti-Flip       Language
> Message-ID:
>         <CAMApp35hhh=
> djm_6j0mh-F2MNxWt4GMGLz771JHDUg+zYs0cag at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Spam Auditor....
> Are you FOR or AGAINST the proposal in general....and does your 'Hear,
> Here' include David's support for option #3?
> Thanks,
> bd
>
>
> On Wed, Mar 5, 2014 at 7:54 PM, Spam Auditor <spamauditor at linuxmagic.com
> >wrote:
>
> > On 14-03-05 01:17 PM, David Huberman wrote:
> >
> >> As the author of this proposal, and having encountered the real-world
> >> consequences of existing 8.4 anti-flip language, I support #3 as the
> >> cleanest, simplest approach that best promotes Whois accuracy.
> >>
> >> ARIN is a registry, not a regulator.  Let's write policy that promotes
> >> accuracy in Whois, please.
> >>
> >> *David R Huberman*
> >> Microsoft Corporation
> >> Senior IT/OPS Program Manager (GFS)
> >>
> >
> > Here, Here...
> >
> > However, even though it isn't a regulator, there should be enforcement
> > considerations, especially when IP Space is granted and used for purposes
> > contrary to the application..
> >
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage 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: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140305/378b9d59/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 105, Issue 11
> ******************************************
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20140307/5a22d0e5/attachment.htm>

From mpetach at netflight.com  Sun Mar  9 14:46:14 2014
From: mpetach at netflight.com (Matthew Petach)
Date: Sun, 9 Mar 2014 11:46:14 -0700
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
	Language
In-Reply-To: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
Message-ID: <CAEmG1=pZoc4hYh-zsqKvK5AJVEqL6fggzZ_9EDuBbcD-PQeXOw@mail.gmail.com>

On Wed, Mar 5, 2014 at 7:00 AM, Bill Darte <billdarte at gmail.com> wrote:

> On Feb. 21 I sent the message (far below) to PPML asking the community to
> support one of 3 alternatives or propose new language which makes one or
> the other better, or a completely new wording which they believe
> accomplishes the goal of producing policy language that is needed,
> technically sound and improves existing policy in the 8.4 Inter-RIR
> transfer realm.
>
>  [...]
>


> 3. Take an alternative tack and simply restrict transfers on a per-block
> rather than a per-organization basis. e.g. 'No block acquired within the
> past 24 months would be eligible for transfer.' (The time frame is of
> course an arbitrary number at this point.)
>
>

I support option #3.

I'm curious if it would be better to reference time
periods from other sections of the NRPM, rather
than hard-coding a specific term here?  IE, if we
limit transfer requests to a 24-month supply, then
tie the anti-transfer period to be the same duration
as the supply length, so that if we extend or contract
the supply length for transfers, this anti-flip language
inherits the same change.   This doesn't affect my
support for option #3, I'm just looking to see if there's
ways we can limit the potential for the NRPM getting
'out of sync' with itself in the future, if we change one
section but don't catch all the related sections like this.

Thanks!

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

From billdarte at gmail.com  Sun Mar  9 19:02:24 2014
From: billdarte at gmail.com (Bill Darte)
Date: Sun, 9 Mar 2014 18:02:24 -0500
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
	Language
In-Reply-To: <CAEmG1=pZoc4hYh-zsqKvK5AJVEqL6fggzZ_9EDuBbcD-PQeXOw@mail.gmail.com>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
	<CAEmG1=pZoc4hYh-zsqKvK5AJVEqL6fggzZ_9EDuBbcD-PQeXOw@mail.gmail.com>
Message-ID: <CAMApp34LWxQGnZ9Y1QeZhZLxB-oc72Sw6RteW1GGU66hL91krg@mail.gmail.com>

Thanks Matt,

Great suggestion, seems reasonable on its face, though perhaps not all
transfers are the same....I will look at this and...perhaps others in the
community can suggest a way to easily do this or suggest why it may not be
prudent....

bd


On Sun, Mar 9, 2014 at 1:46 PM, Matthew Petach <mpetach at netflight.com>wrote:

>
>
>
> On Wed, Mar 5, 2014 at 7:00 AM, Bill Darte <billdarte at gmail.com> wrote:
>
>> On Feb. 21 I sent the message (far below) to PPML asking the community to
>> support one of 3 alternatives or propose new language which makes one or
>> the other better, or a completely new wording which they believe
>> accomplishes the goal of producing policy language that is needed,
>> technically sound and improves existing policy in the 8.4 Inter-RIR
>> transfer realm.
>>
>>  [...]
>>
>
>
>> 3. Take an alternative tack and simply restrict transfers on a per-block
>> rather than a per-organization basis. e.g. 'No block acquired within the
>> past 24 months would be eligible for transfer.' (The time frame is of
>> course an arbitrary number at this point.)
>>
>>
>
> I support option #3.
>
> I'm curious if it would be better to reference time
> periods from other sections of the NRPM, rather
> than hard-coding a specific term here?  IE, if we
> limit transfer requests to a 24-month supply, then
> tie the anti-transfer period to be the same duration
> as the supply length, so that if we extend or contract
> the supply length for transfers, this anti-flip language
> inherits the same change.   This doesn't affect my
> support for option #3, I'm just looking to see if there's
> ways we can limit the potential for the NRPM getting
> 'out of sync' with itself in the future, if we change one
> section but don't catch all the related sections like this.
>
> Thanks!
>
> Matt
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20140309/5be87acd/attachment.htm>

From jcurran at arin.net  Mon Mar 10 04:31:10 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 10 Mar 2014 08:31:10 +0000
Subject: [arin-ppml] ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip
 Language
In-Reply-To: <CAEmG1=pZoc4hYh-zsqKvK5AJVEqL6fggzZ_9EDuBbcD-PQeXOw@mail.gmail.com>
References: <CAMApp35Yo=pFY5QaRHoscr5p1vB_Mgm1jLLr=Xv+q=AXoXmxcQ@mail.gmail.com>
	<CAEmG1=pZoc4hYh-zsqKvK5AJVEqL6fggzZ_9EDuBbcD-PQeXOw@mail.gmail.com>
Message-ID: <4DE9B17E-FF40-43D6-91D3-23E2DEB91C99@corp.arin.net>

On Mar 9, 2014, at 2:46 PM, Matthew Petach <mpetach at netflight.com<mailto:mpetach at netflight.com>> wrote:

On Wed, Mar 5, 2014 at 7:00 AM, Bill Darte <billdarte at gmail.com<mailto:billdarte at gmail.com>> wrote:
...
3. Take an alternative tack and simply restrict transfers on a per-block rather than a per-organization basis. e.g. 'No block acquired within the past 24 months would be eligible for transfer.' (The time frame is of course an arbitrary number at this point.)

I support option #3.

I'm curious if it would be better to reference time
periods from other sections of the NRPM, rather
than hard-coding a specific term here?  IE, if we
limit transfer requests to a 24-month supply, then
tie the anti-transfer period to be the same duration
as the supply length, so that if we extend or contract
the supply length for transfers, this anti-flip language
inherits the same change.   This doesn't affect my
support for option #3, I'm just looking to see if there's
ways we can limit the potential for the NRPM getting
'out of sync' with itself in the future, if we change one
section but don't catch all the related sections like this.

Matt -

   It is possible to reference time periods from other policy sections of the NRPM,
   or define such periods upfront in the definitions section and reference them later,
   as the community prefers.  Either approach should reduce possibility of mismatch
   occurring as the result of future changes.

FYI,
/John

John Curran
President and CEO
ARIN

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

From andrew.dul at quark.net  Mon Mar 10 11:37:30 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Mon, 10 Mar 2014 08:37:30 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <531633FE.8010604@arin.net>
References: <531633FE.8010604@arin.net>
Message-ID: <531DDC3A.7000207@quark.net>

The ARIN AC would appreciate input from the community on this policy.

Specifically, do you support raising the number of participants required
to obtain an IXP micro allocation from 2 to 3?

Thanks,
Andrew

On 3/4/2014 12:13 PM, ARIN wrote:
>
>
> Draft Policy ARIN-2014-7
> Section 4.4 Micro Allocation Conservation Update
>
> Date: 4 March 2014
>
> Problem Statement:
>
> Two networks interconnecting are generally considered to be private
> peers. The current policy allows an IXP to receive a micro-allocation
> with only two devices. Given IPv4 exhaustion and the growth of IXPs in
> North America it is prudent to raise the minimum criteria so that
> micro-allocation space is not wasted.
>
> Policy statement:
>
> Change the following paragraph in Section 4.4 from:
>
> Exchange point operators must provide justification for the
> allocation, including: connection policy, location, other participants
> (minimum of two total), ASN, and contact information.
>
> To:
>
> Exchange point operators must provide justification for the
> allocation, including: connection policy, location, other participants
> (minimum of three total), ASN, and contact information.
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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 hannigan at gmail.com  Mon Mar 10 11:46:40 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 10 Mar 2014 11:46:40 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <531DDC3A.7000207@quark.net>
References: <531633FE.8010604@arin.net>
	<531DDC3A.7000207@quark.net>
Message-ID: <CAMDXq5PTbAB1WfP4KASJL8=F=Ar1pnv32i_dB77zQRQX99VC4w@mail.gmail.com>

Support to raise to at least three. Five might be truly optimal and best to
promote most fair conservation and legitimate use.

Best,

Martin




On Monday, March 10, 2014, Andrew Dul <andrew.dul at quark.net> wrote:

> The ARIN AC would appreciate input from the community on this policy.
>
> Specifically, do you support raising the number of participants required
> to obtain an IXP micro allocation from 2 to 3?
>
> Thanks,
> Andrew
>
> On 3/4/2014 12:13 PM, ARIN wrote:
> >
> >
> > Draft Policy ARIN-2014-7
> > Section 4.4 Micro Allocation Conservation Update
> >
> > Date: 4 March 2014
> >
> > Problem Statement:
> >
> > Two networks interconnecting are generally considered to be private
> > peers. The current policy allows an IXP to receive a micro-allocation
> > with only two devices. Given IPv4 exhaustion and the growth of IXPs in
> > North America it is prudent to raise the minimum criteria so that
> > micro-allocation space is not wasted.
> >
> > Policy statement:
> >
> > Change the following paragraph in Section 4.4 from:
> >
> > Exchange point operators must provide justification for the
> > allocation, including: connection policy, location, other participants
> > (minimum of two total), ASN, and contact information.
> >
> > To:
> >
> > Exchange point operators must provide justification for the
> > allocation, including: connection policy, location, other participants
> > (minimum of three total), ASN, and contact information.
> >
> > Comments:
> > a.Timetable for implementation: Immediate
> > b.Anything else:
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net <javascript:;> 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 <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140310/2288eec0/attachment.htm>

From David.Huberman at microsoft.com  Mon Mar 10 11:50:58 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 10 Mar 2014 15:50:58 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <531DDC3A.7000207@quark.net>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
Message-ID: <0a4fbb7a1d404f88b078468abe9d1f0d@DM2PR03MB398.namprd03.prod.outlook.com>

I support 2014-7's requirement to raise the number of participants required to obtain an IXP micro-allocation.  3 may be too low, but it's better than 2.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul
Sent: Monday, March 10, 2014 8:38 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation Conservation Update - Revised

The ARIN AC would appreciate input from the community on this policy.

Specifically, do you support raising the number of participants required to obtain an IXP micro allocation from 2 to 3?

Thanks,
Andrew

On 3/4/2014 12:13 PM, ARIN wrote:
>
>
> Draft Policy ARIN-2014-7
> Section 4.4 Micro Allocation Conservation Update
>
> Date: 4 March 2014
>
> Problem Statement:
>
> Two networks interconnecting are generally considered to be private 
> peers. The current policy allows an IXP to receive a micro-allocation 
> with only two devices. Given IPv4 exhaustion and the growth of IXPs in 
> North America it is prudent to raise the minimum criteria so that 
> micro-allocation space is not wasted.
>
> Policy statement:
>
> Change the following paragraph in Section 4.4 from:
>
> Exchange point operators must provide justification for the 
> allocation, including: connection policy, location, other participants 
> (minimum of two total), ASN, and contact information.
>
> To:
>
> Exchange point operators must provide justification for the 
> allocation, including: connection policy, location, other participants 
> (minimum of three total), ASN, and contact information.
>
> Comments:
> a.Timetable for implementation: Immediate b.Anything else:
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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


From michael at linuxmagic.com  Mon Mar 10 11:57:57 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Mon, 10 Mar 2014 08:57:57 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <531DDC3A.7000207@quark.net>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
Message-ID: <531DE105.70003@linuxmagic.com>

While on the surface this might seem prudent, it may be onerous for 
smaller players.  More information might be needed to determine adverse 
cases, or possibly some exemption for rural players that might not be 
able to attain a 3rd participant.

On 14-03-10 08:37 AM, Andrew Dul wrote:
> The ARIN AC would appreciate input from the community on this policy.
>
> Specifically, do you support raising the number of participants required
> to obtain an IXP micro allocation from 2 to 3?
>
> Thanks,
> Andrew
>
> On 3/4/2014 12:13 PM, ARIN wrote:
>>
>>
>> Draft Policy ARIN-2014-7
>> Section 4.4 Micro Allocation Conservation Update
>>
>> Date: 4 March 2014
>>
>> Problem Statement:
>>
>> Two networks interconnecting are generally considered to be private
>> peers. The current policy allows an IXP to receive a micro-allocation
>> with only two devices. Given IPv4 exhaustion and the growth of IXPs in
>> North America it is prudent to raise the minimum criteria so that
>> micro-allocation space is not wasted.
>>
>> Policy statement:
>>
>> Change the following paragraph in Section 4.4 from:
>>
>> Exchange point operators must provide justification for the
>> allocation, including: connection policy, location, other participants
>> (minimum of two total), ASN, and contact information.
>>
>> To:
>>
>> Exchange point operators must provide justification for the
>> allocation, including: connection policy, location, other participants
>> (minimum of three total), ASN, and contact information.
>>
>> Comments:
>> a.Timetable for implementation: Immediate
>> b.Anything else:
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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.
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From David.Huberman at microsoft.com  Mon Mar 10 12:05:03 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Mon, 10 Mar 2014 16:05:03 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <531DE105.70003@linuxmagic.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
Message-ID: <dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>

Michael Peddemors wrote:

> While on the surface this might seem prudent, it may be onerous for smaller players.
> More information might be needed to determine adverse cases, or possibly some 
> exemption for rural players that might not be able to attain a 3rd participant.

Is a public exchange point really a public exchange point if there are only 2 participants? Isn't that just private peering for the time during which no one else participates? I'm not seeing the public good, justifying the draw down of a /24 from the public free pool, for two participants.


From michael at linuxmagic.com  Mon Mar 10 12:24:09 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Mon, 10 Mar 2014 09:24:09 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <531DE729.3060508@linuxmagic.com>

On 14-03-10 09:05 AM, David Huberman wrote:
> Michael Peddemors wrote:
>
>> >While on the surface this might seem prudent, it may be onerous for smaller players.
>> >More information might be needed to determine adverse cases, or possibly some
>> >exemption for rural players that might not be able to attain a 3rd participant.
> Is a public exchange point really a public exchange point if there are only 2 participants? Isn't that just private peering for the time during which no one else participates? I'm not seeing the public good, justifying the draw down of a /24 from the public free pool, for two participants.

Understood, however the smaller regional players might want to get this 
in place for the future, when possibly additional peers may come available.

Just playing the devil's advocate, but that is the only reason I can see 
for not increasing it to three or more..



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From scottleibrand at gmail.com  Mon Mar 10 12:44:50 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Mon, 10 Mar 2014 09:44:50 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
	Allocation Conservation Update - Revised
In-Reply-To: <531DE729.3060508@linuxmagic.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
	<531DE729.3060508@linuxmagic.com>
Message-ID: <9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>


> On Mar 10, 2014, at 9:24 AM, Michael Peddemors <michael at linuxmagic.com> wrote:
> 
>> On 14-03-10 09:05 AM, David Huberman wrote:
>> Michael Peddemors wrote:
>> 
>>> >While on the surface this might seem prudent, it may be onerous for smaller players.
>>> >More information might be needed to determine adverse cases, or possibly some
>>> >exemption for rural players that might not be able to attain a 3rd participant.
>> Is a public exchange point really a public exchange point if there are only 2 participants? Isn't that just private peering for the time during which no one else participates? I'm not seeing the public good, justifying the draw down of a /24 from the public free pool, for two participants.
> 
> Understood, however the smaller regional players might want to get this in place for the future, when possibly additional peers may come available.
> 
> Just playing the devil's advocate, but that is the only reason I can see for not increasing it to three or more..

Any reason two small rural players shouldn't start with a PA /30 and renumber into a larger block if/when they get a third participant?

Unless someone has a good argument for why that's an excessive burden, support changing 2 to 3. 

Scott

From hannigan at gmail.com  Mon Mar 10 12:54:08 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 10 Mar 2014 12:54:08 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
	<531DE729.3060508@linuxmagic.com>
	<9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
Message-ID: <CAMDXq5NipM0zoB2QoZe9MT705aPOx9C2ZOe-XbUoMsixUicY5g@mail.gmail.com>

On Mon, Mar 10, 2014 at 12:44 PM, Scott Leibrand
<scottleibrand at gmail.com> wrote:
>
>> On Mar 10, 2014, at 9:24 AM, Michael Peddemors <michael at linuxmagic.com> wrote:
>>
>>> On 14-03-10 09:05 AM, David Huberman wrote:
>>> Michael Peddemors wrote:
>>>
>>>> >While on the surface this might seem prudent, it may be onerous for smaller players.
>>>> >More information might be needed to determine adverse cases, or possibly some
>>>> >exemption for rural players that might not be able to attain a 3rd participant.
>>> Is a public exchange point really a public exchange point if there are only 2 participants? Isn't that just private peering for the time during which no one else participates? I'm not seeing the public good, justifying the draw down of a /24 from the public free pool, for two participants.
>>
>> Understood, however the smaller regional players might want to get this in place for the future, when possibly additional peers may come available.
>>
>> Just playing the devil's advocate, but that is the only reason I can see for not increasing it to three or more..
>
> Any reason two small rural players shouldn't start with a PA /30 and renumber into a larger block if/when they get a third participant?
>
> Unless someone has a good argument for why that's an excessive burden, support changing 2 to 3.
>


Would you entertain more than 3?

Best,

-M<


From michael at linuxmagic.com  Mon Mar 10 12:57:55 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Mon, 10 Mar 2014 09:57:55 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <CAMDXq5NipM0zoB2QoZe9MT705aPOx9C2ZOe-XbUoMsixUicY5g@mail.gmail.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
	<531DE729.3060508@linuxmagic.com>
	<9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
	<CAMDXq5NipM0zoB2QoZe9MT705aPOx9C2ZOe-XbUoMsixUicY5g@mail.gmail.com>
Message-ID: <531DEF13.3020000@linuxmagic.com>

On 14-03-10 09:54 AM, Martin Hannigan wrote:
>>> Just playing the devil's advocate, but that is the only reason I can see for not increasing it to three or more..
>> >
>> >Any reason two small rural players shouldn't start with a PA /30 and renumber into a larger block if/when they get a third participant?
>> >
>> >Unless someone has a good argument for why that's an excessive burden, support changing 2 to 3.
>> >
>
> Would you entertain more than 3?
>
> Best,
>
> -M<

If the outside argument I mentioned is not something that would make 
anyone reconsider, then it might as well be more than 3..


-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From rudi.daniel at gmail.com  Mon Mar 10 13:11:41 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Mon, 10 Mar 2014 13:11:41 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation
Message-ID: <CA+uaoiU4dy+XqqKBMMNwN3_UpG=zNcMzrQu8D+6yeT8yidJ5OQ@mail.gmail.com>

Re: >>>Isn't that just private peering for the time during which no one
else >>>participates?

Surely you can have private peering with 3 participants or 5 participants
if you wish?
I dont see how you can decide simply based on the number of participants
there has to be more in the motar.

RD


>
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 10 Mar 2014 15:50:58 +0000
> From: David Huberman <David.Huberman at microsoft.com>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
>         Allocation Conservation Update - Revised
> Message-ID:
>         <
> 0a4fbb7a1d404f88b078468abe9d1f0d at DM2PR03MB398.namprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> I support 2014-7's requirement to raise the number of participants
> required to obtain an IXP micro-allocation.  3 may be too low, but it's
> better than 2.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Andrew Dul
> Sent: Monday, March 10, 2014 8:38 AM
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
> Allocation Conservation Update - Revised
>
> The ARIN AC would appreciate input from the community on this policy.
>
> Specifically, do you support raising the number of participants required
> to obtain an IXP micro allocation from 2 to 3?
>
> Thanks,
> Andrew
>
> On 3/4/2014 12:13 PM, ARIN wrote:
> >
> >
> > Draft Policy ARIN-2014-7
> > Section 4.4 Micro Allocation Conservation Update
> >
> > Date: 4 March 2014
> >
> > Problem Statement:
> >
> > Two networks interconnecting are generally considered to be private
> > peers. The current policy allows an IXP to receive a micro-allocation
> > with only two devices. Given IPv4 exhaustion and the growth of IXPs in
> > North America it is prudent to raise the minimum criteria so that
> > micro-allocation space is not wasted.
> >
> > Policy statement:
> >
> > Change the following paragraph in Section 4.4 from:
> >
> > Exchange point operators must provide justification for the
> > allocation, including: connection policy, location, other participants
> > (minimum of two total), ASN, and contact information.
> >
> > To:
> >
> > Exchange point operators must provide justification for the
> > allocation, including: connection policy, location, other participants
> > (minimum of three total), ASN, and contact information.
> >
> > Comments:
> > a.Timetable for implementation: Immediate b.Anything else:
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to the ARIN
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage 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.
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 10 Mar 2014 08:57:57 -0700
> From: Michael Peddemors <michael at linuxmagic.com>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
>         Allocation Conservation Update - Revised
> Message-ID: <531DE105.70003 at linuxmagic.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> While on the surface this might seem prudent, it may be onerous for
> smaller players.  More information might be needed to determine adverse
> cases, or possibly some exemption for rural players that might not be
> able to attain a 3rd participant.
>
> On 14-03-10 08:37 AM, Andrew Dul wrote:
> > The ARIN AC would appreciate input from the community on this policy.
> >
> > Specifically, do you support raising the number of participants required
> > to obtain an IXP micro allocation from 2 to 3?
> >
> > Thanks,
> > Andrew
> >
> > On 3/4/2014 12:13 PM, ARIN wrote:
> >>
> >>
> >> Draft Policy ARIN-2014-7
> >> Section 4.4 Micro Allocation Conservation Update
> >>
> >> Date: 4 March 2014
> >>
> >> Problem Statement:
> >>
> >> Two networks interconnecting are generally considered to be private
> >> peers. The current policy allows an IXP to receive a micro-allocation
> >> with only two devices. Given IPv4 exhaustion and the growth of IXPs in
> >> North America it is prudent to raise the minimum criteria so that
> >> micro-allocation space is not wasted.
> >>
> >> Policy statement:
> >>
> >> Change the following paragraph in Section 4.4 from:
> >>
> >> Exchange point operators must provide justification for the
> >> allocation, including: connection policy, location, other participants
> >> (minimum of two total), ASN, and contact information.
> >>
> >> To:
> >>
> >> Exchange point operators must provide justification for the
> >> allocation, including: connection policy, location, other participants
> >> (minimum of three total), ASN, and contact information.
> >>
> >> Comments:
> >> a.Timetable for implementation: Immediate
> >> b.Anything else:
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage 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.
> >
>
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 10 Mar 2014 16:05:03 +0000
> From: David Huberman <David.Huberman at microsoft.com>
> To: 'Michael Peddemors' <michael at linuxmagic.com>, "arin-ppml at arin.net"
>         <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
>         Allocation Conservation Update - Revised
> Message-ID:
>         <
> dfb6bb58dfc14d1d93ce0a13ec99c51f at DM2PR03MB398.namprd03.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Michael Peddemors wrote:
>
> > While on the surface this might seem prudent, it may be onerous for
> smaller players.
> > More information might be needed to determine adverse cases, or possibly
> some
> > exemption for rural players that might not be able to attain a 3rd
> participant.
>
> Is a public exchange point really a public exchange point if there are
> only 2 participants? Isn't that just private peering for the time during
> which no one else participates? I'm not seeing the public good, justifying
> the draw down of a /24 from the public free pool, for two participants.
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 10 Mar 2014 09:24:09 -0700
> From: Michael Peddemors <michael at linuxmagic.com>
> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
>         Allocation Conservation Update - Revised
> Message-ID: <531DE729.3060508 at linuxmagic.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 14-03-10 09:05 AM, David Huberman wrote:
> > Michael Peddemors wrote:
> >
> >> >While on the surface this might seem prudent, it may be onerous for
> smaller players.
> >> >More information might be needed to determine adverse cases, or
> possibly some
> >> >exemption for rural players that might not be able to attain a 3rd
> participant.
> > Is a public exchange point really a public exchange point if there are
> only 2 participants? Isn't that just private peering for the time during
> which no one else participates? I'm not seeing the public good, justifying
> the draw down of a /24 from the public free pool, for two participants.
>
> Understood, however the smaller regional players might want to get this
> in place for the future, when possibly additional peers may come available.
>
> Just playing the devil's advocate, but that is the only reason I can see
> for not increasing it to three or more..
>
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 10 Mar 2014 09:44:50 -0700
> From: Scott Leibrand <scottleibrand at gmail.com>
> To: Michael Peddemors <michael at linuxmagic.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
>         Allocation Conservation Update - Revised
> Message-ID: <9C7BCF42-A42A-469E-90B0-25C51AAA4F23 at gmail.com>
> Content-Type: text/plain;       charset=us-ascii
>
>
> > On Mar 10, 2014, at 9:24 AM, Michael Peddemors <michael at linuxmagic.com>
> wrote:
> >
> >> On 14-03-10 09:05 AM, David Huberman wrote:
> >> Michael Peddemors wrote:
> >>
> >>> >While on the surface this might seem prudent, it may be onerous for
> smaller players.
> >>> >More information might be needed to determine adverse cases, or
> possibly some
> >>> >exemption for rural players that might not be able to attain a 3rd
> participant.
> >> Is a public exchange point really a public exchange point if there are
> only 2 participants? Isn't that just private peering for the time during
> which no one else participates? I'm not seeing the public good, justifying
> the draw down of a /24 from the public free pool, for two participants.
> >
> > Understood, however the smaller regional players might want to get this
> in place for the future, when possibly additional peers may come available.
> >
> > Just playing the devil's advocate, but that is the only reason I can see
> for not increasing it to three or more..
>
> Any reason two small rural players shouldn't start with a PA /30 and
> renumber into a larger block if/when they get a third participant?
>
> Unless someone has a good argument for why that's an excessive burden,
> support changing 2 to 3.
>
> Scott
>
> ------------------------------
>
> Message: 6
> Date: Mon, 10 Mar 2014 12:54:08 -0400
> From: Martin Hannigan <hannigan at gmail.com>
> To: Scott Leibrand <scottleibrand at gmail.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
>         Allocation Conservation Update - Revised
> Message-ID:
>         <
> CAMDXq5NipM0zoB2QoZe9MT705aPOx9C2ZOe-XbUoMsixUicY5g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Mon, Mar 10, 2014 at 12:44 PM, Scott Leibrand
> <scottleibrand at gmail.com> wrote:
> >
> >> On Mar 10, 2014, at 9:24 AM, Michael Peddemors <michael at linuxmagic.com>
> wrote:
> >>
> >>> On 14-03-10 09:05 AM, David Huberman wrote:
> >>> Michael Peddemors wrote:
> >>>
> >>>> >While on the surface this might seem prudent, it may be onerous for
> smaller players.
> >>>> >More information might be needed to determine adverse cases, or
> possibly some
> >>>> >exemption for rural players that might not be able to attain a 3rd
> participant.
> >>> Is a public exchange point really a public exchange point if there are
> only 2 participants? Isn't that just private peering for the time during
> which no one else participates? I'm not seeing the public good, justifying
> the draw down of a /24 from the public free pool, for two participants.
> >>
> >> Understood, however the smaller regional players might want to get this
> in place for the future, when possibly additional peers may come available.
> >>
> >> Just playing the devil's advocate, but that is the only reason I can
> see for not increasing it to three or more..
> >
> > Any reason two small rural players shouldn't start with a PA /30 and
> renumber into a larger block if/when they get a third participant?
> >
> > Unless someone has a good argument for why that's an excessive burden,
> support changing 2 to 3.
> >
>
>
> Would you entertain more than 3?
>
> Best,
>
> -M<
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 10 Mar 2014 09:57:55 -0700
> From: Michael Peddemors <michael at linuxmagic.com>
> To: Martin Hannigan <hannigan at gmail.com>,       Scott Leibrand
>         <scottleibrand at gmail.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
>         Allocation Conservation Update - Revised
> Message-ID: <531DEF13.3020000 at linuxmagic.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 14-03-10 09:54 AM, Martin Hannigan wrote:
> >>> Just playing the devil's advocate, but that is the only reason I can
> see for not increasing it to three or more..
> >> >
> >> >Any reason two small rural players shouldn't start with a PA /30 and
> renumber into a larger block if/when they get a third participant?
> >> >
> >> >Unless someone has a good argument for why that's an excessive burden,
> support changing 2 to 3.
> >> >
> >
> > Would you entertain more than 3?
> >
> > Best,
> >
> > -M<
>
> If the outside argument I mentioned is not something that would make
> anyone reconsider, then it might as well be more than 3..
>
>
> --
> "Catch the Magic of Linux..."
> ------------------------------------------------------------------------
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
> ------------------------------------------------------------------------
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> ------------------------------------------------------------------------
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 105, Issue 16
> ******************************************
>



-- 

Rudi Daniel

*danielcharles consulting
<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140310/6d3a28e1/attachment.htm>

From billdarte at gmail.com  Mon Mar 10 15:29:01 2014
From: billdarte at gmail.com (Bill Darte)
Date: Mon, 10 Mar 2014 14:29:01 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
	<531DE729.3060508@linuxmagic.com>
	<9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
Message-ID: <CAMApp37dncuR8bGHbnmR8TYb2-tL+zjJUDBkkQpYJLkQ6v1k_w@mail.gmail.com>

Scott,
Isn't part of the issue here the getting of space in advance of runout?
 You can only renumber into a larger group if you have the IP addresses to
do so.  As Rudi points out...couldn't one do private peering with any
number of participants using existing addresses?

bd


On Mon, Mar 10, 2014 at 11:44 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:

>
> > On Mar 10, 2014, at 9:24 AM, Michael Peddemors <michael at linuxmagic.com>
> wrote:
> >
> >> On 14-03-10 09:05 AM, David Huberman wrote:
> >> Michael Peddemors wrote:
> >>
> >>> >While on the surface this might seem prudent, it may be onerous for
> smaller players.
> >>> >More information might be needed to determine adverse cases, or
> possibly some
> >>> >exemption for rural players that might not be able to attain a 3rd
> participant.
> >> Is a public exchange point really a public exchange point if there are
> only 2 participants? Isn't that just private peering for the time during
> which no one else participates? I'm not seeing the public good, justifying
> the draw down of a /24 from the public free pool, for two participants.
> >
> > Understood, however the smaller regional players might want to get this
> in place for the future, when possibly additional peers may come available.
> >
> > Just playing the devil's advocate, but that is the only reason I can see
> for not increasing it to three or more..
>
> Any reason two small rural players shouldn't start with a PA /30 and
> renumber into a larger block if/when they get a third participant?
>
> Unless someone has a good argument for why that's an excessive burden,
> support changing 2 to 3.
>
> Scott
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140310/81f45dce/attachment.htm>

From billdarte at gmail.com  Mon Mar 10 15:32:19 2014
From: billdarte at gmail.com (Bill Darte)
Date: Mon, 10 Mar 2014 14:32:19 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
	<531DE729.3060508@linuxmagic.com>
	<9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
Message-ID: <CAMApp37zbo-YoGV8cjA5HfdOsTueXtWRmyx65o24UU0qxHrLbA@mail.gmail.com>

Oh, BTW....I don't have any problem with increasing from 2 to 3, but am
against it for more....and, I may be willing to carve out an exception for
Caribbean communities still encumbered by limited competition.  There, have
a public exchange already in existence may support future competition.  I'd
be very interested to hear from our colleagues in that sub-region.


bd


On Mon, Mar 10, 2014 at 11:44 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:

>
> > On Mar 10, 2014, at 9:24 AM, Michael Peddemors <michael at linuxmagic.com>
> wrote:
> >
> >> On 14-03-10 09:05 AM, David Huberman wrote:
> >> Michael Peddemors wrote:
> >>
> >>> >While on the surface this might seem prudent, it may be onerous for
> smaller players.
> >>> >More information might be needed to determine adverse cases, or
> possibly some
> >>> >exemption for rural players that might not be able to attain a 3rd
> participant.
> >> Is a public exchange point really a public exchange point if there are
> only 2 participants? Isn't that just private peering for the time during
> which no one else participates? I'm not seeing the public good, justifying
> the draw down of a /24 from the public free pool, for two participants.
> >
> > Understood, however the smaller regional players might want to get this
> in place for the future, when possibly additional peers may come available.
> >
> > Just playing the devil's advocate, but that is the only reason I can see
> for not increasing it to three or more..
>
> Any reason two small rural players shouldn't start with a PA /30 and
> renumber into a larger block if/when they get a third participant?
>
> Unless someone has a good argument for why that's an excessive burden,
> support changing 2 to 3.
>
> Scott
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140310/42f9c112/attachment.htm>

From hannigan at gmail.com  Mon Mar 10 15:38:13 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 10 Mar 2014 15:38:13 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <CAMApp37zbo-YoGV8cjA5HfdOsTueXtWRmyx65o24UU0qxHrLbA@mail.gmail.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
	<531DE729.3060508@linuxmagic.com>
	<9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
	<CAMApp37zbo-YoGV8cjA5HfdOsTueXtWRmyx65o24UU0qxHrLbA@mail.gmail.com>
Message-ID: <CAMDXq5OpDE0HmWpqPh3Ed=54buFKHD_KZcdRYHGEbSBKFJJG+A@mail.gmail.com>

No exceptions for Caribbean.  Not necessary. And not part of policy so no
need to rather already.

The addresses are being protected for the future,  ncluding tbe Carribean.

Feel free to elaborate on "more", I'm interested.

On Monday, March 10, 2014, Bill Darte <billdarte at gmail.com> wrote:

> Oh, BTW....I don't have any problem with increasing from 2 to 3, but am
> against it for more....and, I may be willing to carve out an exception for
> Caribbean communities still encumbered by limited competition.  There, have
> a public exchange already in existence may support future competition.  I'd
> be very interested to hear from our colleagues in that sub-region.
>
>
> bd
>
>
> On Mon, Mar 10, 2014 at 11:44 AM, Scott Leibrand <scottleibrand at gmail.com<javascript:_e(%7B%7D,'cvml','scottleibrand at gmail.com');>
> > wrote:
>
>>
>> > On Mar 10, 2014, at 9:24 AM, Michael Peddemors <michael at linuxmagic.com<javascript:_e(%7B%7D,'cvml','michael at linuxmagic.com');>>
>> wrote:
>> >
>> >> On 14-03-10 09:05 AM, David Huberman wrote:
>> >> Michael Peddemors wrote:
>> >>
>> >>> >While on the surface this might seem prudent, it may be onerous for
>> smaller players.
>> >>> >More information might be needed to determine adverse cases, or
>> possibly some
>> >>> >exemption for rural players that might not be able to attain a 3rd
>> participant.
>> >> Is a public exchange point really a public exchange point if there are
>> only 2 participants? Isn't that just private peering for the time during
>> which no one else participates? I'm not seeing the public good, justifying
>> the draw down of a /24 from the public free pool, for two participants.
>> >
>> > Understood, however the smaller regional players might want to get this
>> in place for the future, when possibly additional peers may come available.
>> >
>> > Just playing the devil's advocate, but that is the only reason I can
>> see for not increasing it to three or more..
>>
>> Any reason two small rural players shouldn't start with a PA /30 and
>> renumber into a larger block if/when they get a third participant?
>>
>> Unless someone has a good argument for why that's an excessive burden,
>> support changing 2 to 3.
>>
>> Scott
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<javascript:_e(%7B%7D,'cvml','ARIN-PPML at arin.net');>
>> ).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net<javascript:_e(%7B%7D,'cvml','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/20140310/5bd0603b/attachment.htm>

From bross at pobox.com  Mon Mar 10 15:46:59 2014
From: bross at pobox.com (Brandon Ross)
Date: Mon, 10 Mar 2014 15:46:59 -0400 (EDT)
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <alpine.OSX.2.02.1403101543550.958@brugal.local>

On Mon, 10 Mar 2014, David Huberman wrote:

> Michael Peddemors wrote:
>
>> While on the surface this might seem prudent, it may be onerous for smaller players.
>> More information might be needed to determine adverse cases, or possibly some
>> exemption for rural players that might not be able to attain a 3rd participant.
>
> Is a public exchange point really a public exchange point if there are 
> only 2 participants?

It is if it's open to more participants at any time.

> Isn't that just private peering for the time during which no one else 
> participates?

Not necessarily, a private peering would almost always be implemented very 
differently than an IX.

> I'm not seeing the public good, justifying the draw down of a /24 from 
> the public free pool, for two participants.

The value of more potential IXs becoming available to the public far 
outweighs the tiny bit of IPv4 space that this proposal might consume.

Clearly I'm against raising the requirement.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
                                                          Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross


From bross at pobox.com  Mon Mar 10 15:50:54 2014
From: bross at pobox.com (Brandon Ross)
Date: Mon, 10 Mar 2014 15:50:54 -0400 (EDT)
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
	<531DE729.3060508@linuxmagic.com>
	<9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
Message-ID: <alpine.OSX.2.02.1403101547090.958@brugal.local>

On Mon, 10 Mar 2014, Scott Leibrand wrote:

> Any reason two small rural players shouldn't start with a PA /30 and 
> renumber into a larger block if/when they get a third participant?

Yes, renumbering is hard.  Renumbering is even harder for rural entities 
that don't have tons of high end network engineers around.  It's hard 
enough for rural service providers to pool enough funds to buy a switch 
and stand up an IX, discouraging them from building additional 
interconnectivity by making it difficult to get IP addresses is 
disappointing.

On the other hand, there is absolutely no downside to keeping the 
requirement the way it is.  Changing it does nothing for conservation of 
IPv4 addresses at all, as any dishonest players won't have a harder time 
at all faking 3 entities as compared to 2.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
                                                          Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross


From fearghas at gmail.com  Mon Mar 10 15:51:13 2014
From: fearghas at gmail.com (Fearghas McKay)
Date: Mon, 10 Mar 2014 20:51:13 +0100
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
	Allocation Conservation Update - Revised
In-Reply-To: <531DE105.70003@linuxmagic.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
Message-ID: <6D750D4C-6C90-4D61-BCEA-29EF6C79456F@gmail.com>


On 10 Mar 2014, at 16:57, Michael Peddemors <michael at linuxmagic.com> wrote:

> While on the surface this might seem prudent, it may be onerous for smaller players.  More information might be needed to determine adverse cases, or possibly some exemption for rural players that might not be able to attain a 3rd participant.

If it is two players then it is a Private Interconnect. 

You need three to have an exchange. More than three is no different. 

	f



From SRyerse at eclipse-networks.com  Mon Mar 10 15:56:50 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Mon, 10 Mar 2014 19:56:50 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4
 MicroAllocation Conservation Update - Revised
In-Reply-To: <alpine.OSX.2.02.1403101547090.958@brugal.local>
References: <531633FE.8010604@arin.net>
	<531DDC3A.7000207@quark.net><531DE105.70003@linuxmagic.com><dfb6bb58dfc14d1
	d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com><531DE729.3060508@
	linuxmagic.com><9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
	<alpine.OSX.2.02.1403101547090.958@brugal.local>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12015286CFB0@ENI-MAIL.eclipse-networks.com>

I agree there is no downside keeping it as it is.  We ought to be making it easier not harder wherever we can.  I'm against changing it as well.  

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA? 30338
770.656.1460 - Cell
770.399.9099- Office

? Eclipse Networks, Inc.
             ??????? Conquering Complex Networks?


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brandon Ross
Sent: Monday, March 10, 2014 3:51 PM
To: Scott Leibrand
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 MicroAllocation Conservation Update - Revised

On Mon, 10 Mar 2014, Scott Leibrand wrote:

> Any reason two small rural players shouldn't start with a PA /30 and 
> renumber into a larger block if/when they get a third participant?

Yes, renumbering is hard.  Renumbering is even harder for rural entities that don't have tons of high end network engineers around.  It's hard enough for rural service providers to pool enough funds to buy a switch and stand up an IX, discouraging them from building additional interconnectivity by making it difficult to get IP addresses is disappointing.

On the other hand, there is absolutely no downside to keeping the requirement the way it is.  Changing it does nothing for conservation of
IPv4 addresses at all, as any dishonest players won't have a harder time at all faking 3 entities as compared to 2.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
                                                          Skype:  brandonross Schedule a meeting:  http://www.doodle.com/bross _______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage 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 bross at pobox.com  Tue Mar 11 00:13:44 2014
From: bross at pobox.com (Brandon Ross)
Date: Tue, 11 Mar 2014 00:13:44 -0400 (EDT)
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <531DDC3A.7000207@quark.net>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
Message-ID: <alpine.OSX.2.02.1403110011180.958@brugal.local>

On Mon, 10 Mar 2014, Andrew Dul wrote:

> Specifically, do you support raising the number of participants required
> to obtain an IXP micro allocation from 2 to 3?

An off-list conversation helped me clarify my concern about raising the 
requirement.  It's not just the burden of renumbering alone that's the 
problem, it's the chilling effect it has on the market.  It's already hard 
enough to get a new IX started.  Adding on to that with the knowledge that 
you are unable to get permanent IP space when you start only adds to the 
problem.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
                                                          Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross


From gary.buhrmaster at gmail.com  Tue Mar 11 00:31:37 2014
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Tue, 11 Mar 2014 04:31:37 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <531DDC3A.7000207@quark.net>
References: <531633FE.8010604@arin.net>
	<531DDC3A.7000207@quark.net>
Message-ID: <CAMfXtQziQ-dE2UFkkxCmcKopq4Z52ory6tFd4P=Dncz1Vq7hVw@mail.gmail.com>

On Mon, Mar 10, 2014 at 3:37 PM, Andrew Dul <andrew.dul at quark.net> wrote:
> The ARIN AC would appreciate input from the community on this policy.
>
> Specifically, do you support raising the number of participants required
> to obtain an IXP micro allocation from 2 to 3?

I support raising the number to 3 for the reasons previously presented
in the discussions of 2014-7 from early February.


From michael at linuxmagic.com  Tue Mar 11 11:23:27 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Tue, 11 Mar 2014 08:23:27 -0700
Subject: [arin-ppml] What would the proper method be for reporting bad
	rwhois referrers?
Message-ID: <531F2A6F.9070705@linuxmagic.com>

We see that many ARIN allocated blocks seem to have referral whois 
servers listed at ARIN for their net blocks, but the listing is not 
accurate/not functioning..

Eg, the example below..

What would the ARIN recommended practice be for reporting these cases?

NetRange:       209.152.160.0 - 209.152.191.255
CIDR:           209.152.160.0/19
OriginAS:       AS32748
NetName:        NET-209-152-160-0-19
NetHandle:      NET-209-152-160-0-2
Parent:         NET-209-0-0-0-0
NetType:        Direct Allocation
RegDate:        2002-06-12
Updated:        2012-09-10
Ref:            http://whois.arin.net/rest/net/NET-209-152-160-0-2

OrgName:        WebHostPlus Inc
OrgId:          WEBHO-3
Address:        2621 PICO BLVD
Address:        Unit H
City:           SANTA MONICA
StateProv:      CA
PostalCode:     90405
Country:        US
RegDate:        2003-06-27
Updated:        2012-04-25
Ref:            http://whois.arin.net/rest/org/WEBHO-3

ReferralServer: rwhois://whois.americandedicated.com:4321

Found a referral to whois.americandedicated.com:4321.

getaddrinfo(whois.americandedicated.com): Name or service not known

  
-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.



From andrew.dul at quark.net  Tue Mar 11 14:09:29 2014
From: andrew.dul at quark.net (Andrew Dul)
Date: Tue, 11 Mar 2014 11:09:29 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4
 MicroAllocation Conservation Update - Revised
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12015286CFB0@ENI-MAIL.eclipse-networks.com>
References: <531633FE.8010604@arin.net>	<531DDC3A.7000207@quark.net><531DE105.70003@linuxmagic.com><dfb6bb58dfc14d1	d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com><531DE729.3060508@	linuxmagic.com><9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>	<alpine.OSX.2.02.1403101547090.958@brugal.local>
	<5B9E90747FA2974D91A54FCFA1B8AD12015286CFB0@ENI-MAIL.eclipse-networks.com>
Message-ID: <531F5159.4080301@quark.net>

For those who are concerned about making sure these types of blocks are
available in the future, there are two other avenues which could be
explored beyond what is proposed in this policy.

1. Increase the size of reserved block which ARIN is holding for
micro-allocations.

2. Remove the /24 minimum for IXP allocations.  Since there is no
technical reason to have an IXP block be a /24 and the operational best
practice is to not route these blocks we could look at "right sizing"
IXP blocks rather giving a very small IXPs a rather large block for what
they need.  Yes, this brings up the possible renumbering issue in the
future, but a /25 or /26 still allows quite a number of IXP participants. 

Do operators have any thoughts on these ideas?

Thanks,
Andrew

On 3/10/2014 12:56 PM, Steven Ryerse wrote:
> I agree there is no downside keeping it as it is.  We ought to be making it easier not harder wherever we can.  I'm against changing it as well.  
>
> Steven Ryerse
> President
> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> 770.656.1460 - Cell
> 770.399.9099- Office
>
> ? Eclipse Networks, Inc.
>                      Conquering Complex Networks?
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brandon Ross
> Sent: Monday, March 10, 2014 3:51 PM
> To: Scott Leibrand
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 MicroAllocation Conservation Update - Revised
>
> On Mon, 10 Mar 2014, Scott Leibrand wrote:
>
>> Any reason two small rural players shouldn't start with a PA /30 and 
>> renumber into a larger block if/when they get a third participant?
> Yes, renumbering is hard.  Renumbering is even harder for rural entities that don't have tons of high end network engineers around.  It's hard enough for rural service providers to pool enough funds to buy a switch and stand up an IX, discouraging them from building additional interconnectivity by making it difficult to get IP addresses is disappointing.
>
> On the other hand, there is absolutely no downside to keeping the requirement the way it is.  Changing it does nothing for conservation of
> IPv4 addresses at all, as any dishonest players won't have a harder time at all faking 3 entities as compared to 2.
>



From owen at delong.com  Tue Mar 11 14:34:49 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 11 Mar 2014 11:34:49 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4
	MicroAllocation Conservation Update - Revised
In-Reply-To: <531F5159.4080301@quark.net>
References: <531633FE.8010604@arin.net>	<531DDC3A.7000207@quark.net><531DE105.70003@linuxmagic.com><dfb6bb58dfc14d1	d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com><531DE729.3060508@	linuxmagic.com><9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>	<alpine.OSX.2.02.1403101547090.958@brugal.local>
	<5B9E90747FA2974D91A54FCFA1B8AD12015286CFB0@ENI-MAIL.eclipse-networks.com>
	<531F5159.4080301@quark.net>
Message-ID: <983A98E8-51F7-499E-9CC5-F3B24EC92FE6@delong.com>

The primary thought that comes to my mind:

1.	By the time it got through the policy process, it would probably be overtaken by events.

2.	Deck chairs.

Owen

On Mar 11, 2014, at 11:09 , Andrew Dul <andrew.dul at quark.net> wrote:

> For those who are concerned about making sure these types of blocks are
> available in the future, there are two other avenues which could be
> explored beyond what is proposed in this policy.
> 
> 1. Increase the size of reserved block which ARIN is holding for
> micro-allocations.
> 
> 2. Remove the /24 minimum for IXP allocations.  Since there is no
> technical reason to have an IXP block be a /24 and the operational best
> practice is to not route these blocks we could look at "right sizing"
> IXP blocks rather giving a very small IXPs a rather large block for what
> they need.  Yes, this brings up the possible renumbering issue in the
> future, but a /25 or /26 still allows quite a number of IXP participants. 
> 
> Do operators have any thoughts on these ideas?
> 
> Thanks,
> Andrew
> 
> On 3/10/2014 12:56 PM, Steven Ryerse wrote:
>> I agree there is no downside keeping it as it is.  We ought to be making it easier not harder wherever we can.  I'm against changing it as well.  
>> 
>> Steven Ryerse
>> President
>> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
>> 770.656.1460 - Cell
>> 770.399.9099- Office
>> 
>> ? Eclipse Networks, Inc.
>>                     Conquering Complex Networks?
>> 
>> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brandon Ross
>> Sent: Monday, March 10, 2014 3:51 PM
>> To: Scott Leibrand
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 MicroAllocation Conservation Update - Revised
>> 
>> On Mon, 10 Mar 2014, Scott Leibrand wrote:
>> 
>>> Any reason two small rural players shouldn't start with a PA /30 and 
>>> renumber into a larger block if/when they get a third participant?
>> Yes, renumbering is hard.  Renumbering is even harder for rural entities that don't have tons of high end network engineers around.  It's hard enough for rural service providers to pool enough funds to buy a switch and stand up an IX, discouraging them from building additional interconnectivity by making it difficult to get IP addresses is disappointing.
>> 
>> On the other hand, there is absolutely no downside to keeping the requirement the way it is.  Changing it does nothing for conservation of
>> IPv4 addresses at all, as any dishonest players won't have a harder time at all faking 3 entities as compared to 2.
>> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.



From scottleibrand at gmail.com  Tue Mar 11 15:05:50 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 11 Mar 2014 12:05:50 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4
 MicroAllocation Conservation Update - Revised
In-Reply-To: <531F5159.4080301@quark.net>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
	<alpine.OSX.2.02.1403101547090.958@brugal.local>
	<5B9E90747FA2974D91A54FCFA1B8AD12015286CFB0@ENI-MAIL.eclipse-networks.com>
	<531F5159.4080301@quark.net>
Message-ID: <CAGkMwz7DVRTLhXbRMy-1Vh28HWB1iVW6Lqh7G8WPRZONpZAwNg@mail.gmail.com>

On Tue, Mar 11, 2014 at 11:09 AM, Andrew Dul <andrew.dul at quark.net> wrote:

> For those who are concerned about making sure these types of blocks are
> available in the future, there are two other avenues which could be
> explored beyond what is proposed in this policy.
>
> 1. Increase the size of reserved block which ARIN is holding for
> micro-allocations.
>

We put "new GTLD" operators back in the general pool, so I don't think we
need to reserve more space.  If we're still needing IPv4 for IXPs when the
current reserved block runs out, we could probably replenish it from
returns, or just let them get on the waiting list or get space via transfer
like everyone else.


> 2. Remove the /24 minimum for IXP allocations.  Since there is no
> technical reason to have an IXP block be a /24 and the operational best
> practice is to not route these blocks we could look at "right sizing"
> IXP blocks rather giving a very small IXPs a rather large block for what
> they need.  Yes, this brings up the possible renumbering issue in the
> future, but a /25 or /26 still allows quite a number of IXP participants.
>

I'd be fine with removing the /24 minimum for IXP allocations, particularly
since they're not globally routed.

-Scott


>
> Do operators have any thoughts on these ideas?
>
> Thanks,
> Andrew
>
> On 3/10/2014 12:56 PM, Steven Ryerse wrote:
> > I agree there is no downside keeping it as it is.  We ought to be making
> it easier not harder wherever we can.  I'm against changing it as well.
> >
> > Steven Ryerse
> > President
> > 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> > 770.656.1460 - Cell
> > 770.399.9099- Office
> >
> > ? Eclipse Networks, Inc.
> >                      Conquering Complex Networks?
> >
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Brandon Ross
> > Sent: Monday, March 10, 2014 3:51 PM
> > To: Scott Leibrand
> > Cc: arin-ppml at arin.net
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4
> MicroAllocation Conservation Update - Revised
> >
> > On Mon, 10 Mar 2014, Scott Leibrand wrote:
> >
> >> Any reason two small rural players shouldn't start with a PA /30 and
> >> renumber into a larger block if/when they get a third participant?
> > Yes, renumbering is hard.  Renumbering is even harder for rural entities
> that don't have tons of high end network engineers around.  It's hard
> enough for rural service providers to pool enough funds to buy a switch and
> stand up an IX, discouraging them from building additional
> interconnectivity by making it difficult to get IP addresses is
> disappointing.
> >
> > On the other hand, there is absolutely no downside to keeping the
> requirement the way it is.  Changing it does nothing for conservation of
> > IPv4 addresses at all, as any dishonest players won't have a harder time
> at all faking 3 entities as compared to 2.
> >
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140311/2496edf8/attachment.htm>

From farmer at umn.edu  Tue Mar 11 15:05:55 2014
From: farmer at umn.edu (David Farmer)
Date: Tue, 11 Mar 2014 14:05:55 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <alpine.OSX.2.02.1403110011180.958@brugal.local>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<alpine.OSX.2.02.1403110011180.958@brugal.local>
Message-ID: <531F5E93.8020206@umn.edu>

On 3/10/14, 23:13 , Brandon Ross wrote:
> On Mon, 10 Mar 2014, Andrew Dul wrote:
>
>> Specifically, do you support raising the number of participants required
>> to obtain an IXP micro allocation from 2 to 3?
>
> An off-list conversation helped me clarify my concern about raising the
> requirement.  It's not just the burden of renumbering alone that's the
> problem, it's the chilling effect it has on the market.  It's already
> hard enough to get a new IX started.  Adding on to that with the
> knowledge that you are unable to get permanent IP space when you start
> only adds to the problem.

What if we changed the standard from "other participants (minimum of two 
total)",to "other participants (minimum written commitment from three 
separate participants to connect within 6 months)."

The point being if you can't get a commitment in writing from three 
participants to connect within 6 month the probability of you having a 
viable and sustainable IX is pretty low to nonexistent.

So, I support raising the number of participants to 3, but lowering the 
standard to a written commitment to connect within 6 months.

This even solves the chicken and egg problem with the current policy, 
which implies you have two connected parties even before you are 
eligible to receive an allocation.  With the new language, you need 
three parties willing to make a written commitment to connect within 6 
months.  Which means you can get the IX allocation before anyone 
connects.  And, even if one participant drops out, you would have some 
time to find another participant before you are out of compliance.

What do people think of that concept?

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


From bross at pobox.com  Tue Mar 11 16:02:16 2014
From: bross at pobox.com (Brandon Ross)
Date: Tue, 11 Mar 2014 16:02:16 -0400 (EDT)
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <531F5E93.8020206@umn.edu>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<alpine.OSX.2.02.1403110011180.958@brugal.local>
	<531F5E93.8020206@umn.edu>
Message-ID: <alpine.OSX.2.02.1403111600330.931@brugal.local>

On Tue, 11 Mar 2014, David Farmer wrote:

> On 3/10/14, 23:13 , Brandon Ross wrote:
>> On Mon, 10 Mar 2014, Andrew Dul wrote:
>> 
>>> Specifically, do you support raising the number of participants required
>>> to obtain an IXP micro allocation from 2 to 3?
>> 
>> An off-list conversation helped me clarify my concern about raising the
>> requirement.  It's not just the burden of renumbering alone that's the
>> problem, it's the chilling effect it has on the market.  It's already
>> hard enough to get a new IX started.  Adding on to that with the
>> knowledge that you are unable to get permanent IP space when you start
>> only adds to the problem.
>
> What if we changed the standard from "other participants (minimum of two 
> total)",to "other participants (minimum written commitment from three 
> separate participants to connect within 6 months)."

That change would change my negative support to neutral.

-- 
Brandon Ross                                      Yahoo & AIM:  BrandonNRoss
+1-404-635-6667                                                ICQ:  2269442
                                                          Skype:  brandonross
Schedule a meeting:  http://www.doodle.com/bross


From hannigan at gmail.com  Tue Mar 11 16:57:24 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 11 Mar 2014 16:57:24 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
Message-ID: <CAMDXq5Pg0u1Sf_DsMq5-=bK7-SbC92UhZbJO3eU4ZWmhOKZ4sA@mail.gmail.com>

Different issues. Two  will always be a PNI. Submit other proposals for
other issues please.

Best,
Martin


On Tuesday, March 11, 2014, Andrew Dul <andrew.dul at quark.net> wrote:

> For those who are concerned about making sure these types of blocks are
> available in the future, there are two other avenues which could be
> explored beyond what is proposed in this policy.
>
> 1. Increase the size of reserved block which ARIN is holding for
> micro-allocations.
>
> 2. Remove the /24 minimum for IXP allocations.  Since there is no
> technical reason to have an IXP block be a /24 and the operational best
> practice is to not route these blocks we could look at "right sizing"
> IXP blocks rather giving a very small IXPs a rather large block for what
> they need.  Yes, this brings up the possible renumbering issue in the
> future, but a /25 or /26 still allows quite a number of IXP participants.
>
> Do operators have any thoughts on these ideas?
>
> Thanks,
> Andrew
>
> On 3/10/2014 12:56 PM, Steven Ryerse wrote:
> > I agree there is no downside keeping it as it is.  We ought to be making
> it easier not harder wherever we can.  I'm against changing it as well.
> >
> > Steven Ryerse
> > President
> > 100 Ashford Center North, Suite 110, Atlanta, GA  30338
> > 770.656.1460 - Cell
> > 770.399.9099- Office
> >
> > ? Eclipse Networks, Inc.
> >                      Conquering Complex Networks?
> >
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net <javascript:;> [mailto:
> arin-ppml-bounces at arin.net <javascript:;>] On Behalf Of Brandon Ross
> > Sent: Monday, March 10, 2014 3:51 PM
> > To: Scott Leibrand
> > Cc: arin-ppml at arin.net <javascript:;>
> > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4
> MicroAllocation Conservation Update - Revised
> >
> > On Mon, 10 Mar 2014, Scott Leibrand wrote:
> >
> >> Any reason two small rural players shouldn't start with a PA /30 and
> >> renumber into a larger block if/when they get a third participant?
> > Yes, renumbering is hard.  Renumbering is even harder for rural entities
> that don't have tons of high end network engineers around.  It's hard
> enough for rural service providers to pool enough funds to buy a switch and
> stand up an IX, discouraging them from building additional
> interconnectivity by making it difficult to get IP addresses is
> disappointing.
> >
> > On the other hand, there is absolutely no downside to keeping the
> requirement the way it is.  Changing it does nothing for conservation of
> > IPv4 addresses at all, as any dishonest players won't have a harder time
> at all faking 3 entities as compared to 2.
> >
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140311/b4fe176a/attachment.htm>

From bill at herrin.us  Tue Mar 11 17:01:18 2014
From: bill at herrin.us (William Herrin)
Date: Tue, 11 Mar 2014 17:01:18 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <CAMDXq5NipM0zoB2QoZe9MT705aPOx9C2ZOe-XbUoMsixUicY5g@mail.gmail.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
	<531DE729.3060508@linuxmagic.com>
	<9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
	<CAMDXq5NipM0zoB2QoZe9MT705aPOx9C2ZOe-XbUoMsixUicY5g@mail.gmail.com>
Message-ID: <CAP-guGX2C=155mdM6c2vX1ceCjBRivJJOfR87eiZudN1LjioPQ@mail.gmail.com>

On Mon, Mar 10, 2014 at 12:54 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> On Mon, Mar 10, 2014 at 12:44 PM, Scott Leibrand
> <scottleibrand at gmail.com> wrote:
>> Any reason two small rural players shouldn't start with
>> a PA /30 and renumber into a larger block if/when they get a third participant?
>>
>> Unless someone has a good argument for why that's an excessive burden, support changing 2 to 3.

Howdy,

I agree with Scott. I can still get a /28 on a consumer DSL line for
$25/mo and routers renumber easily. There is no burden here.


> Would you entertain more than 3?

I would entertain up to 5, allowing a comfortable fit in a /29 before
requesting ARIN space. Beyond that the logistical problems become
noticeable enough to merit a direct assignment. Not so severe as to
require it, but noticeable.


On Tue, Mar 11, 2014 at 2:09 PM, Andrew Dul <andrew.dul at quark.net> wrote:
> 2. Remove the /24 minimum for IXP allocations.  Since there is no
> technical reason to have an IXP block be a /24 and the operational best
> practice is to not route these blocks we could look at "right sizing"
> IXP blocks rather giving a very small IXPs a rather large block for what
> they need.  Yes, this brings up the possible renumbering issue in the
> future, but a /25 or /26 still allows quite a number of IXP participants.

I would agree to a /26 minimum assignment for IXPs, but I note that
doing so complicates the critical infrastructure policy. There are
other critical infrastructure uses for which the ISP-enforced /24
boundary is an issue.

Regards,
Bill Herrin


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


From scottleibrand at gmail.com  Tue Mar 11 19:29:12 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 11 Mar 2014 16:29:12 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update - Revised
In-Reply-To: <CAP-guGX2C=155mdM6c2vX1ceCjBRivJJOfR87eiZudN1LjioPQ@mail.gmail.com>
References: <531633FE.8010604@arin.net> <531DDC3A.7000207@quark.net>
	<531DE105.70003@linuxmagic.com>
	<dfb6bb58dfc14d1d93ce0a13ec99c51f@DM2PR03MB398.namprd03.prod.outlook.com>
	<531DE729.3060508@linuxmagic.com>
	<9C7BCF42-A42A-469E-90B0-25C51AAA4F23@gmail.com>
	<CAMDXq5NipM0zoB2QoZe9MT705aPOx9C2ZOe-XbUoMsixUicY5g@mail.gmail.com>
	<CAP-guGX2C=155mdM6c2vX1ceCjBRivJJOfR87eiZudN1LjioPQ@mail.gmail.com>
Message-ID: <CAGkMwz7XkTWtMrE5uDP0y1ibE+xTw0DHfg01fHpsfym83ZJSTw@mail.gmail.com>

On Tue, Mar 11, 2014 at 2:01 PM, William Herrin <bill at herrin.us> wrote:

> On Mon, Mar 10, 2014 at 12:54 PM, Martin Hannigan <hannigan at gmail.com>
> wrote:
> > On Mon, Mar 10, 2014 at 12:44 PM, Scott Leibrand
> > <scottleibrand at gmail.com> wrote:
> >> Any reason two small rural players shouldn't start with
> >> a PA /30 and renumber into a larger block if/when they get a third
> participant?
> >>
> >> Unless someone has a good argument for why that's an excessive burden,
> support changing 2 to 3.
>
> Howdy,
>
> I agree with Scott. I can still get a /28 on a consumer DSL line for
> $25/mo and routers renumber easily. There is no burden here.
>
>
> > Would you entertain more than 3?
>
> I would entertain up to 5, allowing a comfortable fit in a /29 before
> requesting ARIN space. Beyond that the logistical problems become
> noticeable enough to merit a direct assignment. Not so severe as to
> require it, but noticeable.
>

If provider A is connecting to a small IXP in order to connect to provider
B, but the /29 is controlled by a third party (provider C) that provider A
may not even choose to peer with, then provider A may be reluctant to
connect.  If the IXP can get ARIN space based on 3 participants, that seems
like the logical cutoff point to me.

I still (weakly) support the change from 2 to 3, but would not support a
larger number.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140311/2a3d0330/attachment.htm>

From billdarte at gmail.com  Wed Mar 12 17:01:28 2014
From: billdarte at gmail.com (Bill Darte)
Date: Wed, 12 Mar 2014 16:01:28 -0500
Subject: [arin-ppml] New Language Proposed for Draft Policy 2014-2 Improving
	8.4 Anti-Flip Language
Message-ID: <CAMApp37S2Fv+LYu7WG_+BNpOmAbBc=-6tww5ELpFJNCx+zJczg@mail.gmail.com>

Thank you to everyone who has thus far provided input on this draft policy.

Per feedback from the community and the AC on improving Inter-RIR transfer
language found in section 8.4 of the ARIN NRPM, We are now focusing on the
3rd of three alternative suggestions (see all three far below).

Please review the suggested change below and comment indicating your
position for or against the change.  Given sufficient support for this
proposed language, the next step in the Policy Development Process is for
the Draft to be reviewed by staff and legal on its way to becoming a
Recommended Draft and presentation at the upcoming PPM in Chicago.

Thanks,
Bill Darte
Policy Shepherd for 2014-2

NEW PROPOSED POLICY LANGUAGE...the first sentence of the fourth bullet in
quotes immediately below is the only change from current policy)
8.4. Inter-RIR Transfers to Specified Recipients

Inter-regional transfers may take place only via RIRs who agree to the
transfer and share reciprocal, compatible, needs-based policies.

Conditions on source of the transfer:

   - The source entity must be the current rights holder of the IPv4
   address resources recognized by the RIR responsible for the resources, and
   not be involved in any dispute as to the status of those resources.
   - Source entities outside of the ARIN region must meet any requirements
   defined by the RIR where the source entity holds the registration.
   - Source entities within the ARIN region will not be eligible to receive
   any further IPv4 address allocations or assignments from ARIN for a period
   of 12 months after a transfer approval, or until the exhaustion of ARIN's
   IPv4 space, whichever occurs first.
   - *"Source entities within the ARIN region may not transfer a block or
   portion of a block received within the past 12 months."*  This
   restriction does not include M&A transfers.
   - The minimum transfer size is a /24.

Conditions on recipient of the transfer:

   - The conditions on a recipient outside of the ARIN region will be
   defined by the policies of the receiving RIR.
   - Recipients within the ARIN region will be subject to current ARIN
   policies and sign an RSA for the resources being received.
   - Recipients within the ARIN region must demonstrate the need for up to
   a 24-month supply of IPv4 address space.
   - The minimum transfer size is a /24.


<<<<<<<<Original three alternatives were primarily discussed and I wish to
elicit feedback from the community relative to each.>>>>>>>>

1. Use the existing last sentence as is and ask ARIN staff to be
particularly watchful for seeming abuse and to bring such back to the
community through regular Policy Experience Reports.  There was discussion
about this option suggesting that by the time abuse was recognized and
reported, and given limited existing free pool stocks and the extended
policy development cycle....this option may be moot.

2. Remove the clause 'and its subsidiaries' or modify it in such a way as
to mitigate the risk of a laundering of addresses through fraudulent
transfers, but this may still potentially limit the utility to
organizations who may have complex organizational structures in use
internationally.

3. Take an alternative tack and simply restrict transfers on a per-block
rather than a per-organization basis. e.g. 'No block acquired within the
past 24 months would be eligible for transfer.' (The time frame is of
course an arbitrary number at this point.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140312/d54c6b40/attachment.htm>

From jcurran at arin.net  Thu Mar 13 12:29:34 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 13 Mar 2014 16:29:34 +0000
Subject: [arin-ppml] What would the proper method be for reporting
	bad	rwhois referrers?
In-Reply-To: <531F2A6F.9070705@linuxmagic.com>
References: <531F2A6F.9070705@linuxmagic.com>
Message-ID: <A8480534-B6AC-42D7-93FC-9B7A7E7CC65C@arin.net>


On Mar 11, 2014, at 11:23 AM, Michael Peddemors <michael at linuxmagic.com> wrote:

> We see that many ARIN allocated blocks seem to have referral whois servers listed at ARIN for their net blocks, but the listing is not accurate/not functioning..
> 
> Eg, the example below..
> 
> What would the ARIN recommended practice be for reporting these cases?

Michael - 
 
   This information can be reported to ARIN by a message to <hostmaster at arin.net>,
   or reported via "Ask ARIN" in ARIN Online.

   Either way, ARIN staff will then contact the ISP and ask them to update their
   RWhois referral data.

Thanks!
/John

John Curran
President and CEO
ARIN




From narten at us.ibm.com  Fri Mar 14 00:53:02 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 14 Mar 2014 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201403140453.s2E4r2bh022023@rotala.raleigh.ibm.com>

Total of 37 messages in the last 7 days.
 
script run at: Fri Mar 14 00:53:02 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  5.41% |    2 | 17.38% |    75300 | rudi.daniel at gmail.com
 10.81% |    4 | 11.61% |    50297 | billdarte at gmail.com
 10.81% |    4 | 10.07% |    43596 | hannigan at gmail.com
 10.81% |    4 |  6.56% |    28432 | bross at pobox.com
 10.81% |    4 |  6.52% |    28255 | michael at linuxmagic.com
  8.11% |    3 |  7.12% |    30833 | scottleibrand at gmail.com
  2.70% |    1 |  8.12% |    35162 | jay-arin at tp.org
  2.70% |    1 |  8.01% |    34674 | skylar at crissic.net
  5.41% |    2 |  3.68% |    15946 | jcurran at arin.net
  5.41% |    2 |  3.56% |    15407 | david.huberman at microsoft.com
  5.41% |    2 |  3.50% |    15181 | andrew.dul at quark.net
  2.70% |    1 |  2.21% |     9552 | mpetach at netflight.com
  2.70% |    1 |  1.97% |     8551 | owen at delong.com
  2.70% |    1 |  1.94% |     8392 | farmer at umn.edu
  2.70% |    1 |  1.71% |     7416 | bill at herrin.us
  2.70% |    1 |  1.67% |     7229 | narten at us.ibm.com
  2.70% |    1 |  1.65% |     7139 | sryerse at eclipse-networks.com
  2.70% |    1 |  1.39% |     6023 | fearghas at gmail.com
  2.70% |    1 |  1.33% |     5752 | gary.buhrmaster at gmail.com
--------+------+--------+----------+------------------------
100.00% |   37 |100.00% |   433137 | Total



From owen at delong.com  Wed Mar 19 12:17:32 2014
From: owen at delong.com (Owen DeLong)
Date: Wed, 19 Mar 2014 09:17:32 -0700
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
	Requirements
Message-ID: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>

There has not been a lot of feedback on this proposal. It would be nice to have more input from a broader cross-section of the community.

At present, I am leaning towards recommending that we abandon this proposal for lack of support by the community. If you support this action, please speak up. If you support this proposal, then it is vital that you speak up.

Thank you,

Owen



From David.Huberman at microsoft.com  Wed Mar 19 13:27:15 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 19 Mar 2014 17:27:15 +0000
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block
	Size	Requirements
In-Reply-To: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
Message-ID: <806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>

Hello,

As the author, I proposed this policy because it is not ARIN's role to artificially regulate minimum block sizes. I feel this is especially in a post-exhaustion world, which is very quickly coming.  

The economics of routing are the same today as they were 14 years ago when Bill Manning taught me an important principal: people will pay to route whatever you pay them to route. Moreover, there is no technical reason I can think of to require a /24 as the minimum TRANSFERRABLE size.  If two parties wish to exchange smaller prefixes, I cannot see a technical motivation for ARIN policy to prohibit such a transaction.

I ask you to support this policy on principle, or educate us why removing the minimum transferrable block size is harmful to the technical operations of the internet.

/david

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Wednesday, March 19, 2014 9:18 AM
To: ARIN-PPML List
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size Requirements

There has not been a lot of feedback on this proposal. It would be nice to have more input from a broader cross-section of the community.

At present, I am leaning towards recommending that we abandon this proposal for lack of support by the community. If you support this action, please speak up. If you support this proposal, then it is vital that you speak up.

Thank you,

Owen

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


From hannigan at gmail.com  Wed Mar 19 13:30:36 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 19 Mar 2014 13:30:36 -0400
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
	Requirements
In-Reply-To: <806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAMDXq5OO_n1XSRvtKSLTxSnwv0fraZJ7kanHDcAatTE8fdtnrg@mail.gmail.com>

On Wed, Mar 19, 2014 at 1:27 PM, David Huberman
<David.Huberman at microsoft.com> wrote:
> Hello,
>
> As the author, I proposed this policy because it is not ARIN's role to artificially regulate minimum block sizes. I feel this is especially in a post-exhaustion world, which is very quickly coming.
>
> The economics of routing are the same today as they were 14 years ago when Bill Manning taught me an important principal: people will pay to route whatever you pay them to route. Moreover, there is no technical reason I can think of to require a /24 as the minimum TRANSFERRABLE size.  If two parties wish to exchange smaller prefixes, I cannot see a technical motivation for ARIN policy to prohibit such a transaction.
>

Multiple parties exchange smaller prefixes _all the time_. It's called peering.

> I ask you to support this policy on principle, or educate us why removing the minimum transferrable block size is harmful to the technical operations of the internet.
>


Support.

Best,

-M<


From scottleibrand at gmail.com  Wed Mar 19 14:00:13 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 19 Mar 2014 11:00:13 -0700
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
	Requirements
In-Reply-To: <806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>

I am not speaking in favor of the status quo (a /24 minimum transfer size).

However, IMO having a /32 IPv4 minimum transfer size (no limit) would be a
bad idea.  There have been several cases where entities who are completely
ignorant of Internet routing think they have some "right" to a particular
/32, and wish to transfer it.  IMO, having *some* minimum transfer size is
a good way to prevent such efforts from being imposed on the rest of us.
 (If ARIN can point to policy saying "that simply isn't allowed", they're
in a much better position than trying to argue the particulars of each
case.)

I would have no problem reducing the minimum IPv4 transfer size, just not
all the way to /32.  So I oppose the proposal as written, but could support
a revised version.

-Scott


On Wed, Mar 19, 2014 at 10:27 AM, David Huberman <
David.Huberman at microsoft.com> wrote:

> Hello,
>
> As the author, I proposed this policy because it is not ARIN's role to
> artificially regulate minimum block sizes. I feel this is especially in a
> post-exhaustion world, which is very quickly coming.
>
> The economics of routing are the same today as they were 14 years ago when
> Bill Manning taught me an important principal: people will pay to route
> whatever you pay them to route. Moreover, there is no technical reason I
> can think of to require a /24 as the minimum TRANSFERRABLE size.  If two
> parties wish to exchange smaller prefixes, I cannot see a technical
> motivation for ARIN policy to prohibit such a transaction.
>
> I ask you to support this policy on principle, or educate us why removing
> the minimum transferrable block size is harmful to the technical operations
> of the internet.
>
> /david
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Wednesday, March 19, 2014 9:18 AM
> To: ARIN-PPML List
> Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
> Requirements
>
> There has not been a lot of feedback on this proposal. It would be nice to
> have more input from a broader cross-section of the community.
>
> At present, I am leaning towards recommending that we abandon this
> proposal for lack of support by the community. If you support this action,
> please speak up. If you support this proposal, then it is vital that you
> speak up.
>
> Thank you,
>
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140319/2708be2f/attachment.htm>

From David.Huberman at microsoft.com  Wed Mar 19 14:04:19 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 19 Mar 2014 18:04:19 +0000
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
 Requirements
In-Reply-To: <CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
Message-ID: <65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>

Hi Scott,

If I understand your argument - and I'm not sure I do, sorry - you're saying that it's good to have a policy that SPs can point to and say, "no, you can't take that /32 we assigned to you with you"?  If that's what you're arguing, then why is a /24 any different than a /32? We see /24s assigned by SPs to their customers all the time.

Secondly, if this is your argument, why is this not a matter for legal and contracts, rather than a number registry which is not appointed by the IETF or NANOG or any other engineering body as the regulator of what size block is acceptable to regulate? I'm not being flippant and I'm not trying to be a jerk.  I think this kind of reasoning (and 1000 apologies if I misunderstood your argument) is way outside the purview of ARIN.

Thanks!
/david

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

From: Scott Leibrand [mailto:scottleibrand at gmail.com]
Sent: Wednesday, March 19, 2014 11:00 AM
To: David Huberman
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size Requirements

I am not speaking in favor of the status quo (a /24 minimum transfer size).

However, IMO having a /32 IPv4 minimum transfer size (no limit) would be a bad idea.  There have been several cases where entities who are completely ignorant of Internet routing think they have some "right" to a particular /32, and wish to transfer it.  IMO, having *some* minimum transfer size is a good way to prevent such efforts from being imposed on the rest of us.  (If ARIN can point to policy saying "that simply isn't allowed", they're in a much better position than trying to argue the particulars of each case.)

I would have no problem reducing the minimum IPv4 transfer size, just not all the way to /32.  So I oppose the proposal as written, but could support a revised version.

-Scott

On Wed, Mar 19, 2014 at 10:27 AM, David Huberman <David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>> wrote:
Hello,

As the author, I proposed this policy because it is not ARIN's role to artificially regulate minimum block sizes. I feel this is especially in a post-exhaustion world, which is very quickly coming.

The economics of routing are the same today as they were 14 years ago when Bill Manning taught me an important principal: people will pay to route whatever you pay them to route. Moreover, there is no technical reason I can think of to require a /24 as the minimum TRANSFERRABLE size.  If two parties wish to exchange smaller prefixes, I cannot see a technical motivation for ARIN policy to prohibit such a transaction.

I ask you to support this policy on principle, or educate us why removing the minimum transferrable block size is harmful to the technical operations of the internet.

/david

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>] On Behalf Of Owen DeLong
Sent: Wednesday, March 19, 2014 9:18 AM
To: ARIN-PPML List
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size Requirements

There has not been a lot of feedback on this proposal. It would be nice to have more input from a broader cross-section of the community.

At present, I am leaning towards recommending that we abandon this proposal for lack of support by the community. If you support this action, please speak up. If you support this proposal, then it is vital that you speak up.

Thank you,

Owen

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

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

From scottleibrand at gmail.com  Wed Mar 19 14:22:01 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 19 Mar 2014 11:22:01 -0700
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
	Requirements
In-Reply-To: <65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
	<65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>

I'm thinking about things like a lawsuit where the plaintiff gets awarded
all of the defendant's "assets" in question, and the plaintiff then asks
ARIN to transfer the IPv4 defendant's /32 to them.  If ARIN simply doesn't
transfer /32s, then they can tell the judge "I'm sorry, but we just can't
do that, and here's why (point to policy)".  Without such a policy, they
have to make the much trickier "that's not an asset" argument.

IIUIC, exactly that scenario has happened several times.  If so, then I
expect that if we get to the point of doing a Staff and Legal assessment on
this, they'll bring this up.

But regardless of the legal piece, I see no upside, and quite a bit of
downside, to allowing IPv4 /32 transfers.  I think we need to move the
limit, not remove it.

-Scott


On Wed, Mar 19, 2014 at 11:04 AM, David Huberman <
David.Huberman at microsoft.com> wrote:

>  Hi Scott,
>
>
>
> If I understand your argument - and I'm not sure I do, sorry - you're
> saying that it's good to have a policy that SPs can point to and say, "no,
> you can't take that /32 we assigned to you with you"?  If that's what
> you're arguing, then why is a /24 any different than a /32? We see /24s
> assigned by SPs to their customers all the time.
>
>
>
> Secondly, if this is your argument, why is this not a matter for legal and
> contracts, rather than a number registry which is not appointed by the IETF
> or NANOG or any other engineering body as the regulator of what size block
> is acceptable to regulate? I'm not being flippant and I'm not trying to be
> a jerk.  I think this kind of reasoning (and 1000 apologies if I
> misunderstood your argument) is way outside the purview of ARIN.
>
>
>
> Thanks!
>
> /david
>
>
>
> *David R Huberman*
>
> Microsoft Corporation
>
> Senior IT/OPS Program Manager (GFS)
>
>
>
> *From:* Scott Leibrand [mailto:scottleibrand at gmail.com]
> *Sent:* Wednesday, March 19, 2014 11:00 AM
> *To:* David Huberman
> *Cc:* ARIN-PPML List
> *Subject:* Re: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block
> Size Requirements
>
>
>
> I am not speaking in favor of the status quo (a /24 minimum transfer size).
>
>
>
> However, IMO having a /32 IPv4 minimum transfer size (no limit) would be a
> bad idea.  There have been several cases where entities who are completely
> ignorant of Internet routing think they have some "right" to a particular
> /32, and wish to transfer it.  IMO, having *some* minimum transfer size is
> a good way to prevent such efforts from being imposed on the rest of us.
>  (If ARIN can point to policy saying "that simply isn't allowed", they're
> in a much better position than trying to argue the particulars of each
> case.)
>
>
>
> I would have no problem reducing the minimum IPv4 transfer size, just not
> all the way to /32.  So I oppose the proposal as written, but could support
> a revised version.
>
>
>
> -Scott
>
>
>
> On Wed, Mar 19, 2014 at 10:27 AM, David Huberman <
> David.Huberman at microsoft.com> wrote:
>
> Hello,
>
> As the author, I proposed this policy because it is not ARIN's role to
> artificially regulate minimum block sizes. I feel this is especially in a
> post-exhaustion world, which is very quickly coming.
>
> The economics of routing are the same today as they were 14 years ago when
> Bill Manning taught me an important principal: people will pay to route
> whatever you pay them to route. Moreover, there is no technical reason I
> can think of to require a /24 as the minimum TRANSFERRABLE size.  If two
> parties wish to exchange smaller prefixes, I cannot see a technical
> motivation for ARIN policy to prohibit such a transaction.
>
> I ask you to support this policy on principle, or educate us why removing
> the minimum transferrable block size is harmful to the technical operations
> of the internet.
>
> /david
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Owen DeLong
> Sent: Wednesday, March 19, 2014 9:18 AM
> To: ARIN-PPML List
> Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
> Requirements
>
> There has not been a lot of feedback on this proposal. It would be nice to
> have more input from a broader cross-section of the community.
>
> At present, I am leaning towards recommending that we abandon this
> proposal for lack of support by the community. If you support this action,
> please speak up. If you support this proposal, then it is vital that you
> speak up.
>
> Thank you,
>
> Owen
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140319/02a33220/attachment.htm>

From David.Huberman at microsoft.com  Wed Mar 19 14:34:19 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 19 Mar 2014 18:34:19 +0000
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
 Requirements
In-Reply-To: <CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
	<65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>
Message-ID: <d61a4224ffc0481084b2828a0dca8ac4@DM2PR03MB398.namprd03.prod.outlook.com>

> But regardless of the legal piece, I see no upside, and quite a bit of downside, to allowing IPv4 /32 transfers.

Please articulate the "quite a bit of downside".  If we ignore the legal piece of your argument, as you said to, what are the problems with /32 transfers to the technical operations of the internet? I've only seen the legal argument in your replies so far, hence my request.  

Also, I believe ARIN is the wrong place for such constraints.  I believe operators should make the decision on such matters - not central numbers registries which suffer from very very low participation.  You can choose to reply to that or not, of course, but I think it's very germane to the meat of this proposal:  why does ARIN get to set this basement???




From jcurran at arin.net  Wed Mar 19 14:34:57 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 19 Mar 2014 18:34:57 +0000
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
 Requirements
In-Reply-To: <CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
	<65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>
Message-ID: <B5231091-5BE1-4583-ABF3-8D05671ED361@arin.net>

On Mar 19, 2014, at 7:22 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:

> I'm thinking about things like a lawsuit where the plaintiff gets awarded all of the defendant's "assets" in question, and the plaintiff then asks ARIN to transfer the IPv4 defendant's /32 to them.

When that has occurred, it is generally a single IP address out of a block still
registered to the ISP (rather than the particular organization which has a web
site and has gone defunct/bankruptcy/judgement)

> If ARIN simply doesn't transfer /32s, then they can tell the judge "I'm sorry, but we just can't do that, and here's why (point to policy)".  Without such a policy, they have to make the much trickier "that's not an asset" argument.

Which is something we can manage in either case; we need the community to 
set policy which matches their expectations for management of IP address space,
rather than policy solely to make administration easier.

(i.e. given that we have to handle the case where a customer's temporary /24 
assignment is being "transferred" out of the midst of an ISP block, having no 
limit just means potentially dealing with more such cases.)

> IIUIC, exactly that scenario has happened several times.  If so, then I expect that if we get to the point of doing a Staff and Legal assessment on this, they'll bring this up.  

We will so the community is aware of the implications, but the policy the community
desires comes first over easy of implementation.  It is definitely a factor to consider,
but should not be considered a hard impediment if the community decides that no
minimum is more appropriate.

FYI,
/John

John Curran
President and CEO
ARIN





From mysidia at gmail.com  Wed Mar 19 14:42:44 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 19 Mar 2014 13:42:44 -0500
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
	Requirements
In-Reply-To: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
Message-ID: <CAAAwwbXohXT5=EDnSZQGMvcADP1cRZ8LZYnN5E=t83VyG8_4Fw@mail.gmail.com>

On Wed, Mar 19, 2014 at 11:17 AM, Owen DeLong <owen at delong.com> wrote:

> There has not been a lot of feedback on this proposal. It would be nice to
> have more input from a broader cross-section of the community.
>
> At present, I am leaning towards recommending that we abandon this
> proposal for lack of support by the community. If you support this action,
> please speak up. If you support this proposal, then it is vital that you
> speak up.
>

I support the action of abandoning this proposal.

I oppose the proposed policy.   There are is a lack of demonstrated
significant benefits and utility shown of changing the current limit, let
alone having no limit on the minimum size of a transfer.

There are plenty of potential future drawbacks of removing the longstanding
limits;

Including the usefulness to spammers,  who would love to have a /32  from
every /24 on the internet, if they could.
And potential cross-organizational impacts  from  Real-time blacklists that
blacklist /24s.

Plus additional potential time and cost required from ARIN staff, members,
and ISP resource holders, in particular,
in dealing with users wishing to transfer a vanity /28, /29 or /32.



> Thank you,
>
> Owen
>
--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140319/e3e7780e/attachment.htm>

From jcurran at arin.net  Wed Mar 19 14:47:07 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 19 Mar 2014 18:47:07 +0000
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
 Requirements
In-Reply-To: <d61a4224ffc0481084b2828a0dca8ac4@DM2PR03MB398.namprd03.prod.outlook.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
	<65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>
	<d61a4224ffc0481084b2828a0dca8ac4@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <8B067E70-3424-45F3-A49F-C90F7417E82D@arin.net>

On Mar 19, 2014, at 7:34 PM, David Huberman <David.Huberman at microsoft.com> wrote:

> Also, I believe ARIN is the wrong place for such constraints.  I believe operators should make the decision on such matters

I also believe that operators should set such constraints (if desired),
by participation in the regional policy development process.

The ARIN community gets to set policies for the management of IP address
space in the region, and this includes all of the operators, hosting firms,
content companies, etc. who choose to participate.  

For many things, there may be no need for any "regional" or "global" policy,
instead allowing it to be a matter between those using IP addresses, but if
there is to be policy then it would be most appropriate for it to be set via
the bodies which are part of the Internet registry system,

Thanks!
/John

John Curran
President and CEO
ARIN



From scottleibrand at gmail.com  Wed Mar 19 14:51:40 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 19 Mar 2014 11:51:40 -0700
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
	Requirements
In-Reply-To: <d61a4224ffc0481084b2828a0dca8ac4@DM2PR03MB398.namprd03.prod.outlook.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
	<65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>
	<d61a4224ffc0481084b2828a0dca8ac4@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAGkMwz7nvp22N771-bB5Cz5JNTnkbfX5env7snq8bGfctOEO6A@mail.gmail.com>

On Wed, Mar 19, 2014 at 11:34 AM, David Huberman <
David.Huberman at microsoft.com> wrote:

> > But regardless of the legal piece, I see no upside, and quite a bit of
> downside, to allowing IPv4 /32 transfers.
>
> Please articulate the "quite a bit of downside".  If we ignore the legal
> piece of your argument, as you said to, what are the problems with /32
> transfers to the technical operations of the internet? I've only seen the
> legal argument in your replies so far, hence my request.
>
> Also, I believe ARIN is the wrong place for such constraints.  I believe
> operators should make the decision on such matters - not central numbers
> registries which suffer from very very low participation.  You can choose
> to reply to that or not, of course, but I think it's very germane to the
> meat of this proposal:  why does ARIN get to set this basement???
>

Ok, setting aside the Legal thing (based on John's reply), I see this as
mostly an expectations and externalities thing.  Right now, I can make any
size BGP announcement I want to my peers (as Marty pointed out), and that
works fine. But no one is *expecting* me to accept IPv4 /32s via my peers
and transit providers from some unrelated entity across the country/world.

I think ARIN policy needs to be in line with what operators are doing (or
will soon want to do).  I think removing minimum transfer sizes entirely
would act as a forcing function that moves us too far down the "you must
route this" path.  What is actually needed in the next few years is to be
able to transfer /25s and maybe even /28s, not /32s.

Where ARIN is telling operators they can't do what they want, I would agree
with you that we should stop doing that.  But AFAICT no operators actually
want to transfer and try to get everyone to globally route IPv4 /32s, so
ARIN's policy here is just reflecting reality.

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

From michael at linuxmagic.com  Wed Mar 19 15:23:40 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Wed, 19 Mar 2014 12:23:40 -0700
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
 Requirements
In-Reply-To: <65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
	<65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <5329EEBC.7050601@linuxmagic.com>

Personally, not sure if we should allow any transfer in a world of 
diminishing resources, use it or loose it..

But I speak definitely in favor of NOT allowing transfers less than /24, 
and since SWIP isn't allowed for /32 right now... (correct?)

I suggest no smaller than a /29

On 14-03-19 11:04 AM, David Huberman wrote:
> Hi Scott,
>
> If I understand your argument ? and I?m not sure I do, sorry ? you?re
> saying that it?s good to have a policy that SPs can point to and say,
> ?no, you can?t take that /32 we assigned to you with you??  If that?s
> what you?re arguing, then why is a /24 any different than a /32? We see
> /24s assigned by SPs to their customers all the time.
>
> Secondly, if this is your argument, why is this not a matter for legal
> and contracts, rather than a number registry which is not appointed by
> the IETF or NANOG or any other engineering body as the regulator of what
> size block is acceptable to regulate? I?m not being flippant and I?m not
> trying to be a jerk.  I think this kind of reasoning (and 1000 apologies
> if I misunderstood your argument) is way outside the purview of ARIN.
>
> Thanks!
>
> /david
>
> *David R Huberman*
>
> Microsoft Corporation
>
> Senior IT/OPS Program Manager (GFS)
>
> *From:*Scott Leibrand [mailto:scottleibrand at gmail.com]
> *Sent:* Wednesday, March 19, 2014 11:00 AM
> *To:* David Huberman
> *Cc:* ARIN-PPML List
> *Subject:* Re: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block
> Size Requirements
>
> I am not speaking in favor of the status quo (a /24 minimum transfer size).
>
> However, IMO having a /32 IPv4 minimum transfer size (no limit) would be
> a bad idea.  There have been several cases where entities who are
> completely ignorant of Internet routing think they have some "right" to
> a particular /32, and wish to transfer it.  IMO, having *some* minimum
> transfer size is a good way to prevent such efforts from being imposed
> on the rest of us.  (If ARIN can point to policy saying "that simply
> isn't allowed", they're in a much better position than trying to argue
> the particulars of each case.)
>
> I would have no problem reducing the minimum IPv4 transfer size, just
> not all the way to /32.  So I oppose the proposal as written, but could
> support a revised version.
>
> -Scott
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From David.Huberman at microsoft.com  Wed Mar 19 16:34:57 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 19 Mar 2014 20:34:57 +0000
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
 Requirements
In-Reply-To: <CAGkMwz7nvp22N771-bB5Cz5JNTnkbfX5env7snq8bGfctOEO6A@mail.gmail.com>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
	<65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>
	<d61a4224ffc0481084b2828a0dca8ac4@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz7nvp22N771-bB5Cz5JNTnkbfX5env7snq8bGfctOEO6A@mail.gmail.com>
Message-ID: <802e43b7da514ead9faa0d85c2c4774c@DM2PR03MB398.namprd03.prod.outlook.com>

Hi Scott,

Thanks for the great reply.  I agree with a lot of what you are saying.

I guess I'm stuck on the idea that this doesn't belong in ARIN policy.  As you well note, ARIN policy is reflecting what has been the operational reality for a while now.  And as you state, we could keep changing the policy to match whatever happens in the future.  But I guess I don't feel that's necessary; I feel that ARIN policy should be agnostic on prefix size.   Hence my proposal.

I look forward to discussing solutions in Chicago. :)

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

From: Scott Leibrand [mailto:scottleibrand at gmail.com]
Sent: Wednesday, March 19, 2014 11:52 AM
To: David Huberman
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size Requirements

On Wed, Mar 19, 2014 at 11:34 AM, David Huberman <David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>> wrote:
> But regardless of the legal piece, I see no upside, and quite a bit of downside, to allowing IPv4 /32 transfers.
Please articulate the "quite a bit of downside".  If we ignore the legal piece of your argument, as you said to, what are the problems with /32 transfers to the technical operations of the internet? I've only seen the legal argument in your replies so far, hence my request.

Also, I believe ARIN is the wrong place for such constraints.  I believe operators should make the decision on such matters - not central numbers registries which suffer from very very low participation.  You can choose to reply to that or not, of course, but I think it's very germane to the meat of this proposal:  why does ARIN get to set this basement???

Ok, setting aside the Legal thing (based on John's reply), I see this as mostly an expectations and externalities thing.  Right now, I can make any size BGP announcement I want to my peers (as Marty pointed out), and that works fine. But no one is *expecting* me to accept IPv4 /32s via my peers and transit providers from some unrelated entity across the country/world.

I think ARIN policy needs to be in line with what operators are doing (or will soon want to do).  I think removing minimum transfer sizes entirely would act as a forcing function that moves us too far down the "you must route this" path.  What is actually needed in the next few years is to be able to transfer /25s and maybe even /28s, not /32s.

Where ARIN is telling operators they can't do what they want, I would agree with you that we should stop doing that.  But AFAICT no operators actually want to transfer and try to get everyone to globally route IPv4 /32s, so ARIN's policy here is just reflecting reality.

-Scott

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

From info at arin.net  Thu Mar 20 11:20:01 2014
From: info at arin.net (ARIN)
Date: Thu, 20 Mar 2014 11:20:01 -0400
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
Message-ID: <532B0721.8050706@arin.net>

** This announcement was also sent to arin-announce at arin.net. Our 
apologies if you receive duplicate messages. ** 	

On Friday 14 March, the United States Government announced that it 
intends to transition oversight of key Internet functions (including the 
Internet Assigned Numbers Authority, or IANA) to the global 
multi-stakeholder community. It has asked ICANN to facilitate, in 
consultation with the global multi-stakeholder community, the 
development of a proposal for the transition.

Leaders of the I* Internet technical coordination organizations had met 
several times and in line with the Montevideo statement we had discussed 
some common principles for an evolution such as the one announced by the 
US Gov. Regular participants in those meeting, including their 
affiliated organizations, are noted here:
http://www.nro.net/news/statement-from-the-i-leaders-coordination-meeting

As outcome of their discussion, a common position was developed on the 
following points:

     * The roles of all Internet registry policy bodies stay unchanged. 
These bodies continue to hold policy authority for the protocol 
parameter, number, and name spaces, including responsibility to ensure 
the faithful registry implementation according to those policies.

     * The IETF, IAB, and RIRs are committed to the role of ICANN as the 
IANA protocol parameter and IP address registry operator.

     * ICANN reaffirms its commitment to implement all IANA registry 
functions in accordance with the respective policies. ICANN will also 
provide affirmations to all stakeholders (including governments) that 
all Internet registry policy bodies and ICANN itself will continue to 
use open and transparent processes.

The full text summarizing these points is included at the end of this email.

Separately, ICANN released a timeline that details its expectations of 
the multi-stakeholder consultation process. More information on these 
plans will undoubtedly come out of the upcoming ICANN Meeting in 
Singapore from 23-27 March. The timeline document is available here:
http://www.icann.org/en/about/agreements/iana/functions-transfer-process-14mar14-en.pdf

While this timeline focuses on ICANN meetings and events, it is clear 
that this process will not take place only in ICANN venues. The five RIR 
communities are key stakeholders in this process, and it is vital that 
we discuss these issues both within our regional communities and 
globally to ensure that our voices are heard and our concerns 
recognized. The stable, accurate and professional management of the IANA 
functions, including management of the global IP address pool, is 
fundamental to the operation of the Internet. It is important that we 
not lose sight of this fact as management of the IANA evolves to more 
faithfully reflect the multi-stakeholder nature of the Internet community.

In the ARIN community, these discussions will take place via the 
communication and discussion channels already in place, including the 
upcoming ARIN 33 meeting in Chicago this April. ARIN will continue to 
facilitate discussion and ensure that the output is effectively 
channeled into the global process.

If you have any thoughts, comments or questions at this time, I 
encourage you to raise them on ARIN's Public Policy mailing list, 
arin-ppml at arin.net.

If you aren't currently on this list, you can subscribe at: 
http://lists.arin.net/mailman/listinfo/arin-ppml

I look forward to receiving your input on the mailing list and to 
further discussion at ARIN 33.

Regards,

John Curran
President and CEO
American Registry for Internet Numbers (ARIN)


			*******

Agreed text by the Leaders of I* organizations:

In order to ensure global acceptance and affirmation of ICANN's role as 
administrator of the IANA functions, we are now pursuing the transition 
of USG's stewardship of the IANA functions from the USG to ICANN. The 
roles of all Internet registry policy bodies (such as the RIRs, IAB, 
IETF, ASO, ccNSO, ccTLD ROs, and gNSO) stay unchanged. These bodies 
continue to hold policy authority for the protocol parameter, number, 
and name spaces, including responsibility to ensure the faithful 
registry implementation according to those policies.

This transition from the USG has been envisaged since the early days of 
ICANN. It is now feasible due to the growing maturity of ICANN and other 
organisations in the Internet ecosystem. ICANN's structures and 
accountability mechanisms continue to evolve and advance guided by the 
AoC community reviews, including ATRT. In addition, ICANN will continue 
to embrace its aggressive roadmap to truly globalize its structures.

In order to operationalize the transition from USG, ICANN will engage 
with the Internet community in a bottom-up public consultation process 
to ensure appropriate accountability mechanisms. In addition, ICANN will 
work with the names, numbers, and protocol communities to formalize 
relationships, commitments, and mutual responsibilities.

When community stakeholders have input about the policies emanating from 
the names, numbers, and protocol communities, they would be directed to 
pursue their interests through the relevant Internet communities (such 
as the gNSO, ccNSO, ccTLD ROs, ASO, IAB, IETF, or the RIRs) and their 
mechanisms for consideration and potential redress.

The IETF, IAB, and RIRs are committed to open and transparent processes. 
They also are committed to the role of ICANN as the IANA protocol 
parameter and IP address registry operator. The accountability 
mechanisms for ICANN's administration of these core internet functions 
will provide escalation routes that assure the names, numbers, and 
protocol communities that if IANA's performance is lacking, those 
communities can pursue defined processes for improving performance, 
including pre-agreed independent 3rd party arbitration processes.

ICANN reaffirms its commitment to implement all IANA registry functions 
in accordance with the respective policies. ICANN will also provide 
affirmations to all stakeholders (including governments) from all 
Internet registry policy bodies and itself that all of us will use open 
and transparent processes.


From heather.skanks at gmail.com  Thu Mar 20 16:01:07 2014
From: heather.skanks at gmail.com (Heather Schiller)
Date: Thu, 20 Mar 2014 16:01:07 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <531633BD.1010109@arin.net>
References: <531633BD.1010109@arin.net>
Message-ID: <CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>

As a shepherd for this proposal, I would like to solicit community feedback
on the proposed text.

Aside from the general support/against.. some things to consider:

Do you concur with or have any comment on the problem statement?

If you support the problem statement, do you support removing section 8.2
as the correct path for remediating this conflict?  Do you have other
suggestions for how to handle this?

If you are opposed, what concerns do you have about implementing this
policy?

Thanks,
--Heather



On Tue, Mar 4, 2014 at 3:12 PM, ARIN <info at arin.net> wrote:

> On 20 February 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization
> Requirements" as a Draft Policy.
>
> Draft Policy ARIN-2014-9 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_9.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-9 on the Public Policy Mailing List.
>
> 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-2014-9
> Resolve Conflict Between RSA and 8.2 Utilization Requirements
>
> Date: 4 March 2014
>
> Problem Statement:
>
> 8.2 transfer policy has utilization requirements at the time of the review
> of the transfer request.
>
> The RSA section 6 expressly forbids ARIN from de-registering blocks (in
> whole or in part) due to under-utilization or no-justification during
> transfer requests.
>
> This is a direct conflict.
>
> Return and aggregate are not done in collaboration; they are coerced by
> policy without the willing consent of the transfer parties.
>
> We should remove all utilization references from 8.2 language to ensure
> the policy is compliant with the RSA.
>
> Policy statement:
>
> Remove from 8.2:
> "In the event that number resources of the combined organizations are no
> longer justified under ARIN policy at the time ARIN becomes aware of the
> transaction, through a transfer request or otherwise, ARIN will work with
> the resource holder(s) to return, aggregate, transfer, or reclaim resources
> as needed to restore compliance via the processes outlined in current ARIN
> policy."
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20140320/a42d8955/attachment.htm>

From owen at delong.com  Thu Mar 20 16:06:38 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 20 Mar 2014 13:06:38 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
	RSA and 8.2 Utilization Requirements
In-Reply-To: <CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
Message-ID: <2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>


On Mar 20, 2014, at 13:01 , Heather Schiller <heather.skanks at gmail.com> wrote:

> As a shepherd for this proposal, I would like to solicit community feedback on the proposed text.
> 
> Aside from the general support/against.. some things to consider:
> 
> Do you concur with or have any comment on the problem statement?  

I do not concur with the problem statement.

> If you support the problem statement, do you support removing section 8.2 as the correct path for remediating this conflict?  Do you have other suggestions for how to handle this?

No.

> If you are opposed, what concerns do you have about implementing this policy? 

I have previously stated my concerns. IMHO, this is yet another attempt to bypass the needs-basis and seeks to solve a problem which does not, in fact, exist.

Owen

> 
> Thanks,
> --Heather
> 
> 
> 
> On Tue, Mar 4, 2014 at 3:12 PM, ARIN <info at arin.net> wrote:
> On 20 February 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization Requirements" as a Draft Policy.
> 
> Draft Policy ARIN-2014-9 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_9.html
> 
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-9 on the Public Policy Mailing List.
> 
> 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-2014-9
> Resolve Conflict Between RSA and 8.2 Utilization Requirements
> 
> Date: 4 March 2014
> 
> Problem Statement:
> 
> 8.2 transfer policy has utilization requirements at the time of the review of the transfer request.
> 
> The RSA section 6 expressly forbids ARIN from de-registering blocks (in whole or in part) due to under-utilization or no-justification during transfer requests.
> 
> This is a direct conflict.
> 
> Return and aggregate are not done in collaboration; they are coerced by policy without the willing consent of the transfer parties.
> 
> We should remove all utilization references from 8.2 language to ensure the policy is compliant with the RSA.
> 
> Policy statement:
> 
> Remove from 8.2:
> "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy."
> 
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
> 
> 
> 
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

From aaron at wholesaleinternet.net  Thu Mar 20 16:30:08 2014
From: aaron at wholesaleinternet.net (Aaron)
Date: Thu, 20 Mar 2014 15:30:08 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
Message-ID: <532B4FD0.4020607@wholesaleinternet.net>

My issue with this proposal is that it might create an expectation that 
operators will start routing that space.  I just see a s**t storm when 
Customer A gets a /29 and no one can reach it.  I see it, in the long 
term, generating a lot of problems.

Aaron

On 3/20/2014 3:06 PM, Owen DeLong wrote:
>
> On Mar 20, 2014, at 13:01 , Heather Schiller <heather.skanks at gmail.com 
> <mailto:heather.skanks at gmail.com>> wrote:
>
>> As a shepherd for this proposal, I would like to solicit community 
>> feedback on the proposed text.
>>
>> Aside from the general support/against.. some things to consider:
>>
>> Do you concur with or have any comment on the problem statement?
>
> I do not concur with the problem statement.
>
>> If you support the problem statement, do you support removing section 
>> 8.2 as the correct path for remediating this conflict?  Do you have 
>> other suggestions for how to handle this?
>
> No.
>
>> If you are opposed, what concerns do you have about implementing this 
>> policy?
>
> I have previously stated my concerns. IMHO, this is yet another 
> attempt to bypass the needs-basis and seeks to solve a problem which 
> does not, in fact, exist.
>
> Owen
>
>>
>> Thanks,
>> --Heather
>>
>>
>>
>> On Tue, Mar 4, 2014 at 3:12 PM, ARIN <info at arin.net 
>> <mailto:info at arin.net>> wrote:
>>
>>     On 20 February 2014 the ARIN Advisory Council (AC) accepted
>>     "ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization
>>     Requirements" as a Draft Policy.
>>
>>     Draft Policy ARIN-2014-9 is below and can be found at:
>>     https://www.arin.net/policy/proposals/2014_9.html
>>
>>     You are encouraged to discuss the merits and your concerns of Draft
>>     Policy 2014-9 on the Public Policy Mailing List.
>>
>>     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-2014-9
>>     Resolve Conflict Between RSA and 8.2 Utilization Requirements
>>
>>     Date: 4 March 2014
>>
>>     Problem Statement:
>>
>>     8.2 transfer policy has utilization requirements at the time of
>>     the review of the transfer request.
>>
>>     The RSA section 6 expressly forbids ARIN from de-registering
>>     blocks (in whole or in part) due to under-utilization or
>>     no-justification during transfer requests.
>>
>>     This is a direct conflict.
>>
>>     Return and aggregate are not done in collaboration; they are
>>     coerced by policy without the willing consent of the transfer
>>     parties.
>>
>>     We should remove all utilization references from 8.2 language to
>>     ensure the policy is compliant with the RSA.
>>
>>     Policy statement:
>>
>>     Remove from 8.2:
>>     "In the event that number resources of the combined organizations
>>     are no longer justified under ARIN policy at the time ARIN
>>     becomes aware of the transaction, through a transfer request or
>>     otherwise, ARIN will work with the resource holder(s) to return,
>>     aggregate, transfer, or reclaim resources as needed to restore
>>     compliance via the processes outlined in current ARIN policy."
>>
>>     Comments:
>>     a.Timetable for implementation: Immediate
>>     b.Anything else:
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     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 if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

From michael at linuxmagic.com  Thu Mar 20 16:42:28 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Thu, 20 Mar 2014 13:42:28 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
Message-ID: <532B52B4.2030900@linuxmagic.com>

On 14-03-20 01:01 PM, Heather Schiller wrote:
> Remove from 8.2:
> "In the event that number resources of the combined organizations are no
> longer justified under ARIN policy at the time ARIN becomes aware of the
> transaction, through a transfer request or otherwise, ARIN will work
> with the resource holder(s) to return, aggregate, transfer, or reclaim
> resources as needed to restore compliance via the processes outlined in
> current ARIN policy."

I think this is important to keep in, so can we get the exact phrase 
that is in conflict from the RSA Section 6 in this thread for 
comparison. I included it, please adjust if not correct..

(Personally I would like to spend more time on the 'no longer justified 
under ARIN Policy part..')

RSA 6: REVIEW OF HOLDER?S NUMBER RESOURCES
Whenever a transfer or additional IP address space is requested by 
Holder, ARIN may review Holder?s utilization of previously allocated or 
assigned number resources and other Services received from ARIN to 
determine if Holder is complying with the Service Terms. Except as set 
forth in this Agreement,
   (i) ARIN will take no action to reduce the Services currently 
provided for Included Number Resources due to lack of utilization by the 
Holder, and
   (ii) ARIN has no right to revoke any Included Number Resources under 
this Agreement due to lack of utilization by Holder. However, ARIN may 
refuse to permit transfers or additional allocations of number resources
to Holder if Holder?s Included Number Resources are not utilized in 
accordance with Policy.

I have more of a problem with the RSA statement...

ARIN Enforcement is a challenge enough, and with the dearth of IP, it 
seems that there are many cases for reclaimation's.

It can allow a loophole where people can hold on the the valuable 
resource, and just play the transfer game ..


-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From hannigan at gmail.com  Thu Mar 20 16:41:35 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 20 Mar 2014 16:41:35 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <532B4FD0.4020607@wholesaleinternet.net>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<532B4FD0.4020607@wholesaleinternet.net>
Message-ID: <CAMDXq5P-RTs7c0NysZDwV3yeFb+O=HxokcBPvbj1xCN66D14iA@mail.gmail.com>

We can work that out in operator groups. ARIN is a steward of numbers,
not a regulator of operators and their routing policies.

Not adopting this will contribute another to the pile of existing
reasons as to why the registry is hugely inaccurate.

Best,

-M<



On Thu, Mar 20, 2014 at 4:30 PM, Aaron <aaron at wholesaleinternet.net> wrote:
> My issue with this proposal is that it might create an expectation that
> operators will start routing that space.  I just see a s**t storm when
> Customer A gets a /29 and no one can reach it.  I see it, in the long term,
> generating a lot of problems.
>
> Aaron
>
>
> On 3/20/2014 3:06 PM, Owen DeLong wrote:
>
>
> On Mar 20, 2014, at 13:01 , Heather Schiller <heather.skanks at gmail.com>
> wrote:
>
> As a shepherd for this proposal, I would like to solicit community feedback
> on the proposed text.
>
> Aside from the general support/against.. some things to consider:
>
> Do you concur with or have any comment on the problem statement?
>
>
> I do not concur with the problem statement.
>
> If you support the problem statement, do you support removing section 8.2 as
> the correct path for remediating this conflict?  Do you have other
> suggestions for how to handle this?
>
>
> No.
>
> If you are opposed, what concerns do you have about implementing this
> policy?
>
>
> I have previously stated my concerns. IMHO, this is yet another attempt to
> bypass the needs-basis and seeks to solve a problem which does not, in fact,
> exist.
>
> Owen
>
>
> Thanks,
> --Heather
>
>
>
> On Tue, Mar 4, 2014 at 3:12 PM, ARIN <info at arin.net> wrote:
>>
>> On 20 February 2014 the ARIN Advisory Council (AC) accepted
>> "ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization
>> Requirements" as a Draft Policy.
>>
>> Draft Policy ARIN-2014-9 is below and can be found at:
>> https://www.arin.net/policy/proposals/2014_9.html
>>
>> You are encouraged to discuss the merits and your concerns of Draft
>> Policy 2014-9 on the Public Policy Mailing List.
>>
>> 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-2014-9
>> Resolve Conflict Between RSA and 8.2 Utilization Requirements
>>
>> Date: 4 March 2014
>>
>> Problem Statement:
>>
>> 8.2 transfer policy has utilization requirements at the time of the review
>> of the transfer request.
>>
>> The RSA section 6 expressly forbids ARIN from de-registering blocks (in
>> whole or in part) due to under-utilization or no-justification during
>> transfer requests.
>>
>> This is a direct conflict.
>>
>> Return and aggregate are not done in collaboration; they are coerced by
>> policy without the willing consent of the transfer parties.
>>
>> We should remove all utilization references from 8.2 language to ensure
>> the policy is compliant with the RSA.
>>
>> Policy statement:
>>
>> Remove from 8.2:
>> "In the event that number resources of the combined organizations are no
>> longer justified under ARIN policy at the time ARIN becomes aware of the
>> transaction, through a transfer request or otherwise, ARIN will work with
>> the resource holder(s) to return, aggregate, transfer, or reclaim resources
>> as needed to restore compliance via the processes outlined in current ARIN
>> policy."
>>
>> Comments:
>> a.Timetable for implementation: Immediate
>> b.Anything else:
>>
>>
>>
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From dogwallah at gmail.com  Thu Mar 20 16:47:10 2014
From: dogwallah at gmail.com (McTim)
Date: Thu, 20 Mar 2014 16:47:10 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <532B52B4.2030900@linuxmagic.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<532B52B4.2030900@linuxmagic.com>
Message-ID: <CACAaNxgWw_m5FkeJ0VQH+3pF=hwH=RQiETfySuo=uAhZ_yWH5g@mail.gmail.com>

Thank you for looking that up and inserting it, very useful!

On Thu, Mar 20, 2014 at 4:42 PM, Michael Peddemors
<michael at linuxmagic.com> wrote:
> On 14-03-20 01:01 PM, Heather Schiller wrote:
>>
>> Remove from 8.2:
>> "In the event that number resources of the combined organizations are no
>> longer justified under ARIN policy at the time ARIN becomes aware of the
>> transaction, through a transfer request or otherwise, ARIN will work
>> with the resource holder(s) to return, aggregate, transfer, or reclaim
>> resources as needed to restore compliance via the processes outlined in
>> current ARIN policy."
>
>
> I think this is important to keep in, so can we get the exact phrase that is
> in conflict from the RSA Section 6 in this thread for comparison. I included
> it, please adjust if not correct..
>
> (Personally I would like to spend more time on the 'no longer justified
> under ARIN Policy part..')
>
> RSA 6: REVIEW OF HOLDER'S NUMBER RESOURCES
> Whenever a transfer or additional IP address space is requested by Holder,
> ARIN may review Holder's utilization of previously allocated or assigned
> number resources and other Services received from ARIN to determine if
> Holder is complying with the Service Terms. Except as set forth in this
> Agreement,
>   (i) ARIN will take no action to reduce the Services currently provided for
> Included Number Resources due to lack of utilization by the Holder, and
>   (ii) ARIN has no right to revoke any Included Number Resources under this
> Agreement due to lack of utilization by Holder. However, ARIN may refuse to
> permit transfers or additional allocations of number resources
> to Holder if Holder's Included Number Resources are not utilized in
> accordance with Policy.
>
> I have more of a problem with the RSA statement...


agreed, if there is a direct conflict, then either policy changes, or
the contract changes.

Is it not an option to modify the RSA?

>
> ARIN Enforcement is a challenge enough, and with the dearth of IP, it seems
> that there are many cases for reclaimation's.
>
> It can allow a loophole where people can hold on the the valuable resource,
> and just play the transfer game ..


to be avoided!


-- 
Cheers,

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


From David.Huberman at microsoft.com  Thu Mar 20 16:48:12 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 20 Mar 2014 20:48:12 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
	Between	RSA and 8.2 Utilization Requirements
In-Reply-To: <2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
Message-ID: <b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>

In contrast to my friend Owen, not only do I believe there is a very serious issue, but I believe this
proposal is necessary for ARIN to have any hope of being relevant in the years to come. I don't 
mean to use that kind of hyperbole, but the issue is very real from my viewpoint.  Allow me to 
explain.

There are two different problems which this policy proposal solves.

1. Whois accuracy
=============

As an ARIN Hostmaster for 10 years, I saw a very high rate of legitimate transfers which were
abandoned by the requestor.  In turn, Whois did not get updated, and in most cases, remains
out of date today. 

Think about that for a moment please:  legitimate M&A activity occurred, but Whois never
got updated.  That's a failure of the system. Why does it fail? 

The common scenario is straight forward:

	1. Company A buys company B.
	2. Company A submits a transfer request to ARIN to have the IP address and AS number
	registrations reflect that Company A is now the registrant.
	3. ARIN starts asking questions about the utilization of the number resources.
	4. Company A walks away from the transfer and never returns.

Step 3 is the consistent problem.  In many cases, Company A never even submits the transfer
request because they are scared off by step 3.   In some cases, it's because they don't KNOW
how the IP addresses are being used.  In some cases, some IP addresses are used, and others
are not, and they think that if ARIN finds that out, they are going to take the addresses away.
In some cases, none of the addresses are used.  But Company A is expanding their network
(or plans to) and wants to use the IP addresses of Company B which they now own.

Current policy does not work for these common scenarios.  I conclude that having seen
thousands of transfers cross through the ARIN ticket system and talked to these requestors
over the phone for 10 years.

The takeaway from the above is that Whois is not accurate, in part because ARIN policy
demands justification for addresses which, regardless of whether Whois is updated or not,
Company A is going to use.

In December, the PPML list requested metrics from ARIN staff to show the extent of abandoned
transfers.  The metrics provided were as follows:

=== 8.2 Transfer Request Stats

2011: 

422 8.2 transfers requested
226 8.2 transfers approved (54%)
209 8.2 transfers completed (50%)

2012:

451 8.2 transfers requested
264 8.2 transfers approved (59%)
241 8.2 transfers completed (53%)

2013 YTD:

445 8.2 transfers requested
280 8.2 transfers approved (63%)
269 8.2 transfers completed (60%)

If you review the thread in December, these stats generated a lot of discussion. I am among
the many who believe that a 40% abandonment rate FOR LEGITIMATE M&A ACTIVITY belies
a shortcoming in ARIN policy.  There's a barrier that must be removed, and my experience
teaches me that it is the utilization requirements of NRPM 8.2.

Now to the second problem.


2. Conflict with the RSA:
==================

John Curran can give a more accurate and nuanced history, but as best I can recall, ARIN 
tried to bring more legacy registration holders into the registry system by offering a
Legacy Registration Services Agreement.  One of the takeaways from that initial effort
was that legacy registration holders were unwilling to sign any agreement which technically
allowed ARIN to de-register address space that they had without their consent.

One of the concessions made over time was language in the RSA documents which 
removed that concern; it prohibits ARIN from forcibly taking away space when the
signer is in compliance with the other terms and conditions of the contract.

This new language, however, directly conflicts with the plain language of the NRPM 8.2
paragraph that this policy proposal seeks to remove.

>From a business standpoint -- from the standpoint of actually running the registry of
ARIN -- the paragraph I propose to be removed is NON-OPERATIONAL.  It cannot
be enforced under the terms of the RSA.

The community, therefore, I believe is compelled to address the conflict.

I hope this summary helps.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
Sent: Thursday, March 20, 2014 1:07 PM
To: Heather Schiller
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements


On Mar 20, 2014, at 13:01 , Heather Schiller <heather.skanks at gmail.com> wrote:


As a shepherd for this proposal, I would like to solicit community feedback on the proposed text.

Aside from the general support/against.. some things to consider:

Do you concur with or have any comment on the problem statement? ?

I do not concur with the problem statement.


If you support the problem statement, do you support removing section 8.2 as the correct path for remediating this conflict? ?Do you have other suggestions for how to handle this?

No.


If you are opposed, what concerns do you have about implementing this policy??

I have previously stated my concerns. IMHO, this is yet another attempt to bypass the needs-basis and seeks to solve a problem which does not, in fact, exist.

Owen



Thanks,
--Heather


On Tue, Mar 4, 2014 at 3:12 PM, ARIN <info at arin.net> wrote:
On 20 February 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization Requirements" as a Draft Policy.

Draft Policy ARIN-2014-9 is below and can be found at:
https://www.arin.net/policy/proposals/2014_9.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-9 on the Public Policy Mailing List.

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-2014-9
Resolve Conflict Between RSA and 8.2 Utilization Requirements

Date: 4 March 2014

Problem Statement:

8.2 transfer policy has utilization requirements at the time of the review of the transfer request.

The RSA section 6 expressly forbids ARIN from de-registering blocks (in whole or in part) due to under-utilization or no-justification during transfer requests.

This is a direct conflict.

Return and aggregate are not done in collaboration; they are coerced by policy without the willing consent of the transfer parties.

We should remove all utilization references from 8.2 language to ensure the policy is compliant with the RSA.

Policy statement:

Remove from 8.2:
"In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy."

Comments:
a.Timetable for implementation: Immediate
b.Anything else:





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

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



From dogwallah at gmail.com  Thu Mar 20 16:59:49 2014
From: dogwallah at gmail.com (McTim)
Date: Thu, 20 Mar 2014 16:59:49 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CACAaNxhkSpjD3iPvLhD4kRO0nFjM3OCJMGSAOxV2xVJS6_-F6g@mail.gmail.com>

Hi David,

On Thu, Mar 20, 2014 at 4:48 PM, David Huberman
<David.Huberman at microsoft.com> wrote:
> In contrast to my friend Owen, not only do I believe there is a very serious issue, but I believe this
> proposal is necessary for ARIN to have any hope of being relevant in the years to come. I don't
> mean to use that kind of hyperbole, but the issue is very real from my viewpoint.  Allow me to
> explain.
>
> There are two different problems which this policy proposal solves.
>
> 1. Whois accuracy
> =============
>
> As an ARIN Hostmaster for 10 years, I saw a very high rate of legitimate transfers which were
> abandoned by the requestor.  In turn, Whois did not get updated, and in most cases, remains
> out of date today.
>
> Think about that for a moment please:  legitimate M&A activity occurred, but Whois never
> got updated.  That's a failure of the system. Why does it fail?
>
> The common scenario is straight forward:
>
>         1. Company A buys company B.
>         2. Company A submits a transfer request to ARIN to have the IP address and AS number
>         registrations reflect that Company A is now the registrant.
>         3. ARIN starts asking questions about the utilization of the number resources.
>         4. Company A walks away from the transfer and never returns.
>
> Step 3 is the consistent problem.  In many cases, Company A never even submits the transfer
> request because they are scared off by step 3.

Then this is our (ARIN Community) problem isn't it, not the policy itself!!


<snip>



>
> Now to the second problem.
>
>
> 2. Conflict with the RSA:
> ==================
>
> John Curran can give a more accurate and nuanced history, but as best I can recall, ARIN
> tried to bring more legacy registration holders into the registry system by offering a
> Legacy Registration Services Agreement.  One of the takeaways from that initial effort
> was that legacy registration holders were unwilling to sign any agreement which technically
> allowed ARIN to de-register address space that they had without their consent.
>
> One of the concessions made over time was language in the RSA documents which
> removed that concern; it prohibits ARIN from forcibly taking away space when the
> signer is in compliance with the other terms and conditions of the contract.

is this in the LSRA only, or in all RSAs??

-- 
Cheers,

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


From michael at linuxmagic.com  Thu Mar 20 17:06:32 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Thu, 20 Mar 2014 14:06:32 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <532B5858.3070602@linuxmagic.com>

On 14-03-20 01:48 PM, David Huberman wrote:
> John Curran can give a more accurate and nuanced history, but as best I can recall, ARIN
> tried to bring more legacy registration holders into the registry system by offering a
> Legacy Registration Services Agreement.  One of the takeaways from that initial effort
> was that legacy registration holders were unwilling to sign any agreement which technically
> allowed ARIN to de-register address space that they had without their consent.
>
> One of the concessions made over time was language in the RSA documents which
> removed that concern; it prohibits ARIN from forcibly taking away space when the
> signer is in compliance with the other terms and conditions of the contract.
>
> This new language, however, directly conflicts with the plain language of the NRPM 8.2
> paragraph that this policy proposal seeks to remove.
>
>>From a business standpoint -- from the standpoint of actually running the registry of
> ARIN -- the paragraph I propose to be removed is NON-OPERATIONAL.  It cannot
> be enforced under the terms of the RSA.
>
> The community, therefore, I believe is compelled to address the conflict.

Thanks, summary is helpful.

But what about the ones that aren't under a RSA?

But this again stems to the most basic concern..

Is ARIN around only for assigning, or it it around to maintain 
assignments.  If the role of ARIN is to do enforcement, and reclaim 
unused or abused space, then any agreement that prevents that role 
should no be allowed.  So does the RSA prevent ARIN from enforcement?






-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
Remember, the N.A. ISP/Telecom Conference/Cruise Aug 2-9, 2014
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From David.Huberman at microsoft.com  Thu Mar 20 17:07:40 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 20 Mar 2014 21:07:40 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CACAaNxhkSpjD3iPvLhD4kRO0nFjM3OCJMGSAOxV2xVJS6_-F6g@mail.gmail.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<CACAaNxhkSpjD3iPvLhD4kRO0nFjM3OCJMGSAOxV2xVJS6_-F6g@mail.gmail.com>
Message-ID: <2c5df64061234cd6a0a1bb4584565043@DM2PR03MB398.namprd03.prod.outlook.com>

Hello McTim,

It is in both agreements: 
	Paragraph 6. of the RSA 
	Paragraph 7. of the LRSA.

As to your other comment, I think our policy is failing the Registry's users, not the other way around :)

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: McTim [mailto:dogwallah at gmail.com] 
Sent: Thursday, March 20, 2014 2:00 PM
To: David Huberman
Cc: Owen DeLong; Heather Schiller; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements

Hi David,

On Thu, Mar 20, 2014 at 4:48 PM, David Huberman <David.Huberman at microsoft.com> wrote:
> In contrast to my friend Owen, not only do I believe there is a very 
> serious issue, but I believe this proposal is necessary for ARIN to 
> have any hope of being relevant in the years to come. I don't mean to 
> use that kind of hyperbole, but the issue is very real from my viewpoint.  Allow me to explain.
>
> There are two different problems which this policy proposal solves.
>
> 1. Whois accuracy
> =============
>
> As an ARIN Hostmaster for 10 years, I saw a very high rate of 
> legitimate transfers which were abandoned by the requestor.  In turn, 
> Whois did not get updated, and in most cases, remains out of date today.
>
> Think about that for a moment please:  legitimate M&A activity 
> occurred, but Whois never got updated.  That's a failure of the system. Why does it fail?
>
> The common scenario is straight forward:
>
>         1. Company A buys company B.
>         2. Company A submits a transfer request to ARIN to have the IP address and AS number
>         registrations reflect that Company A is now the registrant.
>         3. ARIN starts asking questions about the utilization of the number resources.
>         4. Company A walks away from the transfer and never returns.
>
> Step 3 is the consistent problem.  In many cases, Company A never even 
> submits the transfer request because they are scared off by step 3.

Then this is our (ARIN Community) problem isn't it, not the policy itself!!


<snip>



>
> Now to the second problem.
>
>
> 2. Conflict with the RSA:
> ==================
>
> John Curran can give a more accurate and nuanced history, but as best 
> I can recall, ARIN tried to bring more legacy registration holders 
> into the registry system by offering a Legacy Registration Services 
> Agreement.  One of the takeaways from that initial effort was that 
> legacy registration holders were unwilling to sign any agreement which technically allowed ARIN to de-register address space that they had without their consent.
>
> One of the concessions made over time was language in the RSA 
> documents which removed that concern; it prohibits ARIN from forcibly 
> taking away space when the signer is in compliance with the other terms and conditions of the contract.

is this in the LSRA only, or in all RSAs??

--
Cheers,

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


From Timothy.S.Morizot at irs.gov  Thu Mar 20 17:41:00 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Thu, 20 Mar 2014 21:41:00 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <532B52B4.2030900@linuxmagic.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<532B52B4.2030900@linuxmagic.com>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A751109@MEM0200CP3XF04.ds.irsnet.gov>

I'm not sure I see an actual conflict between 8.2 and the RSA. This is the relevant line, I think, from the RSA.

"However, ARIN may refuse to permit transfers or additional allocations of number resources
to Holder if Holder's Included Number Resources are not utilized in accordance with Policy."

8.2 doesn't say that ARIN will unilaterally revoke resources, it says it will work with the resource holder(s) to bring them back into compliance.

So taking those two together, if the resource holder chooses not to work with ARIN to come into compliance, the impact would be that the 8.2 transfer request may not be approved and future allocations or transfers may not be approved.

It's always been the case that organizations can use any numbers they want and, if they need them routed, can do so to the extent they can convince/pay other operators to route them. The registry doesn't simply record usage. It serves as a central mediating organization for number allocations that people can reference and from which they can receive services like reverse dns delegation. A number resource that isn't properly registered certainly seems to have diminished value.

I don't think I support the draft policy as written, though I'm still mulling it over.

Scott
 




From owen at delong.com  Thu Mar 20 18:11:44 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 20 Mar 2014 15:11:44 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
	RSA and 8.2 Utilization Requirements
In-Reply-To: <532B5858.3070602@linuxmagic.com>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<532B5858.3070602@linuxmagic.com>
Message-ID: <28886CBB-A67E-4A6D-842B-939A2D6E9931@delong.com>


On Mar 20, 2014, at 2:06 PM, Michael Peddemors <michael at linuxmagic.com> wrote:

> On 14-03-20 01:48 PM, David Huberman wrote:
>> John Curran can give a more accurate and nuanced history, but as best I can recall, ARIN
>> tried to bring more legacy registration holders into the registry system by offering a
>> Legacy Registration Services Agreement.  One of the takeaways from that initial effort
>> was that legacy registration holders were unwilling to sign any agreement which technically
>> allowed ARIN to de-register address space that they had without their consent.
>> 
>> One of the concessions made over time was language in the RSA documents which
>> removed that concern; it prohibits ARIN from forcibly taking away space when the
>> signer is in compliance with the other terms and conditions of the contract.
>> 
>> This new language, however, directly conflicts with the plain language of the NRPM 8.2
>> paragraph that this policy proposal seeks to remove.
>> 
>>> From a business standpoint -- from the standpoint of actually running the registry of
>> ARIN -- the paragraph I propose to be removed is NON-OPERATIONAL.  It cannot
>> be enforced under the terms of the RSA.
>> 
>> The community, therefore, I believe is compelled to address the conflict.
> 
> Thanks, summary is helpful.
> 
> But what about the ones that aren't under a RSA?

Policy applies regardless of RSA.

RSA applies only where an RSA is present.

However, if the RSA contradicts policy, I believe the RSA is controlling for the specific resources covered by the particular RSA. This can get slightly more complicated, however, in that I believe most RSAs have phraseology that makes future policy changes act effectively as updates to the RSA.


> But this again stems to the most basic concern..
> 
> Is ARIN around only for assigning, or it it around to maintain assignments.  If the role of ARIN is to do enforcement, and reclaim unused or abused space, then any agreement that prevents that role should no be allowed.  So does the RSA prevent ARIN from enforcement?

First, it is important to understand what we are really talking about when we use terms like assign, enforce, policy, register, etc.

ARIN is not a legislator and does not have regulatory powers. When we talk about policy enforcement, we are strictly talking about control over what actions can be taken in regards to the data in the ARIN registry. Helpfully, a number of cooperating parties have chosen to use the data in the ARIN registry as an authoritative source for decisions about technical implementation of various parts of the internet. However, they don?t have  a legal obligation to do so. Admittedly, the internet will not work nearly as well as it does now if significant parties or significant numbers of parties begin to do otherwise.

When we talk about reclamation or revocation of resources, we are talking about ARIN modifying the ARIN registry database to indicate that those resources are no longer registered to the previous registrant. We are not talking about federal agents going in and taking the addresses by force. We aren?t even talking about detrimental or contrary announcements of the routes or any other directly destructive action by ARIN.

I still believe that it is important to manage the registry according to reasonable policies. I do not believe that just because the policies cannot prevent someone from taking an action which may be harmful to the community, we should remove prohibitions of those actions from policy.

(I apologize for the awkward  abstract wording, but my past corollaries of making bank robbery legal just because laws don?t actually prevent robberies were criticized as ?unhelpful? to the discussion).

I think fear mongering about the ?usefulness of the registry? by those that seek to eliminate all policy enforcement in the registry should be seen for what it is and that we as a community must make a decision whether we want to have reasonable policies and a culture of cooperation, or, abandon that culture which has worked thus far and allow the regulatory chips to fall where they may when it becomes obvious that we are unwilling to attempt to regulate ourselves.

Owen



From David.Huberman at microsoft.com  Thu Mar 20 18:28:32 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 20 Mar 2014 22:28:32 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
	Between	RSA and 8.2 Utilization Requirements
In-Reply-To: <28886CBB-A67E-4A6D-842B-939A2D6E9931@delong.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<532B5858.3070602@linuxmagic.com>,
	<28886CBB-A67E-4A6D-842B-939A2D6E9931@delong.com>
Message-ID: <67e2930520f74272b5a3c99f5bcf3de2@DM2PR03MB398.namprd03.prod.outlook.com>

Last email from me, I promise. I don't want to abuse the hospitality of the list.

Owen, I agree with you when you write that our policies generally work well and we shouldn't muck with them.

But I believe I have shown compelling proof, with hard statistics for 3 years and empirical observations over 10 years, that demonstrate that this specific language is detrimental to the primary purpose of ARIN: running an (accurate) numbers registry.

With exhaustion imminent, I do not see any downside to the technical operations of the Internet if we loosen up the needs-basis of 8.2 transfers, which in reality as Scott from IRS points out, happen with or without the registry.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

________________________________________
From: arin-ppml-bounces at arin.net <arin-ppml-bounces at arin.net> on behalf of Owen DeLong <owen at delong.com>
Sent: Thursday, March 20, 2014 3:11:44 PM
To: Michael Peddemors
Cc: ARIN-PPML List
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between     RSA and 8.2 Utilization Requirements

On Mar 20, 2014, at 2:06 PM, Michael Peddemors <michael at linuxmagic.com> wrote:

> On 14-03-20 01:48 PM, David Huberman wrote:
>> John Curran can give a more accurate and nuanced history, but as best I can recall, ARIN
>> tried to bring more legacy registration holders into the registry system by offering a
>> Legacy Registration Services Agreement.  One of the takeaways from that initial effort
>> was that legacy registration holders were unwilling to sign any agreement which technically
>> allowed ARIN to de-register address space that they had without their consent.
>>
>> One of the concessions made over time was language in the RSA documents which
>> removed that concern; it prohibits ARIN from forcibly taking away space when the
>> signer is in compliance with the other terms and conditions of the contract.
>>
>> This new language, however, directly conflicts with the plain language of the NRPM 8.2
>> paragraph that this policy proposal seeks to remove.
>>
>>> From a business standpoint -- from the standpoint of actually running the registry of
>> ARIN -- the paragraph I propose to be removed is NON-OPERATIONAL.  It cannot
>> be enforced under the terms of the RSA.
>>
>> The community, therefore, I believe is compelled to address the conflict.
>
> Thanks, summary is helpful.
>
> But what about the ones that aren't under a RSA?

Policy applies regardless of RSA.

RSA applies only where an RSA is present.

However, if the RSA contradicts policy, I believe the RSA is controlling for the specific resources covered by the particular RSA. This can get slightly more complicated, however, in that I believe most RSAs have phraseology that makes future policy changes act effectively as updates to the RSA.


> But this again stems to the most basic concern..
>
> Is ARIN around only for assigning, or it it around to maintain assignments.  If the role of ARIN is to do enforcement, and reclaim unused or abused space, then any agreement that prevents that role should no be allowed.  So does the RSA prevent ARIN from enforcement?

First, it is important to understand what we are really talking about when we use terms like assign, enforce, policy, register, etc.

ARIN is not a legislator and does not have regulatory powers. When we talk about policy enforcement, we are strictly talking about control over what actions can be taken in regards to the data in the ARIN registry. Helpfully, a number of cooperating parties have chosen to use the data in the ARIN registry as an authoritative source for decisions about technical implementation of various parts of the internet. However, they don?t have  a legal obligation to do so. Admittedly, the internet will not work nearly as well as it does now if significant parties or significant numbers of parties begin to do otherwise.

When we talk about reclamation or revocation of resources, we are talking about ARIN modifying the ARIN registry database to indicate that those resources are no longer registered to the previous registrant. We are not talking about federal agents going in and taking the addresses by force. We aren?t even talking about detrimental or contrary announcements of the routes or any other directly destructive action by ARIN.

I still believe that it is important to manage the registry according to reasonable policies. I do not believe that just because the policies cannot prevent someone from taking an action which may be harmful to the community, we should remove prohibitions of those actions from policy.

(I apologize for the awkward  abstract wording, but my past corollaries of making bank robbery legal just because laws don?t actually prevent robberies were criticized as ?unhelpful? to the discussion).

I think fear mongering about the ?usefulness of the registry? by those that seek to eliminate all policy enforcement in the registry should be seen for what it is and that we as a community must make a decision whether we want to have reasonable policies and a culture of cooperation, or, abandon that culture which has worked thus far and allow the regulatory chips to fall where they may when it becomes obvious that we are unwilling to attempt to regulate ourselves.

Owen

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


From jcurran at arin.net  Thu Mar 20 18:35:24 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 20 Mar 2014 22:35:24 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve
	Conflict	Between	RSA and 8.2 Utilization Requirements
In-Reply-To: <b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <9AFE1DF9-1500-417A-85F2-02536EDB579F@arin.net>

On Mar 21, 2014, at 4:48 AM, David Huberman <David.Huberman at microsoft.com> wrote:

> Think about that for a moment please:  legitimate M&A activity occurred, but Whois never
> got updated.  That's a failure of the system. Why does it fail? 

Excellent question.

> The common scenario is straight forward:
> 
> 	1. Company A buys company B.
> 	2. Company A submits a transfer request to ARIN to have the IP address and AS number
> 	registrations reflect that Company A is now the registrant.
> 	3. ARIN starts asking questions about the utilization of the number resources.
> 	4. Company A walks away from the transfer and never returns.
> 
> Step 3 is the consistent problem.  In many cases, Company A never even submits the transfer
> request because they are scared off by step 3.   In some cases, it's because they don't KNOW
> how the IP addresses are being used.  In some cases, some IP addresses are used, and others
> are not, and they think that if ARIN finds that out, they are going to take the addresses away.

The potential reasons you cite for companies being "scared off" are:

  - They don't know how their IP addresses are being used
  - They think that if ARIN finds out some are unused, ARIN will take them away.

> ...
> One of the concessions made over time was language in the RSA documents which 
> removed that concern; it prohibits ARIN from forcibly taking away space when the
> signer is in compliance with the other terms and conditions of the contract.

That is correct; the specific language in both the RSA and LRSA is as follows:

   RSA - 
"6. REVIEW OF HOLDER?S NUMBER RESOURCES
Whenever a transfer or additional IP address space is requested by Holder, ARIN may review Holder?s utilization of previously allocated or assigned number resources and other Services received from ARIN to determine if Holder is complying with the Service Terms. Except as set forth in this Agreement, (i) ARIN will take no action to reduce the Services currently provided for Included Number Resources due to lack of utilization by the Holder, and (ii) ARIN has no right to revoke any Included Number Resources under this Agreement due to lack of utilization by Holder. However, ARIN may refuse to permit transfers or additional allocations of number resources to Holder if Holder?s Included Number Resources are not utilized in accordance with Policy."

LRSA - 
"7. REVIEW OF LEGACY HOLDER?S NUMBER RESOURCES
Whenever a transfer or additional IP address space is requested by Legacy Holder, ARIN may review Legacy Holder?s utilization of previously allocated or assigned number resources and other Services received from ARIN to determine if Legacy Holder is complying with the Service Terms. Except as set forth in this Legacy Agreement, (i) ARIN will take no action to reduce the Services currently provided for Included Number Resources due to lack of utilization by the Legacy Holder, and (ii) ARIN has no right to revoke any Included Number Resources under this Legacy Agreement due to lack of utilization by Legacy Holder. However, ARIN may refuse to permit transfers to Legacy Holder or additional allocations of number resources if Legacy Holder?s Included Number Resources are not utilized in accordance with Policy."

Note that the RSA and LRSA are materially the same in terms and conditions at this 
point (except for the applicable fee schedule) and both provide that ARIN may review
utilization of number resources but that ARIN disclaims a right of revocation due to 
lack of utilization. (There is a viable transfer market as well as the option to return
number resources, both of these provide fine alternatives for achieving the targeted
utilization.)

Note that reclamation remains an options with resources _not_ under an agreement; 
if parties want to have a clear statement of rights with respect to their legacy 
number resources, then entry into an LRSA provides them that.

Parties who have their resources under an RSA or LRSA cannot have their resources 
revoked for lack of utilization, although ARIN does ask about their utilization 
during NRPM 8.2 transfer; in cases of significant lack of utilization we will also
note the option of voluntary return as well as the ability to transfer via NRPM 
8.3/8.4 i.e. the other options under NRPM 8.2 language, specifically -
 
 "ARIN will work with the resource holder(s) to return, aggregate, transfer, 
  or reclaim resources as needed to restore compliance via the processes 
  outlined in current ARIN policy."

I do not know if asking parties (that are undergoing NRPM 8.2 transfer) to know 
their number resource utilization serves a useful purpose to the community, but 
that is the primary role of NRPM 8.2.  Note that it may also serve as a deterrent 
(although hard to prove) in some cases to M & A transactions purely for purposes 
of obtaining IP space, since ARIN will seek to understand the utilization of the 
combined entity and may not agree to allow the transfer per community policy 
(and parties that endeavor to work around such requirements via fraudulent 
representations to ARIN can have the number resources reclaimed per NRPM 12) 

> This new language, however, directly conflicts with the plain language of the NRPM 8.2
> paragraph that this policy proposal seeks to remove.

Note that the policy proposal seeks to remove the entire section of NRPM 8.2 
regarding utilization, when only conflict is with respect to the appearance of 
the word "reclaim" in the policy text when dealing with number resources which 
are under registration services agreement.

The intent of NRPM 8.2, however, is quite clear - parties merging with other 
parties will have a discussion with ARIN about the number resources utilization
of the combined entity.

> From a business standpoint -- from the standpoint of actually running the registry of
> ARIN -- the paragraph I propose to be removed is NON-OPERATIONAL.  It cannot
> be enforced under the terms of the RSA.

The language is actually quite operational - as you note, it results in a 
dialogue with the party about the number resources of the combined entity. 

One may attribute NRPM 8.2 transfers not being completed to this requirement,
but it is equally due to lack of understanding or misinformation of the RSA/LRSA 
agreements, whereby parties are "scared off" from completion of the transfer 
processes.  As David notes, the fear of reclamation for legitimate requestors
is unfounded (even if hyped by some in the community for their own purposes.)

It worth considering the benefits provided by reviewing the party's utilization 
of number resources, when compared against the resulting disincentive to completion
of transfers (due to uncertainty); in the end, this is a policy tradeoff that the 
community needs to decide on and ARIN will process 8.2 transfers accordingly.

Thanks!
/John

John Curran
President and CEO
ARIN







From owen at delong.com  Thu Mar 20 20:41:30 2014
From: owen at delong.com (Owen DeLong)
Date: Thu, 20 Mar 2014 17:41:30 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
	RSA and 8.2 Utilization Requirements
In-Reply-To: <67e2930520f74272b5a3c99f5bcf3de2@DM2PR03MB398.namprd03.prod.outlook.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<532B5858.3070602@linuxmagic.com>,
	<28886CBB-A67E-4A6D-842B-939A2D6E9931@delong.com>
	<67e2930520f74272b5a3c99f5bcf3de2@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <FFE154ED-C03D-4858-9820-45C8BBB708C4@delong.com>


On Mar 20, 2014, at 3:28 PM, David Huberman <David.Huberman at microsoft.com> wrote:

> Last email from me, I promise. I don't want to abuse the hospitality of the list.
> 
> Owen, I agree with you when you write that our policies generally work well and we shouldn't muck with them.

I?m not saying that we shouldn?t muck with them. I?m saying that we shouldn?t sacrifice the ability to institute policy on the altar of ?some people don?t comply, so we should eliminate the policy?

> But I believe I have shown compelling proof, with hard statistics for 3 years and empirical observations over 10 years, that demonstrate that this specific language is detrimental to the primary purpose of ARIN: running an (accurate) numbers registry.

I disagree. I would say, instead, that you have proven that there are some people who do not keep their registry records up to date. You have asserted that they would be somehow more likely to update the registry if policy were removed.

> With exhaustion imminent, I do not see any downside to the technical operations of the Internet if we loosen up the needs-basis of 8.2 transfers, which in reality as Scott from IRS points out, happen with or without the registry.

I see several potential downsides, not the least of which is a strong motivation to disguise 8.3 transfers as 8.2 style transactions.

Owen



From farmer at umn.edu  Thu Mar 20 21:04:46 2014
From: farmer at umn.edu (David Farmer)
Date: Thu, 20 Mar 2014 20:04:46 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
Message-ID: <532B902E.8000106@umn.edu>

On 3/20/14, 15:01 , Heather Schiller wrote:
> As a shepherd for this proposal, I would like to solicit community
> feedback on the proposed text.
>
> Aside from the general support/against.. some things to consider:
>
> Do you concur with or have any comment on the problem statement?

The problem statement conflates two issues. I concur with part of the 
problem statement, there is a conflict between this policy and the RSA.

The second issue basically says that it is bad policy to require a 
review of the utilization of M&A Transferred resources.  I must admit 
that I would prefer that legitimate M&A transfers not have to go through 
this process.  However, I cannot support removal of this clause without 
some other way to ensure that people don't use creative contracting to 
make what should be a 8.3 transfer look like a 8.2 transfer.

> If you support the problem statement, do you support removing section
> 8.2 as the correct path for remediating this conflict?  Do you have
> other suggestions for how to handle this?

I'm not fundamentally opposed to removing the paragraph in its entirety, 
if my issue above can be resolved.  However, I suggest there is a less 
drastic solution to resolving the actual conflict between this policy 
and the RSA.

Technically, there is only one word in the paragraph in question that is 
fundamentally in conflict with the RSA, that is "reclaim".  Also, with 
the suspension of sections 4.6 and 4.7 and ARIN-2014-10, I'd suggest 
that "aggregate" will essentially become a NO-OP.

So, I fully support removing the words "reclaim" and "aggregate" from 
the paragraph, and slightly adjusting the wording so makes sense after 
their removal;

    In the event that number resources of the combined organizations
    are no longer justified under ARIN policy at the time ARIN becomes
    aware of the transaction, through a transfer request or otherwise,
    ARIN will work with the resource holder(s) to return or transfer
    resources as needed to restore compliance via the processes outlined
    in current ARIN policy.

The conflict between this policy and the RSA is then resolved, and the 
likely non-operative option is removed.

If someone has useful suggestions for how to ensure that 8.2 doesn't 
become a loop-hole for 8.3 if this paragraph is removed, I'd be willing 
to consider its complete removal.

Thanks.

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


From john.sweeting at twcable.com  Thu Mar 20 21:28:03 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Thu, 20 Mar 2014 21:28:03 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve
	Conflict	Between	RSA and 8.2 Utilization Requirements
In-Reply-To: <b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>

Hi David

I usually do not weigh in on active policy proposals but I did want to point out that a lot companies do not complete transfers during M&A activities simply because they do not have the resources to do so. The one (or half) person they have dealing with IP resources usually cannot even keep up with normal workload, let alone the additional workload associated with M&A activity. At least that has been my experience over many years and more than a few M&A events.

Sent from my iPhone

> On Mar 20, 2014, at 4:51 PM, "David Huberman" <David.Huberman at microsoft.com> wrote:
>
> In contrast to my friend Owen, not only do I believe there is a very serious issue, but I believe this
> proposal is necessary for ARIN to have any hope of being relevant in the years to come. I don't
> mean to use that kind of hyperbole, but the issue is very real from my viewpoint.  Allow me to
> explain.
>
> There are two different problems which this policy proposal solves.
>
> 1. Whois accuracy
> =============
>
> As an ARIN Hostmaster for 10 years, I saw a very high rate of legitimate transfers which were
> abandoned by the requestor.  In turn, Whois did not get updated, and in most cases, remains
> out of date today.
>
> Think about that for a moment please:  legitimate M&A activity occurred, but Whois never
> got updated.  That's a failure of the system. Why does it fail?
>
> The common scenario is straight forward:
>
>        1. Company A buys company B.
>        2. Company A submits a transfer request to ARIN to have the IP address and AS number
>        registrations reflect that Company A is now the registrant.
>        3. ARIN starts asking questions about the utilization of the number resources.
>        4. Company A walks away from the transfer and never returns.
>
> Step 3 is the consistent problem.  In many cases, Company A never even submits the transfer
> request because they are scared off by step 3.   In some cases, it's because they don't KNOW
> how the IP addresses are being used.  In some cases, some IP addresses are used, and others
> are not, and they think that if ARIN finds that out, they are going to take the addresses away.
> In some cases, none of the addresses are used.  But Company A is expanding their network
> (or plans to) and wants to use the IP addresses of Company B which they now own.
>
> Current policy does not work for these common scenarios.  I conclude that having seen
> thousands of transfers cross through the ARIN ticket system and talked to these requestors
> over the phone for 10 years.
>
> The takeaway from the above is that Whois is not accurate, in part because ARIN policy
> demands justification for addresses which, regardless of whether Whois is updated or not,
> Company A is going to use.
>
> In December, the PPML list requested metrics from ARIN staff to show the extent of abandoned
> transfers.  The metrics provided were as follows:
>
> === 8.2 Transfer Request Stats
>
> 2011:
>
> 422 8.2 transfers requested
> 226 8.2 transfers approved (54%)
> 209 8.2 transfers completed (50%)
>
> 2012:
>
> 451 8.2 transfers requested
> 264 8.2 transfers approved (59%)
> 241 8.2 transfers completed (53%)
>
> 2013 YTD:
>
> 445 8.2 transfers requested
> 280 8.2 transfers approved (63%)
> 269 8.2 transfers completed (60%)
>
> If you review the thread in December, these stats generated a lot of discussion. I am among
> the many who believe that a 40% abandonment rate FOR LEGITIMATE M&A ACTIVITY belies
> a shortcoming in ARIN policy.  There's a barrier that must be removed, and my experience
> teaches me that it is the utilization requirements of NRPM 8.2.
>
> Now to the second problem.
>
>
> 2. Conflict with the RSA:
> ==================
>
> John Curran can give a more accurate and nuanced history, but as best I can recall, ARIN
> tried to bring more legacy registration holders into the registry system by offering a
> Legacy Registration Services Agreement.  One of the takeaways from that initial effort
> was that legacy registration holders were unwilling to sign any agreement which technically
> allowed ARIN to de-register address space that they had without their consent.
>
> One of the concessions made over time was language in the RSA documents which
> removed that concern; it prohibits ARIN from forcibly taking away space when the
> signer is in compliance with the other terms and conditions of the contract.
>
> This new language, however, directly conflicts with the plain language of the NRPM 8.2
> paragraph that this policy proposal seeks to remove.
>
>> From a business standpoint -- from the standpoint of actually running the registry of
> ARIN -- the paragraph I propose to be removed is NON-OPERATIONAL.  It cannot
> be enforced under the terms of the RSA.
>
> The community, therefore, I believe is compelled to address the conflict.
>
> I hope this summary helps.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Thursday, March 20, 2014 1:07 PM
> To: Heather Schiller
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements
>
>
> On Mar 20, 2014, at 13:01 , Heather Schiller <heather.skanks at gmail.com> wrote:
>
>
> As a shepherd for this proposal, I would like to solicit community feedback on the proposed text.
>
> Aside from the general support/against.. some things to consider:
>
> Do you concur with or have any comment on the problem statement?
>
> I do not concur with the problem statement.
>
>
> If you support the problem statement, do you support removing section 8.2 as the correct path for remediating this conflict?  Do you have other suggestions for how to handle this?
>
> No.
>
>
> If you are opposed, what concerns do you have about implementing this policy?
>
> I have previously stated my concerns. IMHO, this is yet another attempt to bypass the needs-basis and seeks to solve a problem which does not, in fact, exist.
>
> Owen
>
>
>
> Thanks,
> --Heather
>
>
> On Tue, Mar 4, 2014 at 3:12 PM, ARIN <info at arin.net> wrote:
> On 20 February 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization Requirements" as a Draft Policy.
>
> Draft Policy ARIN-2014-9 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_9.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-9 on the Public Policy Mailing List.
>
> 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-2014-9
> Resolve Conflict Between RSA and 8.2 Utilization Requirements
>
> Date: 4 March 2014
>
> Problem Statement:
>
> 8.2 transfer policy has utilization requirements at the time of the review of the transfer request.
>
> The RSA section 6 expressly forbids ARIN from de-registering blocks (in whole or in part) due to under-utilization or no-justification during transfer requests.
>
> This is a direct conflict.
>
> Return and aggregate are not done in collaboration; they are coerced by policy without the willing consent of the transfer parties.
>
> We should remove all utilization references from 8.2 language to ensure the policy is compliant with the RSA.
>
> Policy statement:
>
> Remove from 8.2:
> "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy."
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


From Timothy.S.Morizot at irs.gov  Thu Mar 20 23:27:28 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Fri, 21 Mar 2014 03:27:28 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <532B902E.8000106@umn.edu>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<532B902E.8000106@umn.edu>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A75149F@MEM0200CP3XF04.ds.irsnet.gov>


David Farmer wrote:
> Technically, there is only one word in the paragraph in question that is
> fundamentally in conflict with the RSA, that is "reclaim".  Also, with
> the suspension of sections 4.6 and 4.7 and ARIN-2014-10, I'd suggest
> that "aggregate" will essentially become a NO-OP.
> 
> So, I fully support removing the words "reclaim" and "aggregate" from
> the paragraph, and slightly adjusting the wording so makes sense after
> their removal;

I would fully support removing those two words from the paragraph.

Scott



From hannigan at gmail.com  Thu Mar 20 23:35:41 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 20 Mar 2014 23:35:41 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>
Message-ID: <CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>

In my buy-merger-sell experience, most companies don't complete transfers
post M&A because they dont want to deal with ARIN.  It's not worth the
difficulty.  Accuracy of the registry suffers again.

Best,

Martin

On Thursday, March 20, 2014, Sweeting, John <john.sweeting at twcable.com>
wrote:

> Hi David
>
> I usually do not weigh in on active policy proposals but I did want to
> point out that a lot companies do not complete transfers during M&A
> activities simply because they do not have the resources to do so. The one
> (or half) person they have dealing with IP resources usually cannot even
> keep up with normal workload, let alone the additional workload associated
> with M&A activity. At least that has been my experience over many years and
> more than a few M&A events.
>
> Sent from my iPhone
>
> > On Mar 20, 2014, at 4:51 PM, "David Huberman" <
> David.Huberman at microsoft.com> wrote:
> >
> > In contrast to my friend Owen, not only do I believe there is a very
> serious issue, but I believe this
> > proposal is necessary for ARIN to have any hope of being relevant in the
> years to come. I don't
> > mean to use that kind of hyperbole, but the issue is very real from my
> viewpoint.  Allow me to
> > explain.
> >
> > There are two different problems which this policy proposal solves.
> >
> > 1. Whois accuracy
> > =============
> >
> > As an ARIN Hostmaster for 10 years, I saw a very high rate of legitimate
> transfers which were
> > abandoned by the requestor.  In turn, Whois did not get updated, and in
> most cases, remains
> > out of date today.
> >
> > Think about that for a moment please:  legitimate M&A activity occurred,
> but Whois never
> > got updated.  That's a failure of the system. Why does it fail?
> >
> > The common scenario is straight forward:
> >
> >        1. Company A buys company B.
> >        2. Company A submits a transfer request to ARIN to have the IP
> address and AS number
> >        registrations reflect that Company A is now the registrant.
> >        3. ARIN starts asking questions about the utilization of the
> number resources.
> >        4. Company A walks away from the transfer and never returns.
> >
> > Step 3 is the consistent problem.  In many cases, Company A never even
> submits the transfer
> > request because they are scared off by step 3.   In some cases, it's
> because they don't KNOW
> > how the IP addresses are being used.  In some cases, some IP addresses
> are used, and others
> > are not, and they think that if ARIN finds that out, they are going to
> take the addresses away.
> > In some cases, none of the addresses are used.  But Company A is
> expanding their network
> > (or plans to) and wants to use the IP addresses of Company B which they
> now own.
> >
> > Current policy does not work for these common scenarios.  I conclude
> that having seen
> > thousands of transfers cross through the ARIN ticket system and talked
> to these requestors
> > over the phone for 10 years.
> >
> > The takeaway from the above is that Whois is not accurate, in part
> because ARIN policy
> > demands justification for addresses which, regardless of whether Whois
> is updated or not,
> > Company A is going to use.
> >
> > In December, the PPML list requested metrics from ARIN staff to show the
> extent of abandoned
> > transfers.  The metrics provided were as follows:
> >
> > === 8.2 Transfer Request Stats
> >
> > 2011:
> >
> > 422 8.2 transfers requested
> > 226 8.2 transfers approved (54%)
> > 209 8.2 transfers completed (50%)
> >
> > 2012:
> >
> > 451 8.2 transfers requested
> > 264 8.2 transfers approved (59%)
> > 241 8.2 transfers completed (53%)
> >
> > 2013 YTD:
> >
> > 445 8.2 transfers requested
> > 280 8.2 transfers approved (63%)
> > 269 8.2 transfers completed (60%)
> >
> > If you review the thread in December, these stats generated a lot of
> discussion. I am among
> > the many who believe that a 40% abandonment rate FOR LEGITIMATE M&A
> ACTIVITY belies
> > a shortcoming in ARIN policy.  There's a barrier that must be removed,
> and my experience
> > teaches me that it is the utilization requirements of NRPM 8.2.
> >
> > Now to the second problem.
> >
> >
> > 2. Conflict with the RSA:
> > ==================
> >
> > John Curran can give a more accurate and nuanced history, but as best I
> can recall, ARIN
> > tried to bring more legacy registration holders into the registry system
> by offering a
> > Legacy Registration Services Agreement.  One of the takeaways from that
> initial effort
> > was that legacy registration holders were unwilling to sign any
> agreement which technically
> > allowed ARIN to de-register address space that they had without their
> consent.
> >
> > One of the concessions made over time was language in the RSA documents
> which
> > removed that concern; it prohibits ARIN from forcibly taking away space
> when the
> > signer is in compliance with the other terms and conditions of the
> contract.
> >
> > This new language, however, directly conflicts with the plain language
> of the NRPM 8.2
> > paragraph that this policy proposal seeks to remove.<This E-mail and any
> of its attachments may contain Time Warner Cable proprietary information,
> which is privileged, confidential, or subject to copyright belonging to
> Time Warner Cable. This E-mail is intended solely for the use of the
> individual or entity to which it is addressed. If you are not the intended
> recipient of this E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be unlawful. If
> you have received this E-mail in error, please notify the sender
> immediately and permanently delete the original and any copy of this E-mail
> and any printout.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <javascript:;>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net <javascript:;> if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140320/e41958ae/attachment.htm>

From narten at us.ibm.com  Fri Mar 21 00:53:02 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 21 Mar 2014 00:53:02 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201403210453.s2L4r2v8002637@rotala.raleigh.ibm.com>

Total of 34 messages in the last 7 days.
 
script run at: Fri Mar 21 00:53:02 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 20.59% |    7 | 24.20% |    90648 | david.huberman at microsoft.com
 11.76% |    4 | 10.24% |    38343 | owen at delong.com
  8.82% |    3 | 12.11% |    45361 | scottleibrand at gmail.com
  8.82% |    3 |  9.84% |    36869 | hannigan at gmail.com
  8.82% |    3 |  6.80% |    25488 | jcurran at arin.net
  8.82% |    3 |  6.39% |    23922 | michael at linuxmagic.com
  5.88% |    2 |  4.21% |    15783 | dogwallah at gmail.com
  5.88% |    2 |  3.48% |    13034 | timothy.s.morizot at irs.gov
  2.94% |    1 |  5.50% |    20608 | aaron at wholesaleinternet.net
  2.94% |    1 |  4.10% |    15348 | john.sweeting at twcable.com
  2.94% |    1 |  3.53% |    13210 | heather.skanks at gmail.com
  2.94% |    1 |  2.77% |    10370 | info at arin.net
  2.94% |    1 |  2.45% |     9161 | farmer at umn.edu
  2.94% |    1 |  2.42% |     9067 | mysidia at gmail.com
  2.94% |    1 |  1.96% |     7354 | narten at us.ibm.com
--------+------+--------+----------+------------------------
100.00% |   34 |100.00% |   374566 | Total



From matthew at matthew.at  Fri Mar 21 02:04:16 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 20 Mar 2014 23:04:16 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <28886CBB-A67E-4A6D-842B-939A2D6E9931@delong.com>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>	<532B5858.3070602@linuxmagic.com>
	<28886CBB-A67E-4A6D-842B-939A2D6E9931@delong.com>
Message-ID: <532BD660.6020508@matthew.at>

On 3/20/2014 3:11 PM, Owen DeLong wrote:
> I think fear mongering about the ?usefulness of the registry? by those 
> that seek to eliminate all policy enforcement in the registry should 
> be seen for what it is and that we as a community must make a decision 
> whether we want to have reasonable policies and a culture of 
> cooperation, or, abandon that culture which has worked thus far and 
> allow the regulatory chips to fall where they may when it becomes 
> obvious that we are unwilling to attempt to regulate ourselves.

I don't see a *documented* 40% abandon rate on 8.2 transfer requests as 
"fear mongering". I strongly suspect that every single one of those 
abandoned requests is a case where a M&A *actually happened* and yet, 
because it was abandoned, the registry no longer accurately reflects 
that M&A activity. (I really can't imagine anyone who would simply, for 
entertainment value, file 8.2 M&A transfer requests when no M&A has 
occurred.)

The longer this abandon rate stays high, the more incorrect entries in 
the registry will accumulate. Not "fear mongering", just fact.

The original author of the draft policy claims to have personal 
experience that suggests that one of the reasons these are getting 
abandoned is the language he seeks to remove. I guess I'd like to hear 
evidence that shows that the abandoned requests are getting abandoned 
entirely for some other reason before opposing this proposal. Until 
then, I support it.

Matthew Kaufman


From matthew at matthew.at  Fri Mar 21 02:08:04 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 20 Mar 2014 23:08:04 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <FFE154ED-C03D-4858-9820-45C8BBB708C4@delong.com>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>	<532B5858.3070602@linuxmagic.com>,
	<28886CBB-A67E-4A6D-842B-939A2D6E9931@delong.com>	<67e2930520f74272b5a3c99f5bcf3de2@DM2PR03MB398.namprd03.prod.outlook.com>
	<FFE154ED-C03D-4858-9820-45C8BBB708C4@delong.com>
Message-ID: <532BD744.9050202@matthew.at>

On 3/20/2014 5:41 PM, Owen DeLong wrote:
>
> I see several potential downsides, not the least of which is a strong motivation to disguise 8.3 transfers as 8.2 style transactions.
>

That's been happening since before there was an 8.3. What does this 
change? As has been pointed out, the "reclaim" option doesn't really 
exist when said transfer involves RSA or LRSA resources. So at the very 
least, that word doesn't belong in the NRPM for this section.

Matthew Kaufman


From matthew at matthew.at  Fri Mar 21 02:10:30 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Thu, 20 Mar 2014 23:10:30 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>
	<CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>
Message-ID: <532BD7D6.4000901@matthew.at>

On 3/20/2014 8:35 PM, Martin Hannigan wrote:
>
> In my buy-merger-sell experience, most companies don't complete 
> transfers post M&A because they dont want to deal with ARIN.  It's not 
> worth the difficulty.  Accuracy of the registry suffers again. 

If they don't want to deal with ARIN (and I agree, I've seen a lot of 
that), why even start the 8.2 transfer process? All this says is that in 
addition to that 40% abandon rate, we *also* have people not even 
starting the process.

Matthew Kaufman


From jcurran at arin.net  Fri Mar 21 02:39:46 2014
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Mar 2014 06:39:46 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <532BD7D6.4000901@matthew.at>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>
	<CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>
	<532BD7D6.4000901@matthew.at>
Message-ID: <CDA64243-36FD-407D-8707-2440E5A7C86B@arin.net>

On Mar 21, 2014, at 2:10 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> If they don't want to deal with ARIN (and I agree, I've seen a lot of that), why even start the 8.2 transfer process? All this says is that in addition to that 40% abandon rate, we *also* have people not even starting the process.

Matthew -

A typical example is a someone who believes that they are a legacy 
resource holder because they are the technical or administrative 
contact on an address block (but the organization field points to 
a company from long ago) who comes to ARIN wishing to update their 
organization field to match a more current organization. In these
cases, because the organization field is changing, the request is 
a transfer.

Upon entering into the process (which in their view started simply 
as "updating their ARIN info"), it is made clear that ARIN will need
to see appropriate documentation (to insure this isn't actually a 
hijacking) and to see utilization information per NRPM 8.2.

At this point, some number of requesters will abandon the process.
Some of those are because of lack of documentation or effort to 
produce same, and some are because of fears related to utilization,
agreements, etc.

I hope this help explains at least one very typical portion of the 
transfer abandon rate.

/John

John Curran
President and CEO
ARIN



From drc at virtualized.org  Fri Mar 21 02:56:11 2014
From: drc at virtualized.org (David Conrad)
Date: Thu, 20 Mar 2014 23:56:11 -0700
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
	Requirements
In-Reply-To: <8B067E70-3424-45F3-A49F-C90F7417E82D@arin.net>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
	<65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>
	<d61a4224ffc0481084b2828a0dca8ac4@DM2PR03MB398.namprd03.prod.outlook.com>
	<8B067E70-3424-45F3-A49F-C90F7417E82D@arin.net>
Message-ID: <1A2FA24B-7CAC-44CA-BF1B-C1000F22550C@virtualized.org>

John,

On Mar 19, 2014, at 11:47 AM, John Curran <jcurran at arin.net> wrote:
>> Also, I believe ARIN is the wrong place for such constraints.  I believe operators should make the decision on such matters
> 
> I also believe that operators should set such constraints (if desired),

They do. It's called "prefix length filters". 

> by participation in the regional policy development process.

Out of curiosity, what percentage of ASes being announced on the Internet participate in ARIN regional policy development processes?  

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140320/b973fdbf/attachment.sig>

From gary.buhrmaster at gmail.com  Fri Mar 21 10:10:42 2014
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 21 Mar 2014 14:10:42 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CDA64243-36FD-407D-8707-2440E5A7C86B@arin.net>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>
	<CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>
	<532BD7D6.4000901@matthew.at>
	<CDA64243-36FD-407D-8707-2440E5A7C86B@arin.net>
Message-ID: <CAMfXtQw9Kyqsbn3F8oZAU9WMjjcYunsOw90=nruaTU8cWQU1Zg@mail.gmail.com>

On Fri, Mar 21, 2014 at 6:39 AM, John Curran <jcurran at arin.net> wrote:
......
> Matthew -
>
> A typical example
.....
> At this point, some number of requesters will abandon the process.

I can, for some values of understanding, understand this.

But I think that is a failure by the requester, not ARIN,
and we should not change ARIN because the requester
wants it to be easy to do what they want to do, whenever
they want to do it, however they want to do it.

History/Background/Reasoning:

At a previous $dayjob$, it took quite some time to pull together
a change.  We had legacy resources, and therefore no formal
contract with ARIN.  At one point, we needed to get the
records accurate (for internal reasons, not due to M&A).

Over the (10-15) years since the records had last been
touched:

* We (well, USPS) had changed our mailing address
* We (well, PacBell) had changed our area code
* We (well, the funding agency) had decided to
  change our organizational name
* We (as part of the previous item) had "mostly"
  changed all the local business records, which
  meant there were few records under the old name
* Everyone who was named on the original ARIN records
  had moved on, and contact to/by those individuals
  was not viable.
* The only thing we had not done was relocate
  (but, of course, the mailing address change sort
  of suggested we might have).

The issue was that since ARIN services were "free",
and managed (really informally) out of the IT group,
it had never occurred to the people in the business
office (who coordinated all these changes with the
local authorities, and the businesses that we had
contracts with), and the local IT people did not choose
to be bothered with updating records they did not
have to update (things worked OK, why do anything?)

ARIN, in my mind, quite legitimately looked at my
request to update the records with some level of
questioning.  Sure, I wished ARIN had just taken
my word for everything (I am an upstanding honest
guy, trust me :-).  Eventually, thanks to the excellent
ARIN staff, we did manage to update our records,
but it took a lot of elapsed time, and pulling together
what documentation I could find was not (always)
easy (and the business office people who had dealt
with other contract updates and documentation at
the time of the previous changes had also moved on.
A query to the current staff went something like
"What change of business documentation?")

Whose "fault" was this?  Actually, it was the IT
departments staff informal processes for what should
always have been a formal process for keeping the
records accurate.  Just like other business records.

Now that we (well, they, I was surplussed) have a
formal contract with ARIN (I also spent many many
many hours regarding the LRSA, which consul
eventually agreed was goodness) I suspect that they
(the business office) will keep the business records
more accurate should other changes occur.

<soapbox>

Any M&A, or organization changes, have a cost
regarding business records, and it is incumbent
on the organization to be prepared to pay that cost
for changes.  Updating ARIN records (and the cost
of doing so) is no different, and should not have a
special "out" just because it can be take time or
the people involved did/do not want to invest that
effort.  The days of informal handshake number
deals are (or should be) long over.  Get over it, and
do the (boring, painful, but necessary) work.

</soapbox>

Gary


From jcurran at arin.net  Fri Mar 21 13:05:02 2014
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Mar 2014 17:05:02 +0000
Subject: [arin-ppml] 2014-3 Remove 8.2/8.3/8.4 Minimum IPv4 Block Size
 Requirements
In-Reply-To: <1A2FA24B-7CAC-44CA-BF1B-C1000F22550C@virtualized.org>
References: <EEAF2ECA-34C8-46B5-B1B6-732C2E973A80@delong.com>
	<806302acf0fa45c593dc20cb785190d8@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz59DP_Ain-LA6dQydfZQ=N7RZMjooK33qw+BJgoH8TYOg@mail.gmail.com>
	<65cd83e3fd62420b99761e94d1f939ae@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAGkMwz5F7zEuHYuifD=suXuD6b_Ddtv0AsTbLZOHeoNj57vRTA@mail.gmail.com>
	<d61a4224ffc0481084b2828a0dca8ac4@DM2PR03MB398.namprd03.prod.outlook.com>
	<8B067E70-3424-45F3-A49F-C90F7417E82D@arin.net>
	<1A2FA24B-7CAC-44CA-BF1B-C1000F22550C@virtualized.org>
Message-ID: <0D10B6D1-C7A9-4006-8287-4935D8C32A34@arin.net>

On Mar 21, 2014, at 2:56 PM, David Conrad <drc at virtualized.org> wrote:

> On Mar 19, 2014, at 11:47 AM, John Curran <jcurran at arin.net> wrote:
>>> Also, I believe ARIN is the wrong place for such constraints.  I believe operators should make the decision on such matters
>> 
>> I also believe that operators should set such constraints (if desired),
> 
> They do. It's called "prefix length filters". 

Indeed... They can individually decide which routes to accept, 
and that may be deemed sufficient by the community such that 
nothing is needed in ARIN number resource policy (or not)

>> by participation in the regional policy development process.
> 
> Out of curiosity, what percentage of ASes being announced on the Internet participate in ARIN regional policy development processes?  

100% of those who are interested in doing so, just all of those who 
are interested may participate in the ICANN DNS registry consensus 
policy development...

You may want to use your domain name any way you want, but you are 
still bound the DNS registry consensus policies, even if you opted
not to participate in their development - 
<http://www.icann.org/en/resources/registrars/consensus-policies>

Out of curiosity, do you know what percentage of domain name holders
participate in the ICANN consensus policy development processes?  

The entire Internet identifier registry system is based on community-
based policy development, and while not everyone participates, the 
key point is making sure that everyone has the ability to do so.

Thanks!
/John

John Curran
President and CEO
ARIN







From owen at delong.com  Fri Mar 21 12:58:15 2014
From: owen at delong.com (Owen DeLong)
Date: Fri, 21 Mar 2014 09:58:15 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
	RSA and 8.2 Utilization Requirements
In-Reply-To: <532BD660.6020508@matthew.at>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>	<532B5858.3070602@linuxmagic.com>
	<28886CBB-A67E-4A6D-842B-939A2D6E9931@delong.com>
	<532BD660.6020508@matthew.at>
Message-ID: <A4A11577-2C52-4BF8-A3AD-1C1DF1FB5C5A@delong.com>


On Mar 20, 2014, at 23:04 , Matthew Kaufman <matthew at matthew.at> wrote:

> On 3/20/2014 3:11 PM, Owen DeLong wrote:
>> I think fear mongering about the ?usefulness of the registry? by those that seek to eliminate all policy enforcement in the registry should be seen for what it is and that we as a community must make a decision whether we want to have reasonable policies and a culture of cooperation, or, abandon that culture which has worked thus far and allow the regulatory chips to fall where they may when it becomes obvious that we are unwilling to attempt to regulate ourselves.
> 
> I don't see a *documented* 40% abandon rate on 8.2 transfer requests as "fear mongering". I strongly suspect that every single one of those abandoned requests is a case where a M&A *actually happened* and yet, because it was abandoned, the registry no longer accurately reflects that M&A activity. (I really can't imagine anyone who would simply, for entertainment value, file 8.2 M&A transfer requests when no M&A has occurred.)
> 

No, but I can imagine lots of people trying to structure an 8.3 transfer to look like an M&A and abandoning the 8.2 request when that fails.

> The longer this abandon rate stays high, the more incorrect entries in the registry will accumulate. Not "fear mongering", just fact.

Nothing has been presented as yet to indicate that taking this provision out of 8.2 would actually reduce the abandon rate of 8.2 transfers.

> The original author of the draft policy claims to have personal experience that suggests that one of the reasons these are getting abandoned is the language he seeks to remove. I guess I'd like to hear evidence that shows that the abandoned requests are getting abandoned entirely for some other reason before opposing this proposal. Until then, I support it.

Unfortunately, the author had access to information not available to the community at large as a result of his former position at ARIN and we have no way to independently verify or validate his claims, nor do we have any way to gain access to any contradictory information that may or may not exist in the same realm.

I'm not accusing the author of anything and I have always had tremendous respect for Mr. Huberman. As he mentioned in an earlier post, we consider each other friends. However, what you are asking for here is nearly impossible to deliver and I will say that Mr. Huberman's perspective, while informed by his experience, may not be entirely objective.

Owen



From jcurran at arin.net  Fri Mar 21 13:47:32 2014
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Mar 2014 17:47:32 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <532BD660.6020508@matthew.at>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<532B5858.3070602@linuxmagic.com>
	<28886CBB-A67E-4A6D-842B-939A2D6E9931@delong.com>
	<532BD660.6020508@matthew.at>
Message-ID: <C6EDC290-3071-4275-8DD2-16C495BADD98@arin.net>

On Mar 21, 2014, at 2:04 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> I don't see a *documented* 40% abandon rate on 8.2 transfer requests as "fear mongering". I strongly suspect that every single one of those abandoned requests is a case where a M&A *actually happened* and yet, because it was abandoned, the registry no longer accurately reflects that M&A activity. (I really can't imagine anyone who would simply, for entertainment value, file 8.2 M&A transfer requests when no M&A has occurred.)

Actually, as noted earlier, it is quite common for parties to 
start an transfer request when there is no M&A activity.  We 
get those from folks who are simply the contacts on an address 
block (which may or may not be legitimate depending on the actual
origin of the block, e.g. was it assigned to a DBA entity of the
contact which somehow has morphed over time and is now operating 
under another name?); it occurs when organizations that think 
they were permanently assigned address space from their ISP come
to "update it" to their most recent organization name; and it 
happens when companies come in to clean up their long-neglected
records, as was noted previously.  All of these may result in 
what looks to be an NRPM 8.2 transfer request without any actual
recent M&A activity.

In the case where there has been an actual M&A transfer, ARIN works
very hard (as Gary Buhrmaster noted in his earlier message) with the
requestor to get the records updated, and with out-of-date records
this can indeed involve several validation steps to make sure that 
we're not updating the registry in error.  There are also those 
who may get nervous during the registration service agreement and
utilization discussion who decide that the effort or risk is not
worth continuing the process.

None of this is a recommendation for keeping the present policy,
but simply to make sure that community understands how the 40% NRPM 
8.2 abandonment rate number covers quite a range of circumstances.  
Note that ARIN is unlikely to be able to provide any more detailed 
objective measures, as the counts of "those who actually had past
M&A activity and then abandoned due to the effort" compared to the 
counts of "those who claimed M&A activity and then abandoned due to 
the effort" (i.e. actually a hijacking deterred) are the same 
transaction when viewed from ARIN's side.

FYI,
/John

John Curran
President and CEO
ARIN











From Meows at techie.com  Fri Mar 21 17:04:27 2014
From: Meows at techie.com (Meows)
Date: Fri, 21 Mar 2014 14:04:27 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <532CA95B.5090001@techie.com>

As a watcher of this since it's inception I have to jump in here as this 
is getting way off the rails, gosh it is reminding me of the affordable 
health care act no one can afford.

Point one RE:

As an ARIN Hostmaster for 10 years, I saw a very high rate of legitimate transfers which were
abandoned by the requestor.  In turn, Whois did not get updated, and in most cases, remains
out of date today.

Think about that for a moment please:  legitimate M&A activity occurred, but Whois never
got updated.  That's a failure of the system. Why does it fail?

Please guys, this is simple programming, a 60 to 90 day check to see if 
it was indeed transferred.

Point Two RE:

  In some cases, some IP addresses are used, and others
are not, and they think that if ARIN finds that out, they are going to take the addresses away.

This is wrong on every level. One of the only free things ( in the since 
you buy a block of addresses and do what you want to with them) the 
human population has in the world and now it is going to be  divvy up 
like the school yard bully's candy. And then controlled.
This is not even in the ball park of the mission statement.

Rant off,
Christine




On 3/20/2014 1:48 PM, David Huberman wrote:
> In contrast to my friend Owen, not only do I believe there is a very serious issue, but I believe this
> proposal is necessary for ARIN to have any hope of being relevant in the years to come. I don't
> mean to use that kind of hyperbole, but the issue is very real from my viewpoint.  Allow me to
> explain.
>
> There are two different problems which this policy proposal solves.
>
> 1. Whois accuracy
> =============
>
> As an ARIN Hostmaster for 10 years, I saw a very high rate of legitimate transfers which were
> abandoned by the requestor.  In turn, Whois did not get updated, and in most cases, remains
> out of date today.
>
> Think about that for a moment please:  legitimate M&A activity occurred, but Whois never
> got updated.  That's a failure of the system. Why does it fail?
>
> The common scenario is straight forward:
>
> 	1. Company A buys company B.
> 	2. Company A submits a transfer request to ARIN to have the IP address and AS number
> 	registrations reflect that Company A is now the registrant.
> 	3. ARIN starts asking questions about the utilization of the number resources.
> 	4. Company A walks away from the transfer and never returns.
>
> Step 3 is the consistent problem.  In many cases, Company A never even submits the transfer
> request because they are scared off by step 3.   In some cases, it's because they don't KNOW
> how the IP addresses are being used.  In some cases, some IP addresses are used, and others
> are not, and they think that if ARIN finds that out, they are going to take the addresses away.
> In some cases, none of the addresses are used.  But Company A is expanding their network
> (or plans to) and wants to use the IP addresses of Company B which they now own.
>
> Current policy does not work for these common scenarios.  I conclude that having seen
> thousands of transfers cross through the ARIN ticket system and talked to these requestors
> over the phone for 10 years.
>
> The takeaway from the above is that Whois is not accurate, in part because ARIN policy
> demands justification for addresses which, regardless of whether Whois is updated or not,
> Company A is going to use.
>
> In December, the PPML list requested metrics from ARIN staff to show the extent of abandoned
> transfers.  The metrics provided were as follows:
>
> === 8.2 Transfer Request Stats
>
> 2011:
>
> 422 8.2 transfers requested
> 226 8.2 transfers approved (54%)
> 209 8.2 transfers completed (50%)
>
> 2012:
>
> 451 8.2 transfers requested
> 264 8.2 transfers approved (59%)
> 241 8.2 transfers completed (53%)
>
> 2013 YTD:
>
> 445 8.2 transfers requested
> 280 8.2 transfers approved (63%)
> 269 8.2 transfers completed (60%)
>
> If you review the thread in December, these stats generated a lot of discussion. I am among
> the many who believe that a 40% abandonment rate FOR LEGITIMATE M&A ACTIVITY belies
> a shortcoming in ARIN policy.  There's a barrier that must be removed, and my experience
> teaches me that it is the utilization requirements of NRPM 8.2.
>
> Now to the second problem.
>
>
> 2. Conflict with the RSA:
> ==================
>
> John Curran can give a more accurate and nuanced history, but as best I can recall, ARIN
> tried to bring more legacy registration holders into the registry system by offering a
> Legacy Registration Services Agreement.  One of the takeaways from that initial effort
> was that legacy registration holders were unwilling to sign any agreement which technically
> allowed ARIN to de-register address space that they had without their consent.
>
> One of the concessions made over time was language in the RSA documents which
> removed that concern; it prohibits ARIN from forcibly taking away space when the
> signer is in compliance with the other terms and conditions of the contract.
>
> This new language, however, directly conflicts with the plain language of the NRPM 8.2
> paragraph that this policy proposal seeks to remove.
>
> >From a business standpoint -- from the standpoint of actually running the registry of
> ARIN -- the paragraph I propose to be removed is NON-OPERATIONAL.  It cannot
> be enforced under the terms of the RSA.
>
> The community, therefore, I believe is compelled to address the conflict.
>
> I hope this summary helps.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Thursday, March 20, 2014 1:07 PM
> To: Heather Schiller
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements
>
>
> On Mar 20, 2014, at 13:01 , Heather Schiller <heather.skanks at gmail.com> wrote:
>
>
> As a shepherd for this proposal, I would like to solicit community feedback on the proposed text.
>
> Aside from the general support/against.. some things to consider:
>
> Do you concur with or have any comment on the problem statement?
>
> I do not concur with the problem statement.
>
>
> If you support the problem statement, do you support removing section 8.2 as the correct path for remediating this conflict?  Do you have other suggestions for how to handle this?
>
> No.
>
>
> If you are opposed, what concerns do you have about implementing this policy?
>
> I have previously stated my concerns. IMHO, this is yet another attempt to bypass the needs-basis and seeks to solve a problem which does not, in fact, exist.
>
> Owen
>
>
>
> Thanks,
> --Heather
>
>
> On Tue, Mar 4, 2014 at 3:12 PM, ARIN <info at arin.net> wrote:
> On 20 February 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization Requirements" as a Draft Policy.
>
> Draft Policy ARIN-2014-9 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_9.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-9 on the Public Policy Mailing List.
>
> 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-2014-9
> Resolve Conflict Between RSA and 8.2 Utilization Requirements
>
> Date: 4 March 2014
>
> Problem Statement:
>
> 8.2 transfer policy has utilization requirements at the time of the review of the transfer request.
>
> The RSA section 6 expressly forbids ARIN from de-registering blocks (in whole or in part) due to under-utilization or no-justification during transfer requests.
>
> This is a direct conflict.
>
> Return and aggregate are not done in collaboration; they are coerced by policy without the willing consent of the transfer parties.
>
> We should remove all utilization references from 8.2 language to ensure the policy is compliant with the RSA.
>
> Policy statement:
>
> Remove from 8.2:
> "In the event that number resources of the combined organizations are no longer justified under ARIN policy at the time ARIN becomes aware of the transaction, through a transfer request or otherwise, ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy."
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



From Timothy.S.Morizot at irs.gov  Fri Mar 21 17:51:47 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Fri, 21 Mar 2014 21:51:47 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CAMfXtQw9Kyqsbn3F8oZAU9WMjjcYunsOw90=nruaTU8cWQU1Zg@mail.gmail.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>
	<CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>
	<532BD7D6.4000901@matthew.at>
	<CDA64243-36FD-407D-8707-2440E5A7C86B@arin.net>
	<CAMfXtQw9Kyqsbn3F8oZAU9WMjjcYunsOw90=nruaTU8cWQU1Zg@mail.gmail.com>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A7517A9@MEM0200CP3XF04.ds.irsnet.gov>

Gary Buhrmaster wrote:
> <soapbox>
> 
> Any M&A, or organization changes, have a cost
> regarding business records, and it is incumbent
> on the organization to be prepared to pay that cost
> for changes.  Updating ARIN records (and the cost
> of doing so) is no different, and should not have a
> special "out" just because it can be take time or
> the people involved did/do not want to invest that
> effort.  The days of informal handshake number
> deals are (or should be) long over.  Get over it, and
> do the (boring, painful, but necessary) work.
> 
> </soapbox>

Thanks for that Gary. It clarified for me one of the things that's been bugging me in this discussion. I'm pretty much a pure IT guy and hate the process and paperwork BS. I tend to avoid it or let others do that aspect as much as possible without also allowing my projects to suffer. But as you say, some of that boring, painful work is simply necessary. Frankly, quite often making the effort to read and keep up with this list fits in that category.

Perhaps I've also absorbed some of the culture of the organization that's employed me for the last several decades. ;-)

I also had to get our registry records up to date once I discovered they weren't. Fortunately, we're still the same organization. And one of the POCs from the 90s was still working for us so we were able to update them ourselves. And when I saw and read the LRSA, I walked through the lengthy process of getting it approved and signed by our organization. It was mostly a no-brainer since it established formal and explicit rights and defined our relationship with the registry where previously that had been one-sided, implicit, and undefined.

I also sense something of a logical inconsistency. On the one hand, the registry is so valuable that the sky is falling because some are choosing not to keep their records up to date. On the other hand, the registry has so little value that resource holders won't expend the effort necessary to maintain their records if they have to suffer any inconvenience to do so. If the registry has value, then those who choose not to maintain their registration have diminished the value of the resources they hold. So the truth is probably somewhere in the middle, but I can't say I find the argument compelling. Given that ARIN will always have to perform due diligence to keep someone from hijacking a registration, there's a limit to how convenient they can make the process. As a result, there will always be those who choose to walk away, for whatever reason, instead.

It seems to me that the real benefit for removing needs-based allocations for 8.2 and legacy transfers (ARIN 2014-11) is more the ability to acquire IPv4 resources without demonstrating a needs basis in a post-IPv4 exhaustion world. It's not at all clear to me that either proposal will have significant impact on registry accuracy, but 2014-11, at least, would certainly free affected transfers from any needs basis requirements.

I don't really have a dog in that fight. My organization has the IPv4 resources it needs for the transition and it's not like our size dramatically changes over time. We're  a pretty stable enterprise organization. However, if we're going to do that, I do think we should simply drop the needs basis policy requirements altogether.

I would support a proposal to remove the words aggregate and reclaim from 8.2 since they may  both be out dated at this point. But I definitely don't support this proposal or 2014-11.

Thanks,

Scott


From jcurran at arin.net  Fri Mar 21 17:58:10 2014
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Mar 2014 21:58:10 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <532CA95B.5090001@techie.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<532CA95B.5090001@techie.com>
Message-ID: <312A0FBF-5C2D-4827-B478-6410A3D565DF@arin.net>

On Mar 22, 2014, at 5:04 AM, Meows <Meows at techie.com> wrote:

> As a watcher of this since it's inception I have to jump in here as this is getting way off the rails, gosh it is reminding me of the affordable health care act no one can afford.
> 
> Point one RE:
> 
> As an ARIN Hostmaster for 10 years, I saw a very high rate of legitimate transfers which were
> abandoned by the requestor.  In turn, Whois did not get updated, and in most cases, remains
> out of date today.
> 
> Think about that for a moment please:  legitimate M&A activity occurred, but Whois never
> got updated.  That's a failure of the system. Why does it fail?
> 
> Please guys, this is simple programming, a 60 to 90 day check to see if it was indeed transferred.
> 
> Point Two RE:
> 
> In some cases, some IP addresses are used, and others
> are not, and they think that if ARIN finds that out, they are going to take the addresses away.
> 
> This is wrong on every level. One of the only free things ( in the since you buy a block of addresses and do what you want to with them) the human population has in the world and now it is going to be  divvy up like the school yard bully's candy. And then controlled.
> This is not even in the ball park of the mission statement.
> 
> Rant off,
> Christine

Christine - 
 
  Thanks for your message! For clarity and to aid the folks who are working 
  on this policy proposal (Draft Policy ARIN-2014-9, which removes the need 
  for ARIN to seek utilization during M & M transfers), I take it that your 
  message is in support of adoption of the draft policy?

Thanks!
/John

John Curran
President and CEO
ARIN





From jcurran at arin.net  Fri Mar 21 18:08:22 2014
From: jcurran at arin.net (John Curran)
Date: Fri, 21 Mar 2014 22:08:22 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <312A0FBF-5C2D-4827-B478-6410A3D565DF@arin.net>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<532CA95B.5090001@techie.com>
	<312A0FBF-5C2D-4827-B478-6410A3D565DF@arin.net>
Message-ID: <BA132FBF-6403-4F98-AC2C-204D7749A050@arin.net>

On Mar 22, 2014, at 5:58 AM, John Curran <jcurran at arin.net> wrote:

> (Draft Policy ARIN-2014-9, which removes the need 
>  for ARIN to seek utilization during M & M transfers),

Apologies for the typo...  should read "M & A" (as in 
Merger and Acquisition address transfers per NRPM 8.2)

ARIN welcomes transfers of any candy-coated chocolates,
and does not seek utilization information...  :-)

/John

John Curran
President and CEO
ARIN



From farmer at umn.edu  Fri Mar 21 18:51:05 2014
From: farmer at umn.edu (David Farmer)
Date: Fri, 21 Mar 2014 17:51:05 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <CAMfXtQw9Kyqsbn3F8oZAU9WMjjcYunsOw90=nruaTU8cWQU1Zg@mail.gmail.com>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>	<CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>	<532BD7D6.4000901@matthew.at>	<CDA64243-36FD-407D-8707-2440E5A7C86B@arin.net>
	<CAMfXtQw9Kyqsbn3F8oZAU9WMjjcYunsOw90=nruaTU8cWQU1Zg@mail.gmail.com>
Message-ID: <532CC259.5020605@umn.edu>

On 3/21/14, 09:10 , Gary Buhrmaster wrote:
> <soapbox>
>
> Any M&A, or organization changes, have a cost
> regarding business records, and it is incumbent
> on the organization to be prepared to pay that cost
> for changes.  Updating ARIN records (and the cost
> of doing so) is no different, and should not have a
> special "out" just because it can be take time or
> the people involved did/do not want to invest that
> effort.  The days of informal handshake number
> deals are (or should be) long over.  Get over it, and
> do the (boring, painful, but necessary) work.
>
> </soapbox>

I very much agree, there is and almost certainly should be work involved.

So, yes with any M&A, or other organization change, you should have to 
the "Business Office" part of documenting business records associated 
with the change.  The rationale for this "Business Office" part is 
clear.  Its necessary to prevent fraudulent changes to resources, and 
ARIN has a clear fiduciary responsibility to ensure this happens 
correctly.

However, I do think it is a reasonable question to ask, should you also 
have to do the "technical" documentation that the paragraph in question 
requires as well?  Frequently, such an organizational change implies 
little to no technical change.  So, what is the rational for doing this 
"technical" reporting?  Let me be clear, I'm not saying there isn't a 
valid rationale, but I personally can't articulate it.  So, I'd 
appreciate it if someone would articulate a valid rationale for this 
"technical" reporting.

Thanks






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


From mueller at syr.edu  Fri Mar 21 23:08:41 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Sat, 22 Mar 2014 03:08:41 +0000
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
In-Reply-To: <532B0721.8050706@arin.net>
References: <532B0721.8050706@arin.net>
Message-ID: <fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>

I am at the ICANN 49 meeting in Singapore, where the "evolution of the IANA functions" was a topic of heavy discussion and debate, which included Assistant Secretary of Commerce Larry Strickling. 

Because the proposed transition raises a number of issues that could affect addressing, it's useful for this group to be aware of the proposed roadmap for the transition proposed by the Internet Governance Project. A short paper outlining our proposal is here:
Mueller, M. & Kuerbis, B. (2014, 03). Roadmap for globalizing IANA: Four principles and a proposal for reform http://www.internetgovernance.org/pdf/ICANNreformglobalizingIANAfinal.pdf 

Our proposal contrasts sharply with the views being circulated by a few leaders of the RIRs, but not debated among the members:
http://www.ripe.net/internet-coordination/news/industry-developments/the-ripe-community-and-the-evolution-of-the-iana-functions 

The key point of contrast between the proposals is the role of ICANN. The I* leaders are proposing to eliminate the accountability function that the IANA contract with NTIA brought with it, allowing ICANN to simply absorb them because it is presumably more "mature" and well-behaved than it was, say, 10 years ago. Our proposal calls for structural separation of the DNS-related IANA and root zone maintenance functions, which has better accountability and transparency features. 

Whatever one's view, the RIRs need to have a broader discussion of these issues among their members. A few staff members should not be allowed to speak for the RIR community as a whole. Further, the Commerce Department will require an open and consensual process before it will approve a transition plan 


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Thursday, March 20, 2014 11:20 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions

** This announcement was also sent to arin-announce at arin.net. Our 
apologies if you receive duplicate messages. ** 	

On Friday 14 March, the United States Government announced that it intends to transition oversight of key Internet functions (including the Internet Assigned Numbers Authority, or IANA) to the global multi-stakeholder community. It has asked ICANN to facilitate, in consultation with the global multi-stakeholder community, the development of a proposal for the transition.

Leaders of the I* Internet technical coordination organizations had met several times and in line with the Montevideo statement we had discussed some common principles for an evolution such as the one announced by the US Gov. Regular participants in those meeting, including their affiliated organizations, are noted here:
http://www.nro.net/news/statement-from-the-i-leaders-coordination-meeting

As outcome of their discussion, a common position was developed on the following points:

     * The roles of all Internet registry policy bodies stay unchanged. 
These bodies continue to hold policy authority for the protocol parameter, number, and name spaces, including responsibility to ensure the faithful registry implementation according to those policies.

     * The IETF, IAB, and RIRs are committed to the role of ICANN as the IANA protocol parameter and IP address registry operator.

     * ICANN reaffirms its commitment to implement all IANA registry functions in accordance with the respective policies. ICANN will also provide affirmations to all stakeholders (including governments) that all Internet registry policy bodies and ICANN itself will continue to use open and transparent processes.

The full text summarizing these points is included at the end of this email.

Separately, ICANN released a timeline that details its expectations of the multi-stakeholder consultation process. More information on these plans will undoubtedly come out of the upcoming ICANN Meeting in Singapore from 23-27 March. The timeline document is available here:
http://www.icann.org/en/about/agreements/iana/functions-transfer-process-14mar14-en.pdf

While this timeline focuses on ICANN meetings and events, it is clear that this process will not take place only in ICANN venues. The five RIR communities are key stakeholders in this process, and it is vital that we discuss these issues both within our regional communities and globally to ensure that our voices are heard and our concerns recognized. The stable, accurate and professional management of the IANA functions, including management of the global IP address pool, is fundamental to the operation of the Internet. It is important that we not lose sight of this fact as management of the IANA evolves to more faithfully reflect the multi-stakeholder nature of the Internet community.

In the ARIN community, these discussions will take place via the communication and discussion channels already in place, including the upcoming ARIN 33 meeting in Chicago this April. ARIN will continue to facilitate discussion and ensure that the output is effectively channeled into the global process.

If you have any thoughts, comments or questions at this time, I encourage you to raise them on ARIN's Public Policy mailing list, arin-ppml at arin.net.

If you aren't currently on this list, you can subscribe at: 
http://lists.arin.net/mailman/listinfo/arin-ppml

I look forward to receiving your input on the mailing list and to further discussion at ARIN 33.

Regards,

John Curran
President and CEO
American Registry for Internet Numbers (ARIN)


			*******

Agreed text by the Leaders of I* organizations:

In order to ensure global acceptance and affirmation of ICANN's role as administrator of the IANA functions, we are now pursuing the transition of USG's stewardship of the IANA functions from the USG to ICANN. The roles of all Internet registry policy bodies (such as the RIRs, IAB, IETF, ASO, ccNSO, ccTLD ROs, and gNSO) stay unchanged. These bodies continue to hold policy authority for the protocol parameter, number, and name spaces, including responsibility to ensure the faithful registry implementation according to those policies.

This transition from the USG has been envisaged since the early days of ICANN. It is now feasible due to the growing maturity of ICANN and other organisations in the Internet ecosystem. ICANN's structures and accountability mechanisms continue to evolve and advance guided by the AoC community reviews, including ATRT. In addition, ICANN will continue to embrace its aggressive roadmap to truly globalize its structures.

In order to operationalize the transition from USG, ICANN will engage with the Internet community in a bottom-up public consultation process to ensure appropriate accountability mechanisms. In addition, ICANN will work with the names, numbers, and protocol communities to formalize relationships, commitments, and mutual responsibilities.

When community stakeholders have input about the policies emanating from the names, numbers, and protocol communities, they would be directed to pursue their interests through the relevant Internet communities (such as the gNSO, ccNSO, ccTLD ROs, ASO, IAB, IETF, or the RIRs) and their mechanisms for consideration and potential redress.

The IETF, IAB, and RIRs are committed to open and transparent processes. 
They also are committed to the role of ICANN as the IANA protocol parameter and IP address registry operator. The accountability mechanisms for ICANN's administration of these core internet functions will provide escalation routes that assure the names, numbers, and protocol communities that if IANA's performance is lacking, those communities can pursue defined processes for improving performance, including pre-agreed independent 3rd party arbitration processes.

ICANN reaffirms its commitment to implement all IANA registry functions in accordance with the respective policies. ICANN will also provide affirmations to all stakeholders (including governments) from all Internet registry policy bodies and itself that all of us will use open and transparent processes.
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage 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 Timothy.S.Morizot at irs.gov  Fri Mar 21 23:59:39 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Sat, 22 Mar 2014 03:59:39 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-11: Improved Registry
 Accuracy	Proposal
In-Reply-To: <531633E0.50901@arin.net>
References: <531633E0.50901@arin.net>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A751822@MEM0200CP3XF04.ds.irsnet.gov>

And the discussions on 2014-9 today clarified the central thing that bothered me about this proposal.

> Section 2, Adds to "Definitions"
> 
> Legacy Internet Resource
> 
> Any Internet Resource obtained prior to or otherwise outside the
> current system of hierarchical distribution (by allocation or
> assignment) through the Regional Internet Registries.
> 
> Legacy Internet Resource Holder
> 
> The holder of a Legacy Internet Resource. Either by receiving these
> resources directly or by receiving (part of) Legacy Internet Resources
> from a Legacy Internet Resource Holder.

I do not agree with the above definitions. A set of numbers is just a set of numbers. Rather, if we're going to add formal definitions I would suggest something more like the following.

Legacy Internet Resource Holder

An organization that received a resource allocation prior to or
otherwise outside the current system of hierarchical distribution
(by allocation or assignment) through the Regional Internet Registries.

Legacy Internet Resource

A resource held by a Legacy Internet Resource Holder that was allocated
To the holder prior to or otherwise outside the current system
of hierarchical distribution (by allocation or assignment) through
the Regional Internet Registries.

I see no reason to assign special status to a number allocation independent of its association with the organization that obtained the legacy allocation. And I'm not at all convinced that this proposal is actually intended or designed to promote improved registry accuracy.

I will also note that if registry degradation reduces the value of IPv4 Internet numbers, I'm also not entirely convinced that's a bad thing. One of a number of my hats at work is the "IPv6 Transition Technical Lead" hat. (The title sounds more impressive than it actually is. I also have other impressive-sounding labels I rarely use associated with other hats I wear. I normally describe myself as "no-one of consequence" mostly to see who catches the joke.) So I'm neck deep, at least, in the IPv6 transition effort. (And we've done pretty well, I think. Most of our Internet-facing stuff is IPv6 enabled. Our "Trusted Internet Connection Access Points" or TICAPs are mostly dual-stacked for services in both directions. And we've IPv6 enabled our 13 largest sites with more to follow after filing season. We're at the point where we're actively discussing when we believe we can start removing IPv4 from portions of our enterprise network.) With that role in mind, I've supported proposals to raise the free pool allocation needs justification to two years to match  the transfer utilization policy. I would probably support reducing the needs-based requirements overall. (I don't think policy should let someone come in and request all of ARIN's free IPv4 and IPv6 pools just because, but I do think the IPv4 needs based rules could and should be greatly relaxed.) But I am not at all in favor of granting special status to legacy IPv4 resources once they leave the hands of the actual legacy holder. 

Basically, I don't believe that "legacy" resources should be treated any differently on the transfer market than non-legacy resources. Equal footing for all. And if people choose to cease using the registry and thus degrade the value and utility of those IPv4 resources, I'm not sure I have a problem with that scenario. I certainly don't think it's a crisis. In fact, I think anything that pushes the Internet toward IPv6 and away from the IPv4 swamp will end up being a plus in the long term.

So I don't support this proposal as written. I would consider a proposal that expanded the time frame for free pool allocations to match that of the transfer market or that eliminated all needs based criteria for all IPv4 transfers. But I don't support trying to carve out one subset of IPv4 resources for special treatment on the transfer market.

And while I fully support ARIN's position of providing free basic registry support to legacy resource holders with no contractual relationship with ARIN and thus contributing not even a nominal sum to support those services, I do not support making that basic support transferable simply because someone "acquires" a resource from someone who had originally obtained the allocation prior to ARIN's formation. Or because someone obtains a resource from someone who had obtained a resource ... ad nauseum. TANSTAAFL. I appreciation the registry and reverse DNS support ARIN provided us for years before we signed an LRSA agreement. I think they provide a valuable Internet service through that support. But I see no reason to make it a transferable burden on ARIN. Nor do I see any value provided to the Internet community by doing so.

Thanks,

Scott


 


From jcurran at arin.net  Sat Mar 22 00:09:58 2014
From: jcurran at arin.net (John Curran)
Date: Sat, 22 Mar 2014 04:09:58 +0000
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
In-Reply-To: <fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>
References: <532B0721.8050706@arin.net>
	<fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>
Message-ID: <06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>

On Mar 22, 2014, at 11:08 AM, Milton L Mueller <mueller at syr.edu> wrote:
> ...
> The key point of contrast between the proposals is the role of ICANN. The I* leaders are proposing to eliminate the accountability function that the IANA contract with NTIA brought with it, allowing ICANN to simply absorb them because it is presumably more "mature" and well-behaved than it was, say, 10 years ago. Our proposal calls for structural separation of the DNS-related IANA and root zone maintenance functions, which has better accountability and transparency features. 

Milton - 
 
  I would not characterize it quite as you did (i.e. "proposing to eliminate 
  the accountability function that the IANA contract with NTIA brought"), 
  particularly since the position clearly states "ICANN will engage with 
  the Internet community in a bottom-up public consultation process to ensure 
  appropriate accountability mechanisms"

  Your characterization: "eliminate the accountability"

  The actual statement: "ensure appropriate accountability mechanisms"

  It is true that the I* leader statement did _not_ include specific 
  mechanisms for accountability, as it was felt that was the type of 
  matter to be discussed among the Internet community. My apologies 
  if this did not come through as clear as it might otherwise have, 
  and for any confusion that may have resulted.

> Whatever one's view, the RIRs need to have a broader discussion of these issues among their members. A few staff members should not be allowed to speak for the RIR community as a whole. Further, the Commerce Department will require an open and consensual process before it will approve a transition plan 

  In the case of ARIN, the ARIN Board of Trustees was consulted to confirm
  that the statement was an appropriate position with which to start the 
  dialogue with the ARIN community.

  The ARIN announcement notes that "In the ARIN community, these discussions 
  will take place via the communication and discussion channels already in 
  place, including the upcoming ARIN 33 meeting in Chicago this April. ARIN 
  will continue to facilitate discussion and ensure that the output is 
  effectively channeled into the global process."

  We look forward to robust discussion on these matters at ARIN 33 next month 
  in Chicago, and I do appreciate you highlighting the importance of this topic 
  to the ARIN community.  There is little doubt that the proposed transition, 
  while helpful from the perspective of completed a long-awaited transition, 
  also has the potential for significant changes in the ecosystem in which 
  ARIN's mission is performed and therefore should be a topic of significant
  interest to the ARIN community.

Thanks!
/John

John Curran
President and CEO
ARIN






From dogwallah at gmail.com  Sat Mar 22 01:19:55 2014
From: dogwallah at gmail.com (McTim)
Date: Sat, 22 Mar 2014 01:19:55 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-11: Improved Registry
	Accuracy Proposal
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A751822@MEM0200CP3XF04.ds.irsnet.gov>
References: <531633E0.50901@arin.net>
	<968C470DAC25FB419E0159952F28F0C06A751822@MEM0200CP3XF04.ds.irsnet.gov>
Message-ID: <CACAaNxhZ6ERHD1EpCwQ8_RSg7eb6V5e=Tv7CvvtTZvp5f-8cwA@mail.gmail.com>

On Fri, Mar 21, 2014 at 11:59 PM, Morizot Timothy S <
Timothy.S.Morizot at irs.gov> wrote:

> And the discussions on 2014-9 today clarified the central thing that
> bothered me about this proposal.
>
>
<snip>


>
> And while I fully support ARIN's position of providing free basic registry
> support to legacy resource holders with no contractual relationship with
> ARIN and thus contributing not even a nominal sum to support those
> services, I do not support making that basic support transferable simply
> because someone "acquires" a resource from someone who had originally
> obtained the allocation prior to ARIN's formation. Or because someone
> obtains a resource from someone who had obtained a resource ... ad nauseum.
> TANSTAAFL. I appreciation the registry and reverse DNS support ARIN
> provided us for years before we signed an LRSA agreement. I think they
> provide a valuable Internet service through that support. But I see no
> reason to make it a transferable burden on ARIN. Nor do I see any value
> provided to the Internet community by doing so.
>


Well said Scott!



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



-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A route
indicates how we get there."  Jon Postel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140322/ee87accb/attachment.htm>

From mueller at syr.edu  Sat Mar 22 21:24:48 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Sun, 23 Mar 2014 01:24:48 +0000
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
In-Reply-To: <06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>
References: <532B0721.8050706@arin.net>
	<fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>
	<06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>
Message-ID: <a5982e5a18094672b3ddafaa049cb947@EX13-MBX-13.ad.syr.edu>



-----Original Message-----
From: John Curran [mailto:jcurran at arin.net] 

>  Your characterization: "eliminate the accountability"
>  The actual statement: "ensure appropriate accountability mechanisms"

The end of the IANA contract WILL eliminate the accountability that comes with NTIA as principal of the IANA contract and ICANN as agent. Factual and definite. 

In the I* statement, "ensure appropriate accountability mechanisms" is just a bunch of words in a statement. At best, it is a declaration of your intention to do something - as yet unspecified - to address the issue. So my characterization is accurate. The only known form of external accountability is being eliminated, and not replaced with anything definite.

What's especially telling, however, is that in your plan accountability is basically an afterthought, something that will, if we are lucky, be bolted on to the architecture of your solution. In the IGP plan, accountability via structural separation is at the core of the architecture. 



From jcurran at arin.net  Sat Mar 22 22:09:29 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 23 Mar 2014 02:09:29 +0000
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
In-Reply-To: <a5982e5a18094672b3ddafaa049cb947@EX13-MBX-13.ad.syr.edu>
References: <532B0721.8050706@arin.net>
	<fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>
	<06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>
	<a5982e5a18094672b3ddafaa049cb947@EX13-MBX-13.ad.syr.edu>
Message-ID: <203257DB-0E2F-4289-A837-1CB1F74A18D4@arin.net>

On Mar 23, 2014, at 9:24 AM, Milton L Mueller <mueller at syr.edu> wrote:
> -----Original Message-----
> From: John Curran [mailto:jcurran at arin.net] 
> 
>> Your characterization: "eliminate the accountability"
>> The actual statement: "ensure appropriate accountability mechanisms"
> 
> The end of the IANA contract WILL eliminate the accountability that comes with NTIA as principal of the IANA contract and ICANN as agent. Factual and definite. 
> 
> In the I* statement, "ensure appropriate accountability mechanisms" is just a bunch of words in a statement. At best, it is a declaration of your intention to do something - as yet unspecified - to address the issue.

Correct.  We will need the community to specify what is necessary for 
accountability mechanisms.

> So my characterization is accurate. The only known form of external accountability is being eliminated, and not replaced with anything definite.

Milton - Please do not mischaracterize the statement as a declaration 
that accountability mechanisms have been considered and deemed sufficient,
since that is not what it says...  I am actually quite proud of the fact 
that the I* statement did not judge the current accountability measures, 
or suggest specific accountability mechanisms, as those are matters for 
the community to consider.

> What's especially telling, however, is that in your plan accountability is basically an afterthought, something that will, if we are lucky, be bolted on to the architecture of your solution. In the IGP plan, accountability via structural separation is at the core of the architecture. 

Actually, the question of the NTIA IANA contract transition does raise 
a valid question about how we demonstrate the accountability of the 
entire system to the global Internet community.  I believe this means 
that we'll need to have a discussion specifically of IANA accountability 
(with respect to performance of the actual IANA functions) and also a 
discussion of overall ICANN system accountability, dealing more with 
the indirect accountability issues that may arise NTIA transition of 
oversight.

I believe that your efforts here are not disjoint with the discussions 
which need to occur, but simply ahead of the process by a short number
of days.  I am attending ICANN this week in Singapore predominantly to
gain an understanding of the process which will be launched, and hope
to have more information to share with the ARIN community by mid-week.

Thanks!
/John

John Curran
President and CEO
ARIN




From louie at louie.net  Sun Mar 23 01:57:23 2014
From: louie at louie.net (Louie Lee)
Date: Sun, 23 Mar 2014 13:57:23 +0800
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
In-Reply-To: <06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>
References: <532B0721.8050706@arin.net>
	<fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>
	<06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>
Message-ID: <5469AA99-DC18-4B1F-989A-D2BB44305616@louie.net>

Thank you, Milton and John, for your thoughts.  I have some to add inline....

On Mar 22, 2014, at 12:09 PM, John Curran <jcurran at arin.net> wrote:
> 

> On Mar 22, 2014, at 11:08 AM, Milton L Mueller <mueller at syr.edu> wrote:
>> ...
>> The key point of contrast between the proposals is the role of ICANN. The I* leaders are proposing to eliminate the accountability function that the IANA contract with NTIA brought with it, allowing ICANN to simply absorb them because it is presumably more "mature" and well-behaved than it was, say, 10 years ago. Our proposal calls for structural separation of the DNS-related IANA and root zone maintenance functions, which has better accountability and transparency features.
> 
> Milton - 
> 
>  I would not characterize it quite as you did (i.e. "proposing to eliminate 
>  the accountability function that the IANA contract with NTIA brought"), 
>  particularly since the position clearly states "ICANN will engage with 
>  the Internet community in a bottom-up public consultation process to ensure 
>  appropriate accountability mechanisms"
> 
>  Your characterization: "eliminate the accountability"
> 
>  The actual statement: "ensure appropriate accountability mechanisms"
> 
>  It is true that the I* leader statement did _not_ include specific 
>  mechanisms for accountability, as it was felt that was the type of 
>  matter to be discussed among the Internet community. My apologies 
>  if this did not come through as clear as it might otherwise have, 
>  and for any confusion that may have resulted.

Milton,

I might add that the assertion that anyone is allowing ICANN to "simply absorb" the accountability function trivializes the large amount of work that the community must do in order to create a proposal for strengthened accountability mechanisms that would be acceptable to NTIA for the transition to be approved.  As the whole of ICANN matures, we are seeing the community taking a larger role in working together to hold the ICANN Board and staff accountable in their execution of policies for DNS and number resources.

Tomorrow morning, you will see a proposal by ICANN CEO Fadi Chehad? pitch a first draft of a way that the community can go about developing the accountability mechanisms that are required.  These mechanisms must be adopted by the community in a bottom-up, multistakeholder manner for them to be part of a viable proposal.

For folks in North America, this will be Sunday evening/night.  Please join us:

http://singapore49.icann.org/en/schedule/mon-globalization-advisory

>> Whatever one's view, the RIRs need to have a broader discussion of these issues among their members. A few staff members should not be allowed to speak for the RIR community as a whole. Further, the Commerce Department will require an open and consensual process before it will approve a transition plan
> 
>  In the case of ARIN, the ARIN Board of Trustees was consulted to confirm
>  that the statement was an appropriate position with which to start the 
>  dialogue with the ARIN community.

In addition, there are a number of RIR Board members and numbering community members here at the ICANN meeting ready to pitch in.  I am here not only as a member-elected representative of the ARIN and NANOG communities, but also as the Chair of the Address Council of the ICANN Address Supporting Organization.  You will find me next to an RIR CEO on stage tomorrow representing the numbering community reminding everyone what the 2nd "N" in ICANN stands for.

We recognize that both the ICANN community and the numbering communities each have divergent views.  We will have an opportunity to demonstrate how our multistakeholder concepts are implemented in the RIR system, and how the RIR staffs and Boards are held accountable for their actions.  Perhaps the ICANN community can take the best features and make it work to "globalize" the accountability of IANA functions at ICANN.

Yours,
Louie Lee
Chair
ICANN ASO Address Council
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140323/7d613967/attachment.htm>

From louie at louie.net  Sun Mar 23 11:10:29 2014
From: louie at louie.net (Louie Lee)
Date: Sun, 23 Mar 2014 23:10:29 +0800
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
In-Reply-To: <5469AA99-DC18-4B1F-989A-D2BB44305616@louie.net>
References: <532B0721.8050706@arin.net>
	<fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>
	<06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>
	<5469AA99-DC18-4B1F-989A-D2BB44305616@louie.net>
Message-ID: <3FC97F06-6F80-4D40-9392-BB8EB02D0FBD@louie.net>

Dear Milton,

I do have just a few things to add.  First, a correction.

I was premature in stating that the numbering community will be represented on stage by Adiel & myself.  The session flow had not been finalized.  Instead, Adiel and myself, along with other numbering community folks, will mostly sit with the rest of the ICANN community to listen to all the contributions that you and all others have on how such an IANA accountability transition might take place.  Each of us will also contribute only in our own capacities because substantial dialog in the communities have yet to take place.

I believe that I was also premature in saying that Fadi will offer a draft....  The development of the proposal must be led by the community completely.  ICANN staff's role is to gather the input and facilitate dialog by documenting the input and summarizing it when appropriate.  You will hear tomorrow morning that the role of the staff and Board will be considerably different from they way that input is handled for typical topics.

And finally, I apologize if you or anyone else believe that I don't think you also represent the numbering community in a less than significant way.  While you & I might be contributing to this effort so far on your own behalves, you are also doing so as an elected member of the numbering community, which carries with it a recognition of your involvement and contribution thus far.

See you tomorrow.  I look forward to hearing your input in this kickoff session.

Yours,
Louie

On Mar 23, 2014, at 1:57 PM, Louie Lee <louie at louie.net> wrote:

> Tomorrow morning, you will see a proposal by ICANN CEO Fadi Chehad? pitch a first draft of a way that the community can go about developing the accountability mechanisms that are required.  These mechanisms must be adopted by the community in a bottom-up, multistakeholder manner for them to be part of a viable proposal.
> 
> For folks in North America, this will be Sunday evening/night.  Please join us:
> 
> http://singapore49.icann.org/en/schedule/mon-globalization-advisory

[snip]

> In addition, there are a number of RIR Board members and numbering community members here at the ICANN meeting ready to pitch in.  I am here not only as a member-elected representative of the ARIN and NANOG communities, but also as the Chair of the Address Council of the ICANN Address Supporting Organization.  You will find me next to an RIR CEO on stage tomorrow representing the numbering community reminding everyone what the 2nd "N" in ICANN stands for.
> 
> We recognize that both the ICANN community and the numbering communities each have divergent views.  We will have an opportunity to demonstrate how our multistakeholder concepts are implemented in the RIR system, and how the RIR staffs and Boards are held accountable for their actions.  Perhaps the ICANN community can take the best features and make it work to "globalize" the accountability of IANA functions at ICANN.
> 
> Yours,
> Louie Lee
> Chair
> ICANN ASO Address Council

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

From hannigan at gmail.com  Sun Mar 23 15:44:26 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Sun, 23 Mar 2014 15:44:26 -0400
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
In-Reply-To: <3FC97F06-6F80-4D40-9392-BB8EB02D0FBD@louie.net>
References: <532B0721.8050706@arin.net>
	<fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>
	<06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>
	<5469AA99-DC18-4B1F-989A-D2BB44305616@louie.net>
	<3FC97F06-6F80-4D40-9392-BB8EB02D0FBD@louie.net>
Message-ID: <CAMDXq5P6bjxo9Vr+pD6DByJabjpv1nJpYdF3gtHLV4V708ZniQ@mail.gmail.com>

Louie,

What elected position in NANOG do you hold? I'm confused. I think it's
a big stretch claiming you also represent NANOG.

NANOG has a duly elected board that represents its members and may, or
may not, make statements on their behalf. Care to clarify?

Best,

-M<



On Sun, Mar 23, 2014 at 11:10 AM, Louie Lee <louie at louie.net> wrote:
> Dear Milton,
>
> I do have just a few things to add.  First, a correction.
>
> I was premature in stating that the numbering community will be represented
> on stage by Adiel & myself.  The session flow had not been finalized.
> Instead, Adiel and myself, along with other numbering community folks, will
> mostly sit with the rest of the ICANN community to listen to all the
> contributions that you and all others have on how such an IANA
> accountability transition might take place.  Each of us will also contribute
> only in our own capacities because substantial dialog in the communities
> have yet to take place.
>
> I believe that I was also premature in saying that Fadi will offer a
> draft....  The development of the proposal must be led by the community
> completely.  ICANN staff's role is to gather the input and facilitate dialog
> by documenting the input and summarizing it when appropriate.  You will hear
> tomorrow morning that the role of the staff and Board will be considerably
> different from they way that input is handled for typical topics.
>
> And finally, I apologize if you or anyone else believe that I don't think
> you also represent the numbering community in a less than significant way.
> While you & I might be contributing to this effort so far on your own
> behalves, you are also doing so as an elected member of the numbering
> community, which carries with it a recognition of your involvement and
> contribution thus far.
>
> See you tomorrow.  I look forward to hearing your input in this kickoff
> session.
>
> Yours,
> Louie
>
> On Mar 23, 2014, at 1:57 PM, Louie Lee <louie at louie.net> wrote:
>
> Tomorrow morning, you will see a proposal by ICANN CEO Fadi Chehad? pitch a
> first draft of a way that the community can go about developing the
> accountability mechanisms that are required.  These mechanisms must be
> adopted by the community in a bottom-up, multistakeholder manner for them to
> be part of a viable proposal.
>
> For folks in North America, this will be Sunday evening/night.  Please join
> us:
>
> http://singapore49.icann.org/en/schedule/mon-globalization-advisory
>
>
> [snip]
>
> In addition, there are a number of RIR Board members and numbering community
> members here at the ICANN meeting ready to pitch in.  I am here not only as
> a member-elected representative of the ARIN and NANOG communities, but also
> as the Chair of the Address Council of the ICANN Address Supporting
> Organization.  You will find me next to an RIR CEO on stage tomorrow
> representing the numbering community reminding everyone what the 2nd "N" in
> ICANN stands for.
>
> We recognize that both the ICANN community and the numbering communities
> each have divergent views.  We will have an opportunity to demonstrate how
> our multistakeholder concepts are implemented in the RIR system, and how the
> RIR staffs and Boards are held accountable for their actions.  Perhaps the
> ICANN community can take the best features and make it work to "globalize"
> the accountability of IANA functions at ICANN.
>
> Yours,
> Louie Lee
> Chair
> ICANN ASO Address Council
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From mueller at syr.edu  Sun Mar 23 22:26:00 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Mon, 24 Mar 2014 02:26:00 +0000
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
In-Reply-To: <3FC97F06-6F80-4D40-9392-BB8EB02D0FBD@louie.net>
References: <532B0721.8050706@arin.net>
	<fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>
	<06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>
	<5469AA99-DC18-4B1F-989A-D2BB44305616@louie.net>
	<3FC97F06-6F80-4D40-9392-BB8EB02D0FBD@louie.net>
Message-ID: <b84fe3fa8dab4a34847a894a8a21dcb5@EX13-MBX-13.ad.syr.edu>

Thanks, Louie, for your insight into the process. It is good to see you levelling with us.
I am sitting in the Padang room Monday morning in Singapore and in an hour and a half the discussion will begin.
See you around!
--MM

From: Louis Lee [mailto:louienet at gmail.com] On Behalf Of Louie Lee
Sent: Sunday, March 23, 2014 11:10 AM
To: Milton L Mueller
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN and the Evolution of the IANA Functions

Dear Milton,

I do have just a few things to add.  First, a correction.

I was premature in stating that the numbering community will be represented on stage by Adiel & myself.  The session flow had not been finalized.  Instead, Adiel and myself, along with other numbering community folks, will mostly sit with the rest of the ICANN community to listen to all the contributions that you and all others have on how such an IANA accountability transition might take place.  Each of us will also contribute only in our own capacities because substantial dialog in the communities have yet to take place.

I believe that I was also premature in saying that Fadi will offer a draft....  The development of the proposal must be led by the community completely.  ICANN staff's role is to gather the input and facilitate dialog by documenting the input and summarizing it when appropriate.  You will hear tomorrow morning that the role of the staff and Board will be considerably different from they way that input is handled for typical topics.

And finally, I apologize if you or anyone else believe that I don't think you also represent the numbering community in a less than significant way.  While you & I might be contributing to this effort so far on your own behalves, you are also doing so as an elected member of the numbering community, which carries with it a recognition of your involvement and contribution thus far.

See you tomorrow.  I look forward to hearing your input in this kickoff session.

Yours,
Louie

On Mar 23, 2014, at 1:57 PM, Louie Lee <louie at louie.net<mailto:louie at louie.net>> wrote:


Tomorrow morning, you will see a proposal by ICANN CEO Fadi Chehad? pitch a first draft of a way that the community can go about developing the accountability mechanisms that are required.  These mechanisms must be adopted by the community in a bottom-up, multistakeholder manner for them to be part of a viable proposal.

For folks in North America, this will be Sunday evening/night.  Please join us:

http://singapore49.icann.org/en/schedule/mon-globalization-advisory

[snip]


In addition, there are a number of RIR Board members and numbering community members here at the ICANN meeting ready to pitch in.  I am here not only as a member-elected representative of the ARIN and NANOG communities, but also as the Chair of the Address Council of the ICANN Address Supporting Organization.  You will find me next to an RIR CEO on stage tomorrow representing the numbering community reminding everyone what the 2nd "N" in ICANN stands for.

We recognize that both the ICANN community and the numbering communities each have divergent views.  We will have an opportunity to demonstrate how our multistakeholder concepts are implemented in the RIR system, and how the RIR staffs and Boards are held accountable for their actions.  Perhaps the ICANN community can take the best features and make it work to "globalize" the accountability of IANA functions at ICANN.

Yours,
Louie Lee
Chair
ICANN ASO Address Council

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

From jcurran at arin.net  Mon Mar 24 03:47:06 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 24 Mar 2014 07:47:06 +0000
Subject: [arin-ppml] TIMELY - Request for expedited input to IANA plan
 development process (was: ARIN and the Evolution of the IANA Functions)
In-Reply-To: <532B0721.8050706@arin.net>
References: <532B0721.8050706@arin.net>
Message-ID: <8E1240AB-68D1-4B93-8186-D23EE41BB9F7@arin.net>

On Mar 20, 2014, at 11:20 PM, ARIN <info at arin.net> wrote:

> Separately, ICANN released a timeline that details its expectations of the multi-stakeholder consultation process. More information on these plans will undoubtedly come out of the upcoming ICANN Meeting in Singapore from 23-27 March. The timeline document is available here:
> http://www.icann.org/en/about/agreements/iana/functions-transfer-process-14mar14-en.pdf

Today at ICANN 49 in Singapore, there was a session which discussed the 
need to develop an IANA Accountability plan, as it will be necessary to
provide NTIA with a community-wide plan for transition of the oversight 
duties which they presently perform.

ICANN is coordinating the effort to develop this plan for IANA transition,
and the first step is establishing a formal timeline and process for plan 
development.

ICANN has provided a mail list for expedited input on the _process_ to be 
used for IANA transition plan development. This includes items such as 
feedback on the timeline document noted above, engagement processes, etc.

The list is here: <ianatransition at icann.org>  (An public archive is also 
available here: <http://mm.icann.org/pipermail/ianatransition/>)

The goal is to gather the input by 27 March 2014, and then combine the 
mail list discussion and the discussions happening at ICANN 49, with
the resulting timeline and next steps to be released for public comment 
and community feedback on 7 April 2014.

If you have specific views on the process for development of the IANA 
transition plan, please contribute promptly.

Thank you!
/John

John Curran
President and CEO
ARIN



From louie at louie.net  Mon Mar 24 06:43:50 2014
From: louie at louie.net (Louie Lee)
Date: Mon, 24 Mar 2014 18:43:50 +0800
Subject: [arin-ppml] ARIN and the Evolution of the IANA Functions
In-Reply-To: <b84fe3fa8dab4a34847a894a8a21dcb5@EX13-MBX-13.ad.syr.edu>
References: <532B0721.8050706@arin.net>
	<fc92ac16ad3e47c8b73a325eb54dfc14@EX13-MBX-13.ad.syr.edu>
	<06DCE788-E4AD-4C47-83A5-551FD0A2BFA0@arin.net>
	<5469AA99-DC18-4B1F-989A-D2BB44305616@louie.net>
	<3FC97F06-6F80-4D40-9392-BB8EB02D0FBD@louie.net>
	<b84fe3fa8dab4a34847a894a8a21dcb5@EX13-MBX-13.ad.syr.edu>
Message-ID: <B47E8486-2D76-4D76-A29F-95E39DBF6AED@louie.net>

On Mar 24, 2014, at 10:26 AM, Milton L Mueller <mueller at syr.edu> wrote:

> Thanks, Louie, for your insight into the process. It is good to see you levelling with us.

Of course, Milton.  There is no intention to mislead; I can certainly help facilitate the communication of updates and changes as they happen.

And I hope you agree with me in that the activities are happening really quickly -- so much so that the Chairs of the various ICANN Supporting Organizations and Advisory Councils insisted on several things:

That the Chairs be described today as "facilitators" rather than "leaders" in order to give focus to the community input rather than have the Chairs offer anything in a top-down manner this early in the process.  (It's with this thought that Fadi did not present any sort of draft or suggestion for a process.)

That it is highlighted that none of us had the chance to consult with nor receive any sort of substantial input from our respective communities.  Any opinion that we might offer is purely our own and not any sort of consensus positions.

The input of the Chairs on stage this morning would be limited to describing the PDPs in use in our respective communities so as to educate the community on the various mechanisms in place.

> I am sitting in the Padang room Monday morning in Singapore and in an hour and a half the discussion will begin.

And thank you for your input today!  I look forward to further discussion with you to make sure that I don't misunderstand your points and the concerns behind them.  I would urge you to document your input fully by emailing it to the address posted on ICANN's webpage on this topic:

	http://www.icann.org/en/about/agreements/iana/transition

And I would also urge the rest of the ARIN community (and the members of other stakeholder groups) send in their input. The deadline for initial input is this Thursday!  The email address is:

	ianatransition at icann.org

Louie

P.S. You saw that I ended up on stage with Adiel on a last minute change.  It was still planned that we would return to our seats to sit with our communities after our PDP descriptions.  When given the chance to leave the stage, we ended up staying, but with no intent to lead the discussion afterwards.  However, we were careful to not respond to input; it was important at this point to receive as much input as possible from the community in the short amount of time, and we did not want our opinions be misunderstood as coming from our communities.

> See you around!
> --MM
>  
> From: Louis Lee [mailto:louienet at gmail.com] On Behalf Of Louie Lee
> Sent: Sunday, March 23, 2014 11:10 AM
> To: Milton L Mueller
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] ARIN and the Evolution of the IANA Functions
>  
> Dear Milton,
>  
> I do have just a few things to add.  First, a correction.
>  
> I was premature in stating that the numbering community will be represented on stage by Adiel & myself.  The session flow had not been finalized.  Instead, Adiel and myself, along with other numbering community folks, will mostly sit with the rest of the ICANN community to listen to all the contributions that you and all others have on how such an IANA accountability transition might take place.  Each of us will also contribute only in our own capacities because substantial dialog in the communities have yet to take place.
>  
> I believe that I was also premature in saying that Fadi will offer a draft....  The development of the proposal must be led by the community completely.  ICANN staff's role is to gather the input and facilitate dialog by documenting the input and summarizing it when appropriate.  You will hear tomorrow morning that the role of the staff and Board will be considerably different from they way that input is handled for typical topics.
>  
> And finally, I apologize if you or anyone else believe that I don't think you also represent the numbering community in a less than significant way.  While you & I might be contributing to this effort so far on your own behalves, you are also doing so as an elected member of the numbering community, which carries with it a recognition of your involvement and contribution thus far.
>  
> See you tomorrow.  I look forward to hearing your input in this kickoff session.
>  
> Yours,
> Louie
>  
> On Mar 23, 2014, at 1:57 PM, Louie Lee <louie at louie.net> wrote:
> 
> 
> Tomorrow morning, you will see a proposal by ICANN CEO Fadi Chehad? pitch a first draft of a way that the community can go about developing the accountability mechanisms that are required.  These mechanisms must be adopted by the community in a bottom-up, multistakeholder manner for them to be part of a viable proposal.
>  
> For folks in North America, this will be Sunday evening/night.  Please join us:
>  
> http://singapore49.icann.org/en/schedule/mon-globalization-advisory
>  
> [snip]
> 
> 
> In addition, there are a number of RIR Board members and numbering community members here at the ICANN meeting ready to pitch in.  I am here not only as a member-elected representative of the ARIN and NANOG communities, but also as the Chair of the Address Council of the ICANN Address Supporting Organization.  You will find me next to an RIR CEO on stage tomorrow representing the numbering community reminding everyone what the 2nd "N" in ICANN stands for.
>  
> We recognize that both the ICANN community and the numbering communities each have divergent views.  We will have an opportunity to demonstrate how our multistakeholder concepts are implemented in the RIR system, and how the RIR staffs and Boards are held accountable for their actions.  Perhaps the ICANN community can take the best features and make it work to "globalize" the accountability of IANA functions at ICANN.
>  
> Yours,
> Louie Lee
> Chair
> ICANN ASO Address Council

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

From owen at delong.com  Mon Mar 24 14:08:03 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 24 Mar 2014 11:08:03 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
	RSA and 8.2 Utilization Requirements
In-Reply-To: <532CC259.5020605@umn.edu>
References: <531633BD.1010109@arin.net>	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>	<CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>	<532BD7D6.4000901@matthew.at>	<CDA64243-36FD-407D-8707-2440E5A7C86B@arin.net>
	<CAMfXtQw9Kyqsbn3F8oZAU9WMjjcYunsOw90=nruaTU8cWQU1Zg@mail.gmail.com>
	<532CC259.5020605@umn.edu>
Message-ID: <184A5AF5-1CDA-4AE8-B744-223083E3692F@delong.com>


On Mar 21, 2014, at 15:51 , David Farmer <farmer at umn.edu> wrote:

> On 3/21/14, 09:10 , Gary Buhrmaster wrote:
>> <soapbox>
>> 
>> Any M&A, or organization changes, have a cost
>> regarding business records, and it is incumbent
>> on the organization to be prepared to pay that cost
>> for changes.  Updating ARIN records (and the cost
>> of doing so) is no different, and should not have a
>> special "out" just because it can be take time or
>> the people involved did/do not want to invest that
>> effort.  The days of informal handshake number
>> deals are (or should be) long over.  Get over it, and
>> do the (boring, painful, but necessary) work.
>> 
>> </soapbox>
> 
> I very much agree, there is and almost certainly should be work involved.
> 
> So, yes with any M&A, or other organization change, you should have to the "Business Office" part of documenting business records associated with the change.  The rationale for this "Business Office" part is clear.  Its necessary to prevent fraudulent changes to resources, and ARIN has a clear fiduciary responsibility to ensure this happens correctly.
> 
> However, I do think it is a reasonable question to ask, should you also have to do the "technical" documentation that the paragraph in question requires as well?  Frequently, such an organizational change implies little to no technical change.  So, what is the rational for doing this "technical" reporting?  Let me be clear, I'm not saying there isn't a valid rationale, but I personally can't articulate it.  So, I'd appreciate it if someone would articulate a valid rationale for this "technical" reporting.

1.	To raise the visibility when an 8.3 transfer is being attempted through structures designed to disguise it as an 8.2 transfer.
2.	For consideration in cases where the 8.2 transfer is a transfer of underutilized resources which would not otherwise get reviewed.
	While the RSA protects the current resource holder from reclamation due to underutilization, during an 8.2 transfer, I see no
	reason that the amount transferred should not at the time be right-sized to fit the infrastructure also being transferred. The policy
	as written is generous about allowing staff to find ways to work with the new resource holder to accommodate that process and
	provides ample time and great flexibility on extensions to that time, if needed.
3.	Related to point 1, to prevent 8.2 from becoming a target vehicle for end-runs to the needs-basis tests in 8.3.

Owen



From Marla.Azinger at FTR.com  Tue Mar 25 12:05:47 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Tue, 25 Mar 2014 16:05:47 +0000
Subject: [arin-ppml] Term Limit Proposal
Message-ID: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>

Having been on the AC for a 6 years I support a term limit for the AC.

When on my 4th year I pursued creating a term limit.  At the time I was told this was an action the BOT would have to take.  No action was taken.  Later I inquired on this being submitted as policy since the BOT did not take action.  I was told it would be thrown out since it's not a matter of policy.  Now with time and reviewing other public posts, I have more hope this will be taken seriously and something done.  I include this small history on my experience to show that the idea of term measures has been around for a  while but for some reason never gained traction.

I believe a balance between familiarity, hitting a productive stride, burn out and mind melting needs to be balanced out with fresh able minds.  I also believe a solid 3 year break is needed for people to re-integrate as a non-AC person and regroup.  Leaving anyone on a committee for more than 6 years opens the door to stagnation, burn out, and conformity of thinking.  Remember, just because someone is not on the AC any longer does not mean AC folks can't get advice from them if desired.

I propose the following be used for AC:
-Keep the 3 year terms in place  and add
-a 6 year contiguous term limit
-a 3 year ineligibility year period after a term ends be it 3year or 6years
-After 3 year ineligibility is over a person my run for a position on the AC again.



I believe the BOT should also have some term measures and limits.  However, I am asking someone who has served on the BOT in the past to create a thought out term plan and propose it.

To keep this topic on track, I have purposely excluded the discussion of committee member candidate requirements.  This should be a separate topic that also needs discussion in order to better ensure community wide representation.


Regards
Marla Azinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/91b16d40/attachment.htm>

From SRyerse at eclipse-networks.com  Tue Mar 25 12:13:09 2014
From: SRyerse at eclipse-networks.com (Steven Ryerse)
Date: Tue, 25 Mar 2014 16:13:09 +0000
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>

I would support this.


Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
www.eclipse-networks.com
770.656.1460 - Cell
770.399.9099- Office

[Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc.
        Conquering Complex Networks?

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Azinger, Marla
Sent: Tuesday, March 25, 2014 12:06 PM
To: arin-ppml at arin.net; arin-discuss at arin.net
Subject: [arin-ppml] Term Limit Proposal

Having been on the AC for a 6 years I support a term limit for the AC.

When on my 4th year I pursued creating a term limit.  At the time I was told this was an action the BOT would have to take.  No action was taken.  Later I inquired on this being submitted as policy since the BOT did not take action.  I was told it would be thrown out since it?s not a matter of policy.  Now with time and reviewing other public posts, I have more hope this will be taken seriously and something done.  I include this small history on my experience to show that the idea of term measures has been around for a  while but for some reason never gained traction.

I believe a balance between familiarity, hitting a productive stride, burn out and mind melting needs to be balanced out with fresh able minds.  I also believe a solid 3 year break is needed for people to re-integrate as a non-AC person and regroup.  Leaving anyone on a committee for more than 6 years opens the door to stagnation, burn out, and conformity of thinking.  Remember, just because someone is not on the AC any longer does not mean AC folks can?t get advice from them if desired.

I propose the following be used for AC:
-Keep the 3 year terms in place  and add
-a 6 year contiguous term limit
-a 3 year ineligibility year period after a term ends be it 3year or 6years
-After 3 year ineligibility is over a person my run for a position on the AC again.



I believe the BOT should also have some term measures and limits.  However, I am asking someone who has served on the BOT in the past to create a thought out term plan and propose it.

To keep this topic on track, I have purposely excluded the discussion of committee member candidate requirements.  This should be a separate topic that also needs discussion in order to better ensure community wide representation.


Regards
Marla Azinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/302ef876/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/302ef876/attachment.jpg>

From ajs at anvilwalrusden.com  Tue Mar 25 12:15:05 2014
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Tue, 25 Mar 2014 12:15:05 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <20140325161504.GO47828@mx1.yitter.info>

On Tue, Mar 25, 2014 at 04:05:47PM +0000, Azinger, Marla wrote:
> 
> I believe a balance between familiarity, hitting a productive
> stride, burn out and mind melting needs to be balanced out with
> fresh able minds.  I also believe a solid 3 year break is needed for
> people to re-integrate as a non-AC person and regroup.  Leaving
> anyone on a committee for more than 6 years opens the door to
> stagnation, burn out, and conformity of thinking.

So, why make a rule about this instead of trusting the voting members
(and the people sitting) to get it right?

That is, I agree with everything you say, but I don't understand why
the solution to that is to make an absolute rule that can never be
violated in exceptional cases.  What problem are you trying to solve?

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From Tony.Radzwon at integratelecom.com  Tue Mar 25 12:15:30 2014
From: Tony.Radzwon at integratelecom.com (Radzwon, Tony)
Date: Tue, 25 Mar 2014 16:15:30 +0000
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
Message-ID: <68B45AC82AE0E249A2BF5C40ABA75F5D14886EE0@IDCPRDMBX1.ads.integratelecom.com>

I second that?.

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Steven Ryerse
Sent: Tuesday, March 25, 2014 11:13 AM
To: Azinger, Marla; arin-ppml at arin.net; arin-discuss at arin.net
Subject: Re: [arin-ppml] Term Limit Proposal

I would support this.


Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
www.eclipse-networks.com<http://www.eclipse-networks.com>
770.656.1460 - Cell
770.399.9099- Office

[Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc.
        Conquering Complex Networks?

From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Azinger, Marla
Sent: Tuesday, March 25, 2014 12:06 PM
To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>; arin-discuss at arin.net<mailto:arin-discuss at arin.net>
Subject: [arin-ppml] Term Limit Proposal

Having been on the AC for a 6 years I support a term limit for the AC.

When on my 4th year I pursued creating a term limit.  At the time I was told this was an action the BOT would have to take.  No action was taken.  Later I inquired on this being submitted as policy since the BOT did not take action.  I was told it would be thrown out since it?s not a matter of policy.  Now with time and reviewing other public posts, I have more hope this will be taken seriously and something done.  I include this small history on my experience to show that the idea of term measures has been around for a  while but for some reason never gained traction.

I believe a balance between familiarity, hitting a productive stride, burn out and mind melting needs to be balanced out with fresh able minds.  I also believe a solid 3 year break is needed for people to re-integrate as a non-AC person and regroup.  Leaving anyone on a committee for more than 6 years opens the door to stagnation, burn out, and conformity of thinking.  Remember, just because someone is not on the AC any longer does not mean AC folks can?t get advice from them if desired.

I propose the following be used for AC:
-Keep the 3 year terms in place  and add
-a 6 year contiguous term limit
-a 3 year ineligibility year period after a term ends be it 3year or 6years
-After 3 year ineligibility is over a person my run for a position on the AC again.



I believe the BOT should also have some term measures and limits.  However, I am asking someone who has served on the BOT in the past to create a thought out term plan and propose it.

To keep this topic on track, I have purposely excluded the discussion of committee member candidate requirements.  This should be a separate topic that also needs discussion in order to better ensure community wide representation.


Regards
Marla Azinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/be9cd6e6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: image001.jpg
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/be9cd6e6/attachment.jpg>

From hannigan at gmail.com  Tue Mar 25 12:15:33 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 25 Mar 2014 12:15:33 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
Message-ID: <CAMDXq5Nq6j1KJVYF5SZB7fVZKBNJ8Tf9cviv6Pk5u_fYH=KeBw@mail.gmail.com>

I support this.




On Tue, Mar 25, 2014 at 12:13 PM, Steven Ryerse <
SRyerse at eclipse-networks.com> wrote:

>  I would support this.
>
>
>
>
>
> *Steven Ryerse*
>
> *President*
>
> *100 Ashford Center North, Suite 110, Atlanta, GA  30338*
>
> *www.eclipse-networks.com <http://www.eclipse-networks.com>*
>
> *770.656.1460 - Cell*
>
> *770.399.9099- Office*
>
>
>
> [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse
> Networks, Inc.
>
>         Conquering Complex Networks?
>
>
>
> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
> Behalf Of *Azinger, Marla
> *Sent:* Tuesday, March 25, 2014 12:06 PM
> *To:* arin-ppml at arin.net; arin-discuss at arin.net
> *Subject:* [arin-ppml] Term Limit Proposal
>
>
>
> Having been on the AC for a 6 years I support a term limit for the AC.
>
>
>
> When on my 4th year I pursued creating a term limit.  At the time I was
> told this was an action the BOT would have to take.  No action was taken.
> Later I inquired on this being submitted as policy since the BOT did not
> take action.  I was told it would be thrown out since it?s not a matter of
> policy.  Now with time and reviewing other public posts, I have more hope
> this will be taken seriously and something done.  I include this small
> history on my experience to show that the idea of term measures has been
> around for a  while but for some reason never gained traction.
>
>
>
> I believe a balance between familiarity, hitting a productive stride, burn
> out and mind melting needs to be balanced out with fresh able minds.  I
> also believe a solid 3 year break is needed for people to re-integrate as a
> non-AC person and regroup.  Leaving anyone on a committee for more than 6
> years opens the door to stagnation, burn out, and conformity of thinking.
> Remember, just because someone is not on the AC any longer does not mean AC
> folks can?t get advice from them if desired.
>
>
>
> *I propose the following be used for AC:*
>
> *-Keep the 3 year terms in place  and add *
>
> *-a 6 year contiguous term limit *
>
> *-a 3 year ineligibility year period after a term ends be it 3year or
> 6years*
>
> *-After 3 year ineligibility is over a person my run for a position on the
> AC again.*
>
>
>
>
>
>
>
> I believe the BOT should also have some term measures and limits.
> However, I am asking someone who has served on the BOT in the past to
> create a thought out term plan and propose it.
>
>
>
> To keep this topic on track, I have purposely excluded the discussion of
> committee member candidate requirements.  This should be a separate topic
> that also needs discussion in order to better ensure community wide
> representation.
>
>
>
>
>
> Regards
>
> Marla Azinger
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20140325/d8cba164/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/d8cba164/attachment.jpg>

From hannigan at gmail.com  Tue Mar 25 12:16:29 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 25 Mar 2014 12:16:29 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <CAMDXq5Nq6j1KJVYF5SZB7fVZKBNJ8Tf9cviv6Pk5u_fYH=KeBw@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
	<CAMDXq5Nq6j1KJVYF5SZB7fVZKBNJ8Tf9cviv6Pk5u_fYH=KeBw@mail.gmail.com>
Message-ID: <CAMDXq5Ma2pD+b4cKaq9X9=vYPv+pfzp2EC9Jv_zVziVpXSyYBw@mail.gmail.com>

One additional caveat, it needs to include the ARIN ASO AC as well.

Best,

-M<




On Tue, Mar 25, 2014 at 12:15 PM, Martin Hannigan <hannigan at gmail.com>wrote:

>
>
> I support this.
>
>
>
>
> On Tue, Mar 25, 2014 at 12:13 PM, Steven Ryerse <
> SRyerse at eclipse-networks.com> wrote:
>
>>  I would support this.
>>
>>
>>
>>
>>
>> *Steven Ryerse*
>>
>> *President*
>>
>> *100 Ashford Center North, Suite 110, Atlanta, GA  30338*
>>
>> *www.eclipse-networks.com <http://www.eclipse-networks.com>*
>>
>> *770.656.1460 - Cell*
>>
>> *770.399.9099- Office*
>>
>>
>>
>> [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse
>> Networks, Inc.
>>
>>         Conquering Complex Networks?
>>
>>
>>
>> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
>> Behalf Of *Azinger, Marla
>> *Sent:* Tuesday, March 25, 2014 12:06 PM
>> *To:* arin-ppml at arin.net; arin-discuss at arin.net
>> *Subject:* [arin-ppml] Term Limit Proposal
>>
>>
>>
>> Having been on the AC for a 6 years I support a term limit for the AC.
>>
>>
>>
>> When on my 4th year I pursued creating a term limit.  At the time I was
>> told this was an action the BOT would have to take.  No action was taken.
>> Later I inquired on this being submitted as policy since the BOT did not
>> take action.  I was told it would be thrown out since it?s not a matter of
>> policy.  Now with time and reviewing other public posts, I have more hope
>> this will be taken seriously and something done.  I include this small
>> history on my experience to show that the idea of term measures has been
>> around for a  while but for some reason never gained traction.
>>
>>
>>
>> I believe a balance between familiarity, hitting a productive stride,
>> burn out and mind melting needs to be balanced out with fresh able minds.
>> I also believe a solid 3 year break is needed for people to re-integrate as
>> a non-AC person and regroup.  Leaving anyone on a committee for more than 6
>> years opens the door to stagnation, burn out, and conformity of thinking.
>> Remember, just because someone is not on the AC any longer does not mean AC
>> folks can?t get advice from them if desired.
>>
>>
>>
>> *I propose the following be used for AC:*
>>
>> *-Keep the 3 year terms in place  and add *
>>
>> *-a 6 year contiguous term limit *
>>
>> *-a 3 year ineligibility year period after a term ends be it 3year or
>> 6years*
>>
>> *-After 3 year ineligibility is over a person my run for a position on
>> the AC again.*
>>
>>
>>
>>
>>
>>
>>
>> I believe the BOT should also have some term measures and limits.
>> However, I am asking someone who has served on the BOT in the past to
>> create a thought out term plan and propose it.
>>
>>
>>
>> To keep this topic on track, I have purposely excluded the discussion of
>> committee member candidate requirements.  This should be a separate topic
>> that also needs discussion in order to better ensure community wide
>> representation.
>>
>>
>>
>>
>>
>> Regards
>>
>> Marla Azinger
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage 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/20140325/a89bf365/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/a89bf365/attachment.jpg>

From Marla.Azinger at FTR.com  Tue Mar 25 12:32:24 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Tue, 25 Mar 2014 16:32:24 +0000
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <20140325161504.GO47828@mx1.yitter.info>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
Message-ID: <f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>

This has nothing to do with trust.  I look at the facts.  History proves that just voting fails.  And the downfall occurs before voting even happens.

-People are less likely to run for a position on the AC knowing they are up against long time incumbents
-People are less likely to run for a position on the AC knowing stagnation exists and new thought is not likely to be received well
-Familiarity is comfort and subconsciously people lean toward this.  True opportunity for change must be present and not just a perception.

Regards
Marla


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Sullivan
Sent: Tuesday, March 25, 2014 9:15 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Term Limit Proposal

On Tue, Mar 25, 2014 at 04:05:47PM +0000, Azinger, Marla wrote:
> 
> I believe a balance between familiarity, hitting a productive stride, 
> burn out and mind melting needs to be balanced out with fresh able 
> minds.  I also believe a solid 3 year break is needed for people to 
> re-integrate as a non-AC person and regroup.  Leaving anyone on a 
> committee for more than 6 years opens the door to stagnation, burn 
> out, and conformity of thinking.

So, why make a rule about this instead of trusting the voting members (and the people sitting) to get it right?

That is, I agree with everything you say, but I don't understand why the solution to that is to make an absolute rule that can never be violated in exceptional cases.  What problem are you trying to solve?

A

--
Andrew Sullivan
ajs at anvilwalrusden.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.


From petertbui0 at gmail.com  Tue Mar 25 12:34:40 2014
From: petertbui0 at gmail.com (Peter Bui)
Date: Tue, 25 Mar 2014 09:34:40 -0700
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <CAMDXq5Nq6j1KJVYF5SZB7fVZKBNJ8Tf9cviv6Pk5u_fYH=KeBw@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
	<CAMDXq5Nq6j1KJVYF5SZB7fVZKBNJ8Tf9cviv6Pk5u_fYH=KeBw@mail.gmail.com>
Message-ID: <BF0D2CA0-C53F-4FF0-8507-ED1B14A19A78@gmail.com>

I support



Sent from my iPhone

> On Mar 25, 2014, at 9:15 AM, Martin Hannigan <hannigan at gmail.com> wrote:
> 
> 
> 
> I support this.
> 
> 
> 
> 
>> On Tue, Mar 25, 2014 at 12:13 PM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:
>> I would support this.
>> 
>>  
>> 
>>  
>> 
>> Steven Ryerse
>> 
>> President
>> 
>> 100 Ashford Center North, Suite 110, Atlanta, GA  30338
>> 
>> www.eclipse-networks.com
>> 
>> 770.656.1460 - Cell
>> 
>> 770.399.9099- Office
>> 
>>  
>> 
>> <image001.jpg>? Eclipse Networks, Inc.
>> 
>>         Conquering Complex Networks?
>> 
>>  
>> 
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Azinger, Marla
>> Sent: Tuesday, March 25, 2014 12:06 PM
>> To: arin-ppml at arin.net; arin-discuss at arin.net
>> Subject: [arin-ppml] Term Limit Proposal
>> 
>>  
>> 
>> Having been on the AC for a 6 years I support a term limit for the AC.  
>> 
>>  
>> 
>> When on my 4th year I pursued creating a term limit.  At the time I was told this was an action the BOT would have to take.  No action was taken.  Later I inquired on this being submitted as policy since the BOT did not take action.  I was told it would be thrown out since it?s not a matter of policy.  Now with time and reviewing other public posts, I have more hope this will be taken seriously and something done.  I include this small history on my experience to show that the idea of term measures has been around for a  while but for some reason never gained traction.
>> 
>>  
>> 
>> I believe a balance between familiarity, hitting a productive stride, burn out and mind melting needs to be balanced out with fresh able minds.  I also believe a solid 3 year break is needed for people to re-integrate as a non-AC person and regroup.  Leaving anyone on a committee for more than 6 years opens the door to stagnation, burn out, and conformity of thinking.  Remember, just because someone is not on the AC any longer does not mean AC folks can?t get advice from them if desired.
>> 
>>  
>> 
>> I propose the following be used for AC:
>> 
>> -Keep the 3 year terms in place  and add
>> 
>> -a 6 year contiguous term limit
>> 
>> -a 3 year ineligibility year period after a term ends be it 3year or 6years
>> 
>> -After 3 year ineligibility is over a person my run for a position on the AC again.
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> I believe the BOT should also have some term measures and limits.  However, I am asking someone who has served on the BOT in the past to create a thought out term plan and propose it.  
>> 
>>  
>> 
>> To keep this topic on track, I have purposely excluded the discussion of committee member candidate requirements.  This should be a separate topic that also needs discussion in order to better ensure community wide representation.  
>> 
>>  
>> 
>>  
>> 
>> Regards
>> 
>> Marla Azinger
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/138d29d8/attachment.htm>

From springer at inlandnet.com  Tue Mar 25 12:52:23 2014
From: springer at inlandnet.com (John Springer)
Date: Tue, 25 Mar 2014 09:52:23 -0700 (PDT)
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <8335CAF4177E7A4CBC4670E5F9FA9B415C33B8EA@CRC-Exchange02.corp.clearrate.net>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>,
	<68B45AC82AE0E249A2BF5C40ABA75F5D14886EE0@IDCPRDMBX1.ads.integratelecom.com>
	<8335CAF4177E7A4CBC4670E5F9FA9B415C33B8EA@CRC-Exchange02.corp.clearrate.net>
Message-ID: <alpine.BSF.2.00.1403250948540.28133@mail.inlandnet.com>

<nit>

On Tue, 25 Mar 2014, Paul Timmins wrote:

> Additionally, the proposal is being floated by someone who has been on the BOT for 6 years, and thus their judgement may be clouded because they've been on the BOT too
> long.
> 
> Paul Timmins
> Clear Rate Communications
> Direct: (248) 556-4532
> Customer Support: (877) 877-4799
> 24 Hour Repair: (866) 366-4665
> Network Operations: (877) 877-1250
> www.clearrate.com
>

I believe Marla was on the Advisory Council for 6 years and not the Board 
of Trustees.

John Springer


From hannigan at gmail.com  Tue Mar 25 12:52:18 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Tue, 25 Mar 2014 12:52:18 -0400
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <8335CAF4177E7A4CBC4670E5F9FA9B415C33B8EA@CRC-Exchange02.corp.clearrate.net>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
	<68B45AC82AE0E249A2BF5C40ABA75F5D14886EE0@IDCPRDMBX1.ads.integratelecom.com>
	<8335CAF4177E7A4CBC4670E5F9FA9B415C33B8EA@CRC-Exchange02.corp.clearrate.net>
Message-ID: <CAMDXq5P-FtxqaBLY5MwcFui=tYFWt6ywYf4iD4tFTFWrfgUozQ@mail.gmail.com>

On Tue, Mar 25, 2014 at 12:33 PM, Paul Timmins <ptimmins at clearrate.com>wrote:

>  I have concerns that forcing people out of a position where people
> repeatedly vote for them is undemocratic,
>

Paul,

It would be interesting to tally the votes available to the respective
bodies (all ORG-IDs). I wonder if there is some high level of self
perpetuation that term limits might not actual be useful to mitigate and
provide for a pro-democratic result?

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/1fc5d5ef/attachment.htm>

From michael at birdhosting.com  Tue Mar 25 12:54:45 2014
From: michael at birdhosting.com (Michael Wallace)
Date: Tue, 25 Mar 2014 09:54:45 -0700
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
Message-ID: <483742df$30fda50$6f59c9a6$@birdhosting.com>

What is AC or BoT?
  
 Thanks,
  
 Michael Wallace
  

----------------------------------------
 From: "John Brown" <john at citylinkfiber.com>
Sent: Tuesday, March 25, 2014 9:52 AM
To: "Azinger, Marla" <Marla.Azinger at ftr.com>
Cc: "arin-discuss at arin.net" <arin-discuss at arin.net>, "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-discuss] Term Limit Proposal   
 I would support this for both the AC and the BoT.  
 The fact that the AC is making a recommendation on its governance and then being told that it will be tossed out and not handled by the BoT is disturbing.
  

   On Tue, Mar 25, 2014 at 10:05 AM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:     

Having been on the AC for a 6 years I support a term limit for the AC.    

   

When on my 4th year I pursued creating a term limit.  At the time I was told this was an action the BOT would have to take.  No action was taken.  Later I inquired on this being submitted as policy since the BOT did not take action.  I was told it would be thrown out since it's not a matter of policy.  Now with time and reviewing other public posts, I have more hope this will be taken seriously and something done.  I include this small history on my experience to show that the idea of term measures has been around for a  while but for some reason never gained traction.  

   

I believe a balance between familiarity, hitting a productive stride, burn out and mind melting needs to be balanced out with fresh able minds.  I also believe a solid 3 year break is needed for people to re-integrate as a non-AC person and regroup.  Leaving anyone on a committee for more than 6 years opens the door to stagnation, burn out, and conformity of thinking.  Remember, just because someone is not on the AC any longer does not mean AC folks can't get advice from them if desired.  

   

I propose the following be used for AC:  

-Keep the 3 year terms in place  and add   

-a 6 year contiguous term limit   

-a 3 year ineligibility year period after a term ends be it 3year or 6years  

-After 3 year ineligibility is over a person my run for a position on the AC again.  

   

   

   

I believe the BOT should also have some term measures and limits.  However, I am asking someone who has served on the BOT in the past to create a thought out term plan and propose it.    

   

To keep this topic on track, I have purposely excluded the discussion of committee member candidate requirements.  This should be a separate topic that also needs discussion in order to better ensure community wide representation.    

   

   

Regards  

Marla Azinger  

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


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

From scottleibrand at gmail.com  Tue Mar 25 12:59:32 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 25 Mar 2014 09:59:32 -0700
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <CAGkMwz4DLw13fz2qz37HJHUp7KDfPOupnQ+GqRRy+d5Zt8HPtg@mail.gmail.com>

On Tue, Mar 25, 2014 at 9:05 AM, Azinger, Marla <Marla.Azinger at ftr.com>wrote:

>  Having been on the AC for a 6 years I support a term limit for the AC.
>
>
>
> When on my 4th year I pursued creating a term limit.  At the time I was
> told this was an action the BOT would have to take.  No action was taken.
> Later I inquired on this being submitted as policy since the BOT did not
> take action.  I was told it would be thrown out since it's not a matter of
> policy.  Now with time and reviewing other public posts, I have more hope
> this will be taken seriously and something done.  I include this small
> history on my experience to show that the idea of term measures has been
> around for a  while but for some reason never gained traction.
>
>
>
> I believe a balance between familiarity, hitting a productive stride, burn
> out and mind melting needs to be balanced out with fresh able minds.  I
> also believe a solid 3 year break is needed for people to re-integrate as a
> non-AC person and regroup.  Leaving anyone on a committee for more than 6
> years opens the door to stagnation, burn out, and conformity of thinking.
> Remember, just because someone is not on the AC any longer does not mean AC
> folks can't get advice from them if desired.
>
>
>
> *I propose the following be used for AC:*
>
> *-Keep the 3 year terms in place  and add *
>
> *-a 6 year contiguous term limit*
>

I support term limits for the AC.  From my experience 6 years is about when
burnout starts to hit, so I think that's a good time to take a 1 year
break.  (I considered doing so myself this year, but narrowly decided
against it and was re-elected for a third 3-year term.)

I would word it as "two full terms", so that someone who serves a partial
term can be re-elected twice and finish their second full term.

 *-a 3 year ineligibility year period after a term ends be it 3year or
> 6years*
>
> *-After 3 year ineligibility is over a person my run for a position on the
> AC again.*
>

I think one year off would be fine.

It's also worth thinking about how we transition into term limits.  If we
just applied them immediately, that would probably cause more turnover than
we want.  One idea might be to ratchet down the number of AC members with
>6 years contiguous service that can be re-elected each year.  This year,
four >6y incumbents could be re-elected, next year three, etc. until we get
to zero (and everyone gets termed out after 6 years).  Ideally, years of
service to date would count toward the above (otherwise we would get no
benefits to our term limits for 6 years).


>
>
> I believe the BOT should also have some term measures and limits.
> However, I am asking someone who has served on the BOT in the past to
> create a thought out term plan and propose it.
>

I don't have any experience with being on the board, so I don't yet have an
opinion there.

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

From michael+ppml at burnttofu.net  Tue Mar 25 13:01:45 2014
From: michael+ppml at burnttofu.net (Michael Sinatra)
Date: Tue, 25 Mar 2014 10:01:45 -0700
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <20140325161504.GO47828@mx1.yitter.info>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
Message-ID: <5331B679.5060906@burnttofu.net>

On 03/25/2014 09:15, Andrew Sullivan wrote:
> On Tue, Mar 25, 2014 at 04:05:47PM +0000, Azinger, Marla wrote:
>>
>> I believe a balance between familiarity, hitting a productive
>> stride, burn out and mind melting needs to be balanced out with
>> fresh able minds.  I also believe a solid 3 year break is needed for
>> people to re-integrate as a non-AC person and regroup.  Leaving
>> anyone on a committee for more than 6 years opens the door to
>> stagnation, burn out, and conformity of thinking.
> 
> So, why make a rule about this instead of trusting the voting members
> (and the people sitting) to get it right?
> 
> That is, I agree with everything you say, but I don't understand why
> the solution to that is to make an absolute rule that can never be
> violated in exceptional cases.  What problem are you trying to solve?

This is the problem with term limits: They're inherently
anti-democratic.  They (further) limit the range of people for whom the
voting members can support.  Now, one may argue (as many political
philosophers have in the past) that too much democracy is a bad thing,
but grafting term limits onto an electoral process rarely counteracts
the ill effects of "too much democracy."  In most cases where term
limits have been imposed (e.g. California, where I live), it has not
reduced the influence of special interests, it has not deterred "career
politicians," whether competent or not, and it has not reduced polarization.

Part of the issue is that term limits don't distinguish between those
who have become stagnant and those who continue to be valuable contributors.

Term limits do sometimes make sense in cases where elections can't be
trusted or for very high offices (e.g. heads of state).  But I don't see
the need for the AC.  I believe that the AC members are competent and
self-aware enough to know when it's time to leave.  I also believe that
informed voters have a similar understanding regarding the performance
of the AC.

michael



From scottleibrand at gmail.com  Tue Mar 25 13:21:23 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 25 Mar 2014 10:21:23 -0700
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <483742df$30fda50$6f59c9a6$@birdhosting.com>
References: <483742df$30fda50$6f59c9a6$@birdhosting.com>
Message-ID: <CAGkMwz4U8d+oG6eZt100AX7HaHRmxQqA-dcC2TAha_gW_evbzQ@mail.gmail.com>

The AC is the ARIN Advisory Council: https://www.arin.net/about_us/ac.html

The BoT is the ARIN Board of Trustees:
https://www.arin.net/about_us/bot.html

-Scott


On Tue, Mar 25, 2014 at 9:54 AM, Michael Wallace <michael at birdhosting.com>wrote:

> What is AC or BoT?
>
> Thanks,
>
> Michael Wallace
>
> ------------------------------
> *From*: "John Brown" <john at citylinkfiber.com>
> *Sent*: Tuesday, March 25, 2014 9:52 AM
> *To*: "Azinger, Marla" <Marla.Azinger at ftr.com>
> *Cc*: "arin-discuss at arin.net" <arin-discuss at arin.net>, "arin-ppml at arin.net"
> <arin-ppml at arin.net>
>
> *Subject*: Re: [arin-discuss] Term Limit Proposal
>
> I would support this for both the AC and the BoT.
>
> The fact that the AC is making a recommendation on its governance and then
> being told that it will be tossed out and not handled by the BoT is
> disturbing.
>
>
> On Tue, Mar 25, 2014 at 10:05 AM, Azinger, Marla <Marla.Azinger at ftr.com>wrote:
>
>>  Having been on the AC for a 6 years I support a term limit for the AC.
>>
>>
>>
>> When on my 4th year I pursued creating a term limit.  At the time I was
>> told this was an action the BOT would have to take.  No action was taken.
>> Later I inquired on this being submitted as policy since the BOT did not
>> take action.  I was told it would be thrown out since it's not a matter of
>> policy.  Now with time and reviewing other public posts, I have more hope
>> this will be taken seriously and something done.  I include this small
>> history on my experience to show that the idea of term measures has been
>> around for a  while but for some reason never gained traction.
>>
>>
>>
>> I believe a balance between familiarity, hitting a productive stride,
>> burn out and mind melting needs to be balanced out with fresh able minds.
>> I also believe a solid 3 year break is needed for people to re-integrate as
>> a non-AC person and regroup.  Leaving anyone on a committee for more than 6
>> years opens the door to stagnation, burn out, and conformity of thinking.
>> Remember, just because someone is not on the AC any longer does not mean AC
>> folks can't get advice from them if desired.
>>
>>
>>
>> *I propose the following be used for AC:*
>>
>> *-Keep the 3 year terms in place  and add *
>>
>> *-a 6 year contiguous term limit *
>>
>> *-a 3 year ineligibility year period after a term ends be it 3year or
>> 6years*
>>
>> *-After 3 year ineligibility is over a person my run for a position on
>> the AC again.*
>>
>>
>>
>>
>>
>>
>>
>> I believe the BOT should also have some term measures and limits.
>> However, I am asking someone who has served on the BOT in the past to
>> create a thought out term plan and propose it.
>>
>>
>>
>> To keep this topic on track, I have purposely excluded the discussion of
>> committee member candidate requirements.  This should be a separate topic
>> that also needs discussion in order to better ensure community wide
>> representation.
>>
>>
>>
>>
>>
>> Regards
>>
>> Marla Azinger
>>
>> _______________________________________________
>> ARIN-Discuss
>> You are receiving this message because you are subscribed to
>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-discuss
>> Please contact info at arin.net if you experience any issues.
>>
>
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/fafa7e28/attachment.htm>

From cja at daydream.com  Tue Mar 25 13:23:40 2014
From: cja at daydream.com (CJ Aronson)
Date: Tue, 25 Mar 2014 17:23:40 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <483742df$30fda50$6f59c9a6$@birdhosting.com>
References: <483742df$30fda50$6f59c9a6$@birdhosting.com>
Message-ID: <CAC6JZKQwwtGV1JgYSdULtXfxk6sfDKpPEwMJUdjaTDnBk8Qj=A@mail.gmail.com>

Here are links that will answer your questions  about the AC and the BoT
https://www.arin.net/about_us/bot.html
https://www.arin.net/about_us/ac.html

---Cathy


On Tue, Mar 25, 2014 at 4:54 PM, Michael Wallace <michael at birdhosting.com>wrote:

> What is AC or BoT?
>
> Thanks,
>
> Michael Wallace
>
> ------------------------------
> *From*: "John Brown" <john at citylinkfiber.com>
> *Sent*: Tuesday, March 25, 2014 9:52 AM
> *To*: "Azinger, Marla" <Marla.Azinger at ftr.com>
> *Cc*: "arin-discuss at arin.net" <arin-discuss at arin.net>, "arin-ppml at arin.net"
> <arin-ppml at arin.net>
>
> *Subject*: Re: [arin-discuss] Term Limit Proposal
>
> I would support this for both the AC and the BoT.
>
> The fact that the AC is making a recommendation on its governance and then
> being told that it will be tossed out and not handled by the BoT is
> disturbing.
>
>
> On Tue, Mar 25, 2014 at 10:05 AM, Azinger, Marla <Marla.Azinger at ftr.com>wrote:
>
>>  Having been on the AC for a 6 years I support a term limit for the AC.
>>
>>
>>
>> When on my 4th year I pursued creating a term limit.  At the time I was
>> told this was an action the BOT would have to take.  No action was taken.
>> Later I inquired on this being submitted as policy since the BOT did not
>> take action.  I was told it would be thrown out since it's not a matter of
>> policy.  Now with time and reviewing other public posts, I have more hope
>> this will be taken seriously and something done.  I include this small
>> history on my experience to show that the idea of term measures has been
>> around for a  while but for some reason never gained traction.
>>
>>
>>
>> I believe a balance between familiarity, hitting a productive stride,
>> burn out and mind melting needs to be balanced out with fresh able minds.
>> I also believe a solid 3 year break is needed for people to re-integrate as
>> a non-AC person and regroup.  Leaving anyone on a committee for more than 6
>> years opens the door to stagnation, burn out, and conformity of thinking.
>> Remember, just because someone is not on the AC any longer does not mean AC
>> folks can't get advice from them if desired.
>>
>>
>>
>> *I propose the following be used for AC:*
>>
>> *-Keep the 3 year terms in place  and add *
>>
>> *-a 6 year contiguous term limit *
>>
>> *-a 3 year ineligibility year period after a term ends be it 3year or
>> 6years*
>>
>> *-After 3 year ineligibility is over a person my run for a position on
>> the AC again.*
>>
>>
>>
>>
>>
>>
>>
>> I believe the BOT should also have some term measures and limits.
>> However, I am asking someone who has served on the BOT in the past to
>> create a thought out term plan and propose it.
>>
>>
>>
>> To keep this topic on track, I have purposely excluded the discussion of
>> committee member candidate requirements.  This should be a separate topic
>> that also needs discussion in order to better ensure community wide
>> representation.
>>
>>
>>
>>
>>
>> Regards
>>
>> Marla Azinger
>>
>> _______________________________________________
>> ARIN-Discuss
>> You are receiving this message because you are subscribed to
>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-discuss
>> Please contact info at arin.net if you experience any issues.
>>
>
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/ff447dda/attachment.htm>

From cja at daydream.com  Tue Mar 25 13:39:18 2014
From: cja at daydream.com (CJ Aronson)
Date: Tue, 25 Mar 2014 17:39:18 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAH_b1v5jrtdb3yoF7TEennYv-9xkyv8DSk1E=Ga1Wvzzw4=etA@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
	<68B45AC82AE0E249A2BF5C40ABA75F5D14886EE0@IDCPRDMBX1.ads.integratelecom.com>
	<8335CAF4177E7A4CBC4670E5F9FA9B415C33B8EA@CRC-Exchange02.corp.clearrate.net>
	<CAH_b1v5jrtdb3yoF7TEennYv-9xkyv8DSk1E=Ga1Wvzzw4=etA@mail.gmail.com>
Message-ID: <CAC6JZKRJbx1Ny+EemZ61x_hWrAAsqxjuh7gnAFeyukcbgFb-Gw@mail.gmail.com>

John

The ARIN website has all the data you refer to here.  It even has how many
votes each candidate got in each election.   You can also google "ARIN
election results <year>" to find a particular year.


----Cathy


On Tue, Mar 25, 2014 at 4:58 PM, John Brown <john at citylinkfiber.com> wrote:

> Industry capture is actually something that could be prevented by term
> limits.
>
> One concern I have is:  Its easier to just click yes on the existing
> people, instead of looking at new candidates, new ideas, etc.
>
> Is there a place that shows total number of eligible voters and the actual
> number of votes received, trended over time.    Is the membership well
> represented by high turn out, or is the turn out "the same old people,
> voting for the same people""
>
> The President of the United States is limited to 8 years.
> Many States and City's have term limits on their elected representatives.
> Seems pretty democratic to me.
>
>
>
>
> On Tue, Mar 25, 2014 at 10:33 AM, Paul Timmins <ptimmins at clearrate.com>wrote:
>
>>  I have concerns that forcing people out of a position where people
>> repeatedly vote for them is undemocratic, and can threaten the stability of
>> the regulatory regime by forcing people with experience out of a role when
>> their judgement may be perfectly okay and properly reflect community
>> consensus.
>>
>> It also can promote inappropriate industry influence by allowing large
>> players to target roles well in advance knowing a certain candidate will be
>> out of the election to cause undue influence on ARIN's policies.
>>
>> Additionally, the proposal is being floated by someone who has been on
>> the BOT for 6 years, and thus their judgement may be clouded because
>> they've been on the BOT too long.
>>
>>  Paul Timmins
>> Clear Rate Communications
>> Direct: (248) 556-4532
>> Customer Support: (877) 877-4799
>> 24 Hour Repair: (866) 366-4665
>> Network Operations: (877) 877-1250
>> www.clearrate.com
>>
>>   This message contains confidential information intended only for the
>> use of the intended recipient(s) and may contain information that is
>> privileged. If you are not the intended recipient, or the person
>> responsible for delivering it to the intended recipient, you are hereby
>> notified that reading, disseminating or copying this message is strictly
>> prohibited.
>>
>> If you have received this message by mistake, please immediately send
>> notification by replying to the message, indicate the message was received
>> by mistake, and then delete the original message immediately thereafter.
>> Thank you.
>>
>> Clear Rate Communications, Inc. 555 S. Old Woodward, Suite 600,
>> Birmingham, MI 48009.
>>
>>
>>    ------------------------------
>> *From:* arin-discuss-bounces at arin.net [arin-discuss-bounces at arin.net] on
>> behalf of Radzwon, Tony [Tony.Radzwon at integratelecom.com]
>> *Sent:* Tuesday, March 25, 2014 12:15 PM
>> *To:* Steven Ryerse; Azinger, Marla; arin-ppml at arin.net;
>> arin-discuss at arin.net
>> *Subject:* Re: [arin-discuss] Term Limit Proposal
>>
>>   I second that?.
>>
>>
>>
>> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On
>> Behalf Of *Steven Ryerse
>> *Sent:* Tuesday, March 25, 2014 11:13 AM
>> *To:* Azinger, Marla; arin-ppml at arin.net; arin-discuss at arin.net
>> *Subject:* Re: [arin-ppml] Term Limit Proposal
>>
>>
>>
>> I would support this.
>>
>>
>>
>>
>>
>> *Steven Ryerse*
>>
>> *President*
>>
>> *100 Ashford Center North, Suite 110, Atlanta, GA  30338*
>>
>> *www.eclipse-networks.com <http://www.eclipse-networks.com>*
>>
>> *770.656.1460 <770.656.1460> - Cell*
>>
>> *770.399.9099 <770.399.9099>- Office*
>>
>>
>>
>> [image: Description: Description: Eclipse Networks Logo_small.png]? Eclipse
>> Networks, Inc.
>>
>>         Conquering Complex Networks?
>>
>>
>>
>> *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net<arin-ppml-bounces at arin.net>]
>> *On Behalf Of *Azinger, Marla
>> *Sent:* Tuesday, March 25, 2014 12:06 PM
>> *To:* arin-ppml at arin.net; arin-discuss at arin.net
>> *Subject:* [arin-ppml] Term Limit Proposal
>>
>>
>>
>> Having been on the AC for a 6 years I support a term limit for the AC.
>>
>>
>>
>> When on my 4th year I pursued creating a term limit.  At the time I was
>> told this was an action the BOT would have to take.  No action was taken.
>> Later I inquired on this being submitted as policy since the BOT did not
>> take action.  I was told it would be thrown out since it?s not a matter of
>> policy.  Now with time and reviewing other public posts, I have more hope
>> this will be taken seriously and something done.  I include this small
>> history on my experience to show that the idea of term measures has been
>> around for a  while but for some reason never gained traction.
>>
>>
>>
>> I believe a balance between familiarity, hitting a productive stride,
>> burn out and mind melting needs to be balanced out with fresh able minds.
>> I also believe a solid 3 year break is needed for people to re-integrate as
>> a non-AC person and regroup.  Leaving anyone on a committee for more than 6
>> years opens the door to stagnation, burn out, and conformity of thinking.
>> Remember, just because someone is not on the AC any longer does not mean AC
>> folks can?t get advice from them if desired.
>>
>>
>>
>> *I propose the following be used for AC:*
>>
>> *-Keep the 3 year terms in place  and add *
>>
>> *-a 6 year contiguous term limit *
>>
>> *-a 3 year ineligibility year period after a term ends be it 3year or
>> 6years*
>>
>> *-After 3 year ineligibility is over a person my run for a position on
>> the AC again.*
>>
>>
>>
>>
>>
>>
>>
>> I believe the BOT should also have some term measures and limits.
>> However, I am asking someone who has served on the BOT in the past to
>> create a thought out term plan and propose it.
>>
>>
>>
>> To keep this topic on track, I have purposely excluded the discussion of
>> committee member candidate requirements.  This should be a separate topic
>> that also needs discussion in order to better ensure community wide
>> representation.
>>
>>
>>
>>
>>
>> Regards
>>
>> Marla Azinger
>>
>> _______________________________________________
>> ARIN-Discuss
>> You are receiving this message because you are subscribed to
>> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-discuss
>> Please contact info at arin.net if you experience any issues.
>>
>
>
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/d211eb27/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1468 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/d211eb27/attachment.jpg>

From info at arin.net  Tue Mar 25 14:18:40 2014
From: info at arin.net (ARIN)
Date: Tue, 25 Mar 2014 14:18:40 -0400
Subject: [arin-ppml] Advisory Council Meeting Results - March 2014
Message-ID: <5331C880.90102@arin.net>

In accordance with the ARIN Policy Development Process the ARIN Advisory
Council (AC) held a meeting on 20 March 2014.

Having found the following Draft Policies to be fully developed and
meeting ARIN's Principles of Internet Number Resource Policy, the AC
recommended them for adoption. These Draft Policies will be posted 
shortly for discussion on the Public Policy Mailing List as Recommended 
Draft Policies:

   Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup
   Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy
   Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation Conservation
   Draft Policy ARIN-2014-10: Remove Sections 4.6 and 4.7

The AC accepted the following Proposal as a Draft Policy. It will be 
posted separately to the Public Policy Mailing List:

ARIN-prop-202 Anti-hijack Policy

The AC is continuing to work on the following:

   Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple 
Discrete Networks
   Draft Policy ARIN-2014-1: Out of Region Use
   Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip Language
   Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 
Block Size Requirements
   Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations
   Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs]
   Draft Policy ARIN-2014-8: Alignment of 8.3 Needs Requirements to 
Reality of Business
   Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 
Utilization Requirements
   Draft Policy ARIN-2014-11: Improved Registry Accuracy Proposal

Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html

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

Regards,

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



From info at arin.net  Tue Mar 25 14:19:07 2014
From: info at arin.net (ARIN)
Date: Tue, 25 Mar 2014 14:19:07 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2013-7: NRPM 4 (IPv4)
	Policy Cleanup
Message-ID: <5331C89B.6010004@arin.net>

Recommended Draft Policy ARIN-2013-7
NRPM 4 (IPv4) Policy Cleanup

On 20 March 2014 the ARIN Advisory Council (AC) recommended
ARIN-2013-7 for adoption, making it a Recommended Draft Policy.

ARIN-2013-7 is below and can be found at:
https://www.arin.net/policy/proposals/2013_7.html

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

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

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

Regards,

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


## * ##


Recommended Draft Policy ARIN-2013-7
NRPM 4 (IPv4) Policy Cleanup

Date: 25 March 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"ARIN-2013-7: "NRPM 4 (IPv4) Policy Cleanup" enables fair and impartial 
number resource administration by removing no-longer-relevant sections 
of the NRPM, and clarifying other sections.  All of the remaining 
changes in this draft policy have proven uncontroversial thus far."

Problem Statement:

Parts of NRPM 4 are irrelevant, especially after IPv4 run-out, and 
should be cleaned up for clarity.

Policy statement:

Short list of changes with details explained below.

     Remove section 4.1.1 Routability
     Update section 4.1.5 Determination of resource requests
     Remove section 4.1.7 RFC2050
     Remove section 4.1.9 Returned IPv4 Addresses
     Replace and retitle section 4.2.4.3 Subscriber Members Less Than 
One Year
     Remove section 4.2.4.4. Subscriber Members After One Year

Details:

     Remove section 4.1.1 Routability

It is no longer necessary for the NRPM to suggest where an organization 
obtains resources from.

     Retitle and rewrite section (4.1.5 Determination of IP address 
allocation size)

Remove: "Determination of IP address allocation size is the 
responsibility of ARIN."

Replace with: (4.1.5 Resource request size) "Determining the validity of 
the amount of requested IP address resources is the responsibility of ARIN."

Rationale: Clarify that it is the validity of the request that is more 
the focus than the amount of resources requested. This does not prevent 
ARIN from suggesting that a smaller block would be justified where a 
larger one would not, but also does not suggest that it is ARIN's sole 
discretion to judge the size of the blocks needed.

     Remove section 4.1.7 RFC2050

Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR 
Principles has been adopted, this section is no longer needed.

     Remove section 4.2.4.3 Subscriber Members Less Than One Year and 
4.2.4.4. Subscriber Members After One Year

Replace with: (4.2.4.3 Request size) "ISPs may request up to a 3-month 
supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 or 8.4 
transfer."

Rationale: Since ARIN received its last /8, by IANA implementing section 
10.4.2.2, this is now a distinction without a difference.

Timetable for implementation: Immediate

##########

ARIN Staff and Legal Assessment

ARIN-prop-2013-7bis ? ?NRPM 4 (IPv4) Policy Cleanup?

Date of Assessment:  04 Mar 2014

1. Summary (Staff Understanding)

The intent of this proposal is to modify several existing sections of 
NRPM 4 as the author believes that they are becoming increasingly 
irrelevant as we move closer to IPv4 run-out.  Sections to be modified 
include 4.1.1, 4.1.5, 4.1.7, 4.1.9, 4.2.4.3, 4.2.4.4, and 4.2.5.

Changes include:
1.     No longer comments on global routability for IP addresses issued 
by ARIN and no longer recommends where ISPs should consider requesting 
IP address space
2.     Removes ARIN's sole discretion to determine the size of 
additional IPv4 allocations to ISPs
3.     Removes reference to RFC2050
4.     Removes text requiring ARIN to make returned, revoked, and 
recovered IP addresses available in the ARIN region as soon as possible
5.     Codifies that all ISPs may request up to a three month supply of 
IPv4 addresses from ARIN, or a 24 month supply via 8.3 transfer
6.     Removes the web hosting policy

  2. Comments

A.    ARIN Staff Comments

?      This proposal removes or modifies 7 different policies in NRPM, 
however, these changes do not appear to alter staff?s ability to obtain 
appropriate justification for resource requests, nor create any 
potential operational impact.

?      This proposal could be implemented as written

B.    ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.



3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

?      Updated guidelines and internal procedures

?      Staff training

  4. Proposal Text

Problem Statement: Parts of NRPM 4 are irrelevant, especially after IPv4
run-out, and should be cleaned up for clarity.

Policy statement:

Short list of changes with details explained below.

Remove section 4.1.1 Routability
Update section 4.1.5 Determination of resource requests
Remove section 4.1.7 RFC2050
Remove section 4.1.9 Returned IPv4 Addresses
Replace and retitle section 4.2.4.3 Subscriber Members Less Than One Year
Remove section 4.2.4.4. Subscriber Members After One Year
Remove section 4.2.5 Web Hosting Policy
Details:

Remove section 4.1.1 Routability
It is no longer necessary for the NRPM to suggest where an organization
obtains resources from.

Retitle and rewrite section (4.1.5 Determination of IP address 
allocation size)
Remove: "Determination of IP address allocation size is the 
responsibility of ARIN."

Replace with: (4.1.5 Resource request size) "Determining the validity of
the amount of requested IP address resources is the responsibility of ARIN."

Rationale: Clarify that it is the validity of the request that is more 
the focus than the amount of resources requested. This does not prevent 
ARIN from suggesting that a smaller block would be justified where a 
larger one would not, but also does not suggest that it is ARIN's sole 
discretion to judge the size of the blocks needed.

Remove section 4.1.7 RFC2050
Now that RFC2050 has been replaced with RFC 7020 and ARIN-2013-4 RIR
Principles has been adopted, this section is no longer needed.

Remove section 4.2.4.3 Subscriber Members Less Than One Year and 
4.2.4.4. Subscriber Members After One Year
Replace with: (4.2.4.3 Request size) "ISPs may request up to a 3-month
supply of IPv4 addresses from ARIN, or a 24-month supply via 8.3 transfer."

Rationale: Since ARIN received its last /8, by IANA implementing section
10.4.2.2, this is now a distinction without a difference.

Remove section 4.2.5 Web Hosting Policy
This information-gathering policy has been in place for a decade now 
with no resulting policy changes, and is no longer needed in light of 
IPv4 runout.


From info at arin.net  Tue Mar 25 14:19:45 2014
From: info at arin.net (ARIN)
Date: Tue, 25 Mar 2014 14:19:45 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-4: Remove 4.2.5 Web
	Hosting Policy
Message-ID: <5331C8C1.6010909@arin.net>

Recommended Draft Policy ARIN-2014-4
Remove 4.2.5 Web Hosting Policy

On 20 March 2014 the ARIN Advisory Council (AC) recommended
ARIN-2014-4 for adoption, making it a Recommended Draft Policy.

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

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

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

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

Regards,

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


## * ##


Recommended Draft Policy ARIN-2014-4
Remove 4.2.5 Web Hosting Policy

Date: 25 March 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy enables fair 
and impartial number resource administration by removing a 
no-longer-relevant section of the NRPM. The change in this draft policy 
has proven
uncontroversial thus far, consisting of one statement of support
and no opposition."

Problem Statement:

Section 4.2.5 is technology-specific language that is not current with 
modern network operation needs and practices. We should remove it to 
make NRPM clearer.

Policy statement:

Remove section 4.2.5.

Comments:
a.Timetable for implementation: Immediate
b.Anything else:

4.2.5. Web Hosting Policy

When an ISP submits a request for IP address space to be used for 
IP-based web hosting, it will supply (for informational purposes only) 
its technical justification for this practice. ARIN will analyze this 
data continuously, evaluating the need for future policy change.

##########

ARIN Staff and Legal Assessment

ARIN-prop-2014-4 ? ?Remove 4.2.5 Web Hosting Policy?

Date of Assessment:

1. Summary (Staff Understanding)

This proposal would remove existing policy NRPM 4.2.5 as it is 
?technology specific language? that is obsolete and not in sync with 
current network practices.

  2. Comments

A.    ARIN Staff Comments

?      If this policy were removed from NRPM, ARIN staff would still be 
able to require technical justification for web hosting based on the 
overall requirement to show efficient use as outlined in NRPM section 4.

?      This proposal could be implemented as written.

B.    ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

?      Updated guidelines and internal procedures

?      Staff training

  4. Proposal Text

Problem Statement:

Section 4.2.5 is technology-specific language that is not current with 
modern network operation needs and practices. We should remove it to 
make NRPM clearer.

Policy statement:

Remove section 4.2.5.

Comments: a.Timetable for implementation: Immediate b.Anything else:

4.2.5. Web Hosting Policy

When an ISP submits a request for IP address space to be used for 
IP-based web hosting, it will supply (for informational purposes only) 
its technical justification for this practice. ARIN will analyze this 
data continuously, evaluating the need for future policy change.


From info at arin.net  Tue Mar 25 14:21:51 2014
From: info at arin.net (ARIN)
Date: Tue, 25 Mar 2014 14:21:51 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-7: Section 4.4 Micro
 Allocation Conservation Update
Message-ID: <5331C93F.3070303@arin.net>

Recommended Draft Policy ARIN-2014-7
Section 4.4 Micro Allocation Conservation Update

On 20 March 2014 the ARIN Advisory Council (AC) recommended
ARIN-2014-7 for adoption, making it a Recommended Draft Policy.

ARIN-2014-7 is below and can be found at:
https://www.arin.net/policy/proposals/2014_7.html

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

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

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

Regards,

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


## * ##


Recommended Draft Policy ARIN-2014-7
Section 4.4 Micro Allocation Conservation Update

Date: 25 March 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"Section 4.4 Micro Allocation Conservation Update enables fair and
impartial number resource administration by updating the requirements
for an IXP to obtain a micro allocation.   The changes are a precise
change (2->3 IXP members) to existing policy.  The policy is technically
sound and meets the overarching technical requirements of conservation,
aggregation, and registration.  This policy has received a number of
statements in support of this proposal on the mailing list and in Nanog
Atlanta PPC."

Problem Statement:

Two networks interconnecting are generally considered to be private 
peers. The current policy allows an IXP to receive a micro-allocation 
with only two devices. Given IPv4 exhaustion and the growth of IXPs in 
North America it is prudent to raise the minimum criteria so that 
micro-allocation space is not wasted.

Policy statement:

Change the following sentence in Section 4.4 from:

Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
two total), ASN, and contact information.

To:

Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
three total), ASN, and contact information.

Comments:
a.Timetable for implementation: Immediate
b.Anything else:

##########

ARIN Staff and Legal Assessment

ARIN-prop-2014-7 ? ?Section 4.4 Micro Allocation Conservation Update?

Date of Assessment:  04 Mar 2014

1. Summary (Staff Understanding)

This proposal would modify existing NRPM section 4.4 to require Exchange 
Point Operators to have a minimum of three participants.  The rationale 
for this change is that with more IXPs being formed and IPv4 depletion 
imminent, there is a need to conserve the limited micro-allocation 
reserved space.

  2. Comments

A.    ARIN Staff Comments

This proposal would have no operational impact and could be implemented 
as written.

B.    ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

?      Updated guidelines and internal procedures

?      Staff training

  4. Proposal Text

Problem Statement:

Two networks interconnecting are generally considered to be private 
peers. The current policy allows an IXP to receive a micro-allocation 
with only two devices. Given IPv4 exhaustion and the growth of IXPs in 
North America it is prudent to raise the minimum criteria so that 
micro-allocation space is not wasted.

Policy statement:

Change the following paragraph in Section 4.4 from:
Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
two total), ASN, and contact information.

To:

Exchange point operators must provide justification for the allocation, 
including: connection policy, location, other participants (minimum of 
three total), ASN, and contact information.



From info at arin.net  Tue Mar 25 14:22:15 2014
From: info at arin.net (ARIN)
Date: Tue, 25 Mar 2014 14:22:15 -0400
Subject: [arin-ppml] Recommended Draft Policy ARIN-2014-10: Remove Sections
	4.6 and 4.7
Message-ID: <5331C957.3010201@arin.net>

Recommended Draft Policy ARIN-2014-10
Remove Sections 4.6 and 4.7

On 20 March 2014 the ARIN Advisory Council (AC) recommended
ARIN-2014-10 for adoption, making it a Recommended Draft Policy.

ARIN-2014-10 is below and can be found at:
https://www.arin.net/policy/proposals/2014_10.html

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

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

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

Regards,

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


## * ##


Recommended Draft Policy ARIN-2014-10
Remove Sections 4.6 and 4.7

Date: 25 March 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

"Draft Policy ARIN-2014-10: Remove Sections 4.6 and 4.7 - This proposal
will permanently remove suspended NRPM policies 4.6 and 4.7, due to the
potential for abuse by large requests. The ARIN staff has noted that
these two policies have rarely been used by the community since their
implementation and have not been used at all in the past 6 years. 
Removing these Policies has received support from the community and is 
technically sound."

Problem Statement:

The ARIN Board of Trustees has suspended sections 4.6 and 4.7 of the 
Number Resource Policy Manual at their January 6, 2014 meeting. This was 
done in response to the potential for abuse of these sections as the 
IPv4 free pool approaches runout.

The last request to use section 4.6, amnesty and aggregation requests, 
was in 2004. The last request to use section 4.7, aggregation requests, 
was in 2008. These sections have not been used to request resources in 
more than five years.

There are a number of organizations who could use these sections as 
justification to request an allocation or assignment that could deplete 
the remaining ARIN IPv4 free pool. This could have unintended 
consequences with ARIN running out so unexpectedly, that outweigh the 
intended benefits the sections were meant to provide.

These sections could also be used to justify large transfers, that would 
put ARIN in an undesirable position trying to reclaim previous 
resources, when the IPv4 pool is depleted. This risk also outweighs the 
intended benefits the sections were meant to provide.

Efforts could be made to patch these sections, and provide additional 
measures to limit abuse. There does not appear to be a need, however, 
given how little the sections have been utilized. As we become aware of 
other implications it may be best to try and deal with them through a 
separate, independent proposal.

Policy statement:

Remove sections 4.6 and 4.7.

Comments:
a.Timetable for implementation: Immediate
b.Anything else:

4.6. Amnesty and Aggregation Requests

4.6.1 Intent of this policy

This policy is intended to allow the community and ARIN staff to work
together with holders of address resources in the best interests of the
community by facilitating the return of unused address space and the
aggregation of existing space in a manner which is in the best interests
of both parties.

All transactions under this policy must either create greater
aggregation (a reduction in the number of prefixes) or the return of
address space. Transactions should only be accepted under this policy if
they are in the interests of the community (e.g. they improve
aggregation or result in a net reclamation of space).

4.6.2 No penalty for returning or aggregating

ARIN shall seek to make the return of address space as convenient and
risk-free to the returning organization as possible. An organization
with several non-contiguous blocks seeking to aggregate and return space
at the same time should be accommodated if possible. If it is possible
to expand one block, for example, to facilitate the return of other
blocks, ARIN should do that.

4.6.3 Return should not force renumbering

An organization shall be allowed to return a partial block of any size
to ARIN. For any return larger than a /24, ARIN shall not require that
the non-returned portion of the block be renumbered unless the returning
organization wishes to do so.

4.6.4 Timeframe for return

Any organization which is returning addresses under this policy shall
negotiate with ARIN an appropriate timeframe in which to return the
addresses after any new resources are received under this policy. In the
case of a simple return, the timeframe shall be immediate. In the case
where renumbering into new addresses out of existing addresses to be
returned is required, the returning organization shall sign a contract
with ARIN which stipulates a final return date not less than 6 months
nor more than 18 months after the receipt of new addresses. If an
organization misses this return date, but, ARIN believes the
organization is working in good faith to complete the renumbering, ARIN
may grant a single extension of 6-12 months as staff deems appropriate
to the situation. Such an extension must be requested in writing (email
to hostmaster at arin.net) by the organization at least 15 days prior to
the original expiration date.

4.6.5 RSA Required if new addresses received

Any organization which receives any additional addresses under this
policy shall be required to sign an ARIN RSA which will apply to all new
addresses issued and to any retained blocks which are expanded under
this policy.

4.6.6 Annual contact required

Any organization which participates in this policy shall be required to
sign an agreement stipulating that ARIN will attempt contact at least
once per year via the contact mechanisms registered for the organization
in Whois. Should ARIN fail to make contact, after reasonable effort the
organization shall be flagged as "unreachable" in Whois. After six
months in "unreachable" status, the organization agrees that ARIN may
consider all resources held by the organization to be abandoned and
reclaim such resources. Should the organization make contact with ARIN
prior to the end of the aforementioned six month period and update their
contact information appropriately, ARIN shall remove the "unreachable"
status and the annual contact cycle shall continue as normal. If the
organization pays annual fees to ARIN, the payment of annual fees shall
be considered sufficient contact.

4.7. Aggregation Requests

If an organization, whether a member or non-member, ISP or end-user,
relinquishes a group of portable, non-aggregatable address blocks to
ARIN, they shall be allowed to receive a block in exchange, /24 or
larger, but no more than the largest block that could contain all of the
returned blocks. Exchanged space shall be returned within 12 months. If
the gain in the number of addresses is greater than 4096, the
aggregation request must be evaluated by the ARIN in accordance with the
current IPv4 allocation policy. If all of the previous address blocks
were maintained in the ARIN database without maintenance fees, the
replacement space shall be as well, but if any one of the returned
blocks had associated maintenance fees, then the replacement block shall
also be subject to maintenance fees.

##########

ARIN Staff and Legal Assessment

ARIN-prop-2014-10 ? ?Remove Sections 4.6 and 4.7?

Date of Assessment:  04 Mar 2014

1. Summary (Staff Understanding)

This proposal seeks to permanently remove suspended NRPM policies 4.6 
and 4.7 based on the rationale that any number of large organizations 
could potentially abuse these policies and request enough IPv4 address 
space to completely deplete ARIN?s available pool of addresses in one 
request.

  2. Comments

A.    ARIN Staff Comments

?      These two policies have rarely been used by the community since 
their implementation and in fact, have not been used at all in the past 
6 years.
o   The last request to use section 4.6, amnesty and aggregation 
requests, was in 2004.
o   The last request to use section 4.7, aggregation requests, was in 2008.
?      Customers wishing to return resources to ARIN have always been 
able to, and can continue to do so, by simply submitting a request 
ticket to hostmaster at arin.net.  Staff then does the requisite 
verification of the request for the return of space.
o   The ARIN website has recently been updated to more clearly outline 
the procedure for returning address space to ARIN.
?      This proposal could be implemented as written and would have no 
operational impact.

B.    ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.

3. Resource Impact

This policy would have minimal resource impact from an implementation 
aspect.  It is estimated that implementation would occur within 3 months 
after ratification by the ARIN Board of Trustees. The following would be 
needed in order to implement:

?      Updated guidelines

  4. Proposal Text

Problem Statement:

The ARIN Board of Trustees has suspended sections 4.6 and 4.7 of the 
Number Resource Policy Manual at their January 6, 2014 meeting. This was 
done in response to the potential for abuse of these sections as the 
IPv4 free pool approaches runout.

The last request to use section 4.6, amnesty and aggregation requests, 
was in 2004. The last request to use section 4.7, aggregation requests, 
was in 2008. These sections have not been used to request resources in 
more than five years.

There are a number of organizations who could use these sections as 
justification to request an allocation or assignment that could deplete 
the remaining ARIN IPv4 free pool. This could have unintended 
consequences with ARIN running out so unexpectedly, that outweigh the 
intended benefits the sections were meant to provide.

These sections could also be used to justify large transfers, that would 
put ARIN in an undesirable position trying to reclaim previous 
resources, when the IPv4 pool is depleted. This risk also outweighs the 
intended benefits the sections were meant to provide.

Efforts could be made to patch these sections, and provide additional 
measures to limit abuse. There does not appear to be a need, however, 
given how little the sections have been utilized. As we become aware of 
other implications it may be best to try and deal with them through a 
separate, independent proposal.

Policy statement:

Remove sections 4.6 and 4.7.



From info at arin.net  Tue Mar 25 14:27:37 2014
From: info at arin.net (ARIN)
Date: Tue, 25 Mar 2014 14:27:37 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
Message-ID: <5331CA99.2000806@arin.net>

On 20 March 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.

Draft Policy ARIN-2014-12 is below and can be found at:
https://www.arin.net/policy/proposals/2014_12.html

You are encouraged to discuss the merits and your concerns of Draft
Policy 2014-12 on the Public Policy Mailing List.

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-2014-12
Anti-hijack Policy

Date: 25 March 2014

Problem Statement:

ARIN should not give research organizations permission to hijack 
prefixes that have already been allocated. Research organizations 
announcing lit aggregates may receive sensitive production traffic 
belonging to live networks during periods of instability.

Section 11.7 describes more than allocation size therefore updating the 
section heading to something more accurate is appropriate.

Policy statement:

Modify the section 11.7 heading to be more accurate. Modify the first 
sentence to prohibit overlapping assignments. Add text at the end to 
define how research allocations should be designated and prohibit LOA's 
without allocations.

11.7 Resource Allocation Guidelines

The Numbering Resources requested come from the global Internet Resource 
space, do not overlap previously assigned space, and are not from 
private or other non-routable Internet Resource space. The allocation 
size should be consistent with the existing ARIN minimum allocation 
sizes, unless small allocations are intended to be explicitly part of 
the experiment. If an organization requires more resource than 
stipulated by the minimum allocation sizes in force at the time of their 
request, their experimental documentation should have clearly described 
and justified why this is required.

All research allocations must be registered publicly in whois. Each 
research allocation will be designated as a research allocation with a 
comment indicating when the allocation will end. ARIN will not issue a 
Letter of Authority (LOA) to route a research prefix unless the 
allocation is properly registered in whois.

Comments:
a. Timetable for implementation: Immediate
b. Anything else:


From mike at iptrading.com  Tue Mar 25 14:32:59 2014
From: mike at iptrading.com (Mike Burns)
Date: Tue, 25 Mar 2014 14:32:59 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <BF0D2CA0-C53F-4FF0-8507-ED1B14A19A78@gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com><5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com><CAMDXq5Nq6j1KJVYF5SZB7fVZKBNJ8Tf9cviv6Pk5u_fYH=KeBw@mail.gmail.com>
	<BF0D2CA0-C53F-4FF0-8507-ED1B14A19A78@gmail.com>
Message-ID: <1CBB85EA024E455FAEC1131CE60A6797@MPC>

Support.


From: Peter Bui 
Sent: Tuesday, March 25, 2014 12:34 PM
To: Martin Hannigan 
Cc: arin-discuss at arin.net ; arin-ppml at arin.net 
Subject: Re: [arin-ppml] Term Limit Proposal

I support




Sent from my iPhone

On Mar 25, 2014, at 9:15 AM, Martin Hannigan <hannigan at gmail.com> wrote:





  I support this.






  On Tue, Mar 25, 2014 at 12:13 PM, Steven Ryerse <SRyerse at eclipse-networks.com> wrote:

    I would support this.





    Steven Ryerse

    President

    100 Ashford Center North, Suite 110, Atlanta, GA  30338

    www.eclipse-networks.com

    770.656.1460 - Cell

    770.399.9099- Office



    <image001.jpg>? Eclipse Networks, Inc.

            Conquering Complex Networks?



    From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Azinger, Marla
    Sent: Tuesday, March 25, 2014 12:06 PM
    To: arin-ppml at arin.net; arin-discuss at arin.net
    Subject: [arin-ppml] Term Limit Proposal



    Having been on the AC for a 6 years I support a term limit for the AC.   



    When on my 4th year I pursued creating a term limit.  At the time I was told this was an action the BOT would have to take.  No action was taken.  Later I inquired on this being submitted as policy since the BOT did not take action.  I was told it would be thrown out since it?s not a matter of policy.  Now with time and reviewing other public posts, I have more hope this will be taken seriously and something done.  I include this small history on my experience to show that the idea of term measures has been around for a  while but for some reason never gained traction.



    I believe a balance between familiarity, hitting a productive stride, burn out and mind melting needs to be balanced out with fresh able minds.  I also believe a solid 3 year break is needed for people to re-integrate as a non-AC person and regroup.  Leaving anyone on a committee for more than 6 years opens the door to stagnation, burn out, and conformity of thinking.  Remember, just because someone is not on the AC any longer does not mean AC folks can?t get advice from them if desired. 



    I propose the following be used for AC:

    -Keep the 3 year terms in place  and add 

    -a 6 year contiguous term limit 

    -a 3 year ineligibility year period after a term ends be it 3year or 6years

    -After 3 year ineligibility is over a person my run for a position on the AC again.







    I believe the BOT should also have some term measures and limits.  However, I am asking someone who has served on the BOT in the past to create a thought out term plan and propose it.  



    To keep this topic on track, I have purposely excluded the discussion of committee member candidate requirements.  This should be a separate topic that also needs discussion in order to better ensure community wide representation.  





    Regards

    Marla Azinger


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


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


--------------------------------------------------------------------------------
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/2413db95/attachment.htm>

From JOHN at egh.com  Tue Mar 25 15:48:24 2014
From: JOHN at egh.com (John Santos)
Date: Tue, 25 Mar 2014 15:48:24 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <5331B679.5060906@burnttofu.net>
Message-ID: <1140325153044.18890C-100000@Ives.egh.com>


I agree with Michael's reasoning for the most part, and generally oppose
term limits.

One caveat that no one has mentioned: in a volunteer run organization like
ARIN, people in leadership postitions may be pressured into continuing,
through direct arguments ("We need you there!") or implicict assumptions
by others that they will continue, or by a sense of responsibility ("If I
don't do this, who will?"), and may find it hard to choose not to run for
re-election even when they feel burned out and non-productive.  A term
limit would give such people a convenient out.

A good test for this is whether there are there usually enough candidates
for all the positions or does some sort of nominating committee need to
drum them up?  If there are plenty of candidates to choose from, a
person at the end of their productive tenure can easily not run again
knowing there are good and eager candidates to replace them.  Also,
an entrenched but non-productive person will likely be replaced.  If
there is a dearth of candidates, then neither of these is true.

As I am not a "member" (in the formal sense, paying dues and being able
to vote), I don't know which of these situations prevails in ARIN.


On Tue, 25 Mar 2014, Michael Sinatra wrote:

> On 03/25/2014 09:15, Andrew Sullivan wrote:
> > On Tue, Mar 25, 2014 at 04:05:47PM +0000, Azinger, Marla wrote:
> >>
> >> I believe a balance between familiarity, hitting a productive
> >> stride, burn out and mind melting needs to be balanced out with
> >> fresh able minds.  I also believe a solid 3 year break is needed for
> >> people to re-integrate as a non-AC person and regroup.  Leaving
> >> anyone on a committee for more than 6 years opens the door to
> >> stagnation, burn out, and conformity of thinking.
> > 
> > So, why make a rule about this instead of trusting the voting members
> > (and the people sitting) to get it right?
> > 
> > That is, I agree with everything you say, but I don't understand why
> > the solution to that is to make an absolute rule that can never be
> > violated in exceptional cases.  What problem are you trying to solve?
> 
> This is the problem with term limits: They're inherently
> anti-democratic.  They (further) limit the range of people for whom the
> voting members can support.  Now, one may argue (as many political
> philosophers have in the past) that too much democracy is a bad thing,
> but grafting term limits onto an electoral process rarely counteracts
> the ill effects of "too much democracy."  In most cases where term
> limits have been imposed (e.g. California, where I live), it has not
> reduced the influence of special interests, it has not deterred "career
> politicians," whether competent or not, and it has not reduced polarization.
> 
> Part of the issue is that term limits don't distinguish between those
> who have become stagnant and those who continue to be valuable contributors.
> 
> Term limits do sometimes make sense in cases where elections can't be
> trusted or for very high offices (e.g. heads of state).  But I don't see
> the need for the AC.  I believe that the AC members are competent and
> self-aware enough to know when it's time to leave.  I also believe that
> informed voters have a similar understanding regarding the performance
> of the AC.
> 
> michael
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 

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



From springer at inlandnet.com  Tue Mar 25 15:51:10 2014
From: springer at inlandnet.com (John Springer)
Date: Tue, 25 Mar 2014 12:51:10 -0700 (PDT)
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>

Hi Marla,

The current PDP requires only two things for a policy proposal to be 
accepted as a Draft Policy, to have a clear problem statement and be in 
scope for the AC.

I am sure all AC members will be delighted to work with you to arrive at 
the former. I am less sure how successful we will be getting around a 
clear statement from the BoT that such matters are not in scope. We can 
certainly give it a shot if that is the way you would prefer to go.

Alternately, all members of the Board of Trustees read these lists,
perhaps they may take the matter up directly from here?

Or they may prefer to receive the question via the suggestion process?

https://www.arin.net/app/suggestion/

The AC has had some recent experience with adopting changes to standing 
rules. Perhaps that might be an option.

There does appear to be a healthy amount of initial support for your idea.
How would you like to proceed?

John Springer


On Tue, 25 Mar 2014, Azinger, Marla wrote:

> 
> Having been on the AC for a 6 years I support a term limit for the AC.??
> 
> ?
> 
> When on my 4th year I pursued creating a term limit.? At the time I was told this was an action the BOT would have to take.? No action was taken.? Later I inquired on
> this being submitted as policy since the BOT did not take action.? I was told it would be thrown out since it?s not a matter of policy. ?Now with time and reviewing
> other public posts, I have more hope this will be taken seriously and something done.? I include this small history on my experience to show that the idea of term
> measures has been around for a? while but for some reason never gained traction.
> 
> ?
> 
> I believe a balance between familiarity, hitting a productive stride, burn out and mind melting needs to be balanced out with fresh able minds.? I also believe a solid
> 3 year break is needed for people to re-integrate as a non-AC person and regroup.? Leaving anyone on a committee for more than 6 years opens the door to stagnation,
> burn out, and conformity of thinking.? Remember, just because someone is not on the AC any longer does not mean AC folks can?t get advice from them if desired.
> 
> ?
> 
> I propose the following be used for AC:
> 
> -Keep the 3 year terms in place ?and add
> 
> -a 6 year contiguous term limit
> 
> -a 3 year ineligibility year period after a term ends be it 3year or 6years
> 
> -After 3 year ineligibility is over a person my run for a position on the AC again.
> 
> ?
> 
> ?
> 
> ?
> 
> I believe the BOT should also have some term measures and limits.? However, I am asking someone who has served on the BOT in the past to create a thought out term plan
> and propose it. ?
> 
> ?
> 
> To keep this topic on track, I have purposely excluded the discussion of committee member candidate requirements.? This should be a separate topic that also needs
> discussion in order to better ensure community wide representation. ?
> 
> ?
> 
> ?
> 
> Regards
> 
> Marla Azinger
> 
> 
>

From scottleibrand at gmail.com  Tue Mar 25 16:08:09 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 25 Mar 2014 13:08:09 -0700
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <1140325153044.18890C-100000@Ives.egh.com>
References: <5331B679.5060906@burnttofu.net>
	<1140325153044.18890C-100000@Ives.egh.com>
Message-ID: <CAGkMwz5J75G63B-4VpLE8y4jc4rRkE63u+CL1EAQoEbqGVJD5Q@mail.gmail.com>

On Tue, Mar 25, 2014 at 12:48 PM, John Santos <JOHN at egh.com> wrote:

>
> I agree with Michael's reasoning for the most part, and generally oppose
> term limits.
>
> One caveat that no one has mentioned: in a volunteer run organization like
> ARIN, people in leadership postitions may be pressured into continuing,
> through direct arguments ("We need you there!") or implicict assumptions
> by others that they will continue, or by a sense of responsibility ("If I
> don't do this, who will?"), and may find it hard to choose not to run for
> re-election even when they feel burned out and non-productive.


Yes, I've seen that first-hand.


>  A term limit would give such people a convenient out.
>

It would also give them a push toward taking a year off and reconsidering
whether they are interested in getting involved again.  (I prefer 1 year
off vs. 3.)


>
> A good test for this is whether there are there usually enough candidates
> for all the positions or does some sort of nominating committee need to
> drum them up?


We have had both situations recently.  Unfortunately, in years where there
are enough candidates, the nominations committee generally limits the
number of candidates who go on the ballot.  This means that if one or more
candidates pulls out of the election after the nomcom has finished its
work, we sometimes end up with too few new candidates to pose a serious
challenge to incumbents.


> If there are plenty of candidates to choose from, a
> person at the end of their productive tenure can easily not run again
> knowing there are good and eager candidates to replace them.


I think we have enough candidates to allow that pretty much every year.


>  Also, an entrenched but non-productive person will likely be replaced.


I can't remember ever seeing this happen.  I don't have the statistics, but
I believe almost all incumbent AC members (productive or not) leave by
resigning, not by losing an election.

-Scott


> If there is a dearth of candidates, then neither of these is true.
>
> As I am not a "member" (in the formal sense, paying dues and being able
> to vote), I don't know which of these situations prevails in ARIN.
>
>
> On Tue, 25 Mar 2014, Michael Sinatra wrote:
>
> > On 03/25/2014 09:15, Andrew Sullivan wrote:
> > > On Tue, Mar 25, 2014 at 04:05:47PM +0000, Azinger, Marla wrote:
> > >>
> > >> I believe a balance between familiarity, hitting a productive
> > >> stride, burn out and mind melting needs to be balanced out with
> > >> fresh able minds.  I also believe a solid 3 year break is needed for
> > >> people to re-integrate as a non-AC person and regroup.  Leaving
> > >> anyone on a committee for more than 6 years opens the door to
> > >> stagnation, burn out, and conformity of thinking.
> > >
> > > So, why make a rule about this instead of trusting the voting members
> > > (and the people sitting) to get it right?
> > >
> > > That is, I agree with everything you say, but I don't understand why
> > > the solution to that is to make an absolute rule that can never be
> > > violated in exceptional cases.  What problem are you trying to solve?
> >
> > This is the problem with term limits: They're inherently
> > anti-democratic.  They (further) limit the range of people for whom the
> > voting members can support.  Now, one may argue (as many political
> > philosophers have in the past) that too much democracy is a bad thing,
> > but grafting term limits onto an electoral process rarely counteracts
> > the ill effects of "too much democracy."  In most cases where term
> > limits have been imposed (e.g. California, where I live), it has not
> > reduced the influence of special interests, it has not deterred "career
> > politicians," whether competent or not, and it has not reduced
> polarization.
> >
> > Part of the issue is that term limits don't distinguish between those
> > who have become stagnant and those who continue to be valuable
> contributors.
> >
> > Term limits do sometimes make sense in cases where elections can't be
> > trusted or for very high offices (e.g. heads of state).  But I don't see
> > the need for the AC.  I believe that the AC members are competent and
> > self-aware enough to know when it's time to leave.  I also believe that
> > informed voters have a similar understanding regarding the performance
> > of the AC.
> >
> > michael
> >
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20140325/b6d418f8/attachment.htm>

From ajs at anvilwalrusden.com  Tue Mar 25 17:13:12 2014
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Tue, 25 Mar 2014 17:13:12 -0400
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAGkMwz4DLw13fz2qz37HJHUp7KDfPOupnQ+GqRRy+d5Zt8HPtg@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAGkMwz4DLw13fz2qz37HJHUp7KDfPOupnQ+GqRRy+d5Zt8HPtg@mail.gmail.com>
Message-ID: <20140325211311.GA47828@mx1.yitter.info>

On Tue, Mar 25, 2014 at 09:59:32AM -0700, Scott Leibrand wrote:
> I support term limits for the AC.  From my experience 6 years is about when
> burnout starts to hit, so I think that's a good time to take a 1 year
> break.  (I considered doing so myself this year, but narrowly decided
> against it and was re-elected for a third 3-year term.)

If I understand the above correctly, you are saying that a term limit
would be a good idea, because when you had to make the decision
yourself you chose the wrong way?

It seems to me that a little bit of social pressure and some
well-placed and -timed advice from others who have previously served
might be at least as effective at achieving the (IMO correct) goal of
lowering the risk that some people will be too long in the saddle,
without the damaging side effects of hard limits that can't be avoided
when something really important comes up.  Just for example, suppose
there was this year a BoT member coming up on the limit who'd been the
primary actor on IANA reforms, and who remained active in that area.
Suppose further that everyone else on the BoT hated everything about
IANA and had historically avoided it like the plague.  Finally,
suppose that this was someone whose professional expertise happened to
include public interest governance.  I suggest that in this particular
(made up) example, the advantages of experience with all these topics,
given what's going on with IANA, would be more valuable than "fresh
eyes" in the middle of the announced transition.  But a hard limit
would not allow that person to serve again.

One of the important things to do when setting a policy is not to
create accidental side effects that are at least as bad as the thing
you're trying to fix.  In this case, it sounds like the advocates of
term limits want them because they don't believe that social pressure
and good judgement on the parts of the incumbents will produce the
right result.  If that is the case, I submit that there are problems
in the organization that term limits won't solve.  Yet term limits
mean that in the exceptional case where someone's skills really are
needed, we might find we can't use them anyway without changing the
policy.  That sounds like a bad policy to me.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From lsawyer at gci.com  Tue Mar 25 17:29:33 2014
From: lsawyer at gci.com (Leif Sawyer)
Date: Tue, 25 Mar 2014 13:29:33 -0800
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <20140325211311.GA47828@mx1.yitter.info>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAGkMwz4DLw13fz2qz37HJHUp7KDfPOupnQ+GqRRy+d5Zt8HPtg@mail.gmail.com>
	<20140325211311.GA47828@mx1.yitter.info>
Message-ID: <18B2C6E38A3A324986B392B2D18ABC5102C6C61819@fnb1mbx01.gci.com>

As somebody who is interested in running for the AC in the future, I have
a concern about term-limits:

IF there were limits, it's possible that by the time I were to be elected,
the people whose experience that I would most value could be gone.  Indeed,
in a "worst-case" scenario, there could be a complete turn-over.

I, for one, don't want to lose all of that experience.

This type of "trust" is completely different than elected political officials.
The inherent checks-and-balances within the AC and BoC prevent any creep of their
vastly limited "power".

In reality, allowing them to cycle in and out as professional and private lives
necessitate allows ARIN and our community to retain the most active and able.


That said, even if there were term limits, I would still run for the AC.
Because I think it's important.



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Sullivan
Sent: Tuesday, March 25, 2014 1:13 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] [arin-discuss] Term Limit Proposal

On Tue, Mar 25, 2014 at 09:59:32AM -0700, Scott Leibrand wrote:
> I support term limits for the AC.  From my experience 6 years is about 
> when burnout starts to hit, so I think that's a good time to take a 1 
> year break.  (I considered doing so myself this year, but narrowly 
> decided against it and was re-elected for a third 3-year term.)

If I understand the above correctly, you are saying that a term limit would be a good idea, because when you had to make the decision yourself you chose the wrong way?

It seems to me that a little bit of social pressure and some well-placed and -timed advice from others who have previously served might be at least as effective at achieving the (IMO correct) goal of lowering the risk that some people will be too long in the saddle, without the damaging side effects of hard limits that can't be avoided when something really important comes up.  Just for example, suppose there was this year a BoT member coming up on the limit who'd been the primary actor on IANA reforms, and who remained active in that area.
Suppose further that everyone else on the BoT hated everything about IANA and had historically avoided it like the plague.  Finally, suppose that this was someone whose professional expertise happened to include public interest governance.  I suggest that in this particular (made up) example, the advantages of experience with all these topics, given what's going on with IANA, would be more valuable than "fresh eyes" in the middle of the announced transition.  But a hard limit would not allow that person to serve again.

One of the important things to do when setting a policy is not to create accidental side effects that are at least as bad as the thing you're trying to fix.  In this case, it sounds like the advocates of term limits want them because they don't believe that social pressure and good judgement on the parts of the incumbents will produce the right result.  If that is the case, I submit that there are problems in the organization that term limits won't solve.  Yet term limits mean that in the exceptional case where someone's skills really are needed, we might find we can't use them anyway without changing the policy.  That sounds like a bad policy to me.

Best regards,

Andrew

--
Andrew Sullivan
ajs at anvilwalrusden.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.



From scottleibrand at gmail.com  Tue Mar 25 18:10:43 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 25 Mar 2014 15:10:43 -0700
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <20140325211311.GA47828@mx1.yitter.info>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAGkMwz4DLw13fz2qz37HJHUp7KDfPOupnQ+GqRRy+d5Zt8HPtg@mail.gmail.com>
	<20140325211311.GA47828@mx1.yitter.info>
Message-ID: <CAGkMwz7mFRim-9Vyw49FU9JmN07z-MTaf0aatPOP1h2r=o7aCQ@mail.gmail.com>

On Tue, Mar 25, 2014 at 2:13 PM, Andrew Sullivan <ajs at anvilwalrusden.com>wrote:

> On Tue, Mar 25, 2014 at 09:59:32AM -0700, Scott Leibrand wrote:
> > I support term limits for the AC.  From my experience 6 years is about
> when
> > burnout starts to hit, so I think that's a good time to take a 1 year
> > break.  (I considered doing so myself this year, but narrowly decided
> > against it and was re-elected for a third 3-year term.)
>
> If I understand the above correctly, you are saying that a term limit
> would be a good idea, because when you had to make the decision
> yourself you chose the wrong way?
>

No, I don't feel like I made the wrong decision.  But this is a collective
action problem: I feel it would be better if all of us took a break every
couple terms.  But until that is normal practice (if not required), I
didn't feel like it would be best for me to resign from the AC, especially
since we only had 7 candidates for what turned out to be 6 AC slots.  If we
had incumbents not running and knew it in advance, I think we could've
gotten stronger new candidates.  And if we didn't, it would be fairly easy
to recruit former AC members who've had a year or more off, and are likely
to be a bit more energetic and productive than those of us who've been
doing it for 6+ years straight.


>
> It seems to me that a little bit of social pressure and some
> well-placed and -timed advice from others who have previously served
> might be at least as effective at achieving the (IMO correct) goal of
> lowering the risk that some people will be too long in the saddle,
> without the damaging side effects of hard limits that can't be avoided
> when something really important comes up.


I think that would be an excellent idea. I'm not sure how to get to that
kind of a norm, though.  The challenge is that all of us want to think well
of ourselves, and admitting when we're no longer at 100% effectiveness is
hard.  It's doubly hard to tell someone *else* you know (and generally
like) that you think they've served too long and should consider not
running again.  If you have any ideas for ways around that, I'm all ears.

I also think it behooves all of us, as those voting in the election (if
we're eligible) and/or writing statements of support for candidates, to
take into consideration which AC members are actually the most effective at
representing the community and crafting good policy (not just which
candidates we like personally, or have the best name recognition).


>  Just for example, suppose
> there was this year a BoT member coming up on the limit who'd been the
> primary actor on IANA reforms, and who remained active in that area.
> Suppose further that everyone else on the BoT hated everything about
> IANA and had historically avoided it like the plague.  Finally,
> suppose that this was someone whose professional expertise happened to
> include public interest governance.  I suggest that in this particular
> (made up) example, the advantages of experience with all these topics,
> given what's going on with IANA, would be more valuable than "fresh
> eyes" in the middle of the announced transition.  But a hard limit
> would not allow that person to serve again.
>

I can see that being a real concern for the BoT, where you actually have to
be on the board to do a lot of the important work of a board member.  But
much of what AC members do can also be done by involved policy authors.  If
I were shepherding a really important policy, and got termed out of the AC,
there's nothing to stop me from continuing to help edit the text, guide the
discussion on PPML, provide input at the PPMs, etc.  And if I stay that
involved over the course of my year off, that's a pretty good sign that I
should probably run for AC again the next year (and would probably get
elected again).


> One of the important things to do when setting a policy is not to
> create accidental side effects that are at least as bad as the thing
> you're trying to fix.  In this case, it sounds like the advocates of
> term limits want them because they don't believe that social pressure
> and good judgement on the parts of the incumbents will produce the
> right result.  If that is the case, I submit that there are problems
> in the organization that term limits won't solve.


I think the problems are with human nature, not with the organization.  We
might be able to solve such problems via various tweaks, but in the absence
of something else that's been shown to help, I still think a soft
contiguous term limit, at least for the AC, would help more than it would
hurt.


>  Yet term limits mean that in the exceptional case where someone's skills
> really are
> needed, we might find we can't use them anyway without changing the
> policy.  That sounds like a bad policy to me.
>

Do you think that concern applies equally to the AC as to the BoT?

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/9e87b021/attachment.htm>

From billdarte at gmail.com  Tue Mar 25 18:22:16 2014
From: billdarte at gmail.com (Bill Darte)
Date: Tue, 25 Mar 2014 17:22:16 -0500
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <CAMApp36TMSjqnDhcwtizxe38rnxss80k3pq1PGJy2X2TCZ2dvg@mail.gmail.com>

Being the poster-child of offense to those who consider term-limits a good
idea.... finishing my 5th elected term(and last) this year....I assure you
I am not replying out of guilt.

I reflect on a quote by Daniel Defoe.  "All evils are to be considered with
the good that is in them, and with what worse attends them."  I do not
object to term limits on either the AC or BoT, but believe as Defoe
apparently did, that there is good news and bad news in everything.  Those
for and against term limits continue to weigh in with good examples and
perspective.

>From personal perspective, I consider that I have contributed more and less
than other members of the AC in past years and largely in different ways
and with different experience and point of view.  I say frankly that I
would have refused to stand for election had a single person ever suggested
that I not. Indeed, I determined to retire two terms ago, but was urged to
stand again and again by members of the community whom I know and trust.
 Incidentally, I believe I garnered more votes than any other candidate in
every election save a single person in 2005.

So, I am ambivalent. Many may have wished I had not run for any of my
terms, but those voices were silent (at least to me) and the voting record
of those who have been engaged in that process have told a different story.
Presumably each one reviewed candidate credentials and heard them state the
case for their candidacy standing before the community.

You can fool some of the people all of the time and all of the people some
of the time.....were all those people fools or fooled by my good looks and
charisma?  I hardly think that is the case.  I deeply respect the community
that contributes to and serves the mission of ARIN.... and who voted for
and against me.

Again, I think there is a good case for either future in the election
process, and I too think this debate is healthy and substantive and is
consistent with our bottom-up, grass roots governance model where
everyone's vote counts.

But, I have a question about what happens to those who are elected to fill
the remainder of another member's term?  Is that considered a term or can
they have two more thereafter?  If not the later, then I suspect that those
interested in being on the AC or BoT might not stand for election or be
unwilling to accept election in years when this is an issue.

bd



On Tue, Mar 25, 2014 at 11:05 AM, Azinger, Marla <Marla.Azinger at ftr.com>wrote:

>  Having been on the AC for a 6 years I support a term limit for the AC.
>
>
>
> When on my 4th year I pursued creating a term limit.  At the time I was
> told this was an action the BOT would have to take.  No action was taken.
> Later I inquired on this being submitted as policy since the BOT did not
> take action.  I was told it would be thrown out since it's not a matter of
> policy.  Now with time and reviewing other public posts, I have more hope
> this will be taken seriously and something done.  I include this small
> history on my experience to show that the idea of term measures has been
> around for a  while but for some reason never gained traction.
>
>
>
> I believe a balance between familiarity, hitting a productive stride, burn
> out and mind melting needs to be balanced out with fresh able minds.  I
> also believe a solid 3 year break is needed for people to re-integrate as a
> non-AC person and regroup.  Leaving anyone on a committee for more than 6
> years opens the door to stagnation, burn out, and conformity of thinking.
> Remember, just because someone is not on the AC any longer does not mean AC
> folks can't get advice from them if desired.
>
>
>
> *I propose the following be used for AC:*
>
> *-Keep the 3 year terms in place  and add *
>
> *-a 6 year contiguous term limit *
>
> *-a 3 year ineligibility year period after a term ends be it 3year or
> 6years*
>
> *-After 3 year ineligibility is over a person my run for a position on the
> AC again.*
>
>
>
>
>
>
>
> I believe the BOT should also have some term measures and limits.
> However, I am asking someone who has served on the BOT in the past to
> create a thought out term plan and propose it.
>
>
>
> To keep this topic on track, I have purposely excluded the discussion of
> committee member candidate requirements.  This should be a separate topic
> that also needs discussion in order to better ensure community wide
> representation.
>
>
>
>
>
> Regards
>
> Marla Azinger
>
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/a57178d5/attachment.htm>

From scottleibrand at gmail.com  Tue Mar 25 19:05:08 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Tue, 25 Mar 2014 16:05:08 -0700
Subject: [arin-ppml] [arin-discuss]  Term Limit Proposal
In-Reply-To: <1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
Message-ID: <CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>

IMO the problem (for the AC, not the BoT) is that all turnover comes from
resignations and people deciding not to run again.  It's very rare that an
incumbent fails to get re-elected.  Given what I've observed as an AC
member of the large diversity in contribution levels from my colleagues on
the AC, both new and old, that's evidence to me that the membership is
re-electing members who are less effective, and we're therefore not getting
the benefit of new ideas and approaches, and the higher willingness to take
on difficult work, that new AC members tend to provide.

Reviewing the results of all the elections since 2007, when I was elected,
I see:

    Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes  2013
4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected  2010
3 2 1 1-year
appointed incumbent not re-elected  2009 3 2 1   2008 2 3   2007 3 2
As you can see, there has only been a single full-term incumbent who was
not re-elected, and that was in a year when there were 5 incumbents on the
ballot.

I think term limits (1 year off after 2 terms) would help get more new
people, with new ideas, approaches, and energy, onto the AC, without unduly
sacrificing experience and continuity.

Of course, there may be other better ways to accomplish the same thing, so
I'd love to hear other ideas for how we can get more fresh faces onto the
AC.  Maybe we could tweak the election process somehow?  One idea I just
had would be to allow advisory input (some sort of straw poll) from PPML
participants that is published for the ARIN membership to review when
casting their votes?

-Scott


On Tue, Mar 25, 2014 at 2:39 PM, Lee Howard <spiffnolee at yahoo.com> wrote:

> Could somebody state more clearly what problem this proposal is trying to
> solve?  I've heard that "organizations tend toward entrenchment" but not
> that ARIN has.  Is the community stagnant?  Is the AC unresponsive to
> evolving thought in the region?  Is the Board inaccessible?  What problem
> would be solved by having new people in those positions?
>
> > Term limits are a must if for nothing else but to prevent
> > what they call "founders syndrome."
>
> There's only one founding Board member still at ARIN, and he's on the
> Board ex-officio: John Curran.  Only Bill Woodcock has more than ten years'
> tenure.
>
> I was a Board member for three years, lost re-election, took a year off,
> then ran again and won.  Two terms later, I lost re-election.  I'm not the
> only one: https://www.arin.net/about_us/bot_former.html
> 15 former Board members (counting myself only twice) for an organization
> that's 16(?) years old doesn't seem stagnant to me.
>
> See also the very long list of former AC members:
> https://www.arin.net/about_us/ac_former.html
> Is it really 46 former AC members?
>
> Looks to me like there's turnover already.  If we need more churn, I would
> want to understand what's broken.
>
> Lee
>
>
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140325/fa85645c/attachment.htm>

From rjletts at uw.edu  Tue Mar 25 20:31:36 2014
From: rjletts at uw.edu (Richard J. Letts)
Date: Wed, 26 Mar 2014 00:31:36 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between
 RSA and 8.2 Utilization Requirements
In-Reply-To: <532CC259.5020605@umn.edu>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>
	<CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>
	<532BD7D6.4000901@matthew.at>
	<CDA64243-36FD-407D-8707-2440E5A7C86B@arin.net>
	<CAMfXtQw9Kyqsbn3F8oZAU9WMjjcYunsOw90=nruaTU8cWQU1Zg@mail.gmail.com>
	<532CC259.5020605@umn.edu>
Message-ID: <6F7ED1C15733994BAF9A4C1CC4479AC83DE4C992@uwit-mbx07.exchange.washington.edu>


> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Farmer
> Sent: Friday, March 21, 2014 3:51 PM
> 
> On 3/21/14, 09:10 , Gary Buhrmaster wrote:
> > <soapbox>
> >
> > Any M&A, or organization changes, have a cost regarding business
> > records, and it is incumbent on the organization to be prepared to pay
> > that cost for changes.  Updating ARIN records (and the cost of doing
> > so) is no different, and should not have a special "out" just because
> > it can be take time or the people involved did/do not want to invest
> > that effort.  The days of informal handshake number deals are (or
> > should be) long over.  Get over it, and do the (boring, painful, but
> > necessary) work.
> >
> > </soapbox>
> 
> I very much agree, there is and almost certainly should be work involved.
> 
> So, yes with any M&A, or other organization change, you should have to the
> "Business Office" part of documenting business records associated with the
> change.  The rationale for this "Business Office" part is clear.  Its
> necessary to prevent fraudulent changes to resources, and ARIN has a clear
> fiduciary responsibility to ensure this happens correctly.

I also agree that getting the ARIN records updated should be a cost of doing business during M&A activities; this is the sort of thing that should be able to be delegated to the finance/business officers and they should deal with whatever is necessary to preserve the assets of the organization. 

I find it frustrating when routing breaks that I can't find the right people to contact about it, and sadly IME it's not small companies that are the worst at this.

Richard Letts


From mueller at syr.edu  Wed Mar 26 01:56:28 2014
From: mueller at syr.edu (Milton L Mueller)
Date: Wed, 26 Mar 2014 05:56:28 +0000
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <75a57066c41b41b9b5215e7e6d667017@EX13-MBX-13.ad.syr.edu>

Agree with Marla, support the proposal. 
--MM

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Azinger, Marla
Sent: Tuesday, March 25, 2014 12:32 PM
To: Andrew Sullivan; arin-ppml at arin.net; 'arin-discuss at arin.net'
Subject: Re: [arin-ppml] Term Limit Proposal

This has nothing to do with trust.  I look at the facts.  History proves that just voting fails.  And the downfall occurs before voting even happens.

-People are less likely to run for a position on the AC knowing they are up against long time incumbents -People are less likely to run for a position on the AC knowing stagnation exists and new thought is not likely to be received well -Familiarity is comfort and subconsciously people lean toward this.  True opportunity for change must be present and not just a perception.

Regards
Marla


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Sullivan
Sent: Tuesday, March 25, 2014 9:15 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Term Limit Proposal

On Tue, Mar 25, 2014 at 04:05:47PM +0000, Azinger, Marla wrote:
> 
> I believe a balance between familiarity, hitting a productive stride, 
> burn out and mind melting needs to be balanced out with fresh able 
> minds.  I also believe a solid 3 year break is needed for people to 
> re-integrate as a non-AC person and regroup.  Leaving anyone on a 
> committee for more than 6 years opens the door to stagnation, burn 
> out, and conformity of thinking.

So, why make a rule about this instead of trusting the voting members (and the people sitting) to get it right?

That is, I agree with everything you say, but I don't understand why the solution to that is to make an absolute rule that can never be violated in exceptional cases.  What problem are you trying to solve?

A

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


From owen at delong.com  Wed Mar 26 01:57:21 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Mar 2014 22:57:21 -0700
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAMDXq5P-FtxqaBLY5MwcFui=tYFWt6ywYf4iD4tFTFWrfgUozQ@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
	<68B45AC82AE0E249A2BF5C40ABA75F5D14886EE0@IDCPRDMBX1.ads.integratelecom.com>
	<8335CAF4177E7A4CBC4670E5F9FA9B415C33B8EA@CRC-Exchange02.corp.clearrate.net>
	<CAMDXq5P-FtxqaBLY5MwcFui=tYFWt6ywYf4iD4tFTFWrfgUozQ@mail.gmail.com>
Message-ID: <2C914EB7-8F78-475F-B507-967423A39976@delong.com>

Speaking only for myself as one of the often more controversial members of the AC, I will say that I have been pleasantly surprised
each time I have been re-elected. While I do vote for myself when applicable, I only have the ability to cast 3 votes as I am the DMR for
three organizations, all ISPs, two of which are pretty small. As such, I think it is pretty hard to make the case for self-perpetuation.

The number resources I hold do not have voting rights as I have chosen not to pay an additional $500 for that privilege. Personally, I think it is a travesty that non-ISP resource holders do not get voting rights without paying an additional fee. I have brought this up many times, but it hasn?t gone anywhere.

At the risk of sounding self-serving, I oppose term limits for the same reasons already articulated by Paul.

Owen

On Mar 25, 2014, at 9:52 AM, Martin Hannigan <hannigan at gmail.com> wrote:

> 
> On Tue, Mar 25, 2014 at 12:33 PM, Paul Timmins <ptimmins at clearrate.com> wrote:
> I have concerns that forcing people out of a position where people repeatedly vote for them is undemocratic,
> 
> Paul,
> 
> It would be interesting to tally the votes available to the respective bodies (all ORG-IDs). I wonder if there is some high level of self perpetuation that term limits might not actual be useful to mitigate and provide for a pro-democratic result?
> 
> Best,
> 
> -M<
> 
>  
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

From owen at delong.com  Wed Mar 26 02:31:41 2014
From: owen at delong.com (Owen DeLong)
Date: Tue, 25 Mar 2014 23:31:41 -0700
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAMApp36TMSjqnDhcwtizxe38rnxss80k3pq1PGJy2X2TCZ2dvg@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAMApp36TMSjqnDhcwtizxe38rnxss80k3pq1PGJy2X2TCZ2dvg@mail.gmail.com>
Message-ID: <7B6C6758-DEA8-441F-BC06-A1060525FD91@delong.com>


On Mar 25, 2014, at 3:22 PM, Bill Darte <billdarte at gmail.com> wrote:

> Being the poster-child of offense to those who consider term-limits a good idea.... finishing my 5th elected term(and last) this year....I assure you I am not replying out of guilt.

In my opinion, this is sad news, indeed. You continue to be a very valuable member of the AC and I believe we and the community have benefited greatly from your input, wisdom, and experience over the years. You are about the least stagnant person I know in that in my experience you have always been open to new ideas and eager to change your thinking in light of new information.

Indeed, if you wanted to run again, I would consider you the poster child for why term limits are a bad idea.

Owen




From mysidia at gmail.com  Wed Mar 26 04:07:00 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 26 Mar 2014 03:07:00 -0500
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
Message-ID: <CAAAwwbWe6ASRR+Fw3NYYMAi-OpMHV0kTG+MuHkxEJB8=1YGo=g@mail.gmail.com>

On Tue, Mar 25, 2014 at 6:05 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> IMO the problem (for the AC, not the BoT) is that all turnover comes from
> resignations and people deciding not to run again.  It's very rare that an
> incumbent fails to get re-elected.  Given what I've observed as an AC
> member of
>

This would tend to suggest that by and large the community is satisfied
with the AC, or at least: the incumbent choices have been considered more
preferable options.

There may not be many options in the first place, and imposing turn limits,
may
be forcing members to elect people they don't want,  by choosing the lesser
of the worst.

the large diversity in contribution levels from my colleagues on the AC,
> both new and old, that's evidence to me that the membership is re-electing
> members who are less effective, and we're therefore not getting the benefit
> of new ideas and approaches, and the higher willingness to take on
> difficult work, that new AC members tend to
>

How is this evidence that members being re-elected are less effective?
How do you measure effectiveness of an AC member?

I am quite sure there is no law of nature that says a committee member
inherently becomes less effective
after serving a certain amount of time,  and it is entirely within reach of
voting members to come to their own conclusion.

I would consider it to likely be orthogonal to the number of terms the AC
member had served.
Although,  the  accumulation of experience, and the ARIN memberships'
continued votes for the person,
are evidence that the community considers the AC member effective to their
satisfaction.


If there is a desire to force churn to occur, in the name of  "encouraging
new ideas and hard work".

Which is really what "Term limits"  means ----  limiting the voting rights
of members, by prohibiting
them from re-electing committee members more than X years.

Perhaps there should be a yearly oscillation in the number of AC members
that will be nominated.
Such as X + 1  members in even numbered years, and  X - 1 members in odd
numbered years.

The addition of 2  more members  in  even numbered years,  provides for
additions that are non-incumbents.

The subtraction of 2 more members in odd numbered years,  effectively means
the  members
then get  to pick  which incumbents they do want to keep on the AC.

Something like that  gets you churn and assures  supposed benefits of new
ideas or other desirable characteristics...  which for some unknown reason
(apparently?) can't come from long-term incumbents?

But leaves the choice with the voting members, as to  which AC members to
keep on,
even beyond magical number of 6 years, or whatever.



> provide.
>
> Reviewing the results of all the elections since 2007, when I was elected,
> I see:
>
>     Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes
> 2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected  2010
> 3 2 1 1-year appointed incumbent not re-elected  2009 3 2 1   2008 2 3
> 2007 3 2
>
>
--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140326/b0204a26/attachment.htm>

From cgrundemann at gmail.com  Wed Mar 26 06:04:58 2014
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 26 Mar 2014 18:04:58 +0800
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAH_b1v5jrtdb3yoF7TEennYv-9xkyv8DSk1E=Ga1Wvzzw4=etA@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<5B9E90747FA2974D91A54FCFA1B8AD1201528E278E@ENI-MAIL.eclipse-networks.com>
	<68B45AC82AE0E249A2BF5C40ABA75F5D14886EE0@IDCPRDMBX1.ads.integratelecom.com>
	<8335CAF4177E7A4CBC4670E5F9FA9B415C33B8EA@CRC-Exchange02.corp.clearrate.net>
	<CAH_b1v5jrtdb3yoF7TEennYv-9xkyv8DSk1E=Ga1Wvzzw4=etA@mail.gmail.com>
Message-ID: <CAC1-dt=d5Y9y2WJG9j9+yV2J9yiMmAV6V7=t-N-rzwWnfdfoHQ@mail.gmail.com>

On Wed, Mar 26, 2014 at 12:58 AM, John Brown <john at citylinkfiber.com> wrote:

> Industry capture is actually something that could be prevented by term
> limits.
>

Exactly the opposite is quite possible, actually. As has been pointed out
already, large organizations can throw a new person into the election (or
large groups of new people even) every time they lose one to term limits
(it's not hard when you have 100,000 employees) - small orgs don't have the
manpower to do this (they likely only have one person even qualified for
the position). Hence term limits could actually help foster industry
capture.

>
> One concern I have is:  Its easier to just click yes on the existing
> people, instead of looking at new candidates, new ideas, etc.
>

Fighting laziness with stupidity seems like a losing battle no matter the
outcome...

>
> Is there a place that shows total number of eligible voters and the actual
> number of votes received, trended over time.    Is the membership well
> represented by high turn out, or is the turn out "the same old people,
> voting for the same people""
>

http://bit.ly/1hqzGVc

>
> The President of the United States is limited to 8 years.
> Many States and City's have term limits on their elected representatives.
> Seems pretty democratic to me.
>

The current United States political system also only allows two candidates
to have any kind of fighting chance in almost all major elections - let's
not rely too heavily on that example of "democracy."

If the U.S. Gov't jumped off a bridge...

Cheers,
~Chris

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



-- 
@ChrisGrundemann
http://chrisgrundemann.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140326/72257677/attachment.htm>

From cgrundemann at gmail.com  Wed Mar 26 06:12:36 2014
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Wed, 26 Mar 2014 18:12:36 +0800
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
Message-ID: <CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>

On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> IMO the problem (for the AC, not the BoT) is that all turnover comes from
> resignations and people deciding not to run again.  It's very rare that an
> incumbent fails to get re-elected.  Given what I've observed as an AC
> member of the large diversity in contribution levels from my colleagues on
> the AC,
>

That is an observation, perhaps even a situation, but not by itself a
problem. From my perspective it simply indicates that the community does a
great job selecting winning candidates initially, those candidates go on to
be solid AC members, and therefor continue to win elections...

both new and old, that's evidence to me that the membership is re-electing
> members who are less effective, and we're therefore not getting the benefit
> of
>

How is it evidence that the membership is re-electing members who are less
effective? Are you saying that YOU are less effective now then in your
first two terms? If not you, than who?


> new ideas and approaches, and the higher willingness to take on difficult
> work, that new AC members tend to provide.
>
> Reviewing the results of all the elections since 2007, when I was elected,
> I see:
>
>     Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes
> 2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected  2010
> 3 2 1 1-year appointed incumbent not re-elected  2009 3 2 1   2008 2 3
> 2007 3 2
> As you can see, there has only been a single full-term incumbent who was
> not re-elected, and that was in a year when there were 5 incumbents on the
> ballot.
>

I see that at least one new person joins the AC EVERY YEAR. Out of five
open positions a minimum 20% turnover is actually pretty fantastic.

>
> I think term limits (1 year off after 2 terms) would help get more new
> people, with new ideas, approaches, and energy, onto the AC, without unduly
> sacrificing experience and continuity.
>
> Of course, there may be other better ways to accomplish the same thing, so
> I'd love to hear other ideas for how we can get more fresh faces onto the
> AC.  Maybe we could tweak the election process somehow?  One idea I just
> had would be to allow advisory input (some sort of straw poll) from PPML
> participants that is published for the ARIN membership to review when
> casting their votes?
>

As others have asked, and you have failed to answer - what is the _problem_
we are trying to solve here? Capable AC members being re-elected is NOT a
problem.

Cheers,
~Chris


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



-- 
@ChrisGrundemann
http://chrisgrundemann.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140326/177d5db5/attachment.htm>

From scottleibrand at gmail.com  Wed Mar 26 13:23:39 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 26 Mar 2014 10:23:39 -0700
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
Message-ID: <CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>

On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com>wrote:

> On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>
>> IMO the problem (for the AC, not the BoT) is that all turnover comes from
>> resignations and people deciding not to run again.  It's very rare that an
>> incumbent fails to get re-elected.  Given what I've observed as an AC
>> member of the large diversity in contribution levels from my colleagues on
>> the AC,
>>
>
> That is an observation, perhaps even a situation, but not by itself a
> problem. From my perspective it simply indicates that the community does a
> great job selecting winning candidates initially, those candidates go on to
> be solid AC members, and therefor continue to win elections...
>

That is a valid interpretation, but my perspective is slightly different.
 I would say it indicates that the community *likes* the people it elects
to the AC.  I think that personal popularity has a disproportionate impact
in re-electing AC members.  It would be better if more information were
readily available to the membership, so they could base their choices on
things like accomplishments and voting records.


> both new and old, that's evidence to me that the membership is re-electing
>> members who are less effective, and we're therefore not getting the benefit
>> of
>>
>
> How is it evidence that the membership is re-electing members who are less
> effective? Are you saying that YOU are less effective now then in your
> first two terms? If not you, than who?
>

Yes, I actually am saying that.  I still believe I am highly effective, but
I found myself "coasting" a bit over the fall/winter, and putting in a lot
less effort than I had in my first few years.  I believe I have mostly
corrected that now, but I definitely see the tendency to start coasting
after a certain amount of time, both in myself and other AC members.


>
>
>> new ideas and approaches, and the higher willingness to take on difficult
>> work, that new AC members tend to provide.
>>
>> Reviewing the results of all the elections since 2007, when I was
>> elected, I see:
>>
>>     Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes
>> 2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected
>> 2010 3 2 1 1-year appointed incumbent not re-elected  2009 3 2 1   2008 2
>> 3   2007 3 2
>> As you can see, there has only been a single full-term incumbent who was
>> not re-elected, and that was in a year when there were 5 incumbents on the
>> ballot.
>>
>
> I see that at least one new person joins the AC EVERY YEAR. Out of five
> open positions a minimum 20% turnover is actually pretty fantastic.
>

Closer to 13% on average (2 AC members out of 15) each year (with a range
of 7-20%), almost all from attrition.  If we had even 3% of full-term
incumbents getting replaced by challengers (1 every 2 years), I would be
quite happy.  But it's actually less than 1%.  IMO that's too low.


>> I think term limits (1 year off after 2 terms) would help get more new
>> people, with new ideas, approaches, and energy, onto the AC, without unduly
>> sacrificing experience and continuity.
>>
>> Of course, there may be other better ways to accomplish the same thing,
>> so I'd love to hear other ideas for how we can get more fresh faces onto
>> the AC.  Maybe we could tweak the election process somehow?  One idea I
>> just had would be to allow advisory input (some sort of straw poll) from
>> PPML participants that is published for the ARIN membership to review when
>> casting their votes?
>>
>
> As others have asked, and you have failed to answer - what is the
> _problem_ we are trying to solve here? Capable AC members being re-elected
> is NOT a problem.
>

Here are some of the problems I see with the AC.  I think term limits would
help with all of them, though it wouldn't be a panacea, and it may be
possible to come up with better solutions to each one of them:

IMO the AC tends to be a little bit slow to incorporate new ideas and
approaches.  More new faces would help with that.  We also tend a little
bit toward becoming a social and travel club.  I don't think that is a
serious problem, yet, but I definitely worry about how many of us stay on
the AC because we like our colleagues and because we like to travel, rather
than because we like to talk about, write, and improve ARIN policy.  I
definitely see that most new AC members are more inclined to spend our time
together talking about policy than most AC members with longer tenures.

Maybe another solution would be to reconsider whether we really need a
15-member AC in the first place.  In all of the other RIRs, they simply
have a policy working group chair and co-chair, and then interested members
of the community do all of the heavy lifting on policy, and on getting a
consensus in the community.  An alternative to think about (and maybe
discuss in Chicago) might be to have proposal authors and wg chairs select
one or more shepherds for each policy proposal, and assign the shepherd the
role of working with the author and community to try to actively forge a
consensus?   I'm not sure if that's a good solution or not, but it's food
for thought, anyway...

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

From Marla.Azinger at FTR.com  Wed Mar 26 13:35:07 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Wed, 26 Mar 2014 17:35:07 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>
Message-ID: <afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>

Hi John

Given the response I think an official proposal needs to be written.  I'm happy to see the acceptance of a written proposal will be received for due process and not turned over to the recycling bin for "not being a policy topic".

I will try to get that turned in this week.

Regards
Marla

-----Original Message-----
From: John Springer [mailto:springer at inlandnet.com] 
Sent: Tuesday, March 25, 2014 12:51 PM
To: Azinger, Marla
Cc: arin-ppml at arin.net; arin-discuss at arin.net
Subject: Re: [arin-discuss] Term Limit Proposal

Hi Marla,

The current PDP requires only two things for a policy proposal to be accepted as a Draft Policy, to have a clear problem statement and be in scope for the AC.

I am sure all AC members will be delighted to work with you to arrive at the former. I am less sure how successful we will be getting around a clear statement from the BoT that such matters are not in scope. We can certainly give it a shot if that is the way you would prefer to go.

Alternately, all members of the Board of Trustees read these lists, perhaps they may take the matter up directly from here?

Or they may prefer to receive the question via the suggestion process?

https://www.arin.net/app/suggestion/

The AC has had some recent experience with adopting changes to standing rules. Perhaps that might be an option.

There does appear to be a healthy amount of initial support for your idea.
How would you like to proceed?

John Springer


On Tue, 25 Mar 2014, Azinger, Marla wrote:

> 
> Having been on the AC for a 6 years I support a term limit for the AC.
> 
> ?
> 
> When on my 4th year I pursued creating a term limit.? At the time I 
> was told this was an action the BOT would have to take.? No action was 
> taken.? Later I inquired on this being submitted as policy since the 
> BOT did not take action.? I was told it would be thrown out since it?s not a matter of policy. ?Now with time and reviewing other public posts, I have more hope this will be taken seriously and something done.? I include this small history on my experience to show that the idea of term measures has been around for a? while but for some reason never gained traction.
> 
> ?
> 
> I believe a balance between familiarity, hitting a productive stride, 
> burn out and mind melting needs to be balanced out with fresh able 
> minds.? I also believe a solid
> 3 year break is needed for people to re-integrate as a non-AC person 
> and regroup.? Leaving anyone on a committee for more than 6 years opens the door to stagnation, burn out, and conformity of thinking.? Remember, just because someone is not on the AC any longer does not mean AC folks can?t get advice from them if desired.
> 
> ?
> 
> I propose the following be used for AC:
> 
> -Keep the 3 year terms in place ?and add
> 
> -a 6 year contiguous term limit
> 
> -a 3 year ineligibility year period after a term ends be it 3year or 
> 6years
> 
> -After 3 year ineligibility is over a person my run for a position on the AC again.
> 
> ?
> 
> ?
> 
> ?
> 
> I believe the BOT should also have some term measures and limits.? 
> However, I am asking someone who has served on the BOT in the past to create a thought out term plan and propose it.
> 
> ?
> 
> To keep this topic on track, I have purposely excluded the discussion 
> of committee member candidate requirements.? This should be a separate topic that also needs discussion in order to better ensure community wide representation.
> 
> ?
> 
> ?
> 
> Regards
> 
> Marla Azinger
> 
> 
>


From jcurran at arin.net  Wed Mar 26 14:06:24 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 26 Mar 2014 18:06:24 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>
	<afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <358A138A-912D-4A9C-BAEB-9316083D80BE@arin.net>

On Mar 27, 2014, at 1:35 AM, Azinger, Marla <Marla.Azinger at FTR.com> wrote:

> Hi John
> 
> Given the response I think an official proposal needs to be written.  I'm happy to see the acceptance of a written proposal will be received for due process and not turned over to the recycling bin for "not being a policy topic".

If the ARIN AC wishes to discuss terms limits for the ARIN AC, then that 
is something that may do at any time and in fact are quite capable of 
voluntarily enforcement thereof...  No ARIN policy proposal is necessary, 
and in fact, it would be out of scope for the policy development process.

If mandatory terms limits are desired for the ARIN Board of Trustees or
ARIN AC, it would be best to write up the specific suggestion and submit
the ARIN consultation and suggestion process, as noted by John Springer.
I will bring the proposal and results of the discussion of the proposal
on the arin-consult mailing list to the ARIN Board of Trustees for their
further consideration.

Thanks!
/John

John Curran
President and CEO
ARIN



From cgrundemann at gmail.com  Wed Mar 26 14:19:29 2014
From: cgrundemann at gmail.com (Chris Grundemann)
Date: Thu, 27 Mar 2014 02:19:29 +0800
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
Message-ID: <CAC1-dtk=-Q=ytJuTuZ6i=x50wCtn2xaGrqUPp-MWBQc_pex7Dg@mail.gmail.com>

On Thu, Mar 27, 2014 at 1:23 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com>wrote:
>
>> On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>>
>>> IMO the problem (for the AC, not the BoT) is that all turnover comes
>>> from resignations and people deciding not to run again.  It's very rare
>>> that an incumbent fails to get re-elected.  Given what I've observed as an
>>> AC member of the large diversity in contribution levels from my colleagues
>>> on the AC,
>>>
>>
>> That is an observation, perhaps even a situation, but not by itself a
>> problem. From my perspective it simply indicates that the community does a
>> great job selecting winning candidates initially, those candidates go on to
>> be solid AC members, and therefor continue to win elections...
>>
>
> That is a valid interpretation, but my perspective is slightly different.
>  I would say it indicates that the community *likes* the people it elects
> to the AC.  I think that personal popularity has a disproportionate impact
> in re-electing AC members.  It would be better if more information were
> readily available to the membership, so they could base their choices on
> things like accomplishments and voting records.
>

That information is readily available:
PPML is publicly archived: http://lists.arin.net/pipermail/arin-ppml/
All AC meeting minutes including vote counts are publicly archived:
https://www.arin.net/about_us/ac/
All AC presentations at PPMs and PPCs are publicly archived:
https://www.arin.net/participate/meetings/past_meetings.html

I can not say why people vote the way they do (I've never cast an ARIN
ballot) but to say the information on AC members is not available is simply
NOT true.

>
>
>> both new and old, that's evidence to me that the membership is
>>> re-electing members who are less effective, and we're therefore not getting
>>> the benefit of
>>>
>>
>> How is it evidence that the membership is re-electing members who are
>> less effective? Are you saying that YOU are less effective now then in your
>> first two terms? If not you, than who?
>>
>
> Yes, I actually am saying that.  I still believe I am highly effective,
> but I found myself "coasting" a bit over the fall/winter, and putting in a
> lot less effort than I had in my first few years.  I believe I have mostly
> corrected that now, but I definitely see the tendency to start coasting
> after a certain amount of time, both in myself and other AC members.
>

If you can no longer do the work, resign (maybe like those past AC members
who left through "attrition" stepped down due to this knowledge of
themselves). The fact that you feel bad for not doing your best for a time
is testament to your character, but not a valid rationale for term limits.
I did not observe what you say you did in my three years on the AC. In
fact, I found many of the longest standing AC members to be the most active
and helpful.

>
>
>>
>>
>>> new ideas and approaches, and the higher willingness to take on
>>> difficult work, that new AC members tend to provide.
>>>
>>> Reviewing the results of all the elections since 2007, when I was
>>> elected, I see:
>>>
>>>     Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes
>>> 2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected
>>> 2010 3 2 1 1-year appointed incumbent not re-elected  2009 3 2 1   2008
>>> 2 3   2007 3 2
>>> As you can see, there has only been a single full-term incumbent who was
>>> not re-elected, and that was in a year when there were 5 incumbents on the
>>> ballot.
>>>
>>
>> I see that at least one new person joins the AC EVERY YEAR. Out of five
>> open positions a minimum 20% turnover is actually pretty fantastic.
>>
>
> Closer to 13% on average (2 AC members out of 15) each year (with a range
> of 7-20%), almost all from attrition.  If we had even 3% of full-term
> incumbents getting replaced by challengers (1 every 2 years), I would be
> quite happy.  But it's actually less than 1%.  IMO that's too low.
>

As I said above, burnt out AC members leaving intentionally is actually a
sign of a working system of trust, not a need for term limits.

Also, let's not start making the "maths" fit your views, stick to the facts
(as you present them above):
 - 5 seats are up for grabs in each election (appointments are additional
sometimes when someone steps down)
 - in EVERY election you list, at least one new member was elected
 - 1 out of 5 is 20% of that election cycle (you can't take it as a
percentage of the 10 that aren't up for election, of course they maintain
their seat that year, counting otherwise is disingenuous at best)
 - 2 out of 5 is 40% and 3 out of 5 is 60%
 - That makes 20-60% new AC members in _every_ election you list

>
>
>>> I think term limits (1 year off after 2 terms) would help get more new
>>> people, with new ideas, approaches, and energy, onto the AC, without unduly
>>> sacrificing experience and continuity.
>>>
>>> Of course, there may be other better ways to accomplish the same thing,
>>> so I'd love to hear other ideas for how we can get more fresh faces onto
>>> the AC.  Maybe we could tweak the election process somehow?  One idea I
>>> just had would be to allow advisory input (some sort of straw poll) from
>>> PPML participants that is published for the ARIN membership to review when
>>> casting their votes?
>>>
>>
>> As others have asked, and you have failed to answer - what is the
>> _problem_ we are trying to solve here? Capable AC members being re-elected
>> is NOT a problem.
>>
>
> Here are some of the problems I see with the AC.  I think term limits
> would help with all of them, though it wouldn't be a panacea, and it may be
> possible to come up with better solutions to each one of them:
>
> IMO the AC tends to be a little bit slow to incorporate new ideas and
> approaches.  More new faces would help with that.  We also tend a little
> bit toward becoming a social and travel club.  I don't think that is a
> serious problem, yet, but I definitely worry about how many of us stay on
> the AC because we like our colleagues and because we like to travel, rather
> than because we like to talk about, write, and improve ARIN policy.  I
> definitely see that most new AC members are more inclined to spend our time
> together talking about policy than most AC members with longer tenures.
>

Thank you for listing what you see as actual problems. That is a huge step
forward. I have to say that I don't agree with you though. In my time on
the AC, the longest standing members where the least likely to be "perks"
driven and had the most thoughtful answers to new situations.

>
> Maybe another solution would be to reconsider whether we really need a
> 15-member AC in the first place.  In all of the other RIRs, they simply
> have a
>

You want more new blood by having less people involved... Does not compute.

policy working group chair and co-chair, and then interested members of the
> community do all of the heavy lifting on policy, and on getting a consensus
> in the community.  An alternative to think about (and maybe discuss in
> Chicago) might be to have proposal authors and wg chairs select one or
> more shepherds for each policy proposal, and assign the shepherd the role
> of working with the author and community to try to actively forge a
> consensus?   I'm not sure if that's a good solution or not, but it's food
> for thought, anyway...
>

Expecting these "policy shepherds" to appear whenever needed may be a tad
utopian. However, I applaud the offer of alternate ideas. If the community
can first agree on a problem statement, and then work out the best solution
to that problem by evaluating all the options, I will happily support the
outcome. Right now we have a solution with no clearly defined or agreed
upon problem seeking approval with little rationale. Let's be a tad more
diligent and honest is all I'm asking.

Cheers,
~Chris


> -Scott
>
>


-- 
@ChrisGrundemann
http://chrisgrundemann.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140327/c54a52f8/attachment.htm>

From billdarte at gmail.com  Wed Mar 26 14:53:38 2014
From: billdarte at gmail.com (Bill Darte)
Date: Wed, 26 Mar 2014 13:53:38 -0500
Subject: [arin-ppml] [arin-discuss]  Term Limit Proposal
In-Reply-To: <CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
Message-ID: <CAMApp36CkSqZHPW+Cy=aitQiH5RPcKSgBLz5Ti45bkV_F-dSPg@mail.gmail.com>

Scott said:
"IMO the AC tends to be a little bit slow to incorporate new ideas and
approaches.  More new faces would help with that.  We also tend a little
bit toward becoming a social and travel club.  I don't think that is a
serious problem, yet, but I definitely worry about how many of us stay on
the AC because we like our colleagues and because we like to travel, rather
than because we like to talk about, write, and improve ARIN policy.  I
definitely see that most new AC members are more inclined to spend our time
together talking about policy than most AC members with longer tenures."


Scott, I am interested to know more about what you consider examples of new
ideas and approaches.... given the highly scripted role of the AC in
support of the PDP, and given the schedules for AC and ARIN meetings, our
standing rules and Robert's Rules all guiding our process and activities.
 Also, we as a body are most often criticized IMO for being too liberal in
our interpretations and support for policy proposals that are re-hashes of
ideas disposed of in the past or for continuing to engage with proposals
that are 'moving deck chairs' or v4 exhaustion which the community has
consistently asked us to stop doing.  I'm sure many would say our workload
is artificially high now.

I do not agree that the AC is tending toward becoming a social and travel
club...I think everyone takes their duties and role in travel seriously,
but I find no fault with people endeavoring to know one another better, to
understand where they are coming from and to build relationships.  More
quality change comes through trust than any other organizational or
technical skill IMO. And, listening is as important a skill as is speaking
when it comes to understanding policy issues and other's perspectives.

In our volunteer role, we all spend a great deal of time with policy
proposals and policy discussion at meetings and in between.  If we have our
different approaches and a diversity of people on the AC, you can thank the
founders of ARIN and the electorate of the membership community.  It seems
to me your are arguing for less diversity in approaches than more in some
ways.


On Wed, Mar 26, 2014 at 12:23 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com>wrote:
>
>> On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>>
>>> IMO the problem (for the AC, not the BoT) is that all turnover comes
>>> from resignations and people deciding not to run again.  It's very rare
>>> that an incumbent fails to get re-elected.  Given what I've observed as an
>>> AC member of the large diversity in contribution levels from my colleagues
>>> on the AC,
>>>
>>
>> That is an observation, perhaps even a situation, but not by itself a
>> problem. From my perspective it simply indicates that the community does a
>> great job selecting winning candidates initially, those candidates go on to
>> be solid AC members, and therefor continue to win elections...
>>
>
> That is a valid interpretation, but my perspective is slightly different.
>  I would say it indicates that the community *likes* the people it elects
> to the AC.  I think that personal popularity has a disproportionate impact
> in re-electing AC members.  It would be better if more information were
> readily available to the membership, so they could base their choices on
> things like accomplishments and voting records.
>
>
>> both new and old, that's evidence to me that the membership is
>>> re-electing members who are less effective, and we're therefore not getting
>>> the benefit of
>>>
>>
>> How is it evidence that the membership is re-electing members who are
>> less effective? Are you saying that YOU are less effective now then in your
>> first two terms? If not you, than who?
>>
>
> Yes, I actually am saying that.  I still believe I am highly effective,
> but I found myself "coasting" a bit over the fall/winter, and putting in a
> lot less effort than I had in my first few years.  I believe I have mostly
> corrected that now, but I definitely see the tendency to start coasting
> after a certain amount of time, both in myself and other AC members.
>
>
>>
>>
>>> new ideas and approaches, and the higher willingness to take on
>>> difficult work, that new AC members tend to provide.
>>>
>>> Reviewing the results of all the elections since 2007, when I was
>>> elected, I see:
>>>
>>>     Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes
>>> 2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected
>>> 2010 3 2 1 1-year appointed incumbent not re-elected  2009 3 2 1   2008
>>> 2 3   2007 3 2
>>> As you can see, there has only been a single full-term incumbent who was
>>> not re-elected, and that was in a year when there were 5 incumbents on the
>>> ballot.
>>>
>>
>> I see that at least one new person joins the AC EVERY YEAR. Out of five
>> open positions a minimum 20% turnover is actually pretty fantastic.
>>
>
> Closer to 13% on average (2 AC members out of 15) each year (with a range
> of 7-20%), almost all from attrition.  If we had even 3% of full-term
> incumbents getting replaced by challengers (1 every 2 years), I would be
> quite happy.  But it's actually less than 1%.  IMO that's too low.
>
>
>>> I think term limits (1 year off after 2 terms) would help get more new
>>> people, with new ideas, approaches, and energy, onto the AC, without unduly
>>> sacrificing experience and continuity.
>>>
>>> Of course, there may be other better ways to accomplish the same thing,
>>> so I'd love to hear other ideas for how we can get more fresh faces onto
>>> the AC.  Maybe we could tweak the election process somehow?  One idea I
>>> just had would be to allow advisory input (some sort of straw poll) from
>>> PPML participants that is published for the ARIN membership to review when
>>> casting their votes?
>>>
>>
>> As others have asked, and you have failed to answer - what is the
>> _problem_ we are trying to solve here? Capable AC members being re-elected
>> is NOT a problem.
>>
>
> Here are some of the problems I see with the AC.  I think term limits
> would help with all of them, though it wouldn't be a panacea, and it may be
> possible to come up with better solutions to each one of them:
>
> IMO the AC tends to be a little bit slow to incorporate new ideas and
> approaches.  More new faces would help with that.  We also tend a little
> bit toward becoming a social and travel club.  I don't think that is a
> serious problem, yet, but I definitely worry about how many of us stay on
> the AC because we like our colleagues and because we like to travel, rather
> than because we like to talk about, write, and improve ARIN policy.  I
> definitely see that most new AC members are more inclined to spend our time
> together talking about policy than most AC members with longer tenures.
>
> Maybe another solution would be to reconsider whether we really need a
> 15-member AC in the first place.  In all of the other RIRs, they simply
> have a policy working group chair and co-chair, and then interested members
> of the community do all of the heavy lifting on policy, and on getting a
> consensus in the community.  An alternative to think about (and maybe
> discuss in Chicago) might be to have proposal authors and wg chairs
> select one or more shepherds for each policy proposal, and assign the
> shepherd the role of working with the author and community to try to
> actively forge a consensus?   I'm not sure if that's a good solution or
> not, but it's food for thought, anyway...
>
> -Scott
>
>
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140326/74038e92/attachment.htm>

From springer at inlandnet.com  Wed Mar 26 14:58:58 2014
From: springer at inlandnet.com (John Springer)
Date: Wed, 26 Mar 2014 11:58:58 -0700 (PDT)
Subject: [arin-ppml] [arin-discuss]  Term Limit Proposal
In-Reply-To: <CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1403261118070.48789@mail.inlandnet.com>

It's going to be a little hard to know to whom I am replying due to 
non-indentation of replies, but I'll do my best.

On Wed, 26 Mar 2014, Scott Leibrand wrote:

> On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:
>       On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>       IMO the problem (for the AC, not the BoT) is that all turnover comes from resignations and people deciding not to run again. ?It's very rare that an
>       incumbent fails to get re-elected. ?Given what I've observed as an AC member of the large diversity in contribution levels from my colleagues on the
>       AC,
> 
> 
> That is an observation, perhaps even a situation, but not by itself a problem. From my perspective it simply indicates that the community does a great job
> selecting winning candidates initially, those candidates go on to be solid AC members, and therefor continue to win elections...

I agree that this does not yet seem to rise to the level of a problem. 
There seems to be rather a lot of new and new/old faces (Kevin, myself, 
Milton, Tina, Andrew) lately.

> That is a valid interpretation, but my perspective is slightly different. ?I would say it indicates that the community *likes* the people it elects to the AC. ?I think
> that personal popularity has a disproportionate impact in re-electing AC members. ?It would be better if more information were readily available to the membership, so
> they could base their choices on things like accomplishments and voting records.

More information is always good. Four of the above five having not been 
re-elected, I don't know what conclusions can be drawn about our 
popularity. How well people are *liked* and questions of how popular 
people are recall to me a particularly odious time in my life prior to 
military service. If, in fact, that is what is going on here, perhaps we 
can address that particular matter in a more targeted way than term 
limits. I can recall some pretty candid discussions that have taken place.

>       both new and old, that's evidence to me that the membership is re-electing members who are less effective, and we're therefore not getting the
>       benefit of
> 
> 
> How is it evidence that the membership is re-electing members who are less effective? Are you saying that YOU are less effective now then in your first two
> terms? If not you, than who?
> 
> 
> Yes, I actually am saying that. ?I still believe I am highly effective, but I found myself "coasting" a bit over the fall/winter, and putting in a lot less effort than
> I had in my first few years. ?I believe I have mostly corrected that now, but I definitely see the tendency to start coasting after a certain amount of time, both in
> myself and other AC members.

Well, don't do that then. Term limits are not the answer for this 
situation. Surely you aren't suggesting that if terms limits were in 
place, this mid-term ennui would not have occured.
       ?
>       new ideas and approaches, and the higher willingness to take on difficult work, that new AC members tend to provide.
> Reviewing the results of all the elections since 2007, when I was elected, I see:
> 
> Year
> Re-elected
> Newly Elected
> Newly appointed
> NOT Re-elected
> Notes
> 2013
> 4
> 1
> 1
> 2012
> 4
> 1
> 1
> 2011
> 4
> 1
> 1
> 3-year incumbent not re-elected
> 2010
> 3
> 2
> 1
> 1-year appointed incumbent not re-elected
> 2009
> 3
> 2
> 1
> 2008
> 2
> 3
> 2007
> 3
> 2
> 
> As you can see, there has only been a single full-term incumbent who was not re-elected, and that was in a year when there were 5 incumbents on the ballot.

I'm not immediately seeing any conclusion to be inferred from this 
observation.

> I see that at least one new person joins the AC EVERY YEAR. Out of five open positions a minimum 20% turnover is actually pretty fantastic.
> 
> 
> Closer to 13% on average (2 AC members out of 15) each year (with a range of 7-20%), almost all from attrition. ?If we had even 3% of full-term incumbents getting
> replaced by challengers (1 every 2 years), I would be quite happy. ?But it's actually less than 1%. ?IMO that's too low.

But higher lately, right?

> I think term limits (1 year off after 2 terms) would help get more new people, with new ideas, approaches, and energy, onto the AC, without unduly
> sacrificing experience and continuity.
> 
> Of course, there may be other better ways to accomplish the same thing, so I'd love to hear other ideas for how we can get more fresh faces onto the AC.
> ?Maybe we could tweak the election process somehow? ?One idea I just had would be to allow advisory input (some sort of straw poll) from PPML participants
> that is published for the ARIN membership to review when casting their votes?
> 
> 
> As others have asked, and you have failed to answer - what is the _problem_ we are trying to solve here? Capable AC members being re-elected is NOT a problem.
> 
> 
> Here are some of the problems I see with the AC. ?I think term limits would help with all of them, though it wouldn't be a panacea, and it may be possible to come up
> with better solutions to each one of them:

Take these one at a time.

> IMO the AC tends to be a little bit slow to incorporate?new ideas and 
> approaches.  More new faces would help with that. ?

Speaking as one of those new faces, I can say with some authority that I 
approach the idea of floating a lot of new ideas and approaches with some 
caution. I am getting a little more willing to take some risks with 
experience, but a case could be made that I at least am more conservative 
than many old timers.

> We also tend a little bit toward becoming a
> social and travel club. ?I don't think that is a serious problem, yet, but I definitely worry about how many of us stay on the AC because we like our colleagues and
> because we like to travel, rather than because we like to talk about, write, and improve ARIN policy. ?I definitely see that most new AC members are more inclined to
> spend our time together talking about policy than most AC members with longer tenures.

This is a bit of a tautological approach. The f2f experience is superior 
to the list in some ways. We need to travel to get f2f. We tend to like 
the f2f experience. Therefore, our motivation is exclusively to be a 
travel and social club. I have heard the grumbling about policy weenie 
wannabies junketing about on endless boondogles, but that is not the way 
it seems to me. Again, if this is a specific problem, let's air it out. 
Term limits seems like a particularly ineffective approach to this one.

> Maybe another solution would be to reconsider whether we really need a 15-member AC in the first place. ?

We did talk about this at some length. I am not against raising the 
subject again.

> In all of the other RIRs,

In addition to being a statement of fact, this is also an appeal to the 
bandwagon, and thus an insufficient reason for action. When I have seen 
such an observation floated in other fora, the response has sometimes been 
that the RIR system is ideal for each region to do things in their own 
way.

> they simply have a policy working
> group chair and co-chair, and then interested members of the community do all of the heavy lifting on policy, and on getting a consensus in the community. ?An
> alternative to think about (and maybe discuss in Chicago) might be?to have proposal authors and wg chairs select one or more shepherds for each policy proposal, and
> assign the shepherd the role of working with the author and community to try to actively forge a consensus? ? I'm not sure if that's a good solution or not, but it's
> food for thought, anyway...

OK, I'm game. But it looks like a lot of ground to cover from here to 
there. It might make a nice change from deck chairs though. Is 
restructuring the AC in scope for the AC?

> -Scott

John Springer

From jcurran at arin.net  Wed Mar 26 15:23:26 2014
From: jcurran at arin.net (John Curran)
Date: Wed, 26 Mar 2014 19:23:26 +0000
Subject: [arin-ppml] [arin-discuss]  Term Limit Proposal
In-Reply-To: <alpine.BSF.2.00.1403261118070.48789@mail.inlandnet.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
	<alpine.BSF.2.00.1403261118070.48789@mail.inlandnet.com>
Message-ID: <CACF438E-FAA2-469D-8E83-279A27B55000@arin.net>

On Mar 27, 2014, at 2:58 AM, John Springer <springer at inlandnet.com> wrote:

> OK, I'm game. But it looks like a lot of ground to cover from here to there. It might make a nice change from deck chairs though. Is restructuring the AC in scope for the AC?

The scope of the ARIN AC is Internet numbering resource policies and 
related matters such as internal guidelines that it needs to perform
its work.

Any members of the community (AC or not) can suggest a change to how
the AC is structured; such proposals should be submitted to the ARIN
consultation and suggestion process (as noted earlier) so the larger
community can discuss the proposal and the results taken to the ARIN
Board of Trustees for their consideration.

Thanks!
/John

John Curran
President and CEO
ARIN





From David.Huberman at microsoft.com  Wed Mar 26 16:36:14 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Wed, 26 Mar 2014 20:36:14 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict
	Between	RSA and 8.2 Utilization Requirements
In-Reply-To: <184A5AF5-1CDA-4AE8-B744-223083E3692F@delong.com>
References: <531633BD.1010109@arin.net>
	<CADricwrHhF-66Y5vYnfjZmv8y08VDq_-9FdCn36uQ+R44-SLLg@mail.gmail.com>
	<2ADB2063-DB59-427D-9610-2E7B7B427A66@delong.com>
	<b455c36415d040e5bef6d0b750ff82db@DM2PR03MB398.namprd03.prod.outlook.com>
	<F3735387-F28E-48D5-8003-E72D596516C2@twcable.com>
	<CAMDXq5PeOcM90q3A5CmatP2HAhE-mg0wKVF-nLu93WLWi-APiw@mail.gmail.com>
	<532BD7D6.4000901@matthew.at>
	<CDA64243-36FD-407D-8707-2440E5A7C86B@arin.net>
	<CAMfXtQw9Kyqsbn3F8oZAU9WMjjcYunsOw90=nruaTU8cWQU1Zg@mail.gmail.com>
	<532CC259.5020605@umn.edu>
	<184A5AF5-1CDA-4AE8-B744-223083E3692F@delong.com>
Message-ID: <b920c0472d5e4dd69fd2791307806873@DM2PR03MB398.namprd03.prod.outlook.com>

Hello,

In discussing opposition to 2014-9, and why audited needs-basis is still very much important,
Owen laid out the following point in support of needs assessments in NRPM 8.2:

> 1. To raise the visibility when an 8.3 transfer is being attempted through structures designed 
> to disguise it as an 8.2 transfer.

My response:

I read this as an anti-speculation argument.  It has been asserted in PPML over the years that
there exists the possibility of well-capitalized actors coming into the IPv4 market, buying up 
tracts of available space, and then artificially raising the prices for the sole purpose of making 
a profit.  This would be a bad thing to genuine needers of IPv4.  By making policy levers a
certain way, ARIN policy can quash those behaviors before they develop. It's a clear and concise 
argument that has, so far, won out in the policy development process 

The counter argument over the years has been equally consistent: markets work, let the
markets be markets, ARIN shouldn't impede on markets.  (That's my lay understanding, 
anyway. I am an engineer, not an arm chair economist.)

I think the quoted text is the most compelling argument against part of my 2014-9 proposal, 
because Owen's probably right: it would be a great way for a speculator to get around the
24-month rule that exists in NRPM 8.3.

It's been a few years (I think) since the ARIN PPML community has really argued through the 
speculator-vs-free market argument in a substantive policy discussion, so maybe Chicago is 
the right venue to see where the community's feelings tend towards nowadays. 

/david


From jschiller at google.com  Wed Mar 26 20:20:12 2014
From: jschiller at google.com (Jason Schiller)
Date: Wed, 26 Mar 2014 20:20:12 -0400
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
Message-ID: <CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>

On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com>
 wrote:
| Here are some of the problems I see with the AC.  I think term limits
would
| help with all of them, though it wouldn't be a panacea, and it may be
| possible to come up with better solutions to each one of them:

I wonder if it would be worth while to list the suggested deficiencies, and
the suggested solutions, then let the community collectively judge which
deficiencies are problematic, and with solution(s) best solve the most
problematic issues with the smallest collateral damage.

Martin Hannigan suggested a 365 degree assessment.  This could give the
community a peak into how the AC evaluates each other's work contribution,
and effectiveness, which may give the community more to go on when voting
than a popularity contest.

Jimmy Hess suggested:
a yearly oscillation in the number of AC members that will be nominated.
Such as X + 1  members in even numbered years, and  X - 1 members in odd
numbered years.

We might also consider making Bill Darte's seat an appointed position and
require the appointment to be filled with someone who has never been on the
AC.  It could continue to have a three year term, or could be shortened.

Rather than an appointment, we could fill Bill Darte's seat by a separate
election.  In this case four seats could be elected out of the pool of
candidates, and the fifth seat would be filled by the candidate who has the
most votes that has never served on the AC.

___Jason



On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com>wrote:
>
>> On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>>
>>> IMO the problem (for the AC, not the BoT) is that all turnover comes
>>> from resignations and people deciding not to run again.  It's very rare
>>> that an incumbent fails to get re-elected.  Given what I've observed as an
>>> AC member of the large diversity in contribution levels from my colleagues
>>> on the AC,
>>>
>>
>> That is an observation, perhaps even a situation, but not by itself a
>> problem. From my perspective it simply indicates that the community does a
>> great job selecting winning candidates initially, those candidates go on to
>> be solid AC members, and therefor continue to win elections...
>>
>
> That is a valid interpretation, but my perspective is slightly different.
>  I would say it indicates that the community *likes* the people it elects
> to the AC.  I think that personal popularity has a disproportionate impact
> in re-electing AC members.  It would be better if more information were
> readily available to the membership, so they could base their choices on
> things like accomplishments and voting records.
>
>
>> both new and old, that's evidence to me that the membership is
>>> re-electing members who are less effective, and we're therefore not getting
>>> the benefit of
>>>
>>
>> How is it evidence that the membership is re-electing members who are
>> less effective? Are you saying that YOU are less effective now then in your
>> first two terms? If not you, than who?
>>
>
> Yes, I actually am saying that.  I still believe I am highly effective,
> but I found myself "coasting" a bit over the fall/winter, and putting in a
> lot less effort than I had in my first few years.  I believe I have mostly
> corrected that now, but I definitely see the tendency to start coasting
> after a certain amount of time, both in myself and other AC members.
>
>
>>
>>
>>> new ideas and approaches, and the higher willingness to take on
>>> difficult work, that new AC members tend to provide.
>>>
>>> Reviewing the results of all the elections since 2007, when I was
>>> elected, I see:
>>>
>>>     Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes
>>> 2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected
>>> 2010 3 2 1 1-year appointed incumbent not re-elected  2009 3 2 1   2008
>>> 2 3   2007 3 2
>>> As you can see, there has only been a single full-term incumbent who was
>>> not re-elected, and that was in a year when there were 5 incumbents on the
>>> ballot.
>>>
>>
>> I see that at least one new person joins the AC EVERY YEAR. Out of five
>> open positions a minimum 20% turnover is actually pretty fantastic.
>>
>
> Closer to 13% on average (2 AC members out of 15) each year (with a range
> of 7-20%), almost all from attrition.  If we had even 3% of full-term
> incumbents getting replaced by challengers (1 every 2 years), I would be
> quite happy.  But it's actually less than 1%.  IMO that's too low.
>
>
>>> I think term limits (1 year off after 2 terms) would help get more new
>>> people, with new ideas, approaches, and energy, onto the AC, without unduly
>>> sacrificing experience and continuity.
>>>
>>> Of course, there may be other better ways to accomplish the same thing,
>>> so I'd love to hear other ideas for how we can get more fresh faces onto
>>> the AC.  Maybe we could tweak the election process somehow?  One idea I
>>> just had would be to allow advisory input (some sort of straw poll) from
>>> PPML participants that is published for the ARIN membership to review when
>>> casting their votes?
>>>
>>
>> As others have asked, and you have failed to answer - what is the
>> _problem_ we are trying to solve here? Capable AC members being re-elected
>> is NOT a problem.
>>
>
> Here are some of the problems I see with the AC.  I think term limits
> would help with all of them, though it wouldn't be a panacea, and it may be
> possible to come up with better solutions to each one of them:
>
> IMO the AC tends to be a little bit slow to incorporate new ideas and
> approaches.  More new faces would help with that.  We also tend a little
> bit toward becoming a social and travel club.  I don't think that is a
> serious problem, yet, but I definitely worry about how many of us stay on
> the AC because we like our colleagues and because we like to travel, rather
> than because we like to talk about, write, and improve ARIN policy.  I
> definitely see that most new AC members are more inclined to spend our time
> together talking about policy than most AC members with longer tenures.
>
> Maybe another solution would be to reconsider whether we really need a
> 15-member AC in the first place.  In all of the other RIRs, they simply
> have a policy working group chair and co-chair, and then interested members
> of the community do all of the heavy lifting on policy, and on getting a
> consensus in the community.  An alternative to think about (and maybe
> discuss in Chicago) might be to have proposal authors and wg chairs
> select one or more shepherds for each policy proposal, and assign the
> shepherd the role of working with the author and community to try to
> actively forge a consensus?   I'm not sure if that's a good solution or
> not, but it's food for thought, anyway...
>
> -Scott
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
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/20140326/79a40c2b/attachment.htm>

From cja at daydream.com  Wed Mar 26 20:29:59 2014
From: cja at daydream.com (CJ Aronson)
Date: Thu, 27 Mar 2014 00:29:59 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
	<CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>
Message-ID: <CAC6JZKScz4bnP-nra8mFvWZO08aPq0m9qD6FH-94PDUeWCS8Dg@mail.gmail.com>

Could you explain why you're talking about Bill Darte's seat as if he is
not on the AC serving a term to which he was duly elected?  There is no
prohibition about him running for a subsequent term at this point either.
Bill has been an outstanding member of the AC and has done significant work
for this community.  If you want to talk about changing a seat on the AC to
be appointed that's fine but leave a particular person out of it.

Thanks
----Cathy


On Thu, Mar 27, 2014 at 12:20 AM, Jason Schiller <jschiller at google.com>wrote:

> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com>
>  wrote:
> | Here are some of the problems I see with the AC.  I think term limits
> would
> | help with all of them, though it wouldn't be a panacea, and it may be
> | possible to come up with better solutions to each one of them:
>
> I wonder if it would be worth while to list the suggested deficiencies,
> and the suggested solutions, then let the community collectively judge
> which deficiencies are problematic, and with solution(s) best solve the
> most problematic issues with the smallest collateral damage.
>
> Martin Hannigan suggested a 365 degree assessment.  This could give the
> community a peak into how the AC evaluates each other's work contribution,
> and effectiveness, which may give the community more to go on when voting
> than a popularity contest.
>
> Jimmy Hess suggested:
> a yearly oscillation in the number of AC members that will be nominated.
> Such as X + 1  members in even numbered years, and  X - 1 members in odd
> numbered years.
>
> We might also consider making Bill Darte's seat an appointed position and
> require the appointment to be filled with someone who has never been on the
> AC.  It could continue to have a three year term, or could be shortened.
>
> Rather than an appointment, we could fill Bill Darte's seat by a separate
> election.  In this case four seats could be elected out of the pool of
> candidates, and the fifth seat would be filled by the candidate who has the
> most votes that has never served on the AC.
>
> ___Jason
>
>
>
> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>
>> On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com>wrote:
>>
>>> On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <scottleibrand at gmail.com
>>> > wrote:
>>>
>>>> IMO the problem (for the AC, not the BoT) is that all turnover comes
>>>> from resignations and people deciding not to run again.  It's very rare
>>>> that an incumbent fails to get re-elected.  Given what I've observed as an
>>>> AC member of the large diversity in contribution levels from my colleagues
>>>> on the AC,
>>>>
>>>
>>> That is an observation, perhaps even a situation, but not by itself a
>>> problem. From my perspective it simply indicates that the community does a
>>> great job selecting winning candidates initially, those candidates go on to
>>> be solid AC members, and therefor continue to win elections...
>>>
>>
>> That is a valid interpretation, but my perspective is slightly different.
>>  I would say it indicates that the community *likes* the people it elects
>> to the AC.  I think that personal popularity has a disproportionate impact
>> in re-electing AC members.  It would be better if more information were
>> readily available to the membership, so they could base their choices on
>> things like accomplishments and voting records.
>>
>>
>>> both new and old, that's evidence to me that the membership is
>>>> re-electing members who are less effective, and we're therefore not getting
>>>> the benefit of
>>>>
>>>
>>> How is it evidence that the membership is re-electing members who are
>>> less effective? Are you saying that YOU are less effective now then in your
>>> first two terms? If not you, than who?
>>>
>>
>> Yes, I actually am saying that.  I still believe I am highly effective,
>> but I found myself "coasting" a bit over the fall/winter, and putting in a
>> lot less effort than I had in my first few years.  I believe I have mostly
>> corrected that now, but I definitely see the tendency to start coasting
>> after a certain amount of time, both in myself and other AC members.
>>
>>
>>>
>>>
>>>> new ideas and approaches, and the higher willingness to take on
>>>> difficult work, that new AC members tend to provide.
>>>>
>>>> Reviewing the results of all the elections since 2007, when I was
>>>> elected, I see:
>>>>
>>>>     Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes
>>>> 2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected
>>>> 2010 3 2 1 1-year appointed incumbent not re-elected  2009 3 2 1   2008
>>>> 2 3   2007 3 2
>>>> As you can see, there has only been a single full-term incumbent who
>>>> was not re-elected, and that was in a year when there were 5 incumbents on
>>>> the ballot.
>>>>
>>>
>>> I see that at least one new person joins the AC EVERY YEAR. Out of five
>>> open positions a minimum 20% turnover is actually pretty fantastic.
>>>
>>
>> Closer to 13% on average (2 AC members out of 15) each year (with a range
>> of 7-20%), almost all from attrition.  If we had even 3% of full-term
>> incumbents getting replaced by challengers (1 every 2 years), I would be
>> quite happy.  But it's actually less than 1%.  IMO that's too low.
>>
>>
>>>> I think term limits (1 year off after 2 terms) would help get more new
>>>> people, with new ideas, approaches, and energy, onto the AC, without unduly
>>>> sacrificing experience and continuity.
>>>>
>>>> Of course, there may be other better ways to accomplish the same thing,
>>>> so I'd love to hear other ideas for how we can get more fresh faces onto
>>>> the AC.  Maybe we could tweak the election process somehow?  One idea I
>>>> just had would be to allow advisory input (some sort of straw poll) from
>>>> PPML participants that is published for the ARIN membership to review when
>>>> casting their votes?
>>>>
>>>
>>> As others have asked, and you have failed to answer - what is the
>>> _problem_ we are trying to solve here? Capable AC members being re-elected
>>> is NOT a problem.
>>>
>>
>> Here are some of the problems I see with the AC.  I think term limits
>> would help with all of them, though it wouldn't be a panacea, and it may be
>> possible to come up with better solutions to each one of them:
>>
>> IMO the AC tends to be a little bit slow to incorporate new ideas and
>> approaches.  More new faces would help with that.  We also tend a little
>> bit toward becoming a social and travel club.  I don't think that is a
>> serious problem, yet, but I definitely worry about how many of us stay on
>> the AC because we like our colleagues and because we like to travel, rather
>> than because we like to talk about, write, and improve ARIN policy.  I
>> definitely see that most new AC members are more inclined to spend our time
>> together talking about policy than most AC members with longer tenures.
>>
>> Maybe another solution would be to reconsider whether we really need a
>> 15-member AC in the first place.  In all of the other RIRs, they simply
>> have a policy working group chair and co-chair, and then interested members
>> of the community do all of the heavy lifting on policy, and on getting a
>> consensus in the community.  An alternative to think about (and maybe
>> discuss in Chicago) might be to have proposal authors and wg chairs
>> select one or more shepherds for each policy proposal, and assign the
>> shepherd the role of working with the author and community to try to
>> actively forge a consensus?   I'm not sure if that's a good solution or
>> not, but it's food for thought, anyway...
>>
>> -Scott
>>
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
>
> --
> _______________________________________________________
> 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/20140327/0d4f559e/attachment.htm>

From springer at inlandnet.com  Wed Mar 26 20:44:52 2014
From: springer at inlandnet.com (John Springer)
Date: Wed, 26 Mar 2014 17:44:52 -0700 (PDT)
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
	<CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1403261738001.10087@mail.inlandnet.com>

Hi Jason,

Pardon my ignorance please, but what is "a 365 degree assessment."? A 
quick google turns up 365 degree total marketing and 360 degree 
assessments and 360 degree feedback. Is this like the Talking Heads 365 
degrees? a typo?

Also, Bill D. has been talked out of not running before. It might be 
premature to start disposing of his place just yet. just sayin'

John Springer


On Wed, 26 Mar 2014, Jason Schiller wrote:

> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand?<scottleibrand at gmail.com>?wrote:|?Here are some of the problems I see with the AC. ?I
> think term limits would
> | help with all of them, though it wouldn't be a panacea, and it may be
> | possible to come up with better solutions to each one of them:
> 
> I wonder if it would be worth while to list the suggested?deficiencies, and the suggested solutions, then let the community?collectively
> judge which deficiencies are?problematic, and with solution(s) best solve the most problematic issues with the smallest collateral
> damage.
> 
> Martin Hannigan suggested a 365 degree assessment. ?This could give the community a peak into how the AC evaluates each other's work
> contribution, and effectiveness, which may give the community more to go on when voting than a popularity contest.
> 
> Jimmy Hess suggested:
> a yearly oscillation in the number of AC members that will be nominated.
> Such as X + 1 ?members in even numbered years, and ?X - 1 members in odd numbered years.
> 
> We might also consider making Bill Darte's seat an appointed position and require the appointment to be filled with someone who has
> never been on the AC. ?It could continue to have a three year term, or could be shortened.?
> 
> Rather than an appointment, we could fill Bill Darte's seat by a separate election. ?In this case four seats could be elected out of the
> pool of candidates, and the fifth seat would be filled by the candidate who has the most votes that has never served on the AC. ??
> 
> ___Jason
> 
> 
> 
> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>       On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:
>             On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>       IMO the problem (for the AC, not the BoT) is that all turnover comes from resignations and people deciding not
>       to run again. ?It's very rare that an incumbent fails to get re-elected. ?Given what I've observed as an AC
>       member of the large diversity in contribution levels from my colleagues on the AC,
> 
> 
> That is an observation, perhaps even a situation, but not by itself a problem. From my perspective it simply indicates that
> the community does a great job selecting winning candidates initially, those candidates go on to be solid AC members, and
> therefor continue to win elections...
> 
> 
> That is a valid interpretation, but my perspective is slightly different. ?I would say it indicates that the community *likes* the
> people it elects to the AC. ?I think that personal popularity has a disproportionate impact in re-electing AC members. ?It would
> be better if more information were readily available to the membership, so they could base their choices on things like
> accomplishments and voting records.
> 
>
>       both new and old, that's evidence to me that the membership is re-electing members who are less effective, and
>       we're therefore not getting the benefit of
> 
> 
> How is it evidence that the membership is re-electing members who are less effective? Are you saying that YOU are less
> effective now then in your first two terms? If not you, than who?
> 
> 
> Yes, I actually am saying that. ?I still believe I am highly effective, but I found myself "coasting" a bit over the fall/winter,
> and putting in a lot less effort than I had in my first few years. ?I believe I have mostly corrected that now, but I definitely
> see the tendency to start coasting after a certain amount of time, both in myself and other AC members.
> ?
>       ?
>       new ideas and approaches, and the higher willingness to take on difficult work, that new AC members tend to
>       provide.
> Reviewing the results of all the elections since 2007, when I was elected, I see:
> 
> Year
> Re-elected
> Newly Elected
> Newly appointed
> NOT Re-elected
> Notes
> 2013
> 4
> 1
> 1
> 2012
> 4
> 1
> 1
> 2011
> 4
> 1
> 1
> 3-year incumbent not re-elected
> 2010
> 3
> 2
> 1
> 1-year appointed incumbent not re-elected
> 2009
> 3
> 2
> 1
> 2008
> 2
> 3
> 2007
> 3
> 2
> 
> As you can see, there has only been a single full-term incumbent who was not re-elected, and that was in a year when
> there were 5 incumbents on the ballot.
> 
> 
> I see that at least one new person joins the AC EVERY YEAR. Out of five open positions a minimum 20% turnover is actually
> pretty fantastic.
> 
> 
> Closer to 13% on average (2 AC members out of 15) each year (with a range of 7-20%), almost all from attrition. ?If we had even 3%
> of full-term incumbents getting replaced by challengers (1 every 2 years), I would be quite happy. ?But it's actually less than
> 1%. ?IMO that's too low.
> 
> 
> I think term limits (1 year off after 2 terms) would help get more new people, with new ideas, approaches, and energy,
> onto the AC, without unduly sacrificing experience and continuity.
> 
> Of course, there may be other better ways to accomplish the same thing, so I'd love to hear other ideas for how we can
> get more fresh faces onto the AC. ?Maybe we could tweak the election process somehow? ?One idea I just had would be to
> allow advisory input (some sort of straw poll) from PPML participants that is published for the ARIN membership to
> review when casting their votes?
> 
> 
> As others have asked, and you have failed to answer - what is the _problem_ we are trying to solve here? Capable AC members
> being re-elected is NOT a problem.
> 
> 
> Here are some of the problems I see with the AC. ?I think term limits would help with all of them, though it wouldn't be a
> panacea, and it may be possible to come up with better solutions to each one of them:
> 
> IMO the AC tends to be a little bit slow to incorporate?new ideas and approaches. ?More new faces would help with that. ?We also
> tend a little bit toward becoming a social and travel club. ?I don't think that is a serious problem, yet, but I definitely worry
> about how many of us stay on the AC because we like our colleagues and because we like to travel, rather than because we like to
> talk about, write, and improve ARIN policy. ?I definitely see that most new AC members are more inclined to spend our time
> together talking about policy than most AC members with longer tenures.
> 
> Maybe another solution would be to reconsider whether we really need a 15-member AC in the first place. ?In all of the other RIRs,
> they simply have a policy working group chair and co-chair, and then interested members of the community do all of the heavy
> lifting on policy, and on getting a consensus in the community. ?An alternative to think about (and maybe discuss in Chicago)
> might be?to have proposal authors and wg chairs select one or more shepherds for each policy proposal, and assign the shepherd the
> role of working with the author and community to try to actively forge a consensus? ? I'm not sure if that's a good solution or
> not, but it's food for thought, anyway...
> 
> -Scott
> 
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> 
> 
> 
> 
> --
> _______________________________________________________
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
> 
> 
>

From scottleibrand at gmail.com  Wed Mar 26 20:46:50 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Wed, 26 Mar 2014 17:46:50 -0700
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAC6JZKScz4bnP-nra8mFvWZO08aPq0m9qD6FH-94PDUeWCS8Dg@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
	<CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>
	<CAC6JZKScz4bnP-nra8mFvWZO08aPq0m9qD6FH-94PDUeWCS8Dg@mail.gmail.com>
Message-ID: <312B1DFE-1AE4-4B3A-870B-83AD1EBB5617@gmail.com>

Bill already said earlier on the thread he wasn't planning to run again. 

Scott

> On Mar 26, 2014, at 5:29 PM, CJ Aronson <cja at daydream.com> wrote:
> 
> Could you explain why you're talking about Bill Darte's seat as if he is not on the AC serving a term to which he was duly elected?  There is no prohibition about him running for a subsequent term at this point either. Bill has been an outstanding member of the AC and has done significant work for this community.  If you want to talk about changing a seat on the AC to be appointed that's fine but leave a particular person out of it.  
> 
> Thanks
> ----Cathy
> 
> 
>> On Thu, Mar 27, 2014 at 12:20 AM, Jason Schiller <jschiller at google.com> wrote:
>> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>> | Here are some of the problems I see with the AC.  I think term limits would
>> | help with all of them, though it wouldn't be a panacea, and it may be
>> | possible to come up with better solutions to each one of them:
>> 
>> I wonder if it would be worth while to list the suggested deficiencies, and the suggested solutions, then let the community collectively judge which deficiencies are problematic, and with solution(s) best solve the most problematic issues with the smallest collateral damage.
>> 
>> Martin Hannigan suggested a 365 degree assessment.  This could give the community a peak into how the AC evaluates each other's work contribution, and effectiveness, which may give the community more to go on when voting than a popularity contest.
>> 
>> Jimmy Hess suggested:
>> a yearly oscillation in the number of AC members that will be nominated.
>> Such as X + 1  members in even numbered years, and  X - 1 members in odd numbered years.
>> 
>> We might also consider making Bill Darte's seat an appointed position and require the appointment to be filled with someone who has never been on the AC.  It could continue to have a three year term, or could be shortened. 
>> 
>> Rather than an appointment, we could fill Bill Darte's seat by a separate election.  In this case four seats could be elected out of the pool of candidates, and the fifth seat would be filled by the candidate who has the most votes that has never served on the AC.   
>> 
>> ___Jason
>> 
>> 
>> 
>>> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>>> On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com> wrote:
>>>>> On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>>>> IMO the problem (for the AC, not the BoT) is that all turnover comes from resignations and people deciding not to run again.  It's very rare that an incumbent fails to get re-elected.  Given what I've observed as an AC member of the large diversity in contribution levels from my colleagues on the AC,
>>>> 
>>>> That is an observation, perhaps even a situation, but not by itself a problem. From my perspective it simply indicates that the community does a great job selecting winning candidates initially, those candidates go on to be solid AC members, and therefor continue to win elections...
>>> 
>>> That is a valid interpretation, but my perspective is slightly different.  I would say it indicates that the community *likes* the people it elects to the AC.  I think that personal popularity has a disproportionate impact in re-electing AC members.  It would be better if more information were readily available to the membership, so they could base their choices on things like accomplishments and voting records.
>>> 
>>>> 
>>>>> both new and old, that's evidence to me that the membership is re-electing members who are less effective, and we're therefore not getting the benefit of
>>>> 
>>>> How is it evidence that the membership is re-electing members who are less effective? Are you saying that YOU are less effective now then in your first two terms? If not you, than who?
>>> 
>>> Yes, I actually am saying that.  I still believe I am highly effective, but I found myself "coasting" a bit over the fall/winter, and putting in a lot less effort than I had in my first few years.  I believe I have mostly corrected that now, but I definitely see the tendency to start coasting after a certain amount of time, both in myself and other AC members.
>>>  
>>>>  
>>>>> new ideas and approaches, and the higher willingness to take on difficult work, that new AC members tend to provide.
>>>>> 
>>>>> Reviewing the results of all the elections since 2007, when I was elected, I see:
>>>>> 
>>>>> Year	Re-elected	Newly Elected	Newly appointed	NOT Re-elected	Notes
>>>>> 2013	4	1	1		
>>>>> 2012	4	1	1		
>>>>> 2011	4	1		1	3-year incumbent not re-elected
>>>>> 2010	3	2		1	1-year appointed incumbent not re-elected
>>>>> 2009	3	2	1		
>>>>> 2008	2	3			
>>>>> 2007	3	2			
>>>>> 
>>>>> As you can see, there has only been a single full-term incumbent who was not re-elected, and that was in a year when there were 5 incumbents on the ballot.
>>>> 
>>>> I see that at least one new person joins the AC EVERY YEAR. Out of five open positions a minimum 20% turnover is actually pretty fantastic.
>>> 
>>> Closer to 13% on average (2 AC members out of 15) each year (with a range of 7-20%), almost all from attrition.  If we had even 3% of full-term incumbents getting replaced by challengers (1 every 2 years), I would be quite happy.  But it's actually less than 1%.  IMO that's too low.
>>> 
>>>>> 
>>>>> I think term limits (1 year off after 2 terms) would help get more new people, with new ideas, approaches, and energy, onto the AC, without unduly sacrificing experience and continuity.
>>>>> 
>>>>> Of course, there may be other better ways to accomplish the same thing, so I'd love to hear other ideas for how we can get more fresh faces onto the AC.  Maybe we could tweak the election process somehow?  One idea I just had would be to allow advisory input (some sort of straw poll) from PPML participants that is published for the ARIN membership to review when casting their votes?
>>>> 
>>>> As others have asked, and you have failed to answer - what is the _problem_ we are trying to solve here? Capable AC members being re-elected is NOT a problem.
>>> 
>>> Here are some of the problems I see with the AC.  I think term limits would help with all of them, though it wouldn't be a panacea, and it may be possible to come up with better solutions to each one of them:
>>> 
>>> IMO the AC tends to be a little bit slow to incorporate new ideas and approaches.  More new faces would help with that.  We also tend a little bit toward becoming a social and travel club.  I don't think that is a serious problem, yet, but I definitely worry about how many of us stay on the AC because we like our colleagues and because we like to travel, rather than because we like to talk about, write, and improve ARIN policy.  I definitely see that most new AC members are more inclined to spend our time together talking about policy than most AC members with longer tenures.
>>> 
>>> Maybe another solution would be to reconsider whether we really need a 15-member AC in the first place.  In all of the other RIRs, they simply have a policy working group chair and co-chair, and then interested members of the community do all of the heavy lifting on policy, and on getting a consensus in the community.  An alternative to think about (and maybe discuss in Chicago) might be to have proposal authors and wg chairs select one or more shepherds for each policy proposal, and assign the shepherd the role of working with the author and community to try to actively forge a consensus?   I'm not sure if that's a good solution or not, but it's food for thought, anyway...
>>> 
>>> -Scott
>>> 
>>> 
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>> 
>> 
>> 
>> -- 
>> _______________________________________________________
>> 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/20140326/cd621045/attachment.htm>

From cja at daydream.com  Wed Mar 26 20:48:57 2014
From: cja at daydream.com (CJ Aronson)
Date: Thu, 27 Mar 2014 00:48:57 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <312B1DFE-1AE4-4B3A-870B-83AD1EBB5617@gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
	<CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>
	<CAC6JZKScz4bnP-nra8mFvWZO08aPq0m9qD6FH-94PDUeWCS8Dg@mail.gmail.com>
	<312B1DFE-1AE4-4B3A-870B-83AD1EBB5617@gmail.com>
Message-ID: <CAC6JZKQQOUCTPO31h4Q7dYRWrjsEcJ_-mUaS3C1Kag9oaq+9Vg@mail.gmail.com>

It doesn't matter if he says he's not running again.  If we generically
want to make a seat appointed then fine but he has every right to change
his mind and run again.  Leave AC member's names out of it.

Thanks
----Cathy


On Thu, Mar 27, 2014 at 12:46 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:

> Bill already said earlier on the thread he wasn't planning to run again.
>
> Scott
>
> On Mar 26, 2014, at 5:29 PM, CJ Aronson <cja at daydream.com> wrote:
>
> Could you explain why you're talking about Bill Darte's seat as if he is
> not on the AC serving a term to which he was duly elected?  There is no
> prohibition about him running for a subsequent term at this point either.
> Bill has been an outstanding member of the AC and has done significant work
> for this community.  If you want to talk about changing a seat on the AC to
> be appointed that's fine but leave a particular person out of it.
>
> Thanks
> ----Cathy
>
>
> On Thu, Mar 27, 2014 at 12:20 AM, Jason Schiller <jschiller at google.com>wrote:
>
>> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com>
>>  wrote:
>> | Here are some of the problems I see with the AC.  I think term limits
>> would
>> | help with all of them, though it wouldn't be a panacea, and it may be
>> | possible to come up with better solutions to each one of them:
>>
>> I wonder if it would be worth while to list the suggested deficiencies,
>> and the suggested solutions, then let the community collectively judge
>> which deficiencies are problematic, and with solution(s) best solve the
>> most problematic issues with the smallest collateral damage.
>>
>> Martin Hannigan suggested a 365 degree assessment.  This could give the
>> community a peak into how the AC evaluates each other's work contribution,
>> and effectiveness, which may give the community more to go on when voting
>> than a popularity contest.
>>
>> Jimmy Hess suggested:
>> a yearly oscillation in the number of AC members that will be nominated.
>> Such as X + 1  members in even numbered years, and  X - 1 members in odd
>> numbered years.
>>
>> We might also consider making Bill Darte's seat an appointed position and
>> require the appointment to be filled with someone who has never been on the
>> AC.  It could continue to have a three year term, or could be shortened.
>>
>> Rather than an appointment, we could fill Bill Darte's seat by a separate
>> election.  In this case four seats could be elected out of the pool of
>> candidates, and the fifth seat would be filled by the candidate who has the
>> most votes that has never served on the AC.
>>
>> ___Jason
>>
>>
>>
>> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>>
>>>  On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <
>>> cgrundemann at gmail.com> wrote:
>>>
>>>> On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <
>>>> scottleibrand at gmail.com> wrote:
>>>>
>>>>> IMO the problem (for the AC, not the BoT) is that all turnover comes
>>>>> from resignations and people deciding not to run again.  It's very rare
>>>>> that an incumbent fails to get re-elected.  Given what I've observed as an
>>>>> AC member of the large diversity in contribution levels from my colleagues
>>>>> on the AC,
>>>>>
>>>>
>>>> That is an observation, perhaps even a situation, but not by itself a
>>>> problem. From my perspective it simply indicates that the community does a
>>>> great job selecting winning candidates initially, those candidates go on to
>>>> be solid AC members, and therefor continue to win elections...
>>>>
>>>
>>> That is a valid interpretation, but my perspective is slightly
>>> different.  I would say it indicates that the community *likes* the people
>>> it elects to the AC.  I think that personal popularity has a
>>> disproportionate impact in re-electing AC members.  It would be better if
>>> more information were readily available to the membership, so they could
>>> base their choices on things like accomplishments and voting records.
>>>
>>>
>>>> both new and old, that's evidence to me that the membership is
>>>>> re-electing members who are less effective, and we're therefore not getting
>>>>> the benefit of
>>>>>
>>>>
>>>> How is it evidence that the membership is re-electing members who are
>>>> less effective? Are you saying that YOU are less effective now then in your
>>>> first two terms? If not you, than who?
>>>>
>>>
>>> Yes, I actually am saying that.  I still believe I am highly effective,
>>> but I found myself "coasting" a bit over the fall/winter, and putting in a
>>> lot less effort than I had in my first few years.  I believe I have mostly
>>> corrected that now, but I definitely see the tendency to start coasting
>>> after a certain amount of time, both in myself and other AC members.
>>>
>>>
>>>>
>>>>
>>>>> new ideas and approaches, and the higher willingness to take on
>>>>> difficult work, that new AC members tend to provide.
>>>>>
>>>>> Reviewing the results of all the elections since 2007, when I was
>>>>> elected, I see:
>>>>>
>>>>>     Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes
>>>>> 2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected
>>>>> 2010 3 2 1 1-year appointed incumbent not re-elected  2009 3 2 1
>>>>> 2008 2 3   2007 3 2
>>>>> As you can see, there has only been a single full-term incumbent who
>>>>> was not re-elected, and that was in a year when there were 5 incumbents on
>>>>> the ballot.
>>>>>
>>>>
>>>> I see that at least one new person joins the AC EVERY YEAR. Out of five
>>>> open positions a minimum 20% turnover is actually pretty fantastic.
>>>>
>>>
>>> Closer to 13% on average (2 AC members out of 15) each year (with a
>>> range of 7-20%), almost all from attrition.  If we had even 3% of full-term
>>> incumbents getting replaced by challengers (1 every 2 years), I would be
>>> quite happy.  But it's actually less than 1%.  IMO that's too low.
>>>
>>>
>>>>> I think term limits (1 year off after 2 terms) would help get more new
>>>>> people, with new ideas, approaches, and energy, onto the AC, without unduly
>>>>> sacrificing experience and continuity.
>>>>>
>>>>> Of course, there may be other better ways to accomplish the same
>>>>> thing, so I'd love to hear other ideas for how we can get more fresh faces
>>>>> onto the AC.  Maybe we could tweak the election process somehow?  One idea
>>>>> I just had would be to allow advisory input (some sort of straw poll) from
>>>>> PPML participants that is published for the ARIN membership to review when
>>>>> casting their votes?
>>>>>
>>>>
>>>> As others have asked, and you have failed to answer - what is the
>>>> _problem_ we are trying to solve here? Capable AC members being re-elected
>>>> is NOT a problem.
>>>>
>>>
>>> Here are some of the problems I see with the AC.  I think term limits
>>> would help with all of them, though it wouldn't be a panacea, and it may be
>>> possible to come up with better solutions to each one of them:
>>>
>>> IMO the AC tends to be a little bit slow to incorporate new ideas and
>>> approaches.  More new faces would help with that.  We also tend a little
>>> bit toward becoming a social and travel club.  I don't think that is a
>>> serious problem, yet, but I definitely worry about how many of us stay on
>>> the AC because we like our colleagues and because we like to travel, rather
>>> than because we like to talk about, write, and improve ARIN policy.  I
>>> definitely see that most new AC members are more inclined to spend our time
>>> together talking about policy than most AC members with longer tenures.
>>>
>>> Maybe another solution would be to reconsider whether we really need a
>>> 15-member AC in the first place.  In all of the other RIRs, they simply
>>> have a policy working group chair and co-chair, and then interested members
>>> of the community do all of the heavy lifting on policy, and on getting a
>>> consensus in the community.  An alternative to think about (and maybe
>>> discuss in Chicago) might be to have proposal authors and wg chairs
>>> select one or more shepherds for each policy proposal, and assign the
>>> shepherd the role of working with the author and community to try to
>>> actively forge a consensus?   I'm not sure if that's a good solution or
>>> not, but it's food for thought, anyway...
>>>
>>> -Scott
>>>
>>>
>>> _______________________________________________
>>> PPML
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contact info at arin.net if you experience any issues.
>>>
>>
>>
>>
>> --
>>  _______________________________________________________
>> 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/20140327/4a970012/attachment.htm>

From jschiller at google.com  Wed Mar 26 21:06:30 2014
From: jschiller at google.com (Jason Schiller)
Date: Wed, 26 Mar 2014 21:06:30 -0400
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAC6JZKQQOUCTPO31h4Q7dYRWrjsEcJ_-mUaS3C1Kag9oaq+9Vg@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
	<CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>
	<CAC6JZKScz4bnP-nra8mFvWZO08aPq0m9qD6FH-94PDUeWCS8Dg@mail.gmail.com>
	<312B1DFE-1AE4-4B3A-870B-83AD1EBB5617@gmail.com>
	<CAC6JZKQQOUCTPO31h4Q7dYRWrjsEcJ_-mUaS3C1Kag9oaq+9Vg@mail.gmail.com>
Message-ID: <CAC4yj2Ujr8WMniu8DVh00iRvTV_H-MpunZb6+kcwBbPB7GYbuA@mail.gmail.com>

The 360 degree review was Martin's suggestion.  At the time it sounded like
it mean a review for every angle (360 degrees in a circle).

Bill Darte is an upstanding member of the AC, and I personally wish he
would continue to serve, but it seemed pretty clear that his intent is to
not continue.  Such a vacancy (if it happens) might be a good opportunity
to repurpose the seat.

Apologies for naming a particular seat, I was being lazy and didn't want to
say should a seat be vacated early, or an incumbent plans to not re-run...
we could easily redefine how that seat be filled without artificially
displacing any current AC member.

__Jason

__Jason


On Wed, Mar 26, 2014 at 8:48 PM, CJ Aronson <cja at daydream.com> wrote:

> It doesn't matter if he says he's not running again.  If we generically
> want to make a seat appointed then fine but he has every right to change
> his mind and run again.  Leave AC member's names out of it.
>
> Thanks
> ----Cathy
>
>
> On Thu, Mar 27, 2014 at 12:46 AM, Scott Leibrand <scottleibrand at gmail.com>wrote:
>
>> Bill already said earlier on the thread he wasn't planning to run again.
>>
>> Scott
>>
>> On Mar 26, 2014, at 5:29 PM, CJ Aronson <cja at daydream.com> wrote:
>>
>> Could you explain why you're talking about Bill Darte's seat as if he is
>> not on the AC serving a term to which he was duly elected?  There is no
>> prohibition about him running for a subsequent term at this point either.
>> Bill has been an outstanding member of the AC and has done significant work
>> for this community.  If you want to talk about changing a seat on the AC to
>> be appointed that's fine but leave a particular person out of it.
>>
>> Thanks
>> ----Cathy
>>
>>
>> On Thu, Mar 27, 2014 at 12:20 AM, Jason Schiller <jschiller at google.com>wrote:
>>
>>> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com
>>> > wrote:
>>> | Here are some of the problems I see with the AC.  I think term limits
>>> would
>>> | help with all of them, though it wouldn't be a panacea, and it may be
>>> | possible to come up with better solutions to each one of them:
>>>
>>> I wonder if it would be worth while to list the suggested deficiencies,
>>> and the suggested solutions, then let the community collectively judge
>>> which deficiencies are problematic, and with solution(s) best solve the
>>> most problematic issues with the smallest collateral damage.
>>>
>>> Martin Hannigan suggested a 365 degree assessment.  This could give the
>>> community a peak into how the AC evaluates each other's work contribution,
>>> and effectiveness, which may give the community more to go on when voting
>>> than a popularity contest.
>>>
>>> Jimmy Hess suggested:
>>> a yearly oscillation in the number of AC members that will be nominated.
>>> Such as X + 1  members in even numbered years, and  X - 1 members in odd
>>> numbered years.
>>>
>>> We might also consider making Bill Darte's seat an appointed position
>>> and require the appointment to be filled with someone who has never been on
>>> the AC.  It could continue to have a three year term, or could be
>>> shortened.
>>>
>>> Rather than an appointment, we could fill Bill Darte's seat by a
>>> separate election.  In this case four seats could be elected out of the
>>> pool of candidates, and the fifth seat would be filled by the candidate who
>>> has the most votes that has never served on the AC.
>>>
>>> ___Jason
>>>
>>>
>>>
>>> On Wed, Mar 26, 2014 at 1:23 PM, Scott Leibrand <scottleibrand at gmail.com
>>> > wrote:
>>>
>>>>  On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <
>>>> cgrundemann at gmail.com> wrote:
>>>>
>>>>> On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <
>>>>> scottleibrand at gmail.com> wrote:
>>>>>
>>>>>> IMO the problem (for the AC, not the BoT) is that all turnover comes
>>>>>> from resignations and people deciding not to run again.  It's very rare
>>>>>> that an incumbent fails to get re-elected.  Given what I've observed as an
>>>>>> AC member of the large diversity in contribution levels from my colleagues
>>>>>> on the AC,
>>>>>>
>>>>>
>>>>> That is an observation, perhaps even a situation, but not by itself a
>>>>> problem. From my perspective it simply indicates that the community does a
>>>>> great job selecting winning candidates initially, those candidates go on to
>>>>> be solid AC members, and therefor continue to win elections...
>>>>>
>>>>
>>>> That is a valid interpretation, but my perspective is slightly
>>>> different.  I would say it indicates that the community *likes* the people
>>>> it elects to the AC.  I think that personal popularity has a
>>>> disproportionate impact in re-electing AC members.  It would be better if
>>>> more information were readily available to the membership, so they could
>>>> base their choices on things like accomplishments and voting records.
>>>>
>>>>
>>>>> both new and old, that's evidence to me that the membership is
>>>>>> re-electing members who are less effective, and we're therefore not getting
>>>>>> the benefit of
>>>>>>
>>>>>
>>>>> How is it evidence that the membership is re-electing members who are
>>>>> less effective? Are you saying that YOU are less effective now then in your
>>>>> first two terms? If not you, than who?
>>>>>
>>>>
>>>> Yes, I actually am saying that.  I still believe I am highly effective,
>>>> but I found myself "coasting" a bit over the fall/winter, and putting in a
>>>> lot less effort than I had in my first few years.  I believe I have mostly
>>>> corrected that now, but I definitely see the tendency to start coasting
>>>> after a certain amount of time, both in myself and other AC members.
>>>>
>>>>
>>>>>
>>>>>
>>>>>> new ideas and approaches, and the higher willingness to take on
>>>>>> difficult work, that new AC members tend to provide.
>>>>>>
>>>>>> Reviewing the results of all the elections since 2007, when I was
>>>>>> elected, I see:
>>>>>>
>>>>>>     Year Re-elected Newly Elected Newly appointed NOT Re-elected
>>>>>> Notes  2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not
>>>>>> re-elected  2010 3 2 1 1-year appointed incumbent not re-elected
>>>>>> 2009 3 2 1   2008 2 3   2007 3 2
>>>>>> As you can see, there has only been a single full-term incumbent who
>>>>>> was not re-elected, and that was in a year when there were 5 incumbents on
>>>>>> the ballot.
>>>>>>
>>>>>
>>>>> I see that at least one new person joins the AC EVERY YEAR. Out of
>>>>> five open positions a minimum 20% turnover is actually pretty fantastic.
>>>>>
>>>>
>>>> Closer to 13% on average (2 AC members out of 15) each year (with a
>>>> range of 7-20%), almost all from attrition.  If we had even 3% of full-term
>>>> incumbents getting replaced by challengers (1 every 2 years), I would be
>>>> quite happy.  But it's actually less than 1%.  IMO that's too low.
>>>>
>>>>
>>>>>> I think term limits (1 year off after 2 terms) would help get more
>>>>>> new people, with new ideas, approaches, and energy, onto the AC, without
>>>>>> unduly sacrificing experience and continuity.
>>>>>>
>>>>>> Of course, there may be other better ways to accomplish the same
>>>>>> thing, so I'd love to hear other ideas for how we can get more fresh faces
>>>>>> onto the AC.  Maybe we could tweak the election process somehow?  One idea
>>>>>> I just had would be to allow advisory input (some sort of straw poll) from
>>>>>> PPML participants that is published for the ARIN membership to review when
>>>>>> casting their votes?
>>>>>>
>>>>>
>>>>> As others have asked, and you have failed to answer - what is the
>>>>> _problem_ we are trying to solve here? Capable AC members being re-elected
>>>>> is NOT a problem.
>>>>>
>>>>
>>>> Here are some of the problems I see with the AC.  I think term limits
>>>> would help with all of them, though it wouldn't be a panacea, and it may be
>>>> possible to come up with better solutions to each one of them:
>>>>
>>>> IMO the AC tends to be a little bit slow to incorporate new ideas and
>>>> approaches.  More new faces would help with that.  We also tend a little
>>>> bit toward becoming a social and travel club.  I don't think that is a
>>>> serious problem, yet, but I definitely worry about how many of us stay on
>>>> the AC because we like our colleagues and because we like to travel, rather
>>>> than because we like to talk about, write, and improve ARIN policy.  I
>>>> definitely see that most new AC members are more inclined to spend our time
>>>> together talking about policy than most AC members with longer tenures.
>>>>
>>>> Maybe another solution would be to reconsider whether we really need a
>>>> 15-member AC in the first place.  In all of the other RIRs, they simply
>>>> have a policy working group chair and co-chair, and then interested members
>>>> of the community do all of the heavy lifting on policy, and on getting a
>>>> consensus in the community.  An alternative to think about (and maybe
>>>> discuss in Chicago) might be to have proposal authors and wg chairs
>>>> select one or more shepherds for each policy proposal, and assign the
>>>> shepherd the role of working with the author and community to try to
>>>> actively forge a consensus?   I'm not sure if that's a good solution or
>>>> not, but it's food for thought, anyway...
>>>>
>>>> -Scott
>>>>
>>>>
>>>> _______________________________________________
>>>> PPML
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>>> Please contact info at arin.net if you experience any issues.
>>>>
>>>
>>>
>>>
>>> --
>>>  _______________________________________________________
>>> 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.
>>>
>>
>>
>


-- 
_______________________________________________________
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/20140326/8c54e494/attachment.htm>

From rudi.daniel at gmail.com  Wed Mar 26 21:11:21 2014
From: rudi.daniel at gmail.com (Rudolph Daniel)
Date: Wed, 26 Mar 2014 21:11:21 -0400
Subject: [arin-ppml] term limit proposal
Message-ID: <CA+uaoiUfMG_5SDgZMLjkL3ZktO4dyYd87_Q439jypONcONGD=w@mail.gmail.com>

Reading with some interest ...let me say that I have no experience of the
AC nor BoT....but some observations;
What exactly is the problem we are proposing a solution to?
Cannot be a social and travel club.... For sure
Originality and or fresh ideas? Not too sure bout that either
..as a body you are bound by too many codes and practices and more
important;  the range of interests, vested and otherwise to be considered,
begs for a certain level of stability at certain nodes in the process of
shepherding at am organizational level.

It would be interesting to see a history of the membership of both ...maybe
the community can gleam some wisdom from the movements in/out ...some
suggested that more participants resign than those who may want to super
glue themselves to the chair.

What I have noticed as a contributing member on the ppml is a constant
commitment to the task by the AC & BoT members I have had the occasion to
interact with.

OK, so take a year off every 3 years and come back refueled.

Personally, I would feel more accomplished doing x years and moving aside
for someone else..because it may well take close to a year to adjust your
seat for effective and meaningful service to the community and when you
take a year off, you are not coming back as such.....you are new to the
seat....but with a history.

History is a complication in the scheme of things...with a tendency to
start where you left off...although you may now find yourself in a very
different construct from where you left off.
Thus introducing a further quotient of personal conflict?

What % of AC and BoT members experience burnout? I would prefer to think
that there is some kind of alarm to safeguard the community from such
inefficiencies in the shepherding process.
Just another view for what it is worth.

Rudi Daniel
 On Mar 26, 2014 2:07 PM, <arin-ppml-request at arin.net> wrote:

> 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. Re: [arin-discuss]  Term Limit Proposal (Bill Darte)
>    2. Re: [arin-discuss]  Term Limit Proposal (John Springer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 26 Mar 2014 13:53:38 -0500
> From: Bill Darte <billdarte at gmail.com>
> To: Scott Leibrand <scottleibrand at gmail.com>
> Cc: "arin-discuss at arin.net" <arin-discuss at arin.net>,    ARIN-PPML List
>         <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] [arin-discuss]  Term Limit Proposal
> Message-ID:
>         <CAMApp36CkSqZHPW+Cy=
> aitQiH5RPcKSgBLz5Ti45bkV_F-dSPg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Scott said:
> "IMO the AC tends to be a little bit slow to incorporate new ideas and
> approaches.  More new faces would help with that.  We also tend a little
> bit toward becoming a social and travel club.  I don't think that is a
> serious problem, yet, but I definitely worry about how many of us stay on
> the AC because we like our colleagues and because we like to travel, rather
> than because we like to talk about, write, and improve ARIN policy.  I
> definitely see that most new AC members are more inclined to spend our time
> together talking about policy than most AC members with longer tenures."
>
>
> Scott, I am interested to know more about what you consider examples of new
> ideas and approaches.... given the highly scripted role of the AC in
> support of the PDP, and given the schedules for AC and ARIN meetings, our
> standing rules and Robert's Rules all guiding our process and activities.
>  Also, we as a body are most often criticized IMO for being too liberal in
> our interpretations and support for policy proposals that are re-hashes of
> ideas disposed of in the past or for continuing to engage with proposals
> that are 'moving deck chairs' or v4 exhaustion which the community has
> consistently asked us to stop doing.  I'm sure many would say our workload
> is artificially high now.
>
> I do not agree that the AC is tending toward becoming a social and travel
> club...I think everyone takes their duties and role in travel seriously,
> but I find no fault with people endeavoring to know one another better, to
> understand where they are coming from and to build relationships.  More
> quality change comes through trust than any other organizational or
> technical skill IMO. And, listening is as important a skill as is speaking
> when it comes to understanding policy issues and other's perspectives.
>
> In our volunteer role, we all spend a great deal of time with policy
> proposals and policy discussion at meetings and in between.  If we have our
> different approaches and a diversity of people on the AC, you can thank the
> founders of ARIN and the electorate of the membership community.  It seems
> to me your are arguing for less diversity in approaches than more in some
> ways.
>
>
> On Wed, Mar 26, 2014 at 12:23 PM, Scott Leibrand <scottleibrand at gmail.com
> >wrote:
>
> > On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com
> >wrote:
> >
> >> On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <
> scottleibrand at gmail.com>wrote:
> >>
> >>> IMO the problem (for the AC, not the BoT) is that all turnover comes
> >>> from resignations and people deciding not to run again.  It's very rare
> >>> that an incumbent fails to get re-elected.  Given what I've observed
> as an
> >>> AC member of the large diversity in contribution levels from my
> colleagues
> >>> on the AC,
> >>>
> >>
> >> That is an observation, perhaps even a situation, but not by itself a
> >> problem. From my perspective it simply indicates that the community
> does a
> >> great job selecting winning candidates initially, those candidates go
> on to
> >> be solid AC members, and therefor continue to win elections...
> >>
> >
> > That is a valid interpretation, but my perspective is slightly different.
> >  I would say it indicates that the community *likes* the people it elects
> > to the AC.  I think that personal popularity has a disproportionate
> impact
> > in re-electing AC members.  It would be better if more information were
> > readily available to the membership, so they could base their choices on
> > things like accomplishments and voting records.
> >
> >
> >> both new and old, that's evidence to me that the membership is
> >>> re-electing members who are less effective, and we're therefore not
> getting
> >>> the benefit of
> >>>
> >>
> >> How is it evidence that the membership is re-electing members who are
> >> less effective? Are you saying that YOU are less effective now then in
> your
> >> first two terms? If not you, than who?
> >>
> >
> > Yes, I actually am saying that.  I still believe I am highly effective,
> > but I found myself "coasting" a bit over the fall/winter, and putting in
> a
> > lot less effort than I had in my first few years.  I believe I have
> mostly
> > corrected that now, but I definitely see the tendency to start coasting
> > after a certain amount of time, both in myself and other AC members.
> >
> >
> >>
> >>
> >>> new ideas and approaches, and the higher willingness to take on
> >>> difficult work, that new AC members tend to provide.
> >>>
> >>> Reviewing the results of all the elections since 2007, when I was
> >>> elected, I see:
> >>>
> >>>     Year Re-elected Newly Elected Newly appointed NOT Re-elected Notes
> >>> 2013 4 1 1   2012 4 1 1   2011 4 1 1 3-year incumbent not re-elected
> >>> 2010 3 2 1 1-year appointed incumbent not re-elected  2009 3 2 1   2008
> >>> 2 3   2007 3 2
> >>> As you can see, there has only been a single full-term incumbent who
> was
> >>> not re-elected, and that was in a year when there were 5 incumbents on
> the
> >>> ballot.
> >>>
> >>
> >> I see that at least one new person joins the AC EVERY YEAR. Out of five
> >> open positions a minimum 20% turnover is actually pretty fantastic.
> >>
> >
> > Closer to 13% on average (2 AC members out of 15) each year (with a range
> > of 7-20%), almost all from attrition.  If we had even 3% of full-term
> > incumbents getting replaced by challengers (1 every 2 years), I would be
> > quite happy.  But it's actually less than 1%.  IMO that's too low.
> >
> >
> >>> I think term limits (1 year off after 2 terms) would help get more new
> >>> people, with new ideas, approaches, and energy, onto the AC, without
> unduly
> >>> sacrificing experience and continuity.
> >>>
> >>> Of course, there may be other better ways to accomplish the same thing,
> >>> so I'd love to hear other ideas for how we can get more fresh faces
> onto
> >>> the AC.  Maybe we could tweak the election process somehow?  One idea I
> >>> just had would be to allow advisory input (some sort of straw poll)
> from
> >>> PPML participants that is published for the ARIN membership to review
> when
> >>> casting their votes?
> >>>
> >>
> >> As others have asked, and you have failed to answer - what is the
> >> _problem_ we are trying to solve here? Capable AC members being
> re-elected
> >> is NOT a problem.
> >>
> >
> > Here are some of the problems I see with the AC.  I think term limits
> > would help with all of them, though it wouldn't be a panacea, and it may
> be
> > possible to come up with better solutions to each one of them:
> >
> > IMO the AC tends to be a little bit slow to incorporate new ideas and
> > approaches.  More new faces would help with that.  We also tend a little
> > bit toward becoming a social and travel club.  I don't think that is a
> > serious problem, yet, but I definitely worry about how many of us stay on
> > the AC because we like our colleagues and because we like to travel,
> rather
> > than because we like to talk about, write, and improve ARIN policy.  I
> > definitely see that most new AC members are more inclined to spend our
> time
> > together talking about policy than most AC members with longer tenures.
> >
> > Maybe another solution would be to reconsider whether we really need a
> > 15-member AC in the first place.  In all of the other RIRs, they simply
> > have a policy working group chair and co-chair, and then interested
> members
> > of the community do all of the heavy lifting on policy, and on getting a
> > consensus in the community.  An alternative to think about (and maybe
> > discuss in Chicago) might be to have proposal authors and wg chairs
> > select one or more shepherds for each policy proposal, and assign the
> > shepherd the role of working with the author and community to try to
> > actively forge a consensus?   I'm not sure if that's a good solution or
> > not, but it's food for thought, anyway...
> >
> > -Scott
> >
> >
> > _______________________________________________
> > ARIN-Discuss
> > You are receiving this message because you are subscribed to
> > the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-discuss
> > Please contact info at arin.net if you experience any issues.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20140326/74038e92/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 26 Mar 2014 11:58:58 -0700 (PDT)
> From: John Springer <springer at inlandnet.com>
> To: Scott Leibrand <scottleibrand at gmail.com>
> Cc: "arin-discuss at arin.net" <arin-discuss at arin.net>,    ARIN-PPML List
>         <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] [arin-discuss]  Term Limit Proposal
> Message-ID: <alpine.BSF.2.00.1403261118070.48789 at mail.inlandnet.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> It's going to be a little hard to know to whom I am replying due to
> non-indentation of replies, but I'll do my best.
>
> On Wed, 26 Mar 2014, Scott Leibrand wrote:
>
> > On Wed, Mar 26, 2014 at 3:12 AM, Chris Grundemann <cgrundemann at gmail.com>
> wrote:
> >       On Wed, Mar 26, 2014 at 7:05 AM, Scott Leibrand <
> scottleibrand at gmail.com> wrote:
> >       IMO the problem (for the AC, not the BoT) is that all turnover
> comes from resignations and people deciding not to run again. ?It's very
> rare that an
> >       incumbent fails to get re-elected. ?Given what I've observed as an
> AC member of the large diversity in contribution levels from my colleagues
> on the
> >       AC,
> >
> >
> > That is an observation, perhaps even a situation, but not by itself a
> problem. From my perspective it simply indicates that the community does a
> great job
> > selecting winning candidates initially, those candidates go on to be
> solid AC members, and therefor continue to win elections...
>
> I agree that this does not yet seem to rise to the level of a problem.
> There seems to be rather a lot of new and new/old faces (Kevin, myself,
> Milton, Tina, Andrew) lately.
>
> > That is a valid interpretation, but my perspective is slightly
> different. ?I would say it indicates that the community *likes* the people
> it elects to the AC. ?I think
> > that personal popularity has a disproportionate impact in re-electing AC
> members. ?It would be better if more information were readily available to
> the membership, so
> > they could base their choices on things like accomplishments and voting
> records.
>
> More information is always good. Four of the above five having not been
> re-elected, I don't know what conclusions can be drawn about our
> popularity. How well people are *liked* and questions of how popular
> people are recall to me a particularly odious time in my life prior to
> military service. If, in fact, that is what is going on here, perhaps we
> can address that particular matter in a more targeted way than term
> limits. I can recall some pretty candid discussions that have taken place.
>
> >       both new and old, that's evidence to me that the membership is
> re-electing members who are less effective, and we're therefore not getting
> the
> >       benefit of
> >
> >
> > How is it evidence that the membership is re-electing members who are
> less effective? Are you saying that YOU are less effective now then in your
> first two
> > terms? If not you, than who?
> >
> >
> > Yes, I actually am saying that. ?I still believe I am highly effective,
> but I found myself "coasting" a bit over the fall/winter, and putting in a
> lot less effort than
> > I had in my first few years. ?I believe I have mostly corrected that
> now, but I definitely see the tendency to start coasting after a certain
> amount of time, both in
> > myself and other AC members.
>
> Well, don't do that then. Term limits are not the answer for this
> situation. Surely you aren't suggesting that if terms limits were in
> place, this mid-term ennui would not have occured.
>        ?
> >       new ideas and approaches, and the higher willingness to take on
> difficult work, that new AC members tend to provide.
> > Reviewing the results of all the elections since 2007, when I was
> elected, I see:
> >
> > Year
> > Re-elected
> > Newly Elected
> > Newly appointed
> > NOT Re-elected
> > Notes
> > 2013
> > 4
> > 1
> > 1
> > 2012
> > 4
> > 1
> > 1
> > 2011
> > 4
> > 1
> > 1
> > 3-year incumbent not re-elected
> > 2010
> > 3
> > 2
> > 1
> > 1-year appointed incumbent not re-elected
> > 2009
> > 3
> > 2
> > 1
> > 2008
> > 2
> > 3
> > 2007
> > 3
> > 2
> >
> > As you can see, there has only been a single full-term incumbent who was
> not re-elected, and that was in a year when there were 5 incumbents on the
> ballot.
>
> I'm not immediately seeing any conclusion to be inferred from this
> observation.
>
> > I see that at least one new person joins the AC EVERY YEAR. Out of five
> open positions a minimum 20% turnover is actually pretty fantastic.
> >
> >
> > Closer to 13% on average (2 AC members out of 15) each year (with a
> range of 7-20%), almost all from attrition. ?If we had even 3% of full-term
> incumbents getting
> > replaced by challengers (1 every 2 years), I would be quite happy. ?But
> it's actually less than 1%. ?IMO that's too low.
>
> But higher lately, right?
>
> > I think term limits (1 year off after 2 terms) would help get more new
> people, with new ideas, approaches, and energy, onto the AC, without unduly
> > sacrificing experience and continuity.
> >
> > Of course, there may be other better ways to accomplish the same thing,
> so I'd love to hear other ideas for how we can get more fresh faces onto
> the AC.
> > ?Maybe we could tweak the election process somehow? ?One idea I just had
> would be to allow advisory input (some sort of straw poll) from PPML
> participants
> > that is published for the ARIN membership to review when casting their
> votes?
> >
> >
> > As others have asked, and you have failed to answer - what is the
> _problem_ we are trying to solve here? Capable AC members being re-elected
> is NOT a problem.
> >
> >
> > Here are some of the problems I see with the AC. ?I think term limits
> would help with all of them, though it wouldn't be a panacea, and it may be
> possible to come up
> > with better solutions to each one of them:
>
> Take these one at a time.
>
> > IMO the AC tends to be a little bit slow to incorporate?new ideas and
> > approaches.  More new faces would help with that. ?
>
> Speaking as one of those new faces, I can say with some authority that I
> approach the idea of floating a lot of new ideas and approaches with some
> caution. I am getting a little more willing to take some risks with
> experience, but a case could be made that I at least am more conservative
> than many old timers.
>
> > We also tend a little bit toward becoming a
> > social and travel club. ?I don't think that is a serious problem, yet,
> but I definitely worry about how many of us stay on the AC because we like
> our colleagues and
> > because we like to travel, rather than because we like to talk about,
> write, and improve ARIN policy. ?I definitely see that most new AC members
> are more inclined to
> > spend our time together talking about policy than most AC members with
> longer tenures.
>
> This is a bit of a tautological approach. The f2f experience is superior
> to the list in some ways. We need to travel to get f2f. We tend to like
> the f2f experience. Therefore, our motivation is exclusively to be a
> travel and social club. I have heard the grumbling about policy weenie
> wannabies junketing about on endless boondogles, but that is not the way
> it seems to me. Again, if this is a specific problem, let's air it out.
> Term limits seems like a particularly ineffective approach to this one.
>
> > Maybe another solution would be to reconsider whether we really need a
> 15-member AC in the first place. ?
>
> We did talk about this at some length. I am not against raising the
> subject again.
>
> > In all of the other RIRs,
>
> In addition to being a statement of fact, this is also an appeal to the
> bandwagon, and thus an insufficient reason for action. When I have seen
> such an observation floated in other fora, the response has sometimes been
> that the RIR system is ideal for each region to do things in their own
> way.
>
> > they simply have a policy working
> > group chair and co-chair, and then interested members of the community
> do all of the heavy lifting on policy, and on getting a consensus in the
> community. ?An
> > alternative to think about (and maybe discuss in Chicago) might be?to
> have proposal authors and wg chairs select one or more shepherds for each
> policy proposal, and
> > assign the shepherd the role of working with the author and community to
> try to actively forge a consensus? ? I'm not sure if that's a good solution
> or not, but it's
> > food for thought, anyway...
>
> OK, I'm game. But it looks like a lot of ground to cover from here to
> there. It might make a nice change from deck chairs though. Is
> restructuring the AC in scope for the AC?
>
> > -Scott
>
> John Springer
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 105, Issue 48
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140326/bfe70426/attachment.htm>

From hannigan at gmail.com  Wed Mar 26 21:27:44 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Wed, 26 Mar 2014 21:27:44 -0400
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAC4yj2Ujr8WMniu8DVh00iRvTV_H-MpunZb6+kcwBbPB7GYbuA@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
	<CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>
	<CAC6JZKScz4bnP-nra8mFvWZO08aPq0m9qD6FH-94PDUeWCS8Dg@mail.gmail.com>
	<312B1DFE-1AE4-4B3A-870B-83AD1EBB5617@gmail.com>
	<CAC6JZKQQOUCTPO31h4Q7dYRWrjsEcJ_-mUaS3C1Kag9oaq+9Vg@mail.gmail.com>
	<CAC4yj2Ujr8WMniu8DVh00iRvTV_H-MpunZb6+kcwBbPB7GYbuA@mail.gmail.com>
Message-ID: <CAMDXq5OwK+WDsJuM2geKL=C-wkzofZJcGpqmO70Ks8t6GgCq8g@mail.gmail.com>

On Wed, Mar 26, 2014 at 9:06 PM, Jason Schiller <jschiller at google.com>wrote:

> The 360 degree review was Martin's suggestion.  At the time it sounded
> like it mean a review for every angle (360 degrees in a circle).
>


You mean by adding in the ASO AC to the term limits requirement as well as
the BoT and the AC? If so, yes, 360.

I'm not suggesting a review though. I haven't seen anyone suggest a review,
rather implementation.


[ clip ]



> Bill Darte is an upstanding member of the AC, and I personally wish he
> would continue to serve, but it seemed pretty clear that his intent is to
> not continue.  Such a vacancy (if it happens) might be a good opportunity
> to repurpose the seat.
>


We all got it. Thanks.


Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140326/8f4007e0/attachment.htm>

From David.Huberman at microsoft.com  Wed Mar 26 22:55:17 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 27 Mar 2014 02:55:17 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <5331CA99.2000806@arin.net>
References: <5331CA99.2000806@arin.net>
Message-ID: <e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>

Hi PPML,

Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.  

Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.

Thank you!
/david

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Tuesday, March 25, 2014 11:28 AM
To: arin-ppml at arin.net
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

On 20 March 2014 the ARIN Advisory Council (AC) accepted
"ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.

Draft Policy ARIN-2014-12 is below and can be found at:
https://www.arin.net/policy/proposals/2014_12.html

You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.

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-2014-12
Anti-hijack Policy

Date: 25 March 2014

Problem Statement:

ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.

Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.

Policy statement:

Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.

11.7 Resource Allocation Guidelines

The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.

All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.

Comments:
a. Timetable for implementation: Immediate b. Anything else:
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage 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 rjletts at uw.edu  Wed Mar 26 23:10:15 2014
From: rjletts at uw.edu (Richard J. Letts)
Date: Thu, 27 Mar 2014 03:10:15 +0000
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <a30cf4c4764a4412a3e143733e301206@DM2PR08MB478.namprd08.prod.outlook.com>

I've seen that a new member has joined the ARIN AC each year.

I have not heard concrete evidence that this proposal improves the policy making process

I do not think this is a good idea.

Richard Letts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140327/6df0405b/attachment.htm>

From alex at aspenworks.com  Wed Mar 26 23:52:51 2014
From: alex at aspenworks.com (Alex)
Date: Wed, 26 Mar 2014 20:52:51 -0700
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <CAMDXq5OwK+WDsJuM2geKL=C-wkzofZJcGpqmO70Ks8t6GgCq8g@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<20140325161504.GO47828@mx1.yitter.info>
	<f71276b659514db5b358188cf852e681@BY2PR06MB488.namprd06.prod.outlook.com>
	<5331B639.4010501@servlet.com>
	<1395783545.90117.YahooMailNeo@web160805.mail.bf1.yahoo.com>
	<CAGkMwz5emw_1_EU5=TZAuuwq8Fn_xm-E20LJbZYPqm-DejZwZA@mail.gmail.com>
	<CAC1-dt=gVD0po1YYTRoVUhGYjHNtafRbaY8_EUauixT1OOVMkA@mail.gmail.com>
	<CAGkMwz4irA30a0tNue4QoUyjWhtnWPcZDKADVKapL_x9SB4nYw@mail.gmail.com>
	<CAC4yj2UXs4Aah0WyRKzTv60oVv8QE4wCY4sv+aTtTTh=J7jdKg@mail.gmail.com>
	<CAC6JZKScz4bnP-nra8mFvWZO08aPq0m9qD6FH-94PDUeWCS8Dg@mail.gmail.com>
	<312B1DFE-1AE4-4B3A-870B-83AD1EBB5617@gmail.com>
	<CAC6JZKQQOUCTPO31h4Q7dYRWrjsEcJ_-mUaS3C1Kag9oaq+9Vg@mail.gmail.com>
	<CAC4yj2Ujr8WMniu8DVh00iRvTV_H-MpunZb6+kcwBbPB7GYbuA@mail.gmail.com>
	<CAMDXq5OwK+WDsJuM2geKL=C-wkzofZJcGpqmO70Ks8t6GgCq8g@mail.gmail.com>
Message-ID: <097E8EA1-CCCC-47BD-B008-23B26076628A@aspenworks.com>

My personal email address just celebrated its 25th year of continuous service last October.
It seems to work fine. If it isn?t broken, don?t fix it.

Alex
alex at aspenworks.com
This electronic message contains information generated by me, and solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.




On Mar 26, 2014, at 6:27 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> 
> On Wed, Mar 26, 2014 at 9:06 PM, Jason Schiller <jschiller at google.com> wrote:
> The 360 degree review was Martin's suggestion.  At the time it sounded like it mean a review for every angle (360 degrees in a circle).  
> 
> 
> You mean by adding in the ASO AC to the term limits requirement as well as the BoT and the AC? If so, yes, 360.
> 
> I'm not suggesting a review though. I haven't seen anyone suggest a review, rather implementation. 
> 
> 
> [ clip ]
> 
>  
> Bill Darte is an upstanding member of the AC, and I personally wish he would continue to serve, but it seemed pretty clear that his intent is to not continue.  Such a vacancy (if it happens) might be a good opportunity to repurpose the seat.
> 
> 
> We all got it. Thanks.
> 
> 
> Best,
> 
> -M<
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

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

From David.Huberman at microsoft.com  Thu Mar 27 00:55:12 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 27 Mar 2014 04:55:12 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>
	<afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <7b2e957f1aba40cea0ecf87f4254478d@DM2PR03MB398.namprd03.prod.outlook.com>

[Apologies if this is asked/answered later in the thread.]

Will ARIN staff or counsel please comment on whether bottoms-up requests to change the Bylaws of the Board of Trustees can be made via the PDP?

Thank you.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Azinger, Marla
Sent: Wednesday, March 26, 2014 10:35 AM
To: John Springer
Cc: arin-discuss at arin.net; arin-ppml at arin.net
Subject: Re: [arin-ppml] [arin-discuss] Term Limit Proposal

Hi John

Given the response I think an official proposal needs to be written.  I'm happy to see the acceptance of a written proposal will be received for due process and not turned over to the recycling bin for "not being a policy topic".

I will try to get that turned in this week.

Regards
Marla

-----Original Message-----
From: John Springer [mailto:springer at inlandnet.com]
Sent: Tuesday, March 25, 2014 12:51 PM
To: Azinger, Marla
Cc: arin-ppml at arin.net; arin-discuss at arin.net
Subject: Re: [arin-discuss] Term Limit Proposal

Hi Marla,

The current PDP requires only two things for a policy proposal to be accepted as a Draft Policy, to have a clear problem statement and be in scope for the AC.

I am sure all AC members will be delighted to work with you to arrive at the former. I am less sure how successful we will be getting around a clear statement from the BoT that such matters are not in scope. We can certainly give it a shot if that is the way you would prefer to go.

Alternately, all members of the Board of Trustees read these lists, perhaps they may take the matter up directly from here?

Or they may prefer to receive the question via the suggestion process?

https://www.arin.net/app/suggestion/

The AC has had some recent experience with adopting changes to standing rules. Perhaps that might be an option.

There does appear to be a healthy amount of initial support for your idea.
How would you like to proceed?

John Springer


On Tue, 25 Mar 2014, Azinger, Marla wrote:

> 
> Having been on the AC for a 6 years I support a term limit for the AC.
> 
> ?
> 
> When on my 4th year I pursued creating a term limit.? At the time I 
> was told this was an action the BOT would have to take.? No action was 
> taken.? Later I inquired on this being submitted as policy since the 
> BOT did not take action.? I was told it would be thrown out since it?s not a matter of policy. ?Now with time and reviewing other public posts, I have more hope this will be taken seriously and something done.? I include this small history on my experience to show that the idea of term measures has been around for a? while but for some reason never gained traction.
> 
> ?
> 
> I believe a balance between familiarity, hitting a productive stride, 
> burn out and mind melting needs to be balanced out with fresh able 
> minds.? I also believe a solid
> 3 year break is needed for people to re-integrate as a non-AC person 
> and regroup.? Leaving anyone on a committee for more than 6 years opens the door to stagnation, burn out, and conformity of thinking.? Remember, just because someone is not on the AC any longer does not mean AC folks can?t get advice from them if desired.
> 
> ?
> 
> I propose the following be used for AC:
> 
> -Keep the 3 year terms in place ?and add
> 
> -a 6 year contiguous term limit
> 
> -a 3 year ineligibility year period after a term ends be it 3year or 
> 6years
> 
> -After 3 year ineligibility is over a person my run for a position on the AC again.
> 
> ?
> 
> ?
> 
> ?
> 
> I believe the BOT should also have some term measures and limits. 
> However, I am asking someone who has served on the BOT in the past to create a thought out term plan and propose it.
> 
> ?
> 
> To keep this topic on track, I have purposely excluded the discussion 
> of committee member candidate requirements.? This should be a separate topic that also needs discussion in order to better ensure community wide representation.
> 
> ?
> 
> ?
> 
> Regards
> 
> Marla Azinger
> 
> 
>
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage 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 David.Huberman at microsoft.com  Thu Mar 27 01:01:58 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 27 Mar 2014 05:01:58 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <358A138A-912D-4A9C-BAEB-9316083D80BE@arin.net>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>
	<afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>
	<358A138A-912D-4A9C-BAEB-9316083D80BE@arin.net>
Message-ID: <de61cf45915a4df7b99bb0dbdbfc399f@DM2PR03MB398.namprd03.prod.outlook.com>

John Curran wrote:

"If mandatory terms limits are desired for the ARIN Board of Trustees or ARIN AC,
it would be best to write up the specific suggestion and submit the ARIN consultation 
and suggestion process, as noted by John Springer. I will bring the proposal and 
results of the discussion of the proposal on the arin-consult mailing list to the ARIN 
Board of Trustees for their further consideration."

I apologize if I sound combative, but I strongly dislike this suggestion.  
John, when there is time, can staff please tell us:

- how many non-staff|non-board|non-AC|non-ASO/NRO|non-RIR subscribers 
are currently on arin-consult?

- how many individuals (same exclusions as above) have posted to the list in
the past 12 months?

I strongly suspect the true participation numbers for this pseudo-invisible
mailing list will be too low for any Bylaws change discussed exclusively 
there to meaningfully represent "bottoms-up participation".

/david


From jcurran at arin.net  Thu Mar 27 01:27:39 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 27 Mar 2014 05:27:39 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <de61cf45915a4df7b99bb0dbdbfc399f@DM2PR03MB398.namprd03.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>
	<afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>
	<358A138A-912D-4A9C-BAEB-9316083D80BE@arin.net>
	<de61cf45915a4df7b99bb0dbdbfc399f@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <E65FA51C-21C5-421F-B928-EAC704B9B742@arin.net>

On Mar 27, 2014, at 1:01 PM, David Huberman <David.Huberman at microsoft.com> wrote:

> I apologize if I sound combative, but I strongly dislike this suggestion.  

David - 

   I noted it as an option because it is the mailing list documented for 
   that purpose in the suggestion process.

> John, when there is time, can staff please tell us:
> 
> - how many non-staff|non-board|non-AC|non-ASO/NRO|non-RIR subscribers 
> are currently on arin-consult?
> 
> - how many individuals (same exclusions as above) have posted to the list in
> the past 12 months?

   We shall obtain such information.

> I strongly suspect the true participation numbers for this pseudo-invisible
> mailing list will be too low for any Bylaws change discussed exclusively 
> there to meaningfully represent "bottoms-up participation".

  The arin-consult mailing list is specifically for handling suggestions
  and is open to the general public.  That does not preclude discussion on
  arin-ppml, but we have had complaints in the past of too much non-policy
  traffic on PPML and hence made arin-consult list specifically for suggestions.  
  You will note that there has been no suggestion that arin-ppml is inappropriate 
  for such a purpose over the discussions of that last two days; it is simply
  a question of how the community wishes to organize its discussions; one 
  omnibus list or a distinct list for operational and organization matters
  which are not number resource policy development.

Thanks!
/John

John Curran 
President and CEO
ARIN



  




From David.Huberman at microsoft.com  Thu Mar 27 02:06:34 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 27 Mar 2014 06:06:34 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <E65FA51C-21C5-421F-B928-EAC704B9B742@arin.net>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>
	<afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>
	<358A138A-912D-4A9C-BAEB-9316083D80BE@arin.net>
	<de61cf45915a4df7b99bb0dbdbfc399f@DM2PR03MB398.namprd03.prod.outlook.com>
	<E65FA51C-21C5-421F-B928-EAC704B9B742@arin.net>
Message-ID: <88fa744127ed489da88336320ebda212@DM2PR03MB398.namprd03.prod.outlook.com>

John,

Thank you for your speedy and helpful reply.

I will note you close your email with the implication that a desire by the participants of ARIN's public fora to alter the Board's bylaws is not a policy development activity.   If that is true - if a policy proposal conducted under the auspices of PDP to change the bylaws is out of scope of the PDP (did you imply that?) - then by what mechanism can the public:
- bring to light an idea for bylaws change;
- discuss it;
- attempt to substantively judge consensus of the proposed change; and 
- upon judging consensus exists, affect disposition of the change?

In other words, surely the public, speaking with consensus, can change the Bylaws of the Board without relying on the elected Board members themselves to effect this change, yes?  If no, please state so, as such a response should be extremely alarming to all who care about ARIN's future, I think.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: John Curran [mailto:jcurran at arin.net] 
Sent: Wednesday, March 26, 2014 10:28 PM
To: David Huberman
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] [arin-discuss] Term Limit Proposal

On Mar 27, 2014, at 1:01 PM, David Huberman <David.Huberman at microsoft.com> wrote:

> I apologize if I sound combative, but I strongly dislike this suggestion.  

David - 

   I noted it as an option because it is the mailing list documented for 
   that purpose in the suggestion process.

> John, when there is time, can staff please tell us:
> 
> - how many non-staff|non-board|non-AC|non-ASO/NRO|non-RIR subscribers 
> are currently on arin-consult?
> 
> - how many individuals (same exclusions as above) have posted to the 
> list in the past 12 months?

   We shall obtain such information.

> I strongly suspect the true participation numbers for this 
> pseudo-invisible mailing list will be too low for any Bylaws change 
> discussed exclusively there to meaningfully represent "bottoms-up participation".

  The arin-consult mailing list is specifically for handling suggestions
  and is open to the general public.  That does not preclude discussion on
  arin-ppml, but we have had complaints in the past of too much non-policy
  traffic on PPML and hence made arin-consult list specifically for suggestions.  
  You will note that there has been no suggestion that arin-ppml is inappropriate
  for such a purpose over the discussions of that last two days; it is simply
  a question of how the community wishes to organize its discussions; one
  omnibus list or a distinct list for operational and organization matters
  which are not number resource policy development.

Thanks!
/John

John Curran
President and CEO
ARIN



  




From jcurran at arin.net  Thu Mar 27 02:37:05 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 27 Mar 2014 06:37:05 +0000
Subject: [arin-ppml] [arin-discuss] Term Limit Proposal
In-Reply-To: <88fa744127ed489da88336320ebda212@DM2PR03MB398.namprd03.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>
	<afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>
	<358A138A-912D-4A9C-BAEB-9316083D80BE@arin.net>
	<de61cf45915a4df7b99bb0dbdbfc399f@DM2PR03MB398.namprd03.prod.outlook.com>
	<E65FA51C-21C5-421F-B928-EAC704B9B742@arin.net>
	<88fa744127ed489da88336320ebda212@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <1ED2FBFC-C519-47BE-86FA-009A525C22BF@arin.net>

On Mar 27, 2014, at 2:06 PM, David Huberman <David.Huberman at microsoft.com> wrote:

> John,
> 
> Thank you for your speedy and helpful reply.
> 
> I will note you close your email with the implication that a desire by the participants of ARIN's public fora to alter the Board's bylaws is not a policy development activity.  

That is correct - The ARIN PDP is the process by which policies (for the
management of Internet number resources in the ARIN region) are developed 
by the community. 

> If that is true - if a policy proposal conducted under the auspices of PDP to change the bylaws is out of scope of the PDP (did you imply that?)

I don't imply it - it has always been the case, and is quite specific in 
the PDP and role of the AC - <https://www.arin.net/policy/pdp.html>

> - then by what mechanism can the public:
> - bring to light an idea for bylaws change;
> - discuss it;

You are doing those items above presently on the public policy mailing list.

> - attempt to substantively judge consensus of the proposed change; and 
> - upon judging consensus exists, affect disposition of the change?

The above two points intersect the responsibilities of the ARIN Board of Trustees;
discussion is encouraged both online and at the open microphone forum at the ARIN 
meetings, but the Board must consider all related aspects (including risk involved
and fiduciary duty) when it comes to making such decisions. The ARIN Board has 
delegated (nearly completely) number resource policy development to the entire
community, but the same does not apply to their fiduciary duties in general.

The good news is, the Board is elected by the community, so folks who wish s
to serve in that capacity can run and be elected for that purpose.  This is 
called "representation" and is a very common structure among associations.

> In other words, surely the public, speaking with consensus, can change the Bylaws of the Board without relying on the elected Board members themselves to effect this change, yes?

You probably mean "members" (as opposed to "public") but in either case that 
is not a capability under ARIN's Bylaws today.  That is is not to say it could
not be added in the future if desired (for example, ARIN originally didn't have 
members or an elected Board; these were added once the organization achieved 
the appropriate level of operational stability and community support.)

FYI,
/John

John Curran
President and CEO
ARIN



From David.Huberman at microsoft.com  Thu Mar 27 03:37:13 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 27 Mar 2014 07:37:13 +0000
Subject: [arin-ppml] ARIN board accountability to network operators
 (was: RE: [arin-discuss] Term Limit Proposal)
Message-ID: <b187855796604954992f390bdfe1767c@DM2PR03MB398.namprd03.prod.outlook.com>

Hello,

Thank you again, John, for a very clear and concise reply.

I have changed the subject line, so as to fork this theme away 
from the very specific term limits discussion, and to pivot it to
what I believe may (again: MAY) be the true problem that exists.
I sincerely apologize in advance for what is a very long email.

I think the true problem may a combination of:
- the reality of how network operators are participating 
in ARIN; and
- the brand new risks which the ARIN corporate governance 
model now presents to the network operator community in 
light of the United States Government's announcement of 
its plans to relinquish its oversight role; and in turn
- the question of whether the American Registry for Internet
Numbers Ltd., as currently incorporated in the Commonwealth
of Virginia, is serving the network operator community in an 
accountable manner.
 
Allow me to explain.

Point 1. - "low participation"

In a recent NANOG-L thread, Randy Bush (copied here) began a 
discussion on the very low participation rates that ARIN is currently 
suffering from.  In that thread, some statistics were provided by
ARIN which highlight that only 17% of the network operators
(mostly companies, a few individuals, some governments) who
are the registrants of IPv4 address space in the ARIN region are
members with voting rights.  

Furthermore, a disturbing reality which many of us know exists 
was highlighted by you: participation in the policy making process 
(the PDP) is down to 30-50 people or thereabouts. As Randy 
notes, 15 of them enjoy travel expenses paid for by ARIN for their 
presence at internet governance fora, including attendance at 
the ARIN meetings.   Succinctly, the number of network operators 
actively participating in the PDP is frighteningly low, and thus 
ARIN as an administrative body with a mission of multi-stakeholder, 
bottoms-up participation, could be judged as modestly failing.

There have been many good effort made recently by ARIN to
fix this, including the good idea to have a PPC at NANOG.  But
I have witnessed a few of these, and I think it's fair to say these
are failing, too.  The participants are mostly the same people who
attend the ARIN PPM.  The network operators ARIN is trying
to engage are opting to not attend or participate in the PPCs.
(The lack of participation at the PPC in Phoenix was especially
troubling to me.)

Point 2. - "USG is leaving the nest"

For the first time in ARIN's history, the ARIN Board is fully and
completely in charge of its destiny.  I submit that for the past
15 years since ARIN's establishment, the Board has been 
accountable in a very real way to the oversight of the United
States Government ("USG").  What do I mean?

Ponder, if you will, a hypothetical.

An ARIN Board finds 4 votes to direct ARIN's CEO to purge all 
non-RSA-covered registrations out of Whois.  As a consequence,
ARIN stops providing inverse mapping for these delegation
points. This action causes material harm to untold numbers of
networks throughout the world.  The afflicted operators seek
remedy in the courts, and ARIN is bankrupted because of its
willful negligence. (A thousand pardons if I'm not quite using the
right legal terms. The technical parts of the hypothetical are
accurate, in my opinion.)

Today if the Board tried this, the dissenting members or the
ARIN CEO or even the ARIN staff charged with carrying out this
order, can stop this from happening with a single email that
reaches USG.  As Ray Plzak once taught me, never underestimate
the awesome power of the USG.  NTIA and DoC would, today, stop
such an action dead in its tracks. 

Today  the Board is accountable for its actions not only by virtue
of elections and recalls, but because there is an emergency lever 
to pull if things get ugly. Tomorrow, that lever will not be there. 
The buck will truly stop at the Board's doorstep.

Part 3. - "the board isn't sufficiently accountable"

The first two parts ("low participation" and "USG is leaving the
nest") neatly form the crux of the problem:

- the ARIN board, under its current bylaws, may not be 
sufficiently accountable to the network operator community 
it is supposed to be serving.

In the hypothetical above where the Board wipes out inverse
mappings for most of the north American internet, the
community of network operators do not have a strong 
enough lever to stop malfeasance before ARIN does 
irreparable harm.  And because the operator community
is clearly NOT participating in significant numbers, the
problem is worse than the hypothetical lays out.

So how do we solve this?  How do we increase participation
so it is actually statistically significant? How do we develop
mechanisms to ensure the elected ARIN Board is accountable
for its actions? How do we ensure we elect really, really good
Board members?

I don't have great answers to offer yet.  Wiser and smarter
heads than mine must be put to this task, I think.  I really
hope that we can find a way to open up ARIN participation
in a meaningful way, and not fall back on the argument that
we have a structure and people choose not to participate
and that's on them.  I hope we can conduct this task openly
and transparently, and not assign a committee of three
BOARD members to solve the problem.

With regards,
David

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: John Curran [mailto:jcurran at arin.net] 
Sent: Wednesday, March 26, 2014 11:37 PM
To: David Huberman
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] [arin-discuss] Term Limit Proposal

On Mar 27, 2014, at 2:06 PM, David Huberman <David.Huberman at microsoft.com> wrote:

> John,
> 
> Thank you for your speedy and helpful reply.
> 
> I will note you close your email with the implication that a desire by the participants of ARIN's public fora to alter the Board's bylaws is not a policy development activity.  

That is correct - The ARIN PDP is the process by which policies (for the management of Internet number resources in the ARIN region) are developed by the community. 

> If that is true - if a policy proposal conducted under the auspices of 
> PDP to change the bylaws is out of scope of the PDP (did you imply 
> that?)

I don't imply it - it has always been the case, and is quite specific in the PDP and role of the AC - <https://www.arin.net/policy/pdp.html>

> - then by what mechanism can the public:
> - bring to light an idea for bylaws change;
> - discuss it;

You are doing those items above presently on the public policy mailing list.

> - attempt to substantively judge consensus of the proposed change; and
> - upon judging consensus exists, affect disposition of the change?

The above two points intersect the responsibilities of the ARIN Board of Trustees; discussion is encouraged both online and at the open microphone forum at the ARIN meetings, but the Board must consider all related aspects (including risk involved and fiduciary duty) when it comes to making such decisions. The ARIN Board has delegated (nearly completely) number resource policy development to the entire community, but the same does not apply to their fiduciary duties in general.

The good news is, the Board is elected by the community, so folks who wish s to serve in that capacity can run and be elected for that purpose.  This is called "representation" and is a very common structure among associations.

> In other words, surely the public, speaking with consensus, can change the Bylaws of the Board without relying on the elected Board members themselves to effect this change, yes?

You probably mean "members" (as opposed to "public") but in either case that is not a capability under ARIN's Bylaws today.  That is is not to say it could not be added in the future if desired (for example, ARIN originally didn't have members or an elected Board; these were added once the organization achieved the appropriate level of operational stability and community support.)

FYI,
/John

John Curran
President and CEO
ARIN



From jcurran at arin.net  Thu Mar 27 05:15:33 2014
From: jcurran at arin.net (John Curran)
Date: Thu, 27 Mar 2014 09:15:33 +0000
Subject: [arin-ppml] ARIN board accountability to network operators
 (was: RE: [arin-discuss] Term Limit Proposal)
In-Reply-To: <b187855796604954992f390bdfe1767c@DM2PR03MB398.namprd03.prod.outlook.com>
References: <b187855796604954992f390bdfe1767c@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <16EDFEA2-39B3-45CD-B018-B4F21A76F574@arin.net>

On Mar 27, 2014, at 3:37 PM, David Huberman <David.Huberman at microsoft.com> wrote:

> I think the true problem may a combination of:
> - the reality of how network operators are participating 
> in ARIN; and
> - the brand new risks which the ARIN corporate governance 
> model now presents to the network operator community in 
> light of the United States Government's announcement of 
> its plans to relinquish its oversight role; and in turn
> - the question of whether the American Registry for Internet
> Numbers Ltd., as currently incorporated in the Commonwealth
> of Virginia, is serving the network operator community in an 
> accountable manner.

David - 
   
An excellent (and timely) set of topics for discussion!

> Point 1. - "low participation"
> ...
> Succinctly, the number of network operators actively participating
> in the PDP is frighteningly low, and thus ARIN as an administrative
> body with a mission of multi-stakeholder, bottoms-up participation,
> could be judged as modestly failing.

Interestingly, you conflate two items in the above logic - you have
equated the "level of network operators participating in the PDP" 
to a measure of ARIN's success of accomplishing its mission.

This would imply that if we were to ever achieve extremely stable 
policy, ARIN would not be successful unless we stimulated policy 
development for its own sake, i.e. as an explicit goal of the system.  

I do not believe that many would support that direction, and while I 
do feel that getting increased levels of participation in the policy
development process is indeed desirable, that needs to be the result 
of network operators finding it useful to participate and not as a 
goal in and of itself.

> There have been many good effort made recently by ARIN to
> fix this, including the good idea to have a PPC at NANOG.  But
> I have witnessed a few of these, and I think it's fair to say these
> are failing, too.  The participants are mostly the same people who
> attend the ARIN PPM.  The network operators ARIN is trying
> to engage are opting to not attend or participate in the PPCs.
> (The lack of participation at the PPC in Phoenix was especially
> troubling to me.)

The PPC's at NANOG are successful from the perspective of allowing for
additional face-to-face exploration of policy proposals and any related
issues.  Understanding the nuances of a given proposal can be challenging 
the mailing list, and so the face-to-face discussion can be quite useful
even if lightly attended.  I do think that everyone realizes that the 
number of participants is relatively low compared to an ARIN policy 
consultation, and thus it may be better to hold off until an ARIN meeting 
before attempting to measuring support for advancing or abandoning a 
proposal.

I'm very much interested in any suggestions that you might have for 
improving participation in the policy development process, but again
I am not certain I'd agree that the level of disinterest in the work 
involved in number policy development somehow equates with an ARIN
failure.

> Point 2. - "USG is leaving the nest"
> ...
> Today  the Board is accountable for its actions not only by virtue
> of elections and recalls, but because there is an emergency lever 
> to pull if things get ugly. Tomorrow, that lever will not be there. 
> The buck will truly stop at the Board's doorstep.

You are correct with respect to the Board being accountable today due to 
several factors: elections, recalls, and the potential, even if remote,
of USG intervention in case of severe ARIN misalignment with the community. 

Note that there are also some other mechanisms which provide a form of
"hard" accountability which you omitted: contractual terms and arbitration
in the registration services agreements, the ability to seek redress in 
a court if ARIN isn't performing per its incorporation and bylaws, etc.  
(These are in addition to "soft' mechanisms such as reviews by ICANN 
and stakeholders via ASO relationship, IETF or NANOG queries regarding 
performance, RIR "peer pressure", etc. - let's omit these for now)

I believe that the Board, as an elected body, is indeed accountable 
to this community, but it is my view as well that these mechanisms 
are well worth reviewing, as the loss of the (largely symbolic) USG 
oversight means that some future Board could indeed take rash actions 
not supported by the community, and even if there are mechanisms today 
in the Bylaws to provide recourse, I do not see any clear assurance 
that they would be still be present or potent some time in the future.

There is also an excellent related question that applicable to the 
entire Internet identifier system regarding whether there are hard
requirements for mechanisms such as "membership organizations" and 
"open and transparent policy development", and if so, should these
be constitutionally mandated for all of these organizations, and 
how exactly would that be implemented?  Folks interested in such 
should look at the IANA Transition mail that I sent earlier this 
week and get involved, but there is no reason that ARIN can't be 
proactive in strengthening its governance practice even while such 
discussions are underway.

> Part 3. - "the board isn't sufficiently accountable"
> 
> The first two parts ("low participation" and "USG is leaving the
> nest") neatly form the crux of the problem:
> 
> - the ARIN board, under its current bylaws, may not be 
> sufficiently accountable to the network operator community 
> it is supposed to be serving.

Again, we've got a logic issue due to your use of policy development
participation as a measure, but let's substitute the 600 organizations
who participated in elections and then noting that is still a fairly
small subset of total resource holders in the region, I think your 
problem statement is a reasonable question to ask.  I would answer 
"yes" (that the Board is accountable based on the presently existing 
structures and ability for parties to participate; I understand you 
might see it differently.

> In the hypothetical above where the Board wipes out inverse
> mappings for most of the north American internet, the
> community of network operators do not have a strong 
> enough lever to stop malfeasance before ARIN does 
> irreparable harm.  And because the operator community
> is clearly NOT participating in significant numbers, the
> problem is worse than the hypothetical lays out.

You hypothecate an extreme case; one which is based on the community 
first electing numerous persons whose judgement is apparently quite 
different than expected - perhaps that is one place to start your 
efforts.

In addition, if there are certain principles which should be inherently 
part of ARIN regarding how we operate or who we serve, perhaps these 
should be discussed by the community to see if there is a common view.  
If that exists, it would be possible to set up mechanisms which would 
provide for community notice, consultation (or more) to change. Note 
that we have been looking into such structures already for ARIN as a
result of last year's Mission Statement change - while it was primarily 
administrative in nature, the community rightly raised that such changes 
should not happen without prior community discussion.

> I don't have great answers to offer yet.  Wiser and smarter
> heads than mine must be put to this task, I think.  I really
> hope that we can find a way to open up ARIN participation
> in a meaningful way, and not fall back on the argument that
> we have a structure and people choose not to participate
> and that's on them.  I hope we can conduct this task openly
> and transparently, and not assign a committee of three
> BOARD members to solve the problem.

I've provided a few suggestions to start above, and this list seems to 
be quite open and transparent, so per above you just need to recruit 
some "wiser and smarter heads" to put to the task... (while neither, 
I am available if any questions arise during your efforts :-)

Thanks!
/John

John Curran
President and CEO
ARIN






From john.sweeting at twcable.com  Thu Mar 27 09:20:25 2014
From: john.sweeting at twcable.com (Sweeting, John)
Date: Thu, 27 Mar 2014 09:20:25 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CF599D70.4298D%john.sweeting@twcable.com>

Hi David,

Draft Policies only get posted to PPML once they are moved forward in the
process to that state. That being said it was just posted as a DP this
week, Tuesday. Discussions need to begin and it will also be presented and
discussed at the PPM in Chicago. This is in accordance with the current
PDP. Hope that helps.

Thanks,
John

On 3/26/14, 10:55 PM, "David Huberman" <David.Huberman at microsoft.com>
wrote:

>Hi PPML,
>
>Can someone show me where in the mailing list archives this policy was
>actively discussed on PPML? I can't find it.
>
>Alternatively, can the policy author or someone who strongly supports
>this policy please either post to the list or email me privately and clue
>me in?  I issued and managed almost every experimental assignment for
>almost 10 years from 2003 to 2013, and I am lost as to what this policy
>is saying.  I would like to be educated so I can support, or not support,
>the efforts that have been made here.
>
>Thank you!
>/david
>
>David R Huberman
>Microsoft Corporation
>Senior IT/OPS Program Manager (GFS)
>
>-----Original Message-----
>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>Behalf Of ARIN
>Sent: Tuesday, March 25, 2014 11:28 AM
>To: arin-ppml at arin.net
>Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
>On 20 March 2014 the ARIN Advisory Council (AC) accepted
>"ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>
>Draft Policy ARIN-2014-12 is below and can be found at:
>https://www.arin.net/policy/proposals/2014_12.html
>
>You are encouraged to discuss the merits and your concerns of Draft
>Policy 2014-12 on the Public Policy Mailing List.
>
>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-2014-12
>Anti-hijack Policy
>
>Date: 25 March 2014
>
>Problem Statement:
>
>ARIN should not give research organizations permission to hijack prefixes
>that have already been allocated. Research organizations announcing lit
>aggregates may receive sensitive production traffic belonging to live
>networks during periods of instability.
>
>Section 11.7 describes more than allocation size therefore updating the
>section heading to something more accurate is appropriate.
>
>Policy statement:
>
>Modify the section 11.7 heading to be more accurate. Modify the first
>sentence to prohibit overlapping assignments. Add text at the end to
>define how research allocations should be designated and prohibit LOA's
>without allocations.
>
>11.7 Resource Allocation Guidelines
>
>The Numbering Resources requested come from the global Internet Resource
>space, do not overlap previously assigned space, and are not from private
>or other non-routable Internet Resource space. The allocation size should
>be consistent with the existing ARIN minimum allocation sizes, unless
>small allocations are intended to be explicitly part of the experiment.
>If an organization requires more resource than stipulated by the minimum
>allocation sizes in force at the time of their request, their
>experimental documentation should have clearly described and justified
>why this is required.
>
>All research allocations must be registered publicly in whois. Each
>research allocation will be designated as a research allocation with a
>comment indicating when the allocation will end. ARIN will not issue a
>Letter of Authority (LOA) to route a research prefix unless the
>allocation is properly registered in whois.
>
>Comments:
>a. Timetable for implementation: Immediate b. Anything else:
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to the ARIN
>Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


From cja at daydream.com  Thu Mar 27 09:54:26 2014
From: cja at daydream.com (CJ Aronson)
Date: Thu, 27 Mar 2014 13:54:26 +0000
Subject: [arin-ppml] Initial IPv4 allocations to ISPs, NRPM section 4.2
Message-ID: <CAC6JZKQidGWhVd2=tOXxgL+3a7Z5tTqPox10jznbREJfyF1tEA@mail.gmail.com>

I have been having a discussion with a member of the community about the
initial allocations to ISPs, NRPM section 4.2.  I thought quite a bit about
this last night and I would love your input.  It seems to me that we might
want to revamp this in light of IPv4 run out.  Does it make sense when the
ARIN free pool is exhausted?  I am sure some think that it does/doesn't
make sense now but since we're so close to run out let's look at whether it
still makes sense when the ARIN free pool is exhausted.

Thanks for your input!  If anyone wants to work with me to draft a new
version please let me know.

Thanks!
-----Cathy

Here is the text from the NRPM
https://www.arin.net/policy/nrpm.html#four2
4.2. Allocations to ISPs (Requirements for Requesting Initial Address Space)
4.2.1. Principles
4.2.1.1. Purpose

ARIN allocates blocks of IP addresses to ISPs for the purpose of
reassigning that space to their customers.
4.2.1.2. Annual Renewal

An annual fee for registered space is due by the anniversary date of the
ISP's first allocation from ARIN. ISPs should take care to ensure that
their annual renewal payment is made by their anniversary due date in
accordance with the Registration Services Agreement. If not paid by the
anniversary date, the address space may be revoked. Please review the
Annual Renewal/Maintenance Fees Page for more details.
4.2.1.3. Utilization rate

Utilization rate of address space is a key factor, among others, in
determining address allocation.
4.2.1.4. Slow start

Because the number of available IP addresses on the Internet is limited,
many factors must be considered in the determination of address space
allocations. Therefore, IP address space is allocated to ISPs using a
slow-start model. Allocations are based on justified need, not solely on a
predicted customer base.
4.2.1.5. Minimum allocation

In general, ARIN allocates /20 and larger IP address prefixes to ISPs. If
allocations smaller than /20 are needed, ISPs should request address space
from their upstream provider. For multihomed ISPs, ARIN allocates /22 and
larger IP address prefixes. If allocations smaller than /22 are needed,
multihomed ISPs should request address space from their upstream provider.
4.2.1.6. Immediate need

If an ISP has an immediate need for address space, and can provide
justification to show that the address space will be utilized within 30
days of the request, ARIN may issue a block of address space, not larger
than a /16 nor smaller than ARIN's customary minimum allocation, to that
organization. These cases are exceptional.
4.2.2. Initial allocation to ISPs
4.2.2.1. Standard or non-multihomed

Organizations that do not meet the requirements described in the multihomed
section below (Section 4.2.2.2) must satisfy the following requirements:
4.2.2.1.1. Use of /20

The efficient utilization of an entire previously allocated /20 from their
upstream ISP. This /20 allocation may have been provided by an ISP's
upstream provider(s), and does not have to be contiguous address space. The
organization must meet the requirement of efficient use of 16 /24s. For
example, if an organization holds a smaller allocation, such as 12 /24s,
from its upstream provider, the organization would not meet the minimum
utilization requirements of a /20.
4.2.2.1.2. Efficient utilization

Demonstrate efficient use of IP address space allocations by providing
appropriate documentation, including assignment histories, showing their
efficient use. ISPs must provide reassignment information on the entire
previously allocated block(s) via SWIP or RWhois server for /29 or larger
blocks. For blocks smaller than /29 and for internal space, ISPs should
provide utilization data either via SWIP or RWhois server or by providing
detailed utilization information.
4.2.2.1.3. Three months

Provide detailed information showing specifically how a /20 will be
utilized within three months.
4.2.2.1.4. Renumber and return

ISPs receiving a new /20 may wish to renumber out of their previously
allocated space. In this case, an ISP must use the new /20 to renumber out
of that previously allocated block of address space and must return the
space to its upstream provider.
4.2.2.2. Multihomed

When prefixes are allocated which are smaller than /20, they will be from a
block reserved for that purpose. In order to receive an initial allocation
from ARIN, organizations applying under the multihomed policy must:

   - When requesting a /22, demonstrate the efficient utilization of a
   minimum contiguous or noncontiguous /23 (two /24s) from an upstream.
   - When requesting a /21, demonstrate the efficient utilization of a
   minimum contiguous or noncontiguous /22 (four /24s) from an upstream.
   - When requesting a /20, demonstrate the efficient utilization of a
   minimum contiguous or noncontiguous /21 (eight /24s) from an upstream.

4.2.2.2.1. Efficient utilization

Provide reassignment information for /29 and larger blocks using the Shared
Whois Project (SWIP) or by providing the same information fields in an
RWhois server. If additional address space is later requested, this
information must be available at the time of the request. Utilization for
blocks smaller than /29 can be documented via SWIP or RWhois server or by
providing detailed utilization information.
4.2.2.2.2. Three months

Provide information showing that the requested IP address space will be
utilized within three months and demonstrating an intent to announce the
requested space in a multihomed fashion.
4.2.2.2.3. Renumber and return

Agree that the newly requested IP address space will be used to renumber
out of the current addresses which will be returned to their upstream
provider(s).
4.2.2.2.4. Additional requests following the initial allocation

To receive additional address space following the initial allocation,
multihomed organizations must have returned the original IP address space
to its provider in its entirety and must provide justification for a new
allocation as described above in the section titled Requirements for
Requesting Initial Address Space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140327/db07678e/attachment.htm>

From michael at linuxmagic.com  Thu Mar 27 11:08:41 2014
From: michael at linuxmagic.com (Michael Peddemors)
Date: Thu, 27 Mar 2014 08:08:41 -0700
Subject: [arin-ppml] Initial IPv4 allocations to ISPs, NRPM section 4.2
In-Reply-To: <CAC6JZKQidGWhVd2=tOXxgL+3a7Z5tTqPox10jznbREJfyF1tEA@mail.gmail.com>
References: <CAC6JZKQidGWhVd2=tOXxgL+3a7Z5tTqPox10jznbREJfyF1tEA@mail.gmail.com>
Message-ID: <53343EF9.209@linuxmagic.com>

Yes, I would like to see a new draft in this area, just from personal 
experience..

We currently use three Class C's from upstream providers, about 70% 
used, and we would like a /22 simply for the flexibility to move between 
providers, but the rules want us to be multi-homed for that.

And we can easily story board a use case for a /20 based on our 
'growth', but we don't REALLY need it.. WANT to have, Good to have.. 
allows us to expand in the future..

But understanding the IPv4 shortage, we could easily do with the /22 for 
now, and add later if need be.

Smaller ranges do allow for more mobility between upstream providers, 
changing IP(s) in this day and age has lots of hidden costs in 
reputation etc..

On 14-03-27 06:54 AM, CJ Aronson wrote:
> I have been having a discussion with a member of the community about the
> initial allocations to ISPs, NRPM section 4.2.  I thought quite a bit
> about this last night and I would love your input.  It seems to me that
> we might want to revamp this in light of IPv4 run out.  Does it make
> sense when the ARIN free pool is exhausted?  I am sure some think that
> it does/doesn't make sense now but since we're so close to run out let's
> look at whether it still makes sense when the ARIN free pool is exhausted.
>
> Thanks for your input!  If anyone wants to work with me to draft a new
> version please let me know.
>
> Thanks!
> -----Cathy
>
> Here is the text from the NRPM
> https://www.arin.net/policy/nrpm.html#four2
>
>
>         4.2. Allocations to ISPs (Requirements for Requesting Initial
>         Address Space)
>
>
>           4.2.1. Principles
>
>
>             4.2.1.1. Purpose
>
> ARIN allocates blocks of IP addresses to ISPs for the purpose of
> reassigning that space to their customers.
>
>
>             4.2.1.2. Annual Renewal
>
> An annual fee for registered space is due by the anniversary date of the
> ISP's first allocation from ARIN. ISPs should take care to ensure that
> their annual renewal payment is made by their anniversary due date in
> accordance with the Registration Services Agreement. If not paid by the
> anniversary date, the address space may be revoked. Please review the
> Annual Renewal/Maintenance Fees Page for more details.
>
>
>             4.2.1.3. Utilization rate
>
> Utilization rate of address space is a key factor, among others, in
> determining address allocation.
>
>
>             4.2.1.4. Slow start
>
> Because the number of available IP addresses on the Internet is limited,
> many factors must be considered in the determination of address space
> allocations. Therefore, IP address space is allocated to ISPs using a
> slow-start model. Allocations are based on justified need, not solely on
> a predicted customer base.
>
>
>             4.2.1.5. Minimum allocation
>
> In general, ARIN allocates /20 and larger IP address prefixes to ISPs.
> If allocations smaller than /20 are needed, ISPs should request address
> space from their upstream provider. For multihomed ISPs, ARIN allocates
> /22 and larger IP address prefixes. If allocations smaller than /22 are
> needed, multihomed ISPs should request address space from their upstream
> provider.
>
>
>             4.2.1.6. Immediate need
>
> If an ISP has an immediate need for address space, and can provide
> justification to show that the address space will be utilized within 30
> days of the request, ARIN may issue a block of address space, not larger
> than a /16 nor smaller than ARIN's customary minimum allocation, to that
> organization. These cases are exceptional.
>
>
>           4.2.2. Initial allocation to ISPs
>
>
>             4.2.2.1. Standard or non-multihomed
>
> Organizations that do not meet the requirements described in the
> multihomed section below (Section 4.2.2.2) must satisfy the following
> requirements:
>
>
>             4.2.2.1.1. Use of /20
>
> The efficient utilization of an entire previously allocated /20 from
> their upstream ISP. This /20 allocation may have been provided by an
> ISP's upstream provider(s), and does not have to be contiguous address
> space. The organization must meet the requirement of efficient use of 16
> /24s. For example, if an organization holds a smaller allocation, such
> as 12 /24s, from its upstream provider, the organization would not meet
> the minimum utilization requirements of a /20.
>
>
>             4.2.2.1.2. Efficient utilization
>
> Demonstrate efficient use of IP address space allocations by providing
> appropriate documentation, including assignment histories, showing their
> efficient use. ISPs must provide reassignment information on the entire
> previously allocated block(s) via SWIP or RWhois server for /29 or
> larger blocks. For blocks smaller than /29 and for internal space, ISPs
> should provide utilization data either via SWIP or RWhois server or by
> providing detailed utilization information.
>
>
>             4.2.2.1.3. Three months
>
> Provide detailed information showing specifically how a /20 will be
> utilized within three months.
>
>
>             4.2.2.1.4. Renumber and return
>
> ISPs receiving a new /20 may wish to renumber out of their previously
> allocated space. In this case, an ISP must use the new /20 to renumber
> out of that previously allocated block of address space and must return
> the space to its upstream provider.
>
>
>             4.2.2.2. Multihomed
>
> When prefixes are allocated which are smaller than /20, they will be
> from a block reserved for that purpose. In order to receive an initial
> allocation from ARIN, organizations applying under the multihomed policy
> must:
>
>   * When requesting a /22, demonstrate the efficient utilization of a
>     minimum contiguous or noncontiguous /23 (two /24s) from an upstream.
>   * When requesting a /21, demonstrate the efficient utilization of a
>     minimum contiguous or noncontiguous /22 (four /24s) from an upstream.
>   * When requesting a /20, demonstrate the efficient utilization of a
>     minimum contiguous or noncontiguous /21 (eight /24s) from an upstream.
>
>
>             4.2.2.2.1. Efficient utilization
>
> Provide reassignment information for /29 and larger blocks using the
> Shared Whois Project (SWIP) or by providing the same information fields
> in an RWhois server. If additional address space is later requested,
> this information must be available at the time of the request.
> Utilization for blocks smaller than /29 can be documented via SWIP or
> RWhois server or by providing detailed utilization information.
>
>
>             4.2.2.2.2. Three months
>
> Provide information showing that the requested IP address space will be
> utilized within three months and demonstrating an intent to announce the
> requested space in a multihomed fashion.
>
>
>             4.2.2.2.3. Renumber and return
>
> Agree that the newly requested IP address space will be used to renumber
> out of the current addresses which will be returned to their upstream
> provider(s).
>
>
>             4.2.2.2.4. Additional requests following the initial allocation
>
> To receive additional address space following the initial allocation,
> multihomed organizations must have returned the original IP address
> space to its provider in its entirety and must provide justification for
> a new allocation as described above in the section titled Requirements
> for Requesting Initial Address Space.
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.


From scottleibrand at gmail.com  Thu Mar 27 12:11:37 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Thu, 27 Mar 2014 09:11:37 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <B5546A65-81A2-4FB6-89FC-5278B5CF7C94@gmail.com>

The author or shepherds can provide more detail, but this was submitted in response to a recent presentation on research that involved announcing a covering aggregate for a significant fraction of the entire IP space with ARIN providing an LOA that allowed it. Per statements at the mic, the author doesn't want ARIN to allow that to happen again. 

Scott

> On Mar 26, 2014, at 7:55 PM, David Huberman <David.Huberman at microsoft.com> wrote:
> 
> Hi PPML,
> 
> Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.  
> 
> Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.
> 
> Thank you!
> /david
> 
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Tuesday, March 25, 2014 11:28 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
> 
> On 20 March 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
> 
> Draft Policy ARIN-2014-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_12.html
> 
> You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.
> 
> 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-2014-12
> Anti-hijack Policy
> 
> Date: 25 March 2014
> 
> Problem Statement:
> 
> ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.
> 
> Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.
> 
> Policy statement:
> 
> Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.
> 
> 11.7 Resource Allocation Guidelines
> 
> The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
> 
> All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.
> 
> Comments:
> a. Timetable for implementation: Immediate b. Anything else:
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From David.Huberman at microsoft.com  Thu Mar 27 13:24:15 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 27 Mar 2014 17:24:15 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <CF599D70.4298D%john.sweeting@twcable.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>,
	<CF599D70.4298D%john.sweeting@twcable.com>
Message-ID: <d0794382201a4f929ded815195ba4401@DM2PR03MB398.namprd03.prod.outlook.com>

Hello John,

Ah ok - that explains why I didn't recall seeing a discussion, thank you.

Will the policy author please reveal themselves and talk to us about
what's going on?  Unless my reading comprehension is poor, I'm
not understanding what's really going on here.

Thanks!
/david

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

________________________________________
From: Sweeting, John <john.sweeting at twcable.com>
Sent: Thursday, March 27, 2014 6:20 AM
To: David Huberman; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

Hi David,

Draft Policies only get posted to PPML once they are moved forward in the
process to that state. That being said it was just posted as a DP this
week, Tuesday. Discussions need to begin and it will also be presented and
discussed at the PPM in Chicago. This is in accordance with the current
PDP. Hope that helps.

Thanks,
John

On 3/26/14, 10:55 PM, "David Huberman" <David.Huberman at microsoft.com>
wrote:

>Hi PPML,
>
>Can someone show me where in the mailing list archives this policy was
>actively discussed on PPML? I can't find it.
>
>Alternatively, can the policy author or someone who strongly supports
>this policy please either post to the list or email me privately and clue
>me in?  I issued and managed almost every experimental assignment for
>almost 10 years from 2003 to 2013, and I am lost as to what this policy
>is saying.  I would like to be educated so I can support, or not support,
>the efforts that have been made here.
>
>Thank you!
>/david
>
>David R Huberman
>Microsoft Corporation
>Senior IT/OPS Program Manager (GFS)
>
>-----Original Message-----
>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>Behalf Of ARIN
>Sent: Tuesday, March 25, 2014 11:28 AM
>To: arin-ppml at arin.net
>Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
>On 20 March 2014 the ARIN Advisory Council (AC) accepted
>"ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>
>Draft Policy ARIN-2014-12 is below and can be found at:
>https://www.arin.net/policy/proposals/2014_12.html
>
>You are encouraged to discuss the merits and your concerns of Draft
>Policy 2014-12 on the Public Policy Mailing List.
>
>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-2014-12
>Anti-hijack Policy
>
>Date: 25 March 2014
>
>Problem Statement:
>
>ARIN should not give research organizations permission to hijack prefixes
>that have already been allocated. Research organizations announcing lit
>aggregates may receive sensitive production traffic belonging to live
>networks during periods of instability.
>
>Section 11.7 describes more than allocation size therefore updating the
>section heading to something more accurate is appropriate.
>
>Policy statement:
>
>Modify the section 11.7 heading to be more accurate. Modify the first
>sentence to prohibit overlapping assignments. Add text at the end to
>define how research allocations should be designated and prohibit LOA's
>without allocations.
>
>11.7 Resource Allocation Guidelines
>
>The Numbering Resources requested come from the global Internet Resource
>space, do not overlap previously assigned space, and are not from private
>or other non-routable Internet Resource space. The allocation size should
>be consistent with the existing ARIN minimum allocation sizes, unless
>small allocations are intended to be explicitly part of the experiment.
>If an organization requires more resource than stipulated by the minimum
>allocation sizes in force at the time of their request, their
>experimental documentation should have clearly described and justified
>why this is required.
>
>All research allocations must be registered publicly in whois. Each
>research allocation will be designated as a research allocation with a
>comment indicating when the allocation will end. ARIN will not issue a
>Letter of Authority (LOA) to route a research prefix unless the
>allocation is properly registered in whois.
>
>Comments:
>a. Timetable for implementation: Immediate b. Anything else:
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to the ARIN
>Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.


From hannigan at gmail.com  Thu Mar 27 13:29:12 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 27 Mar 2014 13:29:12 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <B5546A65-81A2-4FB6-89FC-5278B5CF7C94@gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<B5546A65-81A2-4FB6-89FC-5278B5CF7C94@gmail.com>
Message-ID: <CAMDXq5NwJ-Wz8P2WDRqw7-7Y8qAa-HqTE18PKsd=q6orieRWOg@mail.gmail.com>

That's an operational problem. No one should ever accept nor should ARIN
ever write an LOA for anything except their own registered prefix.

Best,

Martin



On Thursday, March 27, 2014, Scott Leibrand <scottleibrand at gmail.com> wrote:

> The author or shepherds can provide more detail, but this was submitted in
> response to a recent presentation on research that involved announcing a
> covering aggregate for a significant fraction of the entire IP space with
> ARIN providing an LOA that allowed it. Per statements at the mic, the
> author doesn't want ARIN to allow that to happen again.
>
> Scott
>
> > On Mar 26, 2014, at 7:55 PM, David Huberman <
> David.Huberman at microsoft.com> wrote:
> >
> > Hi PPML,
> >
> > Can someone show me where in the mailing list archives this policy was
> actively discussed on PPML? I can't find it.
> >
> > Alternatively, can the policy author or someone who strongly supports
> this policy please either post to the list or email me privately and clue
> me in?  I issued and managed almost every experimental assignment for
> almost 10 years from 2003 to 2013, and I am lost as to what this policy is
> saying.  I would like to be educated so I can support, or not support, the
> efforts that have been made here.
> >
> > Thank you!
> > /david
> >
> > David R Huberman
> > Microsoft Corporation
> > Senior IT/OPS Program Manager (GFS)
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of ARIN
> > Sent: Tuesday, March 25, 2014 11:28 AM
> > To: arin-ppml at arin.net
> > Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
> >
> > On 20 March 2014 the ARIN Advisory Council (AC) accepted
> > "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
> >
> > Draft Policy ARIN-2014-12 is below and can be found at:
> > https://www.arin.net/policy/proposals/2014_12.html
> >
> > You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-12 on the Public Policy Mailing List.
> >
> > 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-2014-12
> > Anti-hijack Policy
> >
> > Date: 25 March 2014
> >
> > Problem Statement:
> >
> > ARIN should not give research organizations permission to hijack
> prefixes that have already been allocated. Research organizations
> announcing lit aggregates may receive sensitive production traffic
> belonging to live networks during periods of instability.
> >
> > Section 11.7 describes more than allocation size therefore updating the
> section heading to something more accurate is appropriate.
> >
> > Policy statement:
> >
> > Modify the section 11.7 heading to be more accurate. Modify the first
> sentence to prohibit overlapping assignments. Add text at the end to define
> how research allocations should be designated and prohibit LOA's without
> allocations.
> >
> > 11.7 Resource Allocation Guidelines
> >
> > The Numbering Resources requested come from the global Internet Resource
> space, do not overlap previously assigned space, and are not from private
> or other non-routable Internet Resource space. The allocation size should
> be consistent with the existing ARIN minimum allocation sizes, unless small
> allocations are intended to be explicitly part of the experiment. If an
> organization requires more resource than stipulated by the minimum
> allocation sizes in force at the time of their request, their experimental
> documentation should have clearly described and justified why this is
> required.
> >
> > All research allocations must be registered publicly in whois. Each
> research allocation will be designated as a research allocation with a
> comment indicating when the allocation will end. ARIN will not issue a
> Letter of Authority (LOA) to route a research prefix unless the allocation
> is properly registered in whois.
> >
> > Comments:
> > a. Timetable for implementation: Immediate b. Anything else:
> > _______________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140327/b3c759d4/attachment.htm>

From David.Huberman at microsoft.com  Thu Mar 27 13:40:28 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Thu, 27 Mar 2014 17:40:28 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <CAMDXq5NwJ-Wz8P2WDRqw7-7Y8qAa-HqTE18PKsd=q6orieRWOg@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<B5546A65-81A2-4FB6-89FC-5278B5CF7C94@gmail.com>,
	<CAMDXq5NwJ-Wz8P2WDRqw7-7Y8qAa-HqTE18PKsd=q6orieRWOg@mail.gmail.com>
Message-ID: <9426cb1507c74099beace87e12743892@DM2PR03MB398.namprd03.prod.outlook.com>

ARIN doesn't have the authority to write an LOA for space not explicitly registered to an entity in Whois.  Is this what happened?!?



Details would be nice if we're going to discuss 2014-12 in a meaningful way :)



David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)
________________________________
From: Martin Hannigan <hannigan at gmail.com>
Sent: Thursday, March 27, 2014 10:29 AM
To: Scott Leibrand
Cc: David Huberman; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy



That's an operational problem. No one should ever accept nor should ARIN ever write an LOA for anything except their own registered prefix.


Best,


Martin




On Thursday, March 27, 2014, Scott Leibrand <scottleibrand at gmail.com<mailto:scottleibrand at gmail.com>> wrote:
The author or shepherds can provide more detail, but this was submitted in response to a recent presentation on research that involved announcing a covering aggregate for a significant fraction of the entire IP space with ARIN providing an LOA that allowed it. Per statements at the mic, the author doesn't want ARIN to allow that to happen again.

Scott

> On Mar 26, 2014, at 7:55 PM, David Huberman <David.Huberman at microsoft.com> wrote:
>
> Hi PPML,
>
> Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.
>
> Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.
>
> Thank you!
> /david
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Tuesday, March 25, 2014 11:28 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
> On 20 March 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>
> Draft Policy ARIN-2014-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_12.html
>
> You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.
>
> 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-2014-12
> Anti-hijack Policy
>
> Date: 25 March 2014
>
> Problem Statement:
>
> ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.
>
> Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.
>
> Policy statement:
>
> Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.
>
> 11.7 Resource Allocation Guidelines
>
> The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
>
> All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.
>
> Comments:
> a. Timetable for implementation: Immediate b. Anything else:
> _______________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140327/2ac03b37/attachment.htm>

From hannigan at gmail.com  Thu Mar 27 14:18:43 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 27 Mar 2014 14:18:43 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <9426cb1507c74099beace87e12743892@DM2PR03MB398.namprd03.prod.outlook.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<B5546A65-81A2-4FB6-89FC-5278B5CF7C94@gmail.com>
	<CAMDXq5NwJ-Wz8P2WDRqw7-7Y8qAa-HqTE18PKsd=q6orieRWOg@mail.gmail.com>
	<9426cb1507c74099beace87e12743892@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAMDXq5OZs8O_H1MAwn5b96fjq6mOZ-Q2a+BeX3hjRwW+FY_-kA@mail.gmail.com>

And if it's in the registry it's in someones name which means THEY can
write the LOA. Even in the case of another advertising a prefix
registered to someone and on their behalf, think routerless location,
the registrant writes the LOA for the upstream to pass off to peers
where and if needed. I do this all the time. The only time I ever have
to write LOA for stuff like this is typically in the AP region.

This sounds more like a giant faux pas than a policy problem to be honest.

Not in support.

Best,

-M<



On Thu, Mar 27, 2014 at 1:40 PM, David Huberman
<David.Huberman at microsoft.com> wrote:
> ARIN doesn't have the authority to write an LOA for space not explicitly
> registered to an entity in Whois.  Is this what happened?!?
>
>
>
> Details would be nice if we're going to discuss 2014-12 in a meaningful way
> :)
>
>
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> ________________________________
> From: Martin Hannigan <hannigan at gmail.com>
> Sent: Thursday, March 27, 2014 10:29 AM
> To: Scott Leibrand
> Cc: David Huberman; arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
>
>
> That's an operational problem. No one should ever accept nor should ARIN
> ever write an LOA for anything except their own registered prefix.
>
>
> Best,
>
>
> Martin
>
>
>
>
> On Thursday, March 27, 2014, Scott Leibrand <scottleibrand at gmail.com> wrote:
>>
>> The author or shepherds can provide more detail, but this was submitted in
>> response to a recent presentation on research that involved announcing a
>> covering aggregate for a significant fraction of the entire IP space with
>> ARIN providing an LOA that allowed it. Per statements at the mic, the author
>> doesn't want ARIN to allow that to happen again.
>>
>> Scott
>>
>> > On Mar 26, 2014, at 7:55 PM, David Huberman
>> > <David.Huberman at microsoft.com> wrote:
>> >
>> > Hi PPML,
>> >
>> > Can someone show me where in the mailing list archives this policy was
>> > actively discussed on PPML? I can't find it.
>> >
>> > Alternatively, can the policy author or someone who strongly supports
>> > this policy please either post to the list or email me privately and clue me
>> > in?  I issued and managed almost every experimental assignment for almost 10
>> > years from 2003 to 2013, and I am lost as to what this policy is saying.  I
>> > would like to be educated so I can support, or not support, the efforts that
>> > have been made here.
>> >
>> > Thank you!
>> > /david
>> >
>> > David R Huberman
>> > Microsoft Corporation
>> > Senior IT/OPS Program Manager (GFS)
>> >
>> > -----Original Message-----
>> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> > Behalf Of ARIN
>> > Sent: Tuesday, March 25, 2014 11:28 AM
>> > To: arin-ppml at arin.net
>> > Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>> >
>> > On 20 March 2014 the ARIN Advisory Council (AC) accepted
>> > "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>> >
>> > Draft Policy ARIN-2014-12 is below and can be found at:
>> > https://www.arin.net/policy/proposals/2014_12.html
>> >
>> > You are encouraged to discuss the merits and your concerns of Draft
>> > Policy 2014-12 on the Public Policy Mailing List.
>> >
>> > 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-2014-12
>> > Anti-hijack Policy
>> >
>> > Date: 25 March 2014
>> >
>> > Problem Statement:
>> >
>> > ARIN should not give research organizations permission to hijack
>> > prefixes that have already been allocated. Research organizations announcing
>> > lit aggregates may receive sensitive production traffic belonging to live
>> > networks during periods of instability.
>> >
>> > Section 11.7 describes more than allocation size therefore updating the
>> > section heading to something more accurate is appropriate.
>> >
>> > Policy statement:
>> >
>> > Modify the section 11.7 heading to be more accurate. Modify the first
>> > sentence to prohibit overlapping assignments. Add text at the end to define
>> > how research allocations should be designated and prohibit LOA's without
>> > allocations.
>> >
>> > 11.7 Resource Allocation Guidelines
>> >
>> > The Numbering Resources requested come from the global Internet Resource
>> > space, do not overlap previously assigned space, and are not from private or
>> > other non-routable Internet Resource space. The allocation size should be
>> > consistent with the existing ARIN minimum allocation sizes, unless small
>> > allocations are intended to be explicitly part of the experiment. If an
>> > organization requires more resource than stipulated by the minimum
>> > allocation sizes in force at the time of their request, their experimental
>> > documentation should have clearly described and justified why this is
>> > required.
>> >
>> > All research allocations must be registered publicly in whois. Each
>> > research allocation will be designated as a research allocation with a
>> > comment indicating when the allocation will end. ARIN will not issue a
>> > Letter of Authority (LOA) to route a research prefix unless the allocation
>> > is properly registered in whois.
>> >
>> > Comments:
>> > a. Timetable for implementation: Immediate b. Anything else:
>> > _______________________________


From farmer at umn.edu  Thu Mar 27 14:42:38 2014
From: farmer at umn.edu (David Farmer)
Date: Thu, 27 Mar 2014 13:42:38 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <5334711E.1000808@umn.edu>

I'm the primary shepherd for this Draft;

The author is Heather Schiller, and I'm only saying that because I'm 
going to reference you to her comments at the mic at the last NANOG.

The research that prompted the proposal was presented at the last NANOG 
in Atlanta and is at the following link;

https://www.nanog.org/meetings/abstract?id=2289

Heather's comments begins at about time stamp 17:10 or so on the video 
of the NANOG presentation, and there are a couple other comments as well.

Additionally, the reference for the published paper for the research in 
question is;

http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND 
SUPPORTING DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS

https://www.arin.net/participate/acsp/suggestions/2014-3.html

[Shepherd hat - OFF]

While I do not have a problem with this research and I don't think we 
should restrict future such activities, I believe this is something the 
community should discuss in detail and try to come to consensus on, one 
way or the other.

Also, while I disagree with the proposed policy text, what is proposed 
is not without precedent.  As discussed in the NANOG presentation, RIPE 
initially gave permission for a covering prefix for its whole /12 and 
then it was modified to a covering prefixes of a /14 plus a /13, 
excluding the space where most allocations were.  This significantly 
reduced the amount of traffic for RIPE region and they were excluded 
from the analysis.

Hope that helps.

On 3/26/14, 21:55 , David Huberman wrote:
> Hi PPML,
>
> Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.
>
> Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.
>
> Thank you!
> /david
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
> Sent: Tuesday, March 25, 2014 11:28 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
> On 20 March 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>
> Draft Policy ARIN-2014-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_12.html
>
> You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.
>
> 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-2014-12
> Anti-hijack Policy
>
> Date: 25 March 2014
>
> Problem Statement:
>
> ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.
>
> Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.
>
> Policy statement:
>
> Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.
>
> 11.7 Resource Allocation Guidelines
>
> The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
>
> All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.
>
> Comments:
> a. Timetable for implementation: Immediate b. Anything else:

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


From hannigan at gmail.com  Thu Mar 27 15:34:24 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Thu, 27 Mar 2014 15:34:24 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <5334711E.1000808@umn.edu>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
Message-ID: <CAMDXq5MBegunakKzcCTzAiQ4W2V9MVrtqq95eKuUW4TeB-rvmw@mail.gmail.com>

Thanks. This wasn't really a big secret or anything. I didn't see an
announcement that I recall. That would've been nice. Oh well.

We discussed it briefly here, we of course reserve the right to change
our mind, still not in support of the proposal. Neutral on the
research unless that becomes an issue related to the policy. It's not.

Best,

-M<



On Thu, Mar 27, 2014 at 2:42 PM, David Farmer <farmer at umn.edu> wrote:
> I'm the primary shepherd for this Draft;
>
> The author is Heather Schiller, and I'm only saying that because I'm going
> to reference you to her comments at the mic at the last NANOG.
>
> The research that prompted the proposal was presented at the last NANOG in
> Atlanta and is at the following link;
>
> https://www.nanog.org/meetings/abstract?id=2289
>
> Heather's comments begins at about time stamp 17:10 or so on the video of
> the NANOG presentation, and there are a couple other comments as well.
>
> Additionally, the reference for the published paper for the research in
> question is;
>
> http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf
>
> Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND SUPPORTING
> DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS
>
> https://www.arin.net/participate/acsp/suggestions/2014-3.html
>
> [Shepherd hat - OFF]
>
> While I do not have a problem with this research and I don't think we should
> restrict future such activities, I believe this is something the community
> should discuss in detail and try to come to consensus on, one way or the
> other.
>
> Also, while I disagree with the proposed policy text, what is proposed is
> not without precedent.  As discussed in the NANOG presentation, RIPE
> initially gave permission for a covering prefix for its whole /12 and then
> it was modified to a covering prefixes of a /14 plus a /13, excluding the
> space where most allocations were.  This significantly reduced the amount of
> traffic for RIPE region and they were excluded from the analysis.
>
> Hope that helps.
>
>
> On 3/26/14, 21:55 , David Huberman wrote:
>>
>> Hi PPML,
>>
>> Can someone show me where in the mailing list archives this policy was
>> actively discussed on PPML? I can't find it.
>>
>> Alternatively, can the policy author or someone who strongly supports this
>> policy please either post to the list or email me privately and clue me in?
>> I issued and managed almost every experimental assignment for almost 10
>> years from 2003 to 2013, and I am lost as to what this policy is saying.  I
>> would like to be educated so I can support, or not support, the efforts that
>> have been made here.
>>
>> Thank you!
>> /david
>>
>> David R Huberman
>> Microsoft Corporation
>> Senior IT/OPS Program Manager (GFS)
>>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of ARIN
>> Sent: Tuesday, March 25, 2014 11:28 AM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>>
>> On 20 March 2014 the ARIN Advisory Council (AC) accepted
>> "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>>
>> Draft Policy ARIN-2014-12 is below and can be found at:
>> https://www.arin.net/policy/proposals/2014_12.html
>>
>> You are encouraged to discuss the merits and your concerns of Draft Policy
>> 2014-12 on the Public Policy Mailing List.
>>
>> 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-2014-12
>> Anti-hijack Policy
>>
>> Date: 25 March 2014
>>
>> Problem Statement:
>>
>> ARIN should not give research organizations permission to hijack prefixes
>> that have already been allocated. Research organizations announcing lit
>> aggregates may receive sensitive production traffic belonging to live
>> networks during periods of instability.
>>
>> Section 11.7 describes more than allocation size therefore updating the
>> section heading to something more accurate is appropriate.
>>
>> Policy statement:
>>
>> Modify the section 11.7 heading to be more accurate. Modify the first
>> sentence to prohibit overlapping assignments. Add text at the end to define
>> how research allocations should be designated and prohibit LOA's without
>> allocations.
>>
>> 11.7 Resource Allocation Guidelines
>>
>> The Numbering Resources requested come from the global Internet Resource
>> space, do not overlap previously assigned space, and are not from private or
>> other non-routable Internet Resource space. The allocation size should be
>> consistent with the existing ARIN minimum allocation sizes, unless small
>> allocations are intended to be explicitly part of the experiment. If an
>> organization requires more resource than stipulated by the minimum
>> allocation sizes in force at the time of their request, their experimental
>> documentation should have clearly described and justified why this is
>> required.
>>
>> All research allocations must be registered publicly in whois. Each
>> research allocation will be designated as a research allocation with a
>> comment indicating when the allocation will end. ARIN will not issue a
>> Letter of Authority (LOA) to route a research prefix unless the allocation
>> is properly registered in whois.
>>
>> Comments:
>> a. Timetable for implementation: Immediate b. Anything else:
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.


From woody at pch.net  Thu Mar 27 18:45:33 2014
From: woody at pch.net (Bill Woodcock)
Date: Thu, 27 Mar 2014 15:45:33 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <d0794382201a4f929ded815195ba4401@DM2PR03MB398.namprd03.prod.outlook.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>,
	<CF599D70.4298D%john.sweeting@twcable.com>
	<d0794382201a4f929ded815195ba4401@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <C2C8F364-2C8F-4FE3-98AB-D747A8455693@pch.net>

>> 11.7 Resource Allocation Guidelines
>> 
>> The Numbering Resources requested come from the global Internet Resource
>> space, do not overlap previously assigned space, 

_Previously_ assigned space, or _currently_ assigned space?

Like David, I?m struggling to understand what problem is being solved here.  Is this a passive-aggressive accusation that ARIN double-allocated the same space at the same time?  Or a complaint that ARIN allocated space that someone was already illegitimately using?

If the former, that?s an implementation issue, and a very serious one, and doesn?t need to be addressed through policy, it needs to be addressed through process.  If the latter, it?s a whine by someone who?s doing the wrong thing and got caught, and certainly doesn?t merit any new policy.

                                -Bill




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140327/56575555/attachment.sig>

From Marla.Azinger at FTR.com  Thu Mar 27 18:56:09 2014
From: Marla.Azinger at FTR.com (Azinger, Marla)
Date: Thu, 27 Mar 2014 22:56:09 +0000
Subject: [arin-ppml] [arin-discuss]   Term Limit Proposal
In-Reply-To: <358A138A-912D-4A9C-BAEB-9316083D80BE@arin.net>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<alpine.BSF.2.00.1403251229120.28133@mail.inlandnet.com>
	<afbb662cb50b4a7bba45d99f93a7291a@BY2PR06MB488.namprd06.prod.outlook.com>
	<358A138A-912D-4A9C-BAEB-9316083D80BE@arin.net>
Message-ID: <3bb8903d5d8a46c09034a443b107b9e0@BY2PR06MB488.namprd06.prod.outlook.com>

I have taken the direction to not submit a proposal since this particular subject has been requested to go through the suggestion process by John Curran.  This will be reviewed and addressed by the BOT.

The number assigned to this:  Suggestion ID 2014.7

Should anyone choose to follow how the BOT handles this, I believe that ID should help.

Regards
Marla

-----Original Message-----
From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of John Curran
Sent: Wednesday, March 26, 2014 11:06 AM
To: arin-ppml at arin.net
Cc: arin-discuss at arin.net
Subject: Re: [arin-discuss] [arin-ppml] Term Limit Proposal

On Mar 27, 2014, at 1:35 AM, Azinger, Marla <Marla.Azinger at FTR.com> wrote:

> Hi John
> 
> Given the response I think an official proposal needs to be written.  I'm happy to see the acceptance of a written proposal will be received for due process and not turned over to the recycling bin for "not being a policy topic".

If the ARIN AC wishes to discuss terms limits for the ARIN AC, then that is something that may do at any time and in fact are quite capable of voluntarily enforcement thereof...  No ARIN policy proposal is necessary, and in fact, it would be out of scope for the policy development process.

If mandatory terms limits are desired for the ARIN Board of Trustees or ARIN AC, it would be best to write up the specific suggestion and submit the ARIN consultation and suggestion process, as noted by John Springer.
I will bring the proposal and results of the discussion of the proposal on the arin-consult mailing list to the ARIN Board of Trustees for their further consideration.

Thanks!
/John

John Curran
President and CEO
ARIN

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


From narten at us.ibm.com  Fri Mar 28 00:53:03 2014
From: narten at us.ibm.com (Thomas Narten)
Date: Fri, 28 Mar 2014 00:53:03 -0400
Subject: [arin-ppml] Weekly posting summary for ppml@arin.net
Message-ID: <201403280453.s2S4r3w1023337@rotala.raleigh.ibm.com>

Total of 104 messages in the last 7 days.
 
script run at: Fri Mar 28 00:53:02 EDT 2014
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 12.50% |   13 |  6.86% |    96058 | jcurran at arin.net
  7.69% |    8 | 10.45% |   146369 | scottleibrand at gmail.com
  7.69% |    8 |  7.45% |   104237 | hannigan at gmail.com
  4.81% |    5 |  9.90% |   138619 | cja at daydream.com
  7.69% |    8 |  6.71% |    93920 | david.huberman at microsoft.com
  5.77% |    6 |  4.07% |    56946 | info at arin.net
  3.85% |    4 |  3.38% |    47359 | mueller at syr.edu
  2.88% |    3 |  4.23% |    59204 | louie at louie.net
  2.88% |    3 |  4.05% |    56757 | cgrundemann at gmail.com
  3.85% |    4 |  2.99% |    41918 | springer at inlandnet.com
  1.92% |    2 |  4.73% |    66291 | jschiller at google.com
  3.85% |    4 |  2.79% |    39124 | marla.azinger at ftr.com
  3.85% |    4 |  2.38% |    33378 | owen at delong.com
  1.92% |    2 |  3.30% |    46221 | billdarte at gmail.com
  0.96% |    1 |  3.68% |    51466 | rudi.daniel at gmail.com
  2.88% |    3 |  1.24% |    17383 | matthew at matthew.at
  1.92% |    2 |  1.50% |    20932 | rjletts at uw.edu
  1.92% |    2 |  1.45% |    20352 | farmer at umn.edu
  1.92% |    2 |  1.43% |    20045 | timothy.s.morizot at irs.gov
  1.92% |    2 |  0.88% |    12290 | ajs at anvilwalrusden.com
  0.96% |    1 |  1.80% |    25239 | tony.radzwon at integratelecom.com
  0.96% |    1 |  1.59% |    22308 | sryerse at eclipse-networks.com
  0.96% |    1 |  1.45% |    20369 | mike at iptrading.com
  0.96% |    1 |  1.35% |    18861 | petertbui0 at gmail.com
  0.96% |    1 |  1.10% |    15439 | mysidia at gmail.com
  0.96% |    1 |  1.07% |    14982 | meows at techie.com
  0.96% |    1 |  0.96% |    13452 | michael at birdhosting.com
  0.96% |    1 |  0.95% |    13300 | michael at linuxmagic.com
  0.96% |    1 |  0.85% |    11946 | alex at aspenworks.com
  0.96% |    1 |  0.75% |    10479 | john.sweeting at twcable.com
  0.96% |    1 |  0.73% |    10188 | dogwallah at gmail.com
  0.96% |    1 |  0.65% |     9155 | gary.buhrmaster at gmail.com
  0.96% |    1 |  0.62% |     8705 | lsawyer at gci.com
  0.96% |    1 |  0.57% |     8039 | john at egh.com
  0.96% |    1 |  0.52% |     7347 | drc at virtualized.org
  0.96% |    1 |  0.52% |     7324 | woody at pch.net
  0.96% |    1 |  0.51% |     7160 | narten at us.ibm.com
  0.96% |    1 |  0.49% |     6862 | michael+ppml at burnttofu.net
--------+------+--------+----------+------------------------
100.00% |  104 |100.00% |  1400024 | Total



From cja at daydream.com  Fri Mar 28 11:04:03 2014
From: cja at daydream.com (CJ Aronson)
Date: Fri, 28 Mar 2014 15:04:03 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <C2C8F364-2C8F-4FE3-98AB-D747A8455693@pch.net>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<CF599D70.4298D%john.sweeting@twcable.com>
	<d0794382201a4f929ded815195ba4401@DM2PR03MB398.namprd03.prod.outlook.com>
	<C2C8F364-2C8F-4FE3-98AB-D747A8455693@pch.net>
Message-ID: <CAC6JZKQKMT61CXjxuvVwJ-t8XdwrYQ6_WQh20W4H-23bcTkANg@mail.gmail.com>

Bill you should watch the presentation.  Basically the RIRs gave these guys
permission to announce the IPv6 /12s that cover >80% of the live IPv6
Internet

https://www.nanog.org/sites/default/files/12-feb-2014.webcast.karir.understanding.ipv6-internet-radiation.mp4

The point is that it's one thing to announce a real dark prefix to see who
has messed up their config.  It's another thing to have permission to
announce a large prefix that covers almost all of the existing LIVE IPv6
Internet.

I hope this helps!
----Cathy


On Thu, Mar 27, 2014 at 10:45 PM, Bill Woodcock <woody at pch.net> wrote:

> >> 11.7 Resource Allocation Guidelines
> >>
> >> The Numbering Resources requested come from the global Internet Resource
> >> space, do not overlap previously assigned space,
>
> _Previously_ assigned space, or _currently_ assigned space?
>
> Like David, I'm struggling to understand what problem is being solved
> here.  Is this a passive-aggressive accusation that ARIN double-allocated
> the same space at the same time?  Or a complaint that ARIN allocated space
> that someone was already illegitimately using?
>
> If the former, that's an implementation issue, and a very serious one, and
> doesn't need to be addressed through policy, it needs to be addressed
> through process.  If the latter, it's a whine by someone who's doing the
> wrong thing and got caught, and certainly doesn't merit any new policy.
>
>                                 -Bill
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140328/37551add/attachment.htm>

From David.Huberman at microsoft.com  Fri Mar 28 12:32:24 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 28 Mar 2014 16:32:24 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <5334711E.1000808@umn.edu>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
Message-ID: <60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>

David:

That summary of the issue helps a lot, thank you!

The question on my mind is:
	Did ARIN provide a written LOA to Merit to announce 2600::/12 ?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: David Farmer [mailto:farmer at umn.edu] 
Sent: Thursday, March 27, 2014 11:43 AM
To: David Huberman; arin-ppml at arin.net
Cc: David Farmer
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

I'm the primary shepherd for this Draft;

The author is Heather Schiller, and I'm only saying that because I'm going to reference you to her comments at the mic at the last NANOG.

The research that prompted the proposal was presented at the last NANOG in Atlanta and is at the following link;

https://www.nanog.org/meetings/abstract?id=2289

Heather's comments begins at about time stamp 17:10 or so on the video of the NANOG presentation, and there are a couple other comments as well.

Additionally, the reference for the published paper for the research in question is;

http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND SUPPORTING DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS

https://www.arin.net/participate/acsp/suggestions/2014-3.html

[Shepherd hat - OFF]

While I do not have a problem with this research and I don't think we should restrict future such activities, I believe this is something the community should discuss in detail and try to come to consensus on, one way or the other.

Also, while I disagree with the proposed policy text, what is proposed is not without precedent.  As discussed in the NANOG presentation, RIPE initially gave permission for a covering prefix for its whole /12 and then it was modified to a covering prefixes of a /14 plus a /13, excluding the space where most allocations were.  This significantly reduced the amount of traffic for RIPE region and they were excluded from the analysis.

Hope that helps.

On 3/26/14, 21:55 , David Huberman wrote:
> Hi PPML,
>
> Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.
>
> Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.
>
> Thank you!
> /david
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> On Behalf Of ARIN
> Sent: Tuesday, March 25, 2014 11:28 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
> On 20 March 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>
> Draft Policy ARIN-2014-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_12.html
>
> You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.
>
> 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-2014-12
> Anti-hijack Policy
>
> Date: 25 March 2014
>
> Problem Statement:
>
> ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.
>
> Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.
>
> Policy statement:
>
> Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.
>
> 11.7 Resource Allocation Guidelines
>
> The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
>
> All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.
>
> Comments:
> a. Timetable for implementation: Immediate b. Anything else:

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


From cja at daydream.com  Fri Mar 28 12:49:16 2014
From: cja at daydream.com (CJ Aronson)
Date: Fri, 28 Mar 2014 16:49:16 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>

There is a paper here
http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

that says
"We announced the prefixes: 2400::/12, 2600::/12, 2800::/12, 2c00::/12,
2a08::/13, and 2a04::/14 for over a three-month period. For a few days, we
also announced RIPE's 2a00::/12"

So I believe that the answer to your question is yes.

-----Cathy


On Fri, Mar 28, 2014 at 4:32 PM, David Huberman <
David.Huberman at microsoft.com> wrote:

> David:
>
> That summary of the issue helps a lot, thank you!
>
> The question on my mind is:
>         Did ARIN provide a written LOA to Merit to announce 2600::/12 ?
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: David Farmer [mailto:farmer at umn.edu]
> Sent: Thursday, March 27, 2014 11:43 AM
> To: David Huberman; arin-ppml at arin.net
> Cc: David Farmer
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
> I'm the primary shepherd for this Draft;
>
> The author is Heather Schiller, and I'm only saying that because I'm going
> to reference you to her comments at the mic at the last NANOG.
>
> The research that prompted the proposal was presented at the last NANOG in
> Atlanta and is at the following link;
>
> https://www.nanog.org/meetings/abstract?id=2289
>
> Heather's comments begins at about time stamp 17:10 or so on the video of
> the NANOG presentation, and there are a couple other comments as well.
>
> Additionally, the reference for the published paper for the research in
> question is;
>
> http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf
>
> Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND
> SUPPORTING DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS
>
> https://www.arin.net/participate/acsp/suggestions/2014-3.html
>
> [Shepherd hat - OFF]
>
> While I do not have a problem with this research and I don't think we
> should restrict future such activities, I believe this is something the
> community should discuss in detail and try to come to consensus on, one way
> or the other.
>
> Also, while I disagree with the proposed policy text, what is proposed is
> not without precedent.  As discussed in the NANOG presentation, RIPE
> initially gave permission for a covering prefix for its whole /12 and then
> it was modified to a covering prefixes of a /14 plus a /13, excluding the
> space where most allocations were.  This significantly reduced the amount
> of traffic for RIPE region and they were excluded from the analysis.
>
> Hope that helps.
>
> On 3/26/14, 21:55 , David Huberman wrote:
> > Hi PPML,
> >
> > Can someone show me where in the mailing list archives this policy was
> actively discussed on PPML? I can't find it.
> >
> > Alternatively, can the policy author or someone who strongly supports
> this policy please either post to the list or email me privately and clue
> me in?  I issued and managed almost every experimental assignment for
> almost 10 years from 2003 to 2013, and I am lost as to what this policy is
> saying.  I would like to be educated so I can support, or not support, the
> efforts that have been made here.
> >
> > Thank you!
> > /david
> >
> > David R Huberman
> > Microsoft Corporation
> > Senior IT/OPS Program Manager (GFS)
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of ARIN
> > Sent: Tuesday, March 25, 2014 11:28 AM
> > To: arin-ppml at arin.net
> > Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
> >
> > On 20 March 2014 the ARIN Advisory Council (AC) accepted
> > "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
> >
> > Draft Policy ARIN-2014-12 is below and can be found at:
> > https://www.arin.net/policy/proposals/2014_12.html
> >
> > You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-12 on the Public Policy Mailing List.
> >
> > 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-2014-12
> > Anti-hijack Policy
> >
> > Date: 25 March 2014
> >
> > Problem Statement:
> >
> > ARIN should not give research organizations permission to hijack
> prefixes that have already been allocated. Research organizations
> announcing lit aggregates may receive sensitive production traffic
> belonging to live networks during periods of instability.
> >
> > Section 11.7 describes more than allocation size therefore updating the
> section heading to something more accurate is appropriate.
> >
> > Policy statement:
> >
> > Modify the section 11.7 heading to be more accurate. Modify the first
> sentence to prohibit overlapping assignments. Add text at the end to define
> how research allocations should be designated and prohibit LOA's without
> allocations.
> >
> > 11.7 Resource Allocation Guidelines
> >
> > The Numbering Resources requested come from the global Internet Resource
> space, do not overlap previously assigned space, and are not from private
> or other non-routable Internet Resource space. The allocation size should
> be consistent with the existing ARIN minimum allocation sizes, unless small
> allocations are intended to be explicitly part of the experiment. If an
> organization requires more resource than stipulated by the minimum
> allocation sizes in force at the time of their request, their experimental
> documentation should have clearly described and justified why this is
> required.
> >
> > All research allocations must be registered publicly in whois. Each
> research allocation will be designated as a research allocation with a
> comment indicating when the allocation will end. ARIN will not issue a
> Letter of Authority (LOA) to route a research prefix unless the allocation
> is properly registered in whois.
> >
> > Comments:
> > a. Timetable for implementation: Immediate b. Anything else:
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952================================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140328/9cb5e131/attachment.htm>

From cja at daydream.com  Fri Mar 28 12:53:43 2014
From: cja at daydream.com (CJ Aronson)
Date: Fri, 28 Mar 2014 16:53:43 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
Message-ID: <CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>

I read some more of that article I sent.  They specifically state that they
had LOAs from the RIRs to do these /12 advertisements.

Thanks!
-----Cathy


On Fri, Mar 28, 2014 at 4:49 PM, CJ Aronson <cja at daydream.com> wrote:

> There is a paper here
> http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf
>
> that says
> "We announced the prefixes: 2400::/12, 2600::/12, 2800::/12, 2c00::/12,
> 2a08::/13, and 2a04::/14 for over a three-month period. For a few days, we
> also announced RIPE's 2a00::/12"
>
> So I believe that the answer to your question is yes.
>
> -----Cathy
>
>
> On Fri, Mar 28, 2014 at 4:32 PM, David Huberman <
> David.Huberman at microsoft.com> wrote:
>
>> David:
>>
>> That summary of the issue helps a lot, thank you!
>>
>> The question on my mind is:
>>         Did ARIN provide a written LOA to Merit to announce 2600::/12 ?
>>
>> David R Huberman
>> Microsoft Corporation
>> Senior IT/OPS Program Manager (GFS)
>>
>> -----Original Message-----
>> From: David Farmer [mailto:farmer at umn.edu]
>> Sent: Thursday, March 27, 2014 11:43 AM
>> To: David Huberman; arin-ppml at arin.net
>> Cc: David Farmer
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>>
>> I'm the primary shepherd for this Draft;
>>
>> The author is Heather Schiller, and I'm only saying that because I'm
>> going to reference you to her comments at the mic at the last NANOG.
>>
>> The research that prompted the proposal was presented at the last NANOG
>> in Atlanta and is at the following link;
>>
>> https://www.nanog.org/meetings/abstract?id=2289
>>
>> Heather's comments begins at about time stamp 17:10 or so on the video of
>> the NANOG presentation, and there are a couple other comments as well.
>>
>> Additionally, the reference for the published paper for the research in
>> question is;
>>
>> http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf
>>
>> Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND
>> SUPPORTING DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS
>>
>> https://www.arin.net/participate/acsp/suggestions/2014-3.html
>>
>> [Shepherd hat - OFF]
>>
>> While I do not have a problem with this research and I don't think we
>> should restrict future such activities, I believe this is something the
>> community should discuss in detail and try to come to consensus on, one way
>> or the other.
>>
>> Also, while I disagree with the proposed policy text, what is proposed is
>> not without precedent.  As discussed in the NANOG presentation, RIPE
>> initially gave permission for a covering prefix for its whole /12 and then
>> it was modified to a covering prefixes of a /14 plus a /13, excluding the
>> space where most allocations were.  This significantly reduced the amount
>> of traffic for RIPE region and they were excluded from the analysis.
>>
>> Hope that helps.
>>
>> On 3/26/14, 21:55 , David Huberman wrote:
>> > Hi PPML,
>> >
>> > Can someone show me where in the mailing list archives this policy was
>> actively discussed on PPML? I can't find it.
>> >
>> > Alternatively, can the policy author or someone who strongly supports
>> this policy please either post to the list or email me privately and clue
>> me in?  I issued and managed almost every experimental assignment for
>> almost 10 years from 2003 to 2013, and I am lost as to what this policy is
>> saying.  I would like to be educated so I can support, or not support, the
>> efforts that have been made here.
>> >
>> > Thank you!
>> > /david
>> >
>> > David R Huberman
>> > Microsoft Corporation
>> > Senior IT/OPS Program Manager (GFS)
>> >
>> > -----Original Message-----
>> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>> > On Behalf Of ARIN
>> > Sent: Tuesday, March 25, 2014 11:28 AM
>> > To: arin-ppml at arin.net
>> > Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>> >
>> > On 20 March 2014 the ARIN Advisory Council (AC) accepted
>> > "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>> >
>> > Draft Policy ARIN-2014-12 is below and can be found at:
>> > https://www.arin.net/policy/proposals/2014_12.html
>> >
>> > You are encouraged to discuss the merits and your concerns of Draft
>> Policy 2014-12 on the Public Policy Mailing List.
>> >
>> > 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-2014-12
>> > Anti-hijack Policy
>> >
>> > Date: 25 March 2014
>> >
>> > Problem Statement:
>> >
>> > ARIN should not give research organizations permission to hijack
>> prefixes that have already been allocated. Research organizations
>> announcing lit aggregates may receive sensitive production traffic
>> belonging to live networks during periods of instability.
>> >
>> > Section 11.7 describes more than allocation size therefore updating the
>> section heading to something more accurate is appropriate.
>> >
>> > Policy statement:
>> >
>> > Modify the section 11.7 heading to be more accurate. Modify the first
>> sentence to prohibit overlapping assignments. Add text at the end to define
>> how research allocations should be designated and prohibit LOA's without
>> allocations.
>> >
>> > 11.7 Resource Allocation Guidelines
>> >
>> > The Numbering Resources requested come from the global Internet
>> Resource space, do not overlap previously assigned space, and are not from
>> private or other non-routable Internet Resource space. The allocation size
>> should be consistent with the existing ARIN minimum allocation sizes,
>> unless small allocations are intended to be explicitly part of the
>> experiment. If an organization requires more resource than stipulated by
>> the minimum allocation sizes in force at the time of their request, their
>> experimental documentation should have clearly described and justified why
>> this is required.
>> >
>> > All research allocations must be registered publicly in whois. Each
>> research allocation will be designated as a research allocation with a
>> comment indicating when the allocation will end. ARIN will not issue a
>> Letter of Authority (LOA) to route a research prefix unless the allocation
>> is properly registered in whois.
>> >
>> > Comments:
>> > a. Timetable for implementation: Immediate b. Anything else:
>>
>> --
>> ================================================
>> David Farmer               Email: farmer at umn.edu
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE     Phone: 1-612-626-0815
>> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952================================================
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140328/b461331c/attachment.htm>

From David.Huberman at microsoft.com  Fri Mar 28 12:54:15 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 28 Mar 2014 16:54:15 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
Message-ID: <797296243dd640c48a56e43117ee8d78@DM2PR03MB398.namprd03.prod.outlook.com>

Thank you for the link, CJ.  I read the NANOG slides, where my question wasn't answered, but I see the paper does answer the question directly.  It states in "The BGP Announcements" section, first paragraph, that in 2012 they got a written LOA from ARIN to announce 2600::/12

While I think that ARIN made a perfectly defensible decision, the operator community should have the right to be able to say to ARIN, "No, don't do that again, please." and I think policy is the right place to do that.

I support this policy proposal in principle.  I have not yet fully digested all the textual changes.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

From: CJ Aronson [mailto:cja at daydream.com]
Sent: Friday, March 28, 2014 9:49 AM
To: David Huberman
Cc: David Farmer; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

There is a paper here
http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

that says
"We announced the prefixes: 2400::/12, 2600::/12, 2800::/12, 2c00::/12, 2a08::/13, and 2a04::/14 for over a three-month period. For a few days, we also announced RIPE's 2a00::/12"
So I believe that the answer to your question is yes.
-----Cathy

On Fri, Mar 28, 2014 at 4:32 PM, David Huberman <David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>> wrote:
David:

That summary of the issue helps a lot, thank you!

The question on my mind is:
        Did ARIN provide a written LOA to Merit to announce 2600::/12 ?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: David Farmer [mailto:farmer at umn.edu<mailto:farmer at umn.edu>]
Sent: Thursday, March 27, 2014 11:43 AM
To: David Huberman; arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Cc: David Farmer
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

I'm the primary shepherd for this Draft;

The author is Heather Schiller, and I'm only saying that because I'm going to reference you to her comments at the mic at the last NANOG.

The research that prompted the proposal was presented at the last NANOG in Atlanta and is at the following link;

https://www.nanog.org/meetings/abstract?id=2289

Heather's comments begins at about time stamp 17:10 or so on the video of the NANOG presentation, and there are a couple other comments as well.

Additionally, the reference for the published paper for the research in question is;

http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND SUPPORTING DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS

https://www.arin.net/participate/acsp/suggestions/2014-3.html

[Shepherd hat - OFF]

While I do not have a problem with this research and I don't think we should restrict future such activities, I believe this is something the community should discuss in detail and try to come to consensus on, one way or the other.

Also, while I disagree with the proposed policy text, what is proposed is not without precedent.  As discussed in the NANOG presentation, RIPE initially gave permission for a covering prefix for its whole /12 and then it was modified to a covering prefixes of a /14 plus a /13, excluding the space where most allocations were.  This significantly reduced the amount of traffic for RIPE region and they were excluded from the analysis.

Hope that helps.

On 3/26/14, 21:55 , David Huberman wrote:
> Hi PPML,
>
> Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.
>
> Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.
>
> Thank you!
> /david
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>]
> On Behalf Of ARIN
> Sent: Tuesday, March 25, 2014 11:28 AM
> To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
> Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
> On 20 March 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>
> Draft Policy ARIN-2014-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_12.html
>
> You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.
>
> 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-2014-12
> Anti-hijack Policy
>
> Date: 25 March 2014
>
> Problem Statement:
>
> ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.
>
> Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.
>
> Policy statement:
>
> Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.
>
> 11.7 Resource Allocation Guidelines
>
> The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
>
> All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.
>
> Comments:
> a. Timetable for implementation: Immediate b. Anything else:

--
================================================
David Farmer               Email: farmer at umn.edu<mailto:farmer at umn.edu>
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815<tel:1-612-626-0815>
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952<tel:1-612-812-9952> ================================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<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/20140328/4e1f3c36/attachment.htm>

From farmer at umn.edu  Fri Mar 28 12:56:49 2014
From: farmer at umn.edu (David Farmer)
Date: Fri, 28 Mar 2014 11:56:49 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <5335A9D1.7020506@umn.edu>

On 3/28/14, 11:32 , David Huberman wrote:
> David:
>
> That summary of the issue helps a lot, thank you!
>
> The question on my mind is:
> 	Did ARIN provide a written LOA to Merit to announce 2600::/12 ?

I have no direct knowledge one way or the other, I have to defer to ARIN 
staff to answer that question.  Paging John Curran please. :)

However, In addition to what CJ referenced, the presentation given at 
RIPE 66 (slide 7) implies that ARIN and the other RIRs did provide an 
LOA, doesn't say "written" but again I think that is implied as well.

http://www.merit.edu/research/pdf/2013/121-v6darknet-ripe2013.pdf


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


From bill at tknow.com  Fri Mar 28 12:57:44 2014
From: bill at tknow.com (Bill Buhler)
Date: Fri, 28 Mar 2014 12:57:44 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
Message-ID: <66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>

So if my understanding is correct, they basically performed a routing man in the middle attack on live IPv6 prefixes. Pardon my understanding level, but how did they keep from creating routing loops and service interruptions. I'm also a little concerned about performance and link loads. Are my concerns legitimate and inline?

Thanks,

--Bill

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of CJ Aronson
Sent: Friday, March 28, 2014 10:54 AM
To: David Huberman
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

I read some more of that article I sent.  They specifically state that they had LOAs from the RIRs to do these /12 advertisements.

Thanks!
-----Cathy

On Fri, Mar 28, 2014 at 4:49 PM, CJ Aronson <cja at daydream.com<mailto:cja at daydream.com>> wrote:
There is a paper here
http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

that says
"We announced the prefixes: 2400::/12, 2600::/12, 2800::/12, 2c00::/12, 2a08::/13, and 2a04::/14 for over a three-month period. For a few days, we also announced RIPE's 2a00::/12"

So I believe that the answer to your question is yes.

-----Cathy

On Fri, Mar 28, 2014 at 4:32 PM, David Huberman <David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>> wrote:
David:

That summary of the issue helps a lot, thank you!

The question on my mind is:
        Did ARIN provide a written LOA to Merit to announce 2600::/12 ?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: David Farmer [mailto:farmer at umn.edu<mailto:farmer at umn.edu>]
Sent: Thursday, March 27, 2014 11:43 AM
To: David Huberman; arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Cc: David Farmer
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

I'm the primary shepherd for this Draft;

The author is Heather Schiller, and I'm only saying that because I'm going to reference you to her comments at the mic at the last NANOG.

The research that prompted the proposal was presented at the last NANOG in Atlanta and is at the following link;

https://www.nanog.org/meetings/abstract?id=2289

Heather's comments begins at about time stamp 17:10 or so on the video of the NANOG presentation, and there are a couple other comments as well.

Additionally, the reference for the published paper for the research in question is;

http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND SUPPORTING DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS

https://www.arin.net/participate/acsp/suggestions/2014-3.html

[Shepherd hat - OFF]

While I do not have a problem with this research and I don't think we should restrict future such activities, I believe this is something the community should discuss in detail and try to come to consensus on, one way or the other.

Also, while I disagree with the proposed policy text, what is proposed is not without precedent.  As discussed in the NANOG presentation, RIPE initially gave permission for a covering prefix for its whole /12 and then it was modified to a covering prefixes of a /14 plus a /13, excluding the space where most allocations were.  This significantly reduced the amount of traffic for RIPE region and they were excluded from the analysis.

Hope that helps.

On 3/26/14, 21:55 , David Huberman wrote:
> Hi PPML,
>
> Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.
>
> Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.
>
> Thank you!
> /david
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>]
> On Behalf Of ARIN
> Sent: Tuesday, March 25, 2014 11:28 AM
> To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
> Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
> On 20 March 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>
> Draft Policy ARIN-2014-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_12.html
>
> You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.
>
> 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-2014-12
> Anti-hijack Policy
>
> Date: 25 March 2014
>
> Problem Statement:
>
> ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.
>
> Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.
>
> Policy statement:
>
> Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.
>
> 11.7 Resource Allocation Guidelines
>
> The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
>
> All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.
>
> Comments:
> a. Timetable for implementation: Immediate b. Anything else:

--
================================================
David Farmer               Email: farmer at umn.edu<mailto:farmer at umn.edu>
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815<tel:1-612-626-0815>
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952<tel:1-612-812-9952> ================================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<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/20140328/f52afa8c/attachment.htm>

From farmer at umn.edu  Fri Mar 28 13:05:25 2014
From: farmer at umn.edu (David Farmer)
Date: Fri, 28 Mar 2014 12:05:25 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
References: <5331CA99.2000806@arin.net>	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>	<5334711E.1000808@umn.edu>	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
	<66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
Message-ID: <5335ABD5.8080606@umn.edu>

On 3/28/14, 11:57 , Bill Buhler wrote:
> So if my understanding is correct, they basically performed a routing
> man in the middle attack on live IPv6 prefixes. Pardon my understanding
> level, but how did they keep from creating routing loops and service
> interruptions. I?m also a little concerned about performance and link
> loads. Are my concerns legitimate and inline?
>
> Thanks,
>
> --Bill

This absolutely WAS NOT an attack.  They announced a covering prefix, 
only traffic with no more specific route would follow this route.  Think 
more specific default route.


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


From scottleibrand at gmail.com  Fri Mar 28 13:05:53 2014
From: scottleibrand at gmail.com (Scott Leibrand)
Date: Fri, 28 Mar 2014 10:05:53 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
	<66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
Message-ID: <79446020-6D6A-46A9-B94D-672D6049D46E@gmail.com>

No, they were announcing less specific BGP prefixes. So they only got traffic for legitimate blocks when there was an interruption in the announcement of the more specific. 

Scott

> On Mar 28, 2014, at 9:57 AM, Bill Buhler <bill at tknow.com> wrote:
> 
> So if my understanding is correct, they basically performed a routing man in the middle attack on live IPv6 prefixes. Pardon my understanding level, but how did they keep from creating routing loops and service interruptions. I?m also a little concerned about performance and link loads. Are my concerns legitimate and inline?
>  
> Thanks,
>  
> --Bill
>  
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of CJ Aronson
> Sent: Friday, March 28, 2014 10:54 AM
> To: David Huberman
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>  
> I read some more of that article I sent.  They specifically state that they had LOAs from the RIRs to do these /12 advertisements. 
>  
> Thanks!
> -----Cathy
>  
> 
> On Fri, Mar 28, 2014 at 4:49 PM, CJ Aronson <cja at daydream.com> wrote:
> There is a paper here
> http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf
>  
> that says
> "We announced the prefixes: 2400::/12, 2600::/12, 2800::/12, 2c00::/12, 2a08::/13, and 2a04::/14 for over a three-month period. For a few days, we also announced RIPE?s 2a00::/12"
> So I believe that the answer to your question is yes.
> 
> -----Cathy
> 
>  
> 
> On Fri, Mar 28, 2014 at 4:32 PM, David Huberman <David.Huberman at microsoft.com> wrote:
> David:
> 
> That summary of the issue helps a lot, thank you!
> 
> The question on my mind is:
>         Did ARIN provide a written LOA to Merit to announce 2600::/12 ?
> 
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
> 
> -----Original Message-----
> From: David Farmer [mailto:farmer at umn.edu]
> Sent: Thursday, March 27, 2014 11:43 AM
> To: David Huberman; arin-ppml at arin.net
> Cc: David Farmer
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
> 
> I'm the primary shepherd for this Draft;
> 
> The author is Heather Schiller, and I'm only saying that because I'm going to reference you to her comments at the mic at the last NANOG.
> 
> The research that prompted the proposal was presented at the last NANOG in Atlanta and is at the following link;
> 
> https://www.nanog.org/meetings/abstract?id=2289
> 
> Heather's comments begins at about time stamp 17:10 or so on the video of the NANOG presentation, and there are a couple other comments as well.
> 
> Additionally, the reference for the published paper for the research in question is;
> 
> http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf
> 
> Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND SUPPORTING DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS
> 
> https://www.arin.net/participate/acsp/suggestions/2014-3.html
> 
> [Shepherd hat - OFF]
> 
> While I do not have a problem with this research and I don't think we should restrict future such activities, I believe this is something the community should discuss in detail and try to come to consensus on, one way or the other.
> 
> Also, while I disagree with the proposed policy text, what is proposed is not without precedent.  As discussed in the NANOG presentation, RIPE initially gave permission for a covering prefix for its whole /12 and then it was modified to a covering prefixes of a /14 plus a /13, excluding the space where most allocations were.  This significantly reduced the amount of traffic for RIPE region and they were excluded from the analysis.
> 
> Hope that helps.
> 
> On 3/26/14, 21:55 , David Huberman wrote:
> > Hi PPML,
> >
> > Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.
> >
> > Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.
> >
> > Thank you!
> > /david
> >
> > David R Huberman
> > Microsoft Corporation
> > Senior IT/OPS Program Manager (GFS)
> >
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of ARIN
> > Sent: Tuesday, March 25, 2014 11:28 AM
> > To: arin-ppml at arin.net
> > Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
> >
> > On 20 March 2014 the ARIN Advisory Council (AC) accepted
> > "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
> >
> > Draft Policy ARIN-2014-12 is below and can be found at:
> > https://www.arin.net/policy/proposals/2014_12.html
> >
> > You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.
> >
> > 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-2014-12
> > Anti-hijack Policy
> >
> > Date: 25 March 2014
> >
> > Problem Statement:
> >
> > ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.
> >
> > Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.
> >
> > Policy statement:
> >
> > Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.
> >
> > 11.7 Resource Allocation Guidelines
> >
> > The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
> >
> > All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.
> >
> > Comments:
> > a. Timetable for implementation: Immediate b. Anything else:
> 
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952 ================================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>  
>  
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140328/6e348ea3/attachment.htm>

From bill at tknow.com  Fri Mar 28 13:18:31 2014
From: bill at tknow.com (Bill Buhler)
Date: Fri, 28 Mar 2014 13:18:31 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <79446020-6D6A-46A9-B94D-672D6049D46E@gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
	<66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
	<79446020-6D6A-46A9-B94D-672D6049D46E@gmail.com>
Message-ID: <66E414654AD098469738606C8E7B03B03D25F65BD0@P1MBX03.HMC1.COMCAST.NET>

OK, that makes sense. Thanks for the clarification.

Bill

From: Scott Leibrand [mailto:scottleibrand at gmail.com]
Sent: Friday, March 28, 2014 11:06 AM
To: Bill Buhler
Cc: CJ Aronson; David Huberman; arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

No, they were announcing less specific BGP prefixes. So they only got traffic for legitimate blocks when there was an interruption in the announcement of the more specific.
Scott

On Mar 28, 2014, at 9:57 AM, Bill Buhler <bill at tknow.com<mailto:bill at tknow.com>> wrote:
So if my understanding is correct, they basically performed a routing man in the middle attack on live IPv6 prefixes. Pardon my understanding level, but how did they keep from creating routing loops and service interruptions. I?m also a little concerned about performance and link loads. Are my concerns legitimate and inline?

Thanks,

--Bill

From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of CJ Aronson
Sent: Friday, March 28, 2014 10:54 AM
To: David Huberman
Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

I read some more of that article I sent.  They specifically state that they had LOAs from the RIRs to do these /12 advertisements.

Thanks!
-----Cathy

On Fri, Mar 28, 2014 at 4:49 PM, CJ Aronson <cja at daydream.com<mailto:cja at daydream.com>> wrote:
There is a paper here
http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

that says
"We announced the prefixes: 2400::/12, 2600::/12, 2800::/12, 2c00::/12, 2a08::/13, and 2a04::/14 for over a three-month period. For a few days, we also announced RIPE?s 2a00::/12"

So I believe that the answer to your question is yes.

-----Cathy

On Fri, Mar 28, 2014 at 4:32 PM, David Huberman <David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>> wrote:
David:

That summary of the issue helps a lot, thank you!

The question on my mind is:
        Did ARIN provide a written LOA to Merit to announce 2600::/12 ?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: David Farmer [mailto:farmer at umn.edu<mailto:farmer at umn.edu>]
Sent: Thursday, March 27, 2014 11:43 AM
To: David Huberman; arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Cc: David Farmer
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

I'm the primary shepherd for this Draft;

The author is Heather Schiller, and I'm only saying that because I'm going to reference you to her comments at the mic at the last NANOG.

The research that prompted the proposal was presented at the last NANOG in Atlanta and is at the following link;

https://www.nanog.org/meetings/abstract?id=2289

Heather's comments begins at about time stamp 17:10 or so on the video of the NANOG presentation, and there are a couple other comments as well.

Additionally, the reference for the published paper for the research in question is;

http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND SUPPORTING DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS

https://www.arin.net/participate/acsp/suggestions/2014-3.html

[Shepherd hat - OFF]

While I do not have a problem with this research and I don't think we should restrict future such activities, I believe this is something the community should discuss in detail and try to come to consensus on, one way or the other.

Also, while I disagree with the proposed policy text, what is proposed is not without precedent.  As discussed in the NANOG presentation, RIPE initially gave permission for a covering prefix for its whole /12 and then it was modified to a covering prefixes of a /14 plus a /13, excluding the space where most allocations were.  This significantly reduced the amount of traffic for RIPE region and they were excluded from the analysis.

Hope that helps.

On 3/26/14, 21:55 , David Huberman wrote:
> Hi PPML,
>
> Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.
>
> Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.
>
> Thank you!
> /david
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>]
> On Behalf Of ARIN
> Sent: Tuesday, March 25, 2014 11:28 AM
> To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
> Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
> On 20 March 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>
> Draft Policy ARIN-2014-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_12.html
>
> You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.
>
> 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-2014-12
> Anti-hijack Policy
>
> Date: 25 March 2014
>
> Problem Statement:
>
> ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.
>
> Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.
>
> Policy statement:
>
> Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.
>
> 11.7 Resource Allocation Guidelines
>
> The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
>
> All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.
>
> Comments:
> a. Timetable for implementation: Immediate b. Anything else:

--
================================================
David Farmer               Email: farmer at umn.edu<mailto:farmer at umn.edu>
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815<tel:1-612-626-0815>
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952<tel:1-612-812-9952> ================================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140328/63e2474f/attachment.htm>

From farmer at umn.edu  Fri Mar 28 13:23:02 2014
From: farmer at umn.edu (David Farmer)
Date: Fri, 28 Mar 2014 12:23:02 -0500
Subject: [arin-ppml] Update: 2014-1 Out of Region Use
Message-ID: <5335AFF6.2060507@umn.edu>

Based on the discussion at the PPC in Atlanta (link below), the 
following changes are proposed.

https://www.arin.net/participate/meetings/reports/ppc_nanog60/webcast/2014-1.mov 


There is a summary of the changes and a red-lined version of the policy 
text with new and deleted text highlighted following the complete Draft 
Policy.

----

Draft Policy ARIN-2014-1
Out of Region Use

Date: 28 March 2014

Problem statement:

Current policy neither clearly forbids nor clearly permits out or region 
use of ARIN registered resources. This has created confusion and 
controversy within the ARIN community for some time. Earlier work on 
this issue has explored several options to restrict or otherwise limit 
out of region use. None of these options have gained consensus within 
the community. The next logical option is to discuss a proposal that 
clearly permits out of region use without limits, beyond those already 
existing in policy.

Permitting out of region use, however, poses issues that have to be 
addressed by policy and adjustments to operational practice. Out of 
region use needs a clear definition and any operational practices based 
on that definition must not be unnecessarily burdensome. It is 
significantly more difficult and costly for ARIN Staff to independently 
verify the justification and utilization of resources that are 
reassigned or otherwise used outside of the ARIN service region. There 
needs to be recognition of this difference in policy and associated 
operational practices, especially the cost differential when there is 
more than an incidental amount of out of region use.

Policy statement:

Create new Section X;

X. Out of Region Use

ARIN registered resources may be used outside the ARIN service region 
and such use is valid justification for new or additional resources. 
Resources are considered to be used outside the region if the user or 
customer service address or the technical infrastructure address, such 
as the point of presence (POP), data center, or other similar location, 
are outside the ARIN service region.

There is a general presumption that requesting resources from ARIN for 
use within another RIR's service region duplicates any resources held by 
the organization with that other RIR.  Therefore, the organization 
should, not hold any resources with the other RIR, or demonstrate that 
all such resources held are utilized based on ARIN policy requirements, 
or provide an operational justification clarifying how the resources 
from ARIN will not duplicate any underutilized resources held with the 
other RIR.

Only the utilization rate of ARIN registered resources or immediate need 
may be use to determine a valid request size beyond the applicable 
minimum allocation size.  The utilization rate of resources received 
from another RIR is not applicable in determining a valid request size.

X.1 Verification of Out of Region Use

The utilization of all ARIN registered resources must be verified when 
evaluating a request for additional resources or during a resource 
review, including any resources used outside the ARIN service region. 
All ARIN registered resources used outside the region must be verified 
to no less than an equivalent standard as resources used within the ARIN 
region. To this end ARIN, in its sole discretion, may engage independent 
external entities to assist it in the verification of information 
related to any resources used outside the region.

X.2 Reporting Resources Held with other RIRs

Except to the extent that incidental use, multi-instance use, or the 
critical infrastructure criteria described below apply, when out of 
region need is used to justify a request for resources from ARIN; The 
requesting organization will also report to ARIN the utilization status, 
based on applicable ARIN policy, of all resources it holds with the RIRs 
who's service regions the need justifying a request to ARIN is within, 
and any additional supporting documentation requested by ARIN regarding 
these reported resource.

X.3 Incidental Use

Out of region use of ARIN registered resources by an organization that 
totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two 
(2) ASNs within each of the other RIR's service regions are considered 
incidental use and as such are accounted for as if used within the ARIN 
service region.

X.4 Multi-Instance Use

Any resources used simultaneously in multiple locations, such as an 
anycast prefix or ASN, are considered as used within the ARIN service 
region, provided at least one instance is located within the region, 
regardless of how many other instances are located outside the region.

X.5 Critical Infrastructure

Resources justified through ARIN critical infrastructure policies are 
accounted for as if used within the ARIN service region, regardless of 
their actual location of use.

Comments:
a. Timetable for implementation: Immediate

b. Anything else

Current policy is ambiguous on the issue of out of region use of ARIN 
registered resources. The only guidance on the issue in current policy 
is in Section 2.2, that defines the term RIR; "... The primary role of 
RIRs is to manage and distribute public Internet address space within 
their respective regions." Some in the community believe this means out 
of region use should be at least limited or restricted while others 
believe this is only intended to focus efforts within the region and not 
define where resources may be used.

Several other policy proposals have explored restricting or otherwise 
limiting out of region use. None of these proposals gained consensus 
within the ARIN community. During the latest of these proposals, 
ARIN-2013-6, several standards were explored, a majority of use within 
region, a plurality of use within region, and some discussion of a 
minimum of 20 percent use within region. It was felt that each of these 
standards would interfered, to one extent or another, with the 
legitimate operations of multi- or trans-regional networks.

Section 2.2 tells us, the primary purpose of the RIRs are to manage and 
distribute resources within their regions. None the less, there have 
always been networks that don't neatly fit within the regions created by 
the RIR system. These legitimate trans-regional networks are operated by 
international businesses or global service providers, many of which are 
based within the ARIN region. Prior to IPv4 run-out, many of these 
trans-regional networks requested resources from ARIN for use both 
inside or outside the region, as long as the requests were justified by 
need.

As a result of IPv4 run-out, many in the community want to restrict out 
of region use to prevent ARIN resources from going to networks without a 
real technical presence in the ARIN region. However, any attempt to 
limit or restrict such out of region use inevitably will affect these 
legitimate trans-regional networks. Further, even the most restrictive 
regional use requirements will not significantly prolong the 
availability of IPv4 resources within the ARIN region. Therefore, 
attempting to restrict or limit out of region use of resources, even if 
it were for IPv4 only, is ineffective, inefficient, and overly 
burdensome to important elements of the global Internet.

The major concept behind this proposal is to allow out of region use 
without any limits, other than those already in policy, but bring an 
economic and reporting factors to play on the issue. It requires ARIN to 
verify out of region use of ARIN registered resources to no less than an 
equivalent standard as in region use, and enables ARIN to engage 
external entities to assist in this verification. It is expected ARIN 
will have agreements with all such external entities to ensure the 
confidentiality of all supporting documentation is preserved.

ARIN engaging external entities to assist in verification of out of 
region use is mostly an ARIN business issue, and not primarily a policy 
issue. However, today there is a general assumption that such 
verification for in region use is done almost exclusively in house at 
ARIN. Making this issue clear in policy follows a principle of least 
surprise, as the use of such external entities is likely to be 
frequently necessary to verify out of region use, especially in parts of 
the world where English is not the primary language. Or put another way, 
use of an external entity when verifying out of region use is more 
likely to be the rule rather than an exception.

When resources are requested for out of region use an organization also 
needs to report the utilization status of all resources it holds with 
the RIRs for the regions that the requested need is within.  This is to 
ensure there are not underutilized resources held with another RIR that 
would contradict the justified need for resources from ARIN.

There are additional expenses and complexity involved in verifying out 
of region use, as a result of language and logistical barriers that the 
regionality of the RIR system was originally conceived to mitigate.
In addition, evaluating the reported information about resources held 
with other RIRs, needed to ensure ARIN resources are not duplicating 
resources held with outer RIRs, increase staff's burden related to out 
of region use. Furthermore, section 2.2 is clear that providing 
resources for out of region use is, at best, only a secondary role for 
ARIN. As a result, out of region use should not significantly burden the 
primary role of providing resources for use within the region. These 
factors justify a recommendation to the Board of Trusties to create a 
separate fee structure for out of region use, creating the 
aforementioned economic factor.

This economic factor and the recommendation for a separate fee 
structure, are again mostly ARIN business issues, and not part of policy 
in general. However, this is one of those instances where policies and 
fees are intertwined.

It seems reasonable that this economic factor should be applied only to 
those that make substantial use of ARIN registered resources outside the 
region, and not to those that primarily use resources within the region. 
This proposal defines incidental out of region use, to ensure that 
trivial, insignificant or otherwise incidental use are exempt from the 
discussed economic factor, the reporting of resources help with other 
RIRs as well, and are accounted for as if used within the region.

Some amount of out of region use should be considered normal even for a 
network primarily based within the ARIN region. For example, numbering a 
global backbone that provides global access necessary for in region 
customers. Also, the other RIRs have minimum requirements to justify an 
initial allocation or assignment, similar to ARIN. These and other 
examples and issues, justify allowing some minimal amount of out of 
region use to be accounted for as if it were in region use. The 
currently proposed policy statement, X.3, defines incidental use in 
terms of an absolute thresholds for each type of resource.

Another option would be a percentage based threshold, say 20%. However, 
a percentage based threshold has the disadvantage that even a minimal 
change in usage can cause the ratio between in region and out of region 
use to change, potentially causing an oscillation around this threshold. 
This creates significant uncertainty for organizations as to if the 
discussed economic factor will apply to them, or not. Where as once an 
absolute threshold has been crossed by a significant amount, it is 
highly unlikely that any additional changes in usage will cause an 
oscillation around the threshold, providing much more certainty for most 
organizations.

Additionally, the proposal deals with a couple special cases in X.4 and 
X.5. Due to the relatively small resource impact and high importance to 
overall Internet stability; resources for critical infrastructure are 
accounted for as if used within the region. Anycast prefixes, and other 
resources used simultaneously in multiple locations, are considered as 
used outside the region only when they are exclusively used outside the 
region. Or put another way, as long as at least one instance is located 
within the region, they are considered used within the region, 
regardless of how many other instances are located outside the region. 
Both of these special cases have an overall positive impact on the 
Internet and should not be discouraged in anyway by this policy, lumping 
them in with general out of region use could be a disservice to the 
Internet and unnecessarily burdensome.

The intent of allowing an operational justification to clarify how 
resources received from ARIN will not duplicate any underutilized 
resources held with another RIR is to account for situations like; It 
may be necessary to use resources from another RIR to meet legal or 
regulatory requirements, or prevailing operational expectations, in some 
economies around the world. In such cases it is justified to also 
receive minimal resources from another RIR for use only in those 
economies. And using resources received from ARIN for the rest of a 
global network.

In summary, this proposal ensures that global organizations or global 
service providers base within the ARIN region may receive resources to 
operate their global network solely from ARIN, if they wish to do so. As 
long as the utilization of the out of region resources are verified to 
no less than an equivalent standard as in region resources and any 
additional reporting requirements are also meet. This is particularly 
important for IPv6; requiring organizations get IPv6 resources from 
multiple RIRs, or even making it appear that they should, will result in 
additional unique non-aggregatable prefixes within the IPv6 route table, 
rather than minimizing them, which one of the policy objectives for IPv6.

Finally, a separate but somewhat related issue; regardless of where ARIN 
registered resources are used, inside or outside of the ARIN service 
region, organizations must first qualify to receive resources from ARIN. 
ARIN's current operational practice is that an organization must be 
formed within the ARIN service region in order to qualify to receive any 
resources from ARIN. The issue of who should be eligible to receive 
resources was commingled with out of region use in ARIN-2013-6. It was 
felt these issues should be considered separately. Therefore, the issue 
of who should be eligible to receive resources is purposefully not dealt 
with by this proposal, and if any changes are necessary there should be 
separate policy proposals to deal with this issue independently.

----

Summary of Changes;

- Clarified out of region use is valid justification for both *new* or 
additional resources.

- Eliminated "user or customer billing address" from definition for out 
of region use, and change the items left to sentence from, instead of 
list form.

- Added that there is a general presumption that requesting resources 
from ARIN for use within another RIR's service region duplicates any 
resources held by the organization with that other RIR.

- Made it clear that only the utilization rate of ARIN resources or 
immediate need are used to determine the valid request size.

- New sections X.2 "Reporting Resources Held with other RIRs," this new 
section is intended to have organizations report the utilization of 
their resources, based on ARIN Policy, for the other RIRs where they are 
requesting ARIN resources for.  Except to the extent incidental use, 
multi-instance use, or critical infrastructure clauses apply.

- Changed incidental use to be on a per other RIR region basis to 
simplify the determination of if the Reporting Resources Held with other 
RIRs applies.

- Changed multi-instance use to use "at least one instance is located 
within the region" language.

- Updated the comments section to account for the above changes.

----

Here is an annotated version of the policy text
_
Deleted Text_
New Text
Retained Text

X. Out of Region Use

ARIN registered resources may be used outside the ARIN service region 
and such use is valid justification for new or additional resources. 
Resources are considered to be used outside the region if _any of the 
following are located outside the region. A. The user or customer 
billing address B._ the user or customer service address or _C._ the 
technical infrastructure address, such as the point of presence (POP), 
data center, or other similar location, are outside the ARIN service region.

There is a general presumption that requesting resources from ARIN for 
use within another RIR's service region duplicates any resources held by 
the organization with that other RIR.  Therefore, the organization 
should, not hold any resources with the other RIR, or demonstrate that 
all such resources held are utilized based on ARIN policy requirements, 
or provide an operational justification clarifying how the resources 
from ARIN will not duplicate any underutilized resources held with the 
other RIR.

Only the utilization rate of ARIN registered resources or immediate need 
may be use to determine a valid request size beyond the applicable 
minimum allocation size.  The utilization rate of resources received 
from another RIR is not applicable in determining a valid request size.

X.1 Verification of Out of Region Use

The utilization of all ARIN registered resources must be verified when 
evaluating a request for additional resources or during a resource 
review, including any resources used outside the ARIN service region. 
All ARIN registered resources used outside the region must be verified 
to no less than an equivalent standard as resources used within the ARIN 
region. To this end ARIN, in its sole discretion, may engage independent 
external entities to assist it in the verification of information 
related to any resources used outside the region.

X.2 Reporting Resources Held with other RIRs

Except to the extent that incidental use, multi-instance use, or the 
critical infrastructure criteria described below apply, when out of 
region need is used to justify a request for resources from ARIN; The 
requesting organization will also report to ARIN the utilization status, 
based on applicable ARIN policy, of all resources it holds with the RIRs 
who's service regions the need justifying a request to ARIN is within, 
and any additional supporting documentation requested by ARIN regarding 
these reported resource.

X._2_3 Incidental Use

Out of region use of ARIN registered resources by an organization that 
totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two 
(2) _10 _ASNs within each of the other RIR's service regions are 
considered incidental use and as such are accounted for as if used 
within the ARIN service region.

X.4 Multi-Instance Use

Any resources used simultaneously in multiple locations, such as an 
anycast prefix or ASN, are _accounted for as used outside the region, 
only if they are exclusively used outside the region._considered as used 
within the ARIN service region, provided at least one instance is 
located within the region, regardless of how many other instances are 
located outside the region.

X._3_5 Critical Infrastructure

Resources justified through ARIN critical infrastructure policies are 
accounted for as if used within the ARIN service region, regardless of 
their actual location of use.



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

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

From Timothy.S.Morizot at irs.gov  Fri Mar 28 13:30:11 2014
From: Timothy.S.Morizot at irs.gov (Morizot Timothy S)
Date: Fri, 28 Mar 2014 17:30:11 +0000
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
	<66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
Message-ID: <968C470DAC25FB419E0159952F28F0C06A75385A@MEM0200CP3XF04.ds.irsnet.gov>

Not really. The only traffic that would have gone to them would have been traffic not covered by a more specific route.

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Buhler
Sent: Friday, March 28, 2014 11:58 AM
To: CJ Aronson; David Huberman
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

So if my understanding is correct, they basically performed a routing man in the middle attack on live IPv6 prefixes. Pardon my understanding level, but how did they keep from creating routing loops and service interruptions. I'm also a little concerned about performance and link loads. Are my concerns legitimate and inline?

Thanks,

--Bill

From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net] On Behalf Of CJ Aronson
Sent: Friday, March 28, 2014 10:54 AM
To: David Huberman
Cc: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

I read some more of that article I sent.  They specifically state that they had LOAs from the RIRs to do these /12 advertisements.

Thanks!
-----Cathy

On Fri, Mar 28, 2014 at 4:49 PM, CJ Aronson <cja at daydream.com<mailto:cja at daydream.com>> wrote:
There is a paper here
http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

that says
"We announced the prefixes: 2400::/12, 2600::/12, 2800::/12, 2c00::/12, 2a08::/13, and 2a04::/14 for over a three-month period. For a few days, we also announced RIPE's 2a00::/12"

So I believe that the answer to your question is yes.

-----Cathy

On Fri, Mar 28, 2014 at 4:32 PM, David Huberman <David.Huberman at microsoft.com<mailto:David.Huberman at microsoft.com>> wrote:
David:

That summary of the issue helps a lot, thank you!

The question on my mind is:
        Did ARIN provide a written LOA to Merit to announce 2600::/12 ?

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)

-----Original Message-----
From: David Farmer [mailto:farmer at umn.edu<mailto:farmer at umn.edu>]
Sent: Thursday, March 27, 2014 11:43 AM
To: David Huberman; arin-ppml at arin.net<mailto:arin-ppml at arin.net>
Cc: David Farmer
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy

I'm the primary shepherd for this Draft;

The author is Heather Schiller, and I'm only saying that because I'm going to reference you to her comments at the mic at the last NANOG.

The research that prompted the proposal was presented at the last NANOG in Atlanta and is at the following link;

https://www.nanog.org/meetings/abstract?id=2289

Heather's comments begins at about time stamp 17:10 or so on the video of the NANOG presentation, and there are a couple other comments as well.

Additionally, the reference for the published paper for the research in question is;

http://www.merit.edu/research/pdf/2013/ipv6_darknet_paper_r6098.pdf

Also related is; ACSP SUGGESTION 2014.3: PUBLISH INFORMATION AND SUPPORTING DOCUMENTS FOR EXPERIMENTAL ALLOCATIONS

https://www.arin.net/participate/acsp/suggestions/2014-3.html

[Shepherd hat - OFF]

While I do not have a problem with this research and I don't think we should restrict future such activities, I believe this is something the community should discuss in detail and try to come to consensus on, one way or the other.

Also, while I disagree with the proposed policy text, what is proposed is not without precedent.  As discussed in the NANOG presentation, RIPE initially gave permission for a covering prefix for its whole /12 and then it was modified to a covering prefixes of a /14 plus a /13, excluding the space where most allocations were.  This significantly reduced the amount of traffic for RIPE region and they were excluded from the analysis.

Hope that helps.

On 3/26/14, 21:55 , David Huberman wrote:
> Hi PPML,
>
> Can someone show me where in the mailing list archives this policy was actively discussed on PPML? I can't find it.
>
> Alternatively, can the policy author or someone who strongly supports this policy please either post to the list or email me privately and clue me in?  I issued and managed almost every experimental assignment for almost 10 years from 2003 to 2013, and I am lost as to what this policy is saying.  I would like to be educated so I can support, or not support, the efforts that have been made here.
>
> Thank you!
> /david
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> -----Original Message-----
> From: arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net> [mailto:arin-ppml-bounces at arin.net<mailto:arin-ppml-bounces at arin.net>]
> On Behalf Of ARIN
> Sent: Tuesday, March 25, 2014 11:28 AM
> To: arin-ppml at arin.net<mailto:arin-ppml at arin.net>
> Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
>
> On 20 March 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-202 Anti-hijack Policy" as a Draft Policy.
>
> Draft Policy ARIN-2014-12 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_12.html
>
> You are encouraged to discuss the merits and your concerns of Draft Policy 2014-12 on the Public Policy Mailing List.
>
> 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-2014-12
> Anti-hijack Policy
>
> Date: 25 March 2014
>
> Problem Statement:
>
> ARIN should not give research organizations permission to hijack prefixes that have already been allocated. Research organizations announcing lit aggregates may receive sensitive production traffic belonging to live networks during periods of instability.
>
> Section 11.7 describes more than allocation size therefore updating the section heading to something more accurate is appropriate.
>
> Policy statement:
>
> Modify the section 11.7 heading to be more accurate. Modify the first sentence to prohibit overlapping assignments. Add text at the end to define how research allocations should be designated and prohibit LOA's without allocations.
>
> 11.7 Resource Allocation Guidelines
>
> The Numbering Resources requested come from the global Internet Resource space, do not overlap previously assigned space, and are not from private or other non-routable Internet Resource space. The allocation size should be consistent with the existing ARIN minimum allocation sizes, unless small allocations are intended to be explicitly part of the experiment. If an organization requires more resource than stipulated by the minimum allocation sizes in force at the time of their request, their experimental documentation should have clearly described and justified why this is required.
>
> All research allocations must be registered publicly in whois. Each research allocation will be designated as a research allocation with a comment indicating when the allocation will end. ARIN will not issue a Letter of Authority (LOA) to route a research prefix unless the allocation is properly registered in whois.
>
> Comments:
> a. Timetable for implementation: Immediate b. Anything else:

--
================================================
David Farmer               Email: farmer at umn.edu<mailto:farmer at umn.edu>
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815<tel:1-612-626-0815>
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952<tel:1-612-812-9952> ================================================
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<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/20140328/af94b66f/attachment.htm>

From David.Huberman at microsoft.com  Fri Mar 28 13:55:54 2014
From: David.Huberman at microsoft.com (David Huberman)
Date: Fri, 28 Mar 2014 17:55:54 +0000
Subject: [arin-ppml] Update: 2014-1 Out of Region Use
In-Reply-To: <5335AFF6.2060507@umn.edu>
References: <5335AFF6.2060507@umn.edu>
Message-ID: <87f821b26ba1410bb718278161a9c529@DM2PR03MB398.namprd03.prod.outlook.com>

Support in principle, strongly opposed as written.

ARIN is a registry, not a regulator.  Networks with global reach should not have regulatory rules placed on them by ARIN whose job is primarily to record number assignments, not make rules which affect network topology. Thus I support the idea that numbers should not be bound to arbitrary political boundaries.

I oppose this draft as written, however, because it adds hundreds of words to NRPM where only a few are needed to address the stated goal.  The problem statement indicates: " The next logical option is to discuss a proposal that clearly permits out of region use without limits".  Well ok.  If you wanted to do that explicitly in policy, how about:

	Section 1.x -  ARIN-issued number resources may be used on equipment located anywhere.

All the rest of the text that I see in this draft come down to, "if you have resources in other RIRs, we'll audit them to ensure you aren't double dipping." Policy already allows that:

	"ISPs must have efficiently utilized all previous allocations and at least 80% of their most recent allocation
	 in order to receive additional space."

	" In order to justify an additional assignment, end-users must have efficiently utilized at least 80% of all 
	previous assignments, and must provide ARIN with utilization details"

We need to simplify NRPM and start peeling back a lot of this over-regulatory policy.  To do so, let's write clearer and more concise policy proposals, please.

David R Huberman
Microsoft Corporation
Senior IT/OPS Program Manager (GFS)


From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer
Sent: Friday, March 28, 2014 10:23 AM
To: ARIN PPML
Subject: [arin-ppml] Update: 2014-1 Out of Region Use

Based on the discussion at the PPC in Atlanta (link below), the following changes are proposed.

https://www.arin.net/participate/meetings/reports/ppc_nanog60/webcast/2014-1.mov 

There is a summary of the changes and a red-lined version of the policy text with new and deleted text highlighted following the complete Draft Policy. 

----

Draft Policy ARIN-2014-1
Out of Region Use

Date: 28 March 2014

Problem statement:

Current policy neither clearly forbids nor clearly permits out or region use of ARIN registered resources. This has created confusion and controversy within the ARIN community for some time. Earlier work on this issue has explored several options to restrict or otherwise limit out of region use. None of these options have gained consensus within the community. The next logical option is to discuss a proposal that clearly permits out of region use without limits, beyond those already existing in policy.

Permitting out of region use, however, poses issues that have to be addressed by policy and adjustments to operational practice. Out of region use needs a clear definition and any operational practices based on that definition must not be unnecessarily burdensome. It is significantly more difficult and costly for ARIN Staff to independently verify the justification and utilization of resources that are reassigned or otherwise used outside of the ARIN service region. There needs to be recognition of this difference in policy and associated operational practices, especially the cost differential when there is more than an incidental amount of out of region use.

Policy statement:

Create new Section X;

X. Out of Region Use

ARIN registered resources may be used outside the ARIN service region and such use is valid justification for new or additional resources. Resources are considered to be used outside the region if the user or customer service address or the technical infrastructure address, such as the point of presence (POP), data center, or other similar location, are outside the ARIN service region.

There is a general presumption that requesting resources from ARIN for use within another RIR's service region duplicates any resources held by the organization with that other RIR.? Therefore, the organization should, not hold any resources with the other RIR, or demonstrate that all such resources held are utilized based on ARIN policy requirements, or provide an operational justification clarifying how the resources from ARIN will not duplicate any underutilized resources held with the other RIR.

Only the utilization rate of ARIN registered resources or immediate need may be use to determine a valid request size beyond the applicable minimum allocation size.? The utilization rate of resources received from another RIR is not applicable in determining a valid request size.

X.1 Verification of Out of Region Use

The utilization of all ARIN registered resources must be verified when evaluating a request for additional resources or during a resource review, including any resources used outside the ARIN service region. All ARIN registered resources used outside the region must be verified to no less than an equivalent standard as resources used within the ARIN region. To this end ARIN, in its sole discretion, may engage independent external entities to assist it in the verification of information related to any resources used outside the region.

X.2 Reporting Resources Held with other RIRs

Except to the extent that incidental use, multi-instance use, or the critical infrastructure criteria described below apply, when out of region need is used to justify a request for resources from ARIN; The requesting organization will also report to ARIN the utilization status, based on applicable ARIN policy, of all resources it holds with the RIRs who's service regions the need justifying a request to ARIN is within, and any additional supporting documentation requested by ARIN regarding these reported resource.

X.3 Incidental Use

Out of region use of ARIN registered resources by an organization that totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two (2) ASNs within each of the other RIR's service regions are considered incidental use and as such are accounted for as if used within the ARIN service region.

X.4 Multi-Instance Use

Any resources used simultaneously in multiple locations, such as an anycast prefix or ASN, are considered as used within the ARIN service region, provided at least one instance is located within the region, regardless of how many other instances are located outside the region.

X.5 Critical Infrastructure

Resources justified through ARIN critical infrastructure policies are accounted for as if used within the ARIN service region, regardless of their actual location of use.

Comments:
a. Timetable for implementation: Immediate

b. Anything else

Current policy is ambiguous on the issue of out of region use of ARIN registered resources. The only guidance on the issue in current policy is in Section 2.2, that defines the term RIR; "... The primary role of RIRs is to manage and distribute public Internet address space within their respective regions." Some in the community believe this means out of region use should be at least limited or restricted while others believe this is only intended to focus efforts within the region and not define where resources may be used.

Several other policy proposals have explored restricting or otherwise limiting out of region use. None of these proposals gained consensus within the ARIN community. During the latest of these proposals, ARIN-2013-6, several standards were explored, a majority of use within region, a plurality of use within region, and some discussion of a minimum of 20 percent use within region. It was felt that each of these standards would interfered, to one extent or another, with the legitimate operations of multi- or trans-regional networks.

Section 2.2 tells us, the primary purpose of the RIRs are to manage and distribute resources within their regions. None the less, there have always been networks that don't neatly fit within the regions created by the RIR system. These legitimate trans-regional networks are operated by international businesses or global service providers, many of which are based within the ARIN region. Prior to IPv4 run-out, many of these trans-regional networks requested resources from ARIN for use both inside or outside the region, as long as the requests were justified by need.

As a result of IPv4 run-out, many in the community want to restrict out of region use to prevent ARIN resources from going to networks without a real technical presence in the ARIN region. However, any attempt to limit or restrict such out of region use inevitably will affect these legitimate trans-regional networks. Further, even the most restrictive regional use requirements will not significantly prolong the availability of IPv4 resources within the ARIN region. Therefore, attempting to restrict or limit out of region use of resources, even if it were for IPv4 only, is ineffective, inefficient, and overly burdensome to important elements of the global Internet.

The major concept behind this proposal is to allow out of region use without any limits, other than those already in policy, but bring an economic and reporting factors to play on the issue. It requires ARIN to verify out of region use of ARIN registered resources to no less than an equivalent standard as in region use, and enables ARIN to engage external entities to assist in this verification. It is expected ARIN will have agreements with all such external entities to ensure the confidentiality of all supporting documentation is preserved.

ARIN engaging external entities to assist in verification of out of region use is mostly an ARIN business issue, and not primarily a policy issue. However, today there is a general assumption that such verification for in region use is done almost exclusively in house at ARIN. Making this issue clear in policy follows a principle of least surprise, as the use of such external entities is likely to be frequently necessary to verify out of region use, especially in parts of the world where English is not the primary language. Or put another way, use of an external entity when verifying out of region use is more likely to be the rule rather than an exception.

When resources are requested for out of region use an organization also needs to report the utilization status of all resources it holds with the RIRs for the regions that the requested need is within.? This is to ensure there are not underutilized resources held with another RIR that would contradict the justified need for resources from ARIN.

There are additional expenses and complexity involved in verifying out of region use, as a result of language and logistical barriers that the regionality of the RIR system was originally conceived to mitigate.
In addition, evaluating the reported information about resources held with other RIRs, needed to ensure ARIN resources are not duplicating resources held with outer RIRs, increase staff's burden related to out of region use. Furthermore, section 2.2 is clear that providing resources for out of region use is, at best, only a secondary role for ARIN. As a result, out of region use should not significantly burden the primary role of providing resources for use within the region. These factors justify a recommendation to the Board of Trusties to create a separate fee structure for out of region use, creating the aforementioned economic factor.

This economic factor and the recommendation for a separate fee structure, are again mostly ARIN business issues, and not part of policy in general. However, this is one of those instances where policies and fees are intertwined.

It seems reasonable that this economic factor should be applied only to those that make substantial use of ARIN registered resources outside the region, and not to those that primarily use resources within the region. This proposal defines incidental out of region use, to ensure that trivial, insignificant or otherwise incidental use are exempt from the discussed economic factor, the reporting of resources help with other RIRs as well, and are accounted for as if used within the region.

Some amount of out of region use should be considered normal even for a network primarily based within the ARIN region. For example, numbering a global backbone that provides global access necessary for in region customers. Also, the other RIRs have minimum requirements to justify an initial allocation or assignment, similar to ARIN. These and other examples and issues, justify allowing some minimal amount of out of region use to be accounted for as if it were in region use. The currently proposed policy statement, X.3, defines incidental use in terms of an absolute thresholds for each type of resource.

Another option would be a percentage based threshold, say 20%. However, a percentage based threshold has the disadvantage that even a minimal change in usage can cause the ratio between in region and out of region use to change, potentially causing an oscillation around this threshold. This creates significant uncertainty for organizations as to if the discussed economic factor will apply to them, or not. Where as once an absolute threshold has been crossed by a significant amount, it is highly unlikely that any additional changes in usage will cause an oscillation around the threshold, providing much more certainty for most organizations.

Additionally, the proposal deals with a couple special cases in X.4 and X.5. Due to the relatively small resource impact and high importance to overall Internet stability; resources for critical infrastructure are accounted for as if used within the region. Anycast prefixes, and other resources used simultaneously in multiple locations, are considered as used outside the region only when they are exclusively used outside the region. Or put another way, as long as at least one instance is located within the region, they are considered used within the region, regardless of how many other instances are located outside the region. Both of these special cases have an overall positive impact on the Internet and should not be discouraged in anyway by this policy, lumping them in with general out of region use could be a disservice to the Internet and unnecessarily burdensome.

The intent of allowing an operational justification to clarify how resources received from ARIN will not duplicate any underutilized resources held with another RIR is to account for situations like; It may be necessary to use resources from another RIR to meet legal or regulatory requirements, or prevailing operational expectations, in some economies around the world. In such cases it is justified to also receive minimal resources from another RIR for use only in those economies. And using resources received from ARIN for the rest of a global network.

In summary, this proposal ensures that global organizations or global service providers base within the ARIN region may receive resources to operate their global network solely from ARIN, if they wish to do so. As long as the utilization of the out of region resources are verified to no less than an equivalent standard as in region resources and any additional reporting requirements are also meet. This is particularly important for IPv6; requiring organizations get IPv6 resources from multiple RIRs, or even making it appear that they should, will result in additional unique non-aggregatable prefixes within the IPv6 route table, rather than minimizing them, which one of the policy objectives for IPv6.

Finally, a separate but somewhat related issue; regardless of where ARIN registered resources are used, inside or outside of the ARIN service region, organizations must first qualify to receive resources from ARIN. ARIN's current operational practice is that an organization must be formed within the ARIN service region in order to qualify to receive any resources from ARIN. The issue of who should be eligible to receive resources was commingled with out of region use in ARIN-2013-6. It was felt these issues should be considered separately. Therefore, the issue of who should be eligible to receive resources is purposefully not dealt with by this proposal, and if any changes are necessary there should be separate policy proposals to deal with this issue independently.

----

Summary of Changes;

- Clarified out of region use is valid justification for both new or additional resources.

- Eliminated "user or customer billing address" from definition for out of region use, and change the items left to sentence from, instead of list form.

- Added that there is a general presumption that requesting resources from ARIN for use within another RIR's service region duplicates any resources held by the organization with that other RIR.

- Made it clear that only the utilization rate of ARIN resources or immediate need are used to determine the valid request size.

- New sections X.2 "Reporting Resources Held with other RIRs," this new section is intended to have organizations report the utilization of their resources, based on ARIN Policy, for the other RIRs where they are requesting ARIN resources for.? Except to the extent incidental use, multi-instance use, or critical infrastructure clauses apply.

- Changed incidental use to be on a per other RIR region basis to simplify the determination of if the Reporting Resources Held with other RIRs applies.

- Changed multi-instance use to use "at least one instance is located within the region" language. 

- Updated the comments section to account for the above changes.

---- 
Here is an annotated version of the policy text

Deleted Text
New Text
Retained Text
X. Out of Region Use

ARIN registered resources may be used outside the ARIN service region and such use is valid justification for new or additional resources. Resources are considered to be used outside the region if any of the following are located outside the region. A. The user or customer billing address B. the user or customer service address or C. the technical infrastructure address, such as the point of presence (POP), data center, or other similar location, are outside the ARIN service region.

There is a general presumption that requesting resources from ARIN for use within another RIR's service region duplicates any resources held by the organization with that other RIR.? Therefore, the organization should, not hold any resources with the other RIR, or demonstrate that all such resources held are utilized based on ARIN policy requirements, or provide an operational justification clarifying how the resources from ARIN will not duplicate any underutilized resources held with the other RIR.

Only the utilization rate of ARIN registered resources or immediate need may be use to determine a valid request size beyond the applicable minimum allocation size.? The utilization rate of resources received from another RIR is not applicable in determining a valid request size.

X.1 Verification of Out of Region Use

The utilization of all ARIN registered resources must be verified when evaluating a request for additional resources or during a resource review, including any resources used outside the ARIN service region. All ARIN registered resources used outside the region must be verified to no less than an equivalent standard as resources used within the ARIN region. To this end ARIN, in its sole discretion, may engage independent external entities to assist it in the verification of information related to any resources used outside the region.

X.2 Reporting Resources Held with other RIRs

Except to the extent that incidental use, multi-instance use, or the critical infrastructure criteria described below apply, when out of region need is used to justify a request for resources from ARIN; The requesting organization will also report to ARIN the utilization status, based on applicable ARIN policy, of all resources it holds with the RIRs who's service regions the need justifying a request to ARIN is within, and any additional supporting documentation requested by ARIN regarding these reported resource.

X.23 Incidental Use

Out of region use of ARIN registered resources by an organization that totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two (2) 10 ASNs within each of the other RIR's service regions are considered incidental use and as such are accounted for as if used within the ARIN service region.

X.4 Multi-Instance Use

Any resources used simultaneously in multiple locations, such as an anycast prefix or ASN, are accounted for as used outside the region, only if they are exclusively used outside the region.considered as used within the ARIN service region, provided at least one instance is located within the region, regardless of how many other instances are located outside the region.

X.35 Critical Infrastructure

Resources justified through ARIN critical infrastructure policies are accounted for as if used within the ARIN service region, regardless of their actual location of use. 



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


From jay-ARIN at tp.org  Fri Mar 28 16:06:25 2014
From: jay-ARIN at tp.org (Jay Moran (AOL))
Date: Fri, 28 Mar 2014 16:06:25 -0400
Subject: [arin-ppml] Update: 2014-1 Out of Region Use
In-Reply-To: <87f821b26ba1410bb718278161a9c529@DM2PR03MB398.namprd03.prod.outlook.com>
References: <5335AFF6.2060507@umn.edu>
	<87f821b26ba1410bb718278161a9c529@DM2PR03MB398.namprd03.prod.outlook.com>
Message-ID: <CA+Ld8r8irr5GkBnz-WWaiESRSjD5RjDXY1=JtqzOz+EVYf2j1A@mail.gmail.com>

Fully agree with David Huberman's comments.

Jay Moran
AOL and ATDN

--
Jay Moran
http://tp.org/jay


On Fri, Mar 28, 2014 at 1:55 PM, David Huberman <
David.Huberman at microsoft.com> wrote:

> Support in principle, strongly opposed as written.
>
> ARIN is a registry, not a regulator.  Networks with global reach should
> not have regulatory rules placed on them by ARIN whose job is primarily to
> record number assignments, not make rules which affect network topology.
> Thus I support the idea that numbers should not be bound to arbitrary
> political boundaries.
>
> I oppose this draft as written, however, because it adds hundreds of words
> to NRPM where only a few are needed to address the stated goal.  The
> problem statement indicates: " The next logical option is to discuss a
> proposal that clearly permits out of region use without limits".  Well ok.
>  If you wanted to do that explicitly in policy, how about:
>
>         Section 1.x -  ARIN-issued number resources may be used on
> equipment located anywhere.
>
> All the rest of the text that I see in this draft come down to, "if you
> have resources in other RIRs, we'll audit them to ensure you aren't double
> dipping." Policy already allows that:
>
>         "ISPs must have efficiently utilized all previous allocations and
> at least 80% of their most recent allocation
>          in order to receive additional space."
>
>         " In order to justify an additional assignment, end-users must
> have efficiently utilized at least 80% of all
>         previous assignments, and must provide ARIN with utilization
> details"
>
> We need to simplify NRPM and start peeling back a lot of this
> over-regulatory policy.  To do so, let's write clearer and more concise
> policy proposals, please.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of David Farmer
> Sent: Friday, March 28, 2014 10:23 AM
> To: ARIN PPML
> Subject: [arin-ppml] Update: 2014-1 Out of Region Use
>
> Based on the discussion at the PPC in Atlanta (link below), the following
> changes are proposed.
>
>
> https://www.arin.net/participate/meetings/reports/ppc_nanog60/webcast/2014-1.mov
>
> There is a summary of the changes and a red-lined version of the policy
> text with new and deleted text highlighted following the complete Draft
> Policy.
>
> ----
>
> Draft Policy ARIN-2014-1
> Out of Region Use
>
> Date: 28 March 2014
>
> Problem statement:
>
> Current policy neither clearly forbids nor clearly permits out or region
> use of ARIN registered resources. This has created confusion and
> controversy within the ARIN community for some time. Earlier work on this
> issue has explored several options to restrict or otherwise limit out of
> region use. None of these options have gained consensus within the
> community. The next logical option is to discuss a proposal that clearly
> permits out of region use without limits, beyond those already existing in
> policy.
>
> Permitting out of region use, however, poses issues that have to be
> addressed by policy and adjustments to operational practice. Out of region
> use needs a clear definition and any operational practices based on that
> definition must not be unnecessarily burdensome. It is significantly more
> difficult and costly for ARIN Staff to independently verify the
> justification and utilization of resources that are reassigned or otherwise
> used outside of the ARIN service region. There needs to be recognition of
> this difference in policy and associated operational practices, especially
> the cost differential when there is more than an incidental amount of out
> of region use.
>
> Policy statement:
>
> Create new Section X;
>
> X. Out of Region Use
>
> ARIN registered resources may be used outside the ARIN service region and
> such use is valid justification for new or additional resources. Resources
> are considered to be used outside the region if the user or customer
> service address or the technical infrastructure address, such as the point
> of presence (POP), data center, or other similar location, are outside the
> ARIN service region.
>
> There is a general presumption that requesting resources from ARIN for use
> within another RIR's service region duplicates any resources held by the
> organization with that other RIR.  Therefore, the organization should, not
> hold any resources with the other RIR, or demonstrate that all such
> resources held are utilized based on ARIN policy requirements, or provide
> an operational justification clarifying how the resources from ARIN will
> not duplicate any underutilized resources held with the other RIR.
>
> Only the utilization rate of ARIN registered resources or immediate need
> may be use to determine a valid request size beyond the applicable minimum
> allocation size.  The utilization rate of resources received from another
> RIR is not applicable in determining a valid request size.
>
> X.1 Verification of Out of Region Use
>
> The utilization of all ARIN registered resources must be verified when
> evaluating a request for additional resources or during a resource review,
> including any resources used outside the ARIN service region. All ARIN
> registered resources used outside the region must be verified to no less
> than an equivalent standard as resources used within the ARIN region. To
> this end ARIN, in its sole discretion, may engage independent external
> entities to assist it in the verification of information related to any
> resources used outside the region.
>
> X.2 Reporting Resources Held with other RIRs
>
> Except to the extent that incidental use, multi-instance use, or the
> critical infrastructure criteria described below apply, when out of region
> need is used to justify a request for resources from ARIN; The requesting
> organization will also report to ARIN the utilization status, based on
> applicable ARIN policy, of all resources it holds with the RIRs who's
> service regions the need justifying a request to ARIN is within, and any
> additional supporting documentation requested by ARIN regarding these
> reported resource.
>
> X.3 Incidental Use
>
> Out of region use of ARIN registered resources by an organization that
> totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two (2)
> ASNs within each of the other RIR's service regions are considered
> incidental use and as such are accounted for as if used within the ARIN
> service region.
>
> X.4 Multi-Instance Use
>
> Any resources used simultaneously in multiple locations, such as an
> anycast prefix or ASN, are considered as used within the ARIN service
> region, provided at least one instance is located within the region,
> regardless of how many other instances are located outside the region.
>
> X.5 Critical Infrastructure
>
> Resources justified through ARIN critical infrastructure policies are
> accounted for as if used within the ARIN service region, regardless of
> their actual location of use.
>
> Comments:
> a. Timetable for implementation: Immediate
>
> b. Anything else
>
> Current policy is ambiguous on the issue of out of region use of ARIN
> registered resources. The only guidance on the issue in current policy is
> in Section 2.2, that defines the term RIR; "... The primary role of RIRs is
> to manage and distribute public Internet address space within their
> respective regions." Some in the community believe this means out of region
> use should be at least limited or restricted while others believe this is
> only intended to focus efforts within the region and not define where
> resources may be used.
>
> Several other policy proposals have explored restricting or otherwise
> limiting out of region use. None of these proposals gained consensus within
> the ARIN community. During the latest of these proposals, ARIN-2013-6,
> several standards were explored, a majority of use within region, a
> plurality of use within region, and some discussion of a minimum of 20
> percent use within region. It was felt that each of these standards would
> interfered, to one extent or another, with the legitimate operations of
> multi- or trans-regional networks.
>
> Section 2.2 tells us, the primary purpose of the RIRs are to manage and
> distribute resources within their regions. None the less, there have always
> been networks that don't neatly fit within the regions created by the RIR
> system. These legitimate trans-regional networks are operated by
> international businesses or global service providers, many of which are
> based within the ARIN region. Prior to IPv4 run-out, many of these
> trans-regional networks requested resources from ARIN for use both inside
> or outside the region, as long as the requests were justified by need.
>
> As a result of IPv4 run-out, many in the community want to restrict out of
> region use to prevent ARIN resources from going to networks without a real
> technical presence in the ARIN region. However, any attempt to limit or
> restrict such out of region use inevitably will affect these legitimate
> trans-regional networks. Further, even the most restrictive regional use
> requirements will not significantly prolong the availability of IPv4
> resources within the ARIN region. Therefore, attempting to restrict or
> limit out of region use of resources, even if it were for IPv4 only, is
> ineffective, inefficient, and overly burdensome to important elements of
> the global Internet.
>
> The major concept behind this proposal is to allow out of region use
> without any limits, other than those already in policy, but bring an
> economic and reporting factors to play on the issue. It requires ARIN to
> verify out of region use of ARIN registered resources to no less than an
> equivalent standard as in region use, and enables ARIN to engage external
> entities to assist in this verification. It is expected ARIN will have
> agreements with all such external entities to ensure the confidentiality of
> all supporting documentation is preserved.
>
> ARIN engaging external entities to assist in verification of out of region
> use is mostly an ARIN business issue, and not primarily a policy issue.
> However, today there is a general assumption that such verification for in
> region use is done almost exclusively in house at ARIN. Making this issue
> clear in policy follows a principle of least surprise, as the use of such
> external entities is likely to be frequently necessary to verify out of
> region use, especially in parts of the world where English is not the
> primary language. Or put another way, use of an external entity when
> verifying out of region use is more likely to be the rule rather than an
> exception.
>
> When resources are requested for out of region use an organization also
> needs to report the utilization status of all resources it holds with the
> RIRs for the regions that the requested need is within.  This is to ensure
> there are not underutilized resources held with another RIR that would
> contradict the justified need for resources from ARIN.
>
> There are additional expenses and complexity involved in verifying out of
> region use, as a result of language and logistical barriers that the
> regionality of the RIR system was originally conceived to mitigate.
> In addition, evaluating the reported information about resources held with
> other RIRs, needed to ensure ARIN resources are not duplicating resources
> held with outer RIRs, increase staff's burden related to out of region use.
> Furthermore, section 2.2 is clear that providing resources for out of
> region use is, at best, only a secondary role for ARIN. As a result, out of
> region use should not significantly burden the primary role of providing
> resources for use within the region. These factors justify a recommendation
> to the Board of Trusties to create a separate fee structure for out of
> region use, creating the aforementioned economic factor.
>
> This economic factor and the recommendation for a separate fee structure,
> are again mostly ARIN business issues, and not part of policy in general.
> However, this is one of those instances where policies and fees are
> intertwined.
>
> It seems reasonable that this economic factor should be applied only to
> those that make substantial use of ARIN registered resources outside the
> region, and not to those that primarily use resources within the region.
> This proposal defines incidental out of region use, to ensure that trivial,
> insignificant or otherwise incidental use are exempt from the discussed
> economic factor, the reporting of resources help with other RIRs as well,
> and are accounted for as if used within the region.
>
> Some amount of out of region use should be considered normal even for a
> network primarily based within the ARIN region. For example, numbering a
> global backbone that provides global access necessary for in region
> customers. Also, the other RIRs have minimum requirements to justify an
> initial allocation or assignment, similar to ARIN. These and other examples
> and issues, justify allowing some minimal amount of out of region use to be
> accounted for as if it were in region use. The currently proposed policy
> statement, X.3, defines incidental use in terms of an absolute thresholds
> for each type of resource.
>
> Another option would be a percentage based threshold, say 20%. However, a
> percentage based threshold has the disadvantage that even a minimal change
> in usage can cause the ratio between in region and out of region use to
> change, potentially causing an oscillation around this threshold. This
> creates significant uncertainty for organizations as to if the discussed
> economic factor will apply to them, or not. Where as once an absolute
> threshold has been crossed by a significant amount, it is highly unlikely
> that any additional changes in usage will cause an oscillation around the
> threshold, providing much more certainty for most organizations.
>
> Additionally, the proposal deals with a couple special cases in X.4 and
> X.5. Due to the relatively small resource impact and high importance to
> overall Internet stability; resources for critical infrastructure are
> accounted for as if used within the region. Anycast prefixes, and other
> resources used simultaneously in multiple locations, are considered as used
> outside the region only when they are exclusively used outside the region.
> Or put another way, as long as at least one instance is located within the
> region, they are considered used within the region, regardless of how many
> other instances are located outside the region. Both of these special cases
> have an overall positive impact on the Internet and should not be
> discouraged in anyway by this policy, lumping them in with general out of
> region use could be a disservice to the Internet and unnecessarily
> burdensome.
>
> The intent of allowing an operational justification to clarify how
> resources received from ARIN will not duplicate any underutilized resources
> held with another RIR is to account for situations like; It may be
> necessary to use resources from another RIR to meet legal or regulatory
> requirements, or prevailing operational expectations, in some economies
> around the world. In such cases it is justified to also receive minimal
> resources from another RIR for use only in those economies. And using
> resources received from ARIN for the rest of a global network.
>
> In summary, this proposal ensures that global organizations or global
> service providers base within the ARIN region may receive resources to
> operate their global network solely from ARIN, if they wish to do so. As
> long as the utilization of the out of region resources are verified to no
> less than an equivalent standard as in region resources and any additional
> reporting requirements are also meet. This is particularly important for
> IPv6; requiring organizations get IPv6 resources from multiple RIRs, or
> even making it appear that they should, will result in additional unique
> non-aggregatable prefixes within the IPv6 route table, rather than
> minimizing them, which one of the policy objectives for IPv6.
>
> Finally, a separate but somewhat related issue; regardless of where ARIN
> registered resources are used, inside or outside of the ARIN service
> region, organizations must first qualify to receive resources from ARIN.
> ARIN's current operational practice is that an organization must be formed
> within the ARIN service region in order to qualify to receive any resources
> from ARIN. The issue of who should be eligible to receive resources was
> commingled with out of region use in ARIN-2013-6. It was felt these issues
> should be considered separately. Therefore, the issue of who should be
> eligible to receive resources is purposefully not dealt with by this
> proposal, and if any changes are necessary there should be separate policy
> proposals to deal with this issue independently.
>
> ----
>
> Summary of Changes;
>
> - Clarified out of region use is valid justification for both new or
> additional resources.
>
> - Eliminated "user or customer billing address" from definition for out of
> region use, and change the items left to sentence from, instead of list
> form.
>
> - Added that there is a general presumption that requesting resources from
> ARIN for use within another RIR's service region duplicates any resources
> held by the organization with that other RIR.
>
> - Made it clear that only the utilization rate of ARIN resources or
> immediate need are used to determine the valid request size.
>
> - New sections X.2 "Reporting Resources Held with other RIRs," this new
> section is intended to have organizations report the utilization of their
> resources, based on ARIN Policy, for the other RIRs where they are
> requesting ARIN resources for.  Except to the extent incidental use,
> multi-instance use, or critical infrastructure clauses apply.
>
> - Changed incidental use to be on a per other RIR region basis to simplify
> the determination of if the Reporting Resources Held with other RIRs
> applies.
>
> - Changed multi-instance use to use "at least one instance is located
> within the region" language.
>
> - Updated the comments section to account for the above changes.
>
> ----
> Here is an annotated version of the policy text
>
> Deleted Text
> New Text
> Retained Text
> X. Out of Region Use
>
> ARIN registered resources may be used outside the ARIN service region and
> such use is valid justification for new or additional resources. Resources
> are considered to be used outside the region if any of the following are
> located outside the region. A. The user or customer billing address B. the
> user or customer service address or C. the technical infrastructure
> address, such as the point of presence (POP), data center, or other similar
> location, are outside the ARIN service region.
>
> There is a general presumption that requesting resources from ARIN for use
> within another RIR's service region duplicates any resources held by the
> organization with that other RIR.  Therefore, the organization should, not
> hold any resources with the other RIR, or demonstrate that all such
> resources held are utilized based on ARIN policy requirements, or provide
> an operational justification clarifying how the resources from ARIN will
> not duplicate any underutilized resources held with the other RIR.
>
> Only the utilization rate of ARIN registered resources or immediate need
> may be use to determine a valid request size beyond the applicable minimum
> allocation size.  The utilization rate of resources received from another
> RIR is not applicable in determining a valid request size.
>
> X.1 Verification of Out of Region Use
>
> The utilization of all ARIN registered resources must be verified when
> evaluating a request for additional resources or during a resource review,
> including any resources used outside the ARIN service region. All ARIN
> registered resources used outside the region must be verified to no less
> than an equivalent standard as resources used within the ARIN region. To
> this end ARIN, in its sole discretion, may engage independent external
> entities to assist it in the verification of information related to any
> resources used outside the region.
>
> X.2 Reporting Resources Held with other RIRs
>
> Except to the extent that incidental use, multi-instance use, or the
> critical infrastructure criteria described below apply, when out of region
> need is used to justify a request for resources from ARIN; The requesting
> organization will also report to ARIN the utilization status, based on
> applicable ARIN policy, of all resources it holds with the RIRs who's
> service regions the need justifying a request to ARIN is within, and any
> additional supporting documentation requested by ARIN regarding these
> reported resource.
>
> X.23 Incidental Use
>
> Out of region use of ARIN registered resources by an organization that
> totals less than an equivalent of a /20 of IPv4, a /36 of IPv6, and two (2)
> 10 ASNs within each of the other RIR's service regions are considered
> incidental use and as such are accounted for as if used within the ARIN
> service region.
>
> X.4 Multi-Instance Use
>
> Any resources used simultaneously in multiple locations, such as an
> anycast prefix or ASN, are accounted for as used outside the region, only
> if they are exclusively used outside the region.considered as used within
> the ARIN service region, provided at least one instance is located within
> the region, regardless of how many other instances are located outside the
> region.
>
> X.35 Critical Infrastructure
>
> Resources justified through ARIN critical infrastructure policies are
> accounted for as if used within the ARIN service region, regardless of
> their actual location of use.
>
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140328/520477e9/attachment.htm>

From george.herbert at gmail.com  Fri Mar 28 21:09:15 2014
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 28 Mar 2014 18:09:15 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <5335ABD5.8080606@umn.edu>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
	<66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
	<5335ABD5.8080606@umn.edu>
Message-ID: <CAK__Kzsmes7zYH2Hcch-=aa3pECtJhNDjV5Srzz7n9HkN3_Yhw@mail.gmail.com>

However, reading the paper, the "AR" (allocated+routed) traffic they
received, 35% or so, covered traffic which theoretically should have been
routed more specifically but their covering prefix effectively captured
instead.

I.e., oops.

One can presume that this traffic that showed at least mid-stream sessions
(and not SYNs) was for prefixes where "upstreams" had a more-specific route
that hadn't propagated down to Merit's direct upstreams, for some reason.
 88% of the total traffic (if I read it right) was SYN (12%) or SYNACK
(76%) in the 3-month dataset, mostly on ports 80 and 443.  I.e., valid
destination webserver trying to establish the handshake unable to find a
route back to a (theoretically properly allocated and routed) source.

At the very least this raises a question as to whether it's wise to allow
such experiments, where a significant amount of apparently valid traffic
(allocated, and for which routing info was identified in further research)
gets effectively MITMed as it flows.

That may not have been the intention; the theory that "oh, more specific
will just override our research announcement" is colorable.  But the actual
data shows the assumptions fails; they did intercept a lot of legit (or
apparently legit) traffic.  Hence, oops, and perhaps we should not let this
happen again.



On Fri, Mar 28, 2014 at 10:05 AM, David Farmer <farmer at umn.edu> wrote:

> On 3/28/14, 11:57 , Bill Buhler wrote:
>
>> So if my understanding is correct, they basically performed a routing
>> man in the middle attack on live IPv6 prefixes. Pardon my understanding
>> level, but how did they keep from creating routing loops and service
>> interruptions. I'm also a little concerned about performance and link
>> loads. Are my concerns legitimate and inline?
>>
>> Thanks,
>>
>> --Bill
>>
>
> This absolutely WAS NOT an attack.  They announced a covering prefix, only
> traffic with no more specific route would follow this route.  Think more
> specific default route.
>
>
>
> --
> ================================================
> David Farmer               Email: farmer at umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140328/79e9e874/attachment.htm>

From george.herbert at gmail.com  Fri Mar 28 22:15:35 2014
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 28 Mar 2014 19:15:35 -0700
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <CAK__Kzsmes7zYH2Hcch-=aa3pECtJhNDjV5Srzz7n9HkN3_Yhw@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
	<66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
	<5335ABD5.8080606@umn.edu>
	<CAK__Kzsmes7zYH2Hcch-=aa3pECtJhNDjV5Srzz7n9HkN3_Yhw@mail.gmail.com>
Message-ID: <CAK__KzsW-qGXemEEE4=E7S1gSDrUQrCJy=couTERmLYp8rL5Qg@mail.gmail.com>

Having had time now to catch up on the background by watching the recording
of the presentation and Heather's detailed objections -

I support the policy change as written.

Further, I believe it was somewhat irresponsible for ARIN and the other
RIRs to have issued these LOAs without having consulted the community
beforehand, and would like to hear why and under what detailed
justification it was done.  That it was technically in compliance with 11.7
as it stands today seems operationally unwise.

I would have liked to have had ARIN et al push back and do a pre-issuing
public commentary period.  Further, I am concerned that Merit's upstreams
accepted the LOAs without asking about a public commentary.

Frankly, given the prosecutions of individuals for various IP attacks in V4
space, did you even get attorneys to check as to whether this might
approach criminal behavior, much less operationally unwise?  Merit and even
ARIN seem to have been potentially exposed to both civil and criminal
liability over this.

There seems to have been an undercurrent of "But Geoff's been doing this
with APNIC forever..." justifying it being reasonable to do to the rest of
us.  What was acceptable there is not by extension acceptable everywhere,
though it does suggest that further research over there was probably more
acceptable than the equivalents in ARIN and other space.




On Fri, Mar 28, 2014 at 6:09 PM, George Herbert <george.herbert at gmail.com>wrote:

> However, reading the paper, the "AR" (allocated+routed) traffic they
> received, 35% or so, covered traffic which theoretically should have been
> routed more specifically but their covering prefix effectively captured
> instead.
>
> I.e., oops.
>
> One can presume that this traffic that showed at least mid-stream sessions
> (and not SYNs) was for prefixes where "upstreams" had a more-specific route
> that hadn't propagated down to Merit's direct upstreams, for some reason.
>  88% of the total traffic (if I read it right) was SYN (12%) or SYNACK
> (76%) in the 3-month dataset, mostly on ports 80 and 443.  I.e., valid
> destination webserver trying to establish the handshake unable to find a
> route back to a (theoretically properly allocated and routed) source.
>
> At the very least this raises a question as to whether it's wise to allow
> such experiments, where a significant amount of apparently valid traffic
> (allocated, and for which routing info was identified in further research)
> gets effectively MITMed as it flows.
>
> That may not have been the intention; the theory that "oh, more specific
> will just override our research announcement" is colorable.  But the actual
> data shows the assumptions fails; they did intercept a lot of legit (or
> apparently legit) traffic.  Hence, oops, and perhaps we should not let this
> happen again.
>
>
>
> On Fri, Mar 28, 2014 at 10:05 AM, David Farmer <farmer at umn.edu> wrote:
>
>> On 3/28/14, 11:57 , Bill Buhler wrote:
>>
>>> So if my understanding is correct, they basically performed a routing
>>> man in the middle attack on live IPv6 prefixes. Pardon my understanding
>>> level, but how did they keep from creating routing loops and service
>>> interruptions. I'm also a little concerned about performance and link
>>> loads. Are my concerns legitimate and inline?
>>>
>>> Thanks,
>>>
>>> --Bill
>>>
>>
>> This absolutely WAS NOT an attack.  They announced a covering prefix,
>> only traffic with no more specific route would follow this route.  Think
>> more specific default route.
>>
>>
>>
>> --
>> ================================================
>> David Farmer               Email: farmer at umn.edu
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE     Phone: 1-612-626-0815
>> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
>> ================================================
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>
>
>
> --
> -george william herbert
> george.herbert at gmail.com
>



-- 
-george william herbert
george.herbert at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140328/43c7cefd/attachment.htm>

From mysidia at gmail.com  Fri Mar 28 22:20:50 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 28 Mar 2014 21:20:50 -0500
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <968C470DAC25FB419E0159952F28F0C06A75385A@MEM0200CP3XF04.ds.irsnet.gov>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
	<66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
	<968C470DAC25FB419E0159952F28F0C06A75385A@MEM0200CP3XF04.ds.irsnet.gov>
Message-ID: <CAAAwwbXFfyWsV1ZFZKwzuaOV6KbLe-fXZRO9-+rbypZt4Fsohw@mail.gmail.com>

On Fri, Mar 28, 2014 at 12:30 PM, Morizot Timothy S <
Timothy.S.Morizot at irs.gov> wrote:

>  Not really. The only traffic that would have gone to them would have
> been traffic not covered by a more specific route.
>

Even so...  the  /12  blocks or other covering aggregats are specifically
not for ARIN's internal use  ---  ARIN  is entrusted with stewardship to
manage allocation,  and  ARIN has no authority to  co-opt  or use the
blocks for its own purposes  or to be writing any LOA  for announcements
covering aggregates  for these blocks which are registered to other
organizations,

And which improper announcements can break the default route for BGP
speakers carrying partial tables (filtered by length) and which may cause
other unwanted and damaging affects.

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

From babydr at baby-dragons.com  Fri Mar 28 22:27:41 2014
From: babydr at baby-dragons.com (Mr. James W. Laferriere)
Date: Fri, 28 Mar 2014 18:27:41 -0800 (AKDT)
Subject: [arin-ppml] rdappilot.arin.net: Secure Connection Failed
Message-ID: <alpine.LNX.2.01.1403281822460.22223@filesrv1.baby-dragons.com>


 	Hello All ,  When I goto the rdap url to preview the present code I get 
the error message below .

https://rdappilot.arin.net/restfulwhois/rdap

Secure Connection Failed

An error occurred during a connection to rdappilot.arin.net. SSL received a 
record that exceeded the maximum permissible length. (Error code: 
ssl_error_rx_record_too_long)

     The page you are trying to view cannot be shown because the authenticity of 
the received data could not be verified.
     Please contact the website owners to inform them of this problem. 
Alternatively, use the command found in the help menu to report this broken 
site.

firefox 28.0
Windows Vista Ult. sp2 64bit

 		Tia ,  JimL
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network&System Engineer | 3237     Holden Road |  Give me Linux  |
| babydr at baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+------------------------------------------------------------------+


From jcurran at arin.net  Sat Mar 29 08:58:35 2014
From: jcurran at arin.net (John Curran)
Date: Sat, 29 Mar 2014 12:58:35 +0000
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <5335A9D1.7020506@umn.edu>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
Message-ID: <B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>

On Mar 28, 2014, at 11:56 AM, David Farmer <farmer at umn.edu> wrote:

> On 3/28/14, 11:32 , David Huberman wrote:
>> David:
>> 
>> That summary of the issue helps a lot, thank you!
>> 
>> The question on my mind is:
>> 	Did ARIN provide a written LOA to Merit to announce 2600::/12 ?
> 
> I have no direct knowledge one way or the other, I have to defer to ARIN staff to answer that question.  Paging John Curran please. :)
> 
> However, In addition to what CJ referenced, the presentation given at RIPE 66 (slide 7) implies that ARIN and the other RIRs did provide an LOA, doesn't say "written" but again I think that is implied as well.

Yes, ARIN provided the referenced LOA, which is a bit of a surprise to 
me as well.  I'm looking into the details on this now, but here's the 
short version of what I know at this point -

ARIN has often cooperated with Merit on darknet research activities, and 
this includes providing authorization to enable looking into latent traffic 
on space not yet issued by ARIN.  Some typical examples that come to mind 
include new /8's just received from IANA and the /10 for shared transition 
space.

We were asked to cooperate with Merit on darknet research on ARIN's IPv6
2600::/12 space and I authorized the effort.  Apparently, the effort also
included the routing an overall covering prefix and I missed that aspect 
of the project.  Aside from the technical concerns outlined here, there 
is also a very valid question of whether ARIN should ever be involved in 
routing authorization covering already issued space, since presumably the 
same dialogue and consensus in the operator community (that should be a 
prerequisite for such an experiment) should also suffice as the approval 
with ISPs when it comes to researchers actually inserting the necessary 
routes.

Going forward, ARIN will not issue routing authorization that covers any
address space issued to others without community-developed policy that
specifically directs us to do so.   

Sincerely, 
/John

John Curran
President and CEO
ARIN






From joe at oregon.uoregon.edu  Sat Mar 29 13:29:42 2014
From: joe at oregon.uoregon.edu (Joe St Sauver)
Date: Sat, 29 Mar 2014 10:29:42 -0700 (PDT)
Subject: [arin-ppml] 2600::/12 LOA
Message-ID: <14032910294208_374B@oregon.uoregon.edu>

Hi,

John Curran commented:

#We were asked to cooperate with Merit on darknet research on ARIN's IPv6
#2600::/12 space and I authorized the effort.  Apparently, the effort also
#included the routing an overall covering prefix and I missed that aspect 
#of the project.  Aside from the technical concerns outlined here, there 
#is also a very valid question of whether ARIN should ever be involved in 
#routing authorization covering already issued space, since presumably the 
#same dialogue and consensus in the operator community (that should be a 
#prerequisite for such an experiment) should also suffice as the approval 
#with ISPs when it comes to researchers actually inserting the necessary 
#routes.
#
#Going forward, ARIN will not issue routing authorization that covers any
#address space issued to others without community-developed policy that
#specifically directs us to do so.   

In mid-December 2013 I highlighted this very Merit darknet project in 
a keynote I did for Merit Networks Networking Summit in Ann Arbor, see
"Networking in These Crazy Days: Stay Calm, Get Secure, and Get Involved,"
http://pages.uoregon.edu/joe/merit-networking/merit-networking.pdf
at slide 28. 

I think that the Merit IPv6 darknet project was *very* important in helping
to promote uptake of IPv6 in that it provides empirical evidence that the 
level of "background radiation" in IPv6 space isn't very high right now 
(roughly ~1Mbps), and what is there is typically the result of 
misconfiguration rather than malicious scanning (or at least that's what 
was reported in the Merit technical paper summarizing that experience,
as cited in my slides).

Moreover, given BGP route selection rules, I'm not particularly disturbed
by the presence of that covering announcement: any more specific route should
immediately be preferred to a broad covering route of the sort employed by
the IPv6 darknet research effort.

I believe that ARIN acted properly in supporting this network research, and 
I'd be quite disappointed if ARIN (and other RIRs) discontinued support for 
research of this sort, particularly when carefully done by leading academic 
networking research organizations.

Regards,

Joe St Sauver, Ph.D. (joe at oregon.uoregon.edu)

Disclaimer: I am not affiliated with the Merit Darknet effort, and all 
opinions expressed in this note are purely my own.


From cja at daydream.com  Sat Mar 29 14:51:38 2014
From: cja at daydream.com (CJ Aronson)
Date: Sat, 29 Mar 2014 18:51:38 +0000
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <14032910294208_374B@oregon.uoregon.edu>
References: <14032910294208_374B@oregon.uoregon.edu>
Message-ID: <CAC6JZKSKb3ri72XACM8H2qf0ARybJBmDqVVrC+xcxNRqD80a4w@mail.gmail.com>

Joe,

The ends don't always justify the means.  The reason there is a policy
proposal in the ARIN region to stop this practice is because not everyone
covered by these /12 announcements is happy that their addresses were part
of an experiment.  There is a belief that Merit should have had permission
from the entities who had allocations out of these aggregates before
announcing a prefix that included them.   Note also that this is called a
darknet project but these networks were NOT dark.  They were live
production IPv6 deployments around the world.  This is not the same as
announcing an IPv4 /8 that has nothing assigned out of it to see who is
using it who shouldn't be.

Thanks!
----Cathy


On Sat, Mar 29, 2014 at 5:29 PM, Joe St Sauver <joe at oregon.uoregon.edu>wrote:

> Hi,
>
> John Curran commented:
>
> #We were asked to cooperate with Merit on darknet research on ARIN's IPv6
> #2600::/12 space and I authorized the effort.  Apparently, the effort also
> #included the routing an overall covering prefix and I missed that aspect
> #of the project.  Aside from the technical concerns outlined here, there
> #is also a very valid question of whether ARIN should ever be involved in
> #routing authorization covering already issued space, since presumably the
> #same dialogue and consensus in the operator community (that should be a
> #prerequisite for such an experiment) should also suffice as the approval
> #with ISPs when it comes to researchers actually inserting the necessary
> #routes.
> #
> #Going forward, ARIN will not issue routing authorization that covers any
> #address space issued to others without community-developed policy that
> #specifically directs us to do so.
>
> In mid-December 2013 I highlighted this very Merit darknet project in
> a keynote I did for Merit Networks Networking Summit in Ann Arbor, see
> "Networking in These Crazy Days: Stay Calm, Get Secure, and Get Involved,"
> http://pages.uoregon.edu/joe/merit-networking/merit-networking.pdf
> at slide 28.
>
> I think that the Merit IPv6 darknet project was *very* important in helping
> to promote uptake of IPv6 in that it provides empirical evidence that the
> level of "background radiation" in IPv6 space isn't very high right now
> (roughly ~1Mbps), and what is there is typically the result of
> misconfiguration rather than malicious scanning (or at least that's what
> was reported in the Merit technical paper summarizing that experience,
> as cited in my slides).
>
> Moreover, given BGP route selection rules, I'm not particularly disturbed
> by the presence of that covering announcement: any more specific route
> should
> immediately be preferred to a broad covering route of the sort employed by
> the IPv6 darknet research effort.
>
> I believe that ARIN acted properly in supporting this network research, and
> I'd be quite disappointed if ARIN (and other RIRs) discontinued support for
> research of this sort, particularly when carefully done by leading academic
> networking research organizations.
>
> Regards,
>
> Joe St Sauver, Ph.D. (joe at oregon.uoregon.edu)
>
> Disclaimer: I am not affiliated with the Merit Darknet effort, and all
> opinions expressed in this note are purely my own.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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/20140329/5450efe2/attachment.htm>

From afried at deteque.com  Sat Mar 29 15:01:45 2014
From: afried at deteque.com (Andrew Fried)
Date: Sat, 29 Mar 2014 15:01:45 -0400
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <14032910294208_374B@oregon.uoregon.edu>
References: <14032910294208_374B@oregon.uoregon.edu>
Message-ID: <53371899.4060006@deteque.com>

Hi Joe,

The problem with announcing overlapping space like this is that MERIT
becomes a sinkhole for legitimate traffic should an organization using
address space in 2600::/12 have some kind of network problem.  While
many organizations with IPv6 space are dual homed, many rely on a single
router.  If that router goes down for a firmware update or a power cable
gets inadvertently unplugged, all of their inbound connections will
suddenly start getting intercepted by MERIT.  I'm not comfortable with that.

I use the term sinkhole in hopes that MERIT isn't more aggressive with
their data capturing and running honeypots.

This is not a "service" that ARIN should have allowed without the
express consent of each netblock owner that could be potentially
affected.  And I don't agree with your position that this in any way
promotes IPv6 implementation.

Regardless of the justifications for having done this in the past, ARIN
should not allow this to continue.

Andrew


On 3/29/14, 1:29 PM, Joe St Sauver wrote:
> Hi,
>
> John Curran commented:
>
> #We were asked to cooperate with Merit on darknet research on ARIN's IPv6
> #2600::/12 space and I authorized the effort.  Apparently, the effort also
> #included the routing an overall covering prefix and I missed that aspect 
> #of the project.  Aside from the technical concerns outlined here, there 
> #is also a very valid question of whether ARIN should ever be involved in 
> #routing authorization covering already issued space, since presumably the 
> #same dialogue and consensus in the operator community (that should be a 
> #prerequisite for such an experiment) should also suffice as the approval 
> #with ISPs when it comes to researchers actually inserting the necessary 
> #routes.
> #
> #Going forward, ARIN will not issue routing authorization that covers any
> #address space issued to others without community-developed policy that
> #specifically directs us to do so.   
>
> In mid-December 2013 I highlighted this very Merit darknet project in 
> a keynote I did for Merit Networks Networking Summit in Ann Arbor, see
> "Networking in These Crazy Days: Stay Calm, Get Secure, and Get Involved,"
> http://pages.uoregon.edu/joe/merit-networking/merit-networking.pdf
> at slide 28. 
>
> I think that the Merit IPv6 darknet project was *very* important in helping
> to promote uptake of IPv6 in that it provides empirical evidence that the 
> level of "background radiation" in IPv6 space isn't very high right now 
> (roughly ~1Mbps), and what is there is typically the result of 
> misconfiguration rather than malicious scanning (or at least that's what 
> was reported in the Merit technical paper summarizing that experience,
> as cited in my slides).
>
> Moreover, given BGP route selection rules, I'm not particularly disturbed
> by the presence of that covering announcement: any more specific route should
> immediately be preferred to a broad covering route of the sort employed by
> the IPv6 darknet research effort.
>
> I believe that ARIN acted properly in supporting this network research, and 
> I'd be quite disappointed if ARIN (and other RIRs) discontinued support for 
> research of this sort, particularly when carefully done by leading academic 
> networking research organizations.
>
> Regards,
>
> Joe St Sauver, Ph.D. (joe at oregon.uoregon.edu)
>
> Disclaimer: I am not affiliated with the Merit Darknet effort, and all 
> opinions expressed in this note are purely my own.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-- 
Andrew Fried
afried at deteque.com

+1.703.667.4050   Office
+1.703.362.0067   Mobile
deteque           Skype



From heather.skanks at gmail.com  Sat Mar 29 15:12:25 2014
From: heather.skanks at gmail.com (Heather Schiller)
Date: Sat, 29 Mar 2014 15:12:25 -0400
Subject: [arin-ppml] Draft Policy ARIN-2014-12: Anti-hijack Policy
In-Reply-To: <CAAAwwbXFfyWsV1ZFZKwzuaOV6KbLe-fXZRO9-+rbypZt4Fsohw@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<CAC6JZKSxQ-RX-HnTV4M-zeVz_ttR8NJ4D+QzrEbiOJpOTQQTZQ@mail.gmail.com>
	<CAC6JZKQuN8gzPR6utNrBVYougW5qtiS3u+YadUBnXKWBHGFr_w@mail.gmail.com>
	<66E414654AD098469738606C8E7B03B03D25F65BC0@P1MBX03.HMC1.COMCAST.NET>
	<968C470DAC25FB419E0159952F28F0C06A75385A@MEM0200CP3XF04.ds.irsnet.gov>
	<CAAAwwbXFfyWsV1ZFZKwzuaOV6KbLe-fXZRO9-+rbypZt4Fsohw@mail.gmail.com>
Message-ID: <CADricwr92bScYk5a+c8Y1wyeGyvwX_TTfWFEaF9gCj3ArMi4dw@mail.gmail.com>

I strongly disagree with the comments that indicate this is not a problem
because in use prefixes will have a more specific.  That is true, only
until they don't have a more specific.  Until an outage causes the more
specific prefix to be withdrawn or improperly propagated or filtered.  This
is one of the things that Merit measured!  This caused Merit to be able to
intercept production traffic.  There is a lot more production IPv6 traffic
online now, then there was when Geoff ran this experiment in April 2012.
 Geoff's experiment in April 2012 occurred before World IPv6 Launch in June
2012, the day when many companies permanently enabled v6 for their web
services and several providers permanently enabled IPv6 for their
customers.  By the time Merit did their experiment, IPv6 was no longer an
experiment.  Real networks carry real traffic for real customers.  What
would you think if it had been an IPv4 /8 instead of an IPv6 /12?  What if
that v4 /8 covered your allocation?  Would you want to rely on not having
an outage to ensure that your traffic wouldn't be intercepted?

This policy is intended to preclude ARIN from issuing a broad LOA for
research, that covers actively assigned prefixes and so that ARIN can't
silently issue an LOA without the assignment being publicly registered.
 This policy is not intended to preclude individuals from issuing LOA for
their own prefixes.

In addition to ARIN having issued an LOA for this /12, there was no
followup to ensure the route was withdrawn when the terms of the LOA ended
(December 31, 2013)   Merit was still announcing, and their upstreams still
propagating, this prefix, at the time of the Nanog meeting in February.
 There is also the failure of all parties to ensure the prefix was
withdrawn at the agreed upon time.


--Heather


On Fri, Mar 28, 2014 at 10:20 PM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Fri, Mar 28, 2014 at 12:30 PM, Morizot Timothy S <
> Timothy.S.Morizot at irs.gov> wrote:
>
>>  Not really. The only traffic that would have gone to them would have
>> been traffic not covered by a more specific route.
>>
>
> Even so...  the  /12  blocks or other covering aggregats are specifically
> not for ARIN's internal use  ---  ARIN  is entrusted with stewardship to
> manage allocation,  and  ARIN has no authority to  co-opt  or use the
> blocks for its own purposes  or to be writing any LOA  for announcements
> covering aggregates  for these blocks which are registered to other
> organizations,
>
> And which improper announcements can break the default route for BGP
> speakers carrying partial tables (filtered by length) and which may cause
> other unwanted and damaging affects.
>
>  --
> -JH
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140329/2f85ae08/attachment.htm>

From owens at nysernet.org  Sat Mar 29 15:17:36 2014
From: owens at nysernet.org (Bill Owens)
Date: Sat, 29 Mar 2014 15:17:36 -0400
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <14032910294208_374B@oregon.uoregon.edu>
References: <14032910294208_374B@oregon.uoregon.edu>
Message-ID: <20140329191736.GB6323@nysernet.org>

I do not support this kind of research using routes that overlap with live traffic. Moreover, I'm very surprised that the researchers' institutional legal counsel and/or IRB had approved this, given what seem to be obvious legal and ethical questions.

Bill.


From thinkofit at gmail.com  Sat Mar 29 15:43:01 2014
From: thinkofit at gmail.com (Antonio Prado)
Date: Sat, 29 Mar 2014 20:43:01 +0100
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
References: <5331CA99.2000806@arin.net>	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>	<5334711E.1000808@umn.edu>	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
Message-ID: <53372245.2050907@gmail.com>

On 29/03/14 13:58, John Curran wrote:
> Going forward, ARIN will not issue routing authorization that covers any
> address space issued to others without community-developed policy that
> specifically directs us to do so.   

Hi John,

I would just point out a previous discussion held in various IPv6 ML on
the same subject: it was November 2012 when I first raised my concerns
about lack of consensus, lack of policy in RIPE region and (eventually)
legitimate traffic interception by Merit as well.

http://www.ripe.net/ripe/mail/archives/ipv6-wg/2012-November/002069.html

Thank you
--
antonio



From mysidia at gmail.com  Sat Mar 29 18:38:38 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 29 Mar 2014 17:38:38 -0500
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <14032910294208_374B@oregon.uoregon.edu>
References: <14032910294208_374B@oregon.uoregon.edu>
Message-ID: <CAAAwwbU0cbwy4_6UOvpNr1s_fYaF-35ggFoYFVYmApJfncXQ-w@mail.gmail.com>

On Sat, Mar 29, 2014 at 12:29 PM, Joe St Sauver <joe at oregon.uoregon.edu>wrote:


> I think that the Merit IPv6 darknet project was *very* important in helping
> to promote uptake of IPv6 in that it provides empirical evidence that the
> level of "background radiation" in IPv6 space isn't very high right now
> (roughly ~1Mbps), and what is there is typically the result of
> misconfiguration rather than malicious scanning (or at least that's what
>

This may be the case.    I support research,  BUT  using  solely methods
that do not involve  generating BGP announcements for aggregates   or
otherwise taking actions that might redirect any traffic covering address
space assigned to other organizations,  without  the express permission of
those organizations.

Moreover, given BGP route selection rules, I'm not particularly disturbed
> by the presence of that covering announcement: any more specific route
> should
> immediately be preferred to a broad covering route of the sort employed by
> the IPv6 darknet research effort.
>

Announcement of a broad covering route can cause unwanted traffic
redirection.
Occassionally NSPs internally  use broad covering routes of their own,  and
 broad improper announcements can interfere with this.  Most popular is the
/0 route (default).


> I believe that ARIN acted properly in supporting this network research, and
> I'd be quite disappointed if ARIN (and other RIRs) discontinued support for
> research of this sort, particularly when carefully done by leading academic
> networking research organizations.
>


I would say it is appropriate for ARIN to support the network research.

But it is improper for ARIN to sign a LOA  for a  /12  covering an address
range in which assignments have already been made to other organizations,
without  express permission in writing from each registrant covered by the
/12.



>
> Regards,
>
> Joe St Sauver, Ph.D. (joe at oregon.uoregon.edu)
>
> --
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140329/8f2f0f72/attachment.htm>

From matthew at matthew.at  Sat Mar 29 20:23:24 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Sat, 29 Mar 2014 17:23:24 -0700
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
References: <5331CA99.2000806@arin.net>	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>	<5334711E.1000808@umn.edu>	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
Message-ID: <533763FC.7030302@matthew.at>

On 3/29/2014 5:58 AM, John Curran wrote:
> On Mar 28, 2014, at 11:56 AM, David Farmer <farmer at umn.edu> wrote:
>
>> On 3/28/14, 11:32 , David Huberman wrote:
>>> David:
>>>
>>> That summary of the issue helps a lot, thank you!
>>>
>>> The question on my mind is:
>>> 	Did ARIN provide a written LOA to Merit to announce 2600::/12 ?
>> I have no direct knowledge one way or the other, I have to defer to ARIN staff to answer that question.  Paging John Curran please. :)
>>
>> However, In addition to what CJ referenced, the presentation given at RIPE 66 (slide 7) implies that ARIN and the other RIRs did provide an LOA, doesn't say "written" but again I think that is implied as well.
> Yes, ARIN provided the referenced LOA, which is a bit of a surprise to
> me as well.


Here's what surprises me: that it is ARIN's business at all to provide 
an LOA allowing someone to announce a BGP route. I could have sworn that 
I have read hundreds of times that ARIN is *only* in the business of 
running a database in which they maintain unique registrations, and that 
routing policy is of no concern to ARIN.

Either ARIN added a database entry assigning 2600::/12 to Merit, in 
which case I am confused for several reasons, starting with it not being 
a unique assignment...

Or ARIN didn't add a database entry assigning 2600::/12 to Merit, in 
which case what could the letter possibly have said?


>   I'm looking into the details on this now, but here's the
> short version of what I know at this point -
>
> ARIN has often cooperated with Merit on darknet research activities, and
> this includes providing authorization to enable looking into latent traffic
> on space not yet issued by ARIN.  Some typical examples that come to mind
> include new /8's just received from IANA and the /10 for shared transition
> space.
>
> We were asked to cooperate with Merit on darknet research on ARIN's IPv6
> 2600::/12 space and I authorized the effort.  Apparently, the effort also
> included the routing an overall covering prefix and I missed that aspect
> of the project.  Aside from the technical concerns outlined here, there
> is also a very valid question of whether ARIN should ever be involved in
> routing authorization covering already issued space, since presumably the
> same dialogue and consensus in the operator community (that should be a
> prerequisite for such an experiment) should also suffice as the approval
> with ISPs when it comes to researchers actually inserting the necessary
> routes.

I think there's a valid question of whether ARIN should ever be involved 
in routing authorization. Full stop.

>
> Going forward, ARIN will not issue routing authorization that covers any
> address space issued to others without community-developed policy that
> specifically directs us to do so.

I would hope that in the absence of both community-developed policy 
*and* a change in ARIN's chartered mission, ARIN would not issue routing 
authorization that covers any address space, with the possible exception 
of the addresses assigned to ARIN itself for its own servers.

Matthew Kaufman



From matthew at matthew.at  Sat Mar 29 20:30:13 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Sat, 29 Mar 2014 17:30:13 -0700
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <14032910294208_374B@oregon.uoregon.edu>
References: <14032910294208_374B@oregon.uoregon.edu>
Message-ID: <53376595.6000508@matthew.at>

On 3/29/2014 10:29 AM, Joe St Sauver wrote:
> ...
> Moreover, given BGP route selection rules, I'm not particularly disturbed
> by the presence of that covering announcement: any more specific route should
> immediately be preferred to a broad covering route of the sort employed by
> the IPv6 darknet research effort.

If the BGP listener is able to hear the more-specific route. If the 
more-specific is temporarily missing, the traffic goes to the wrong 
place. If the more-specific is not heard due to length filters at the 
listener, the traffic also goes to the wrong place. In both cases, that 
is production network traffic being diverted from where it should be going.

>
> I believe that ARIN acted properly in supporting this network research, and
> I'd be quite disappointed if ARIN (and other RIRs) discontinued support for
> research of this sort, particularly when carefully done by leading academic
> networking research organizations.

I don't see how ARIN had any business at all supporting research other 
than to issue *unique* address space to researchers. In this case, it 
wasn't unique, and so there was no way ARIN could supply that space 
under the existing numbering policy, and so ARIN should have said "I'm 
sorry, we've issued addresses in that space, so we can't issue you 
2600::/12 as a unique assignment under section 11 of the NRPM... if 
you'd like to announce a covering route in that space, we encourage you 
to talk to the organizations that are already using parts of that space, 
and the organizations to which you intend to announce that route to"

Matthew Kaufman



From cja at daydream.com  Sat Mar 29 20:55:30 2014
From: cja at daydream.com (CJ Aronson)
Date: Sun, 30 Mar 2014 00:55:30 +0000
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <533763FC.7030302@matthew.at>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
Message-ID: <CAC6JZKTJZVz_o6WtGoeYDZLwxFynSTu_wX9g66gJtnq-NNAA8g@mail.gmail.com>

I just wanted to mention per the research paper all the RIRs gave LOAs for
these covering prefixes.  Not just ARIN

"In early October 2012, we contacted each of the five RIRs to request
permission to announce the entire /12 IPv6 address block that had been
allocated to them by IANA. After deliberation, each RIR granted us a Letter
of Authority (LOA) temporarily allowing us to announce these prefixes via
BGP for the duration of our fourmonth experiment"

----Cathy



On Sun, Mar 30, 2014 at 12:23 AM, Matthew Kaufman <matthew at matthew.at>wrote:

> On 3/29/2014 5:58 AM, John Curran wrote:
>
>> On Mar 28, 2014, at 11:56 AM, David Farmer <farmer at umn.edu> wrote:
>>
>>  On 3/28/14, 11:32 , David Huberman wrote:
>>>
>>>> David:
>>>>
>>>> That summary of the issue helps a lot, thank you!
>>>>
>>>> The question on my mind is:
>>>>         Did ARIN provide a written LOA to Merit to announce 2600::/12 ?
>>>>
>>> I have no direct knowledge one way or the other, I have to defer to ARIN
>>> staff to answer that question.  Paging John Curran please. :)
>>>
>>> However, In addition to what CJ referenced, the presentation given at
>>> RIPE 66 (slide 7) implies that ARIN and the other RIRs did provide an LOA,
>>> doesn't say "written" but again I think that is implied as well.
>>>
>> Yes, ARIN provided the referenced LOA, which is a bit of a surprise to
>> me as well.
>>
>
>
> Here's what surprises me: that it is ARIN's business at all to provide an
> LOA allowing someone to announce a BGP route. I could have sworn that I
> have read hundreds of times that ARIN is *only* in the business of running
> a database in which they maintain unique registrations, and that routing
> policy is of no concern to ARIN.
>
> Either ARIN added a database entry assigning 2600::/12 to Merit, in which
> case I am confused for several reasons, starting with it not being a unique
> assignment...
>
> Or ARIN didn't add a database entry assigning 2600::/12 to Merit, in which
> case what could the letter possibly have said?
>
>
>
>    I'm looking into the details on this now, but here's the
>> short version of what I know at this point -
>>
>> ARIN has often cooperated with Merit on darknet research activities, and
>> this includes providing authorization to enable looking into latent
>> traffic
>> on space not yet issued by ARIN.  Some typical examples that come to mind
>> include new /8's just received from IANA and the /10 for shared transition
>> space.
>>
>> We were asked to cooperate with Merit on darknet research on ARIN's IPv6
>> 2600::/12 space and I authorized the effort.  Apparently, the effort also
>> included the routing an overall covering prefix and I missed that aspect
>> of the project.  Aside from the technical concerns outlined here, there
>> is also a very valid question of whether ARIN should ever be involved in
>> routing authorization covering already issued space, since presumably the
>> same dialogue and consensus in the operator community (that should be a
>> prerequisite for such an experiment) should also suffice as the approval
>> with ISPs when it comes to researchers actually inserting the necessary
>> routes.
>>
>
> I think there's a valid question of whether ARIN should ever be involved
> in routing authorization. Full stop.
>
>
>
>> Going forward, ARIN will not issue routing authorization that covers any
>> address space issued to others without community-developed policy that
>> specifically directs us to do so.
>>
>
> I would hope that in the absence of both community-developed policy *and*
> a change in ARIN's chartered mission, ARIN would not issue routing
> authorization that covers any address space, with the possible exception of
> the addresses assigned to ARIN itself for its own servers.
>
> Matthew Kaufman
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140330/92ec192f/attachment.htm>

From jcurran at arin.net  Sat Mar 29 22:06:18 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 30 Mar 2014 02:06:18 +0000
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <533763FC.7030302@matthew.at>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
Message-ID: <BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>

On Mar 29, 2014, at 8:23 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> Here's what surprises me: that it is ARIN's business at all to provide an LOA allowing someone to announce a BGP route. I could have sworn that I have read hundreds of times that ARIN is *only* in the business of running a database in which they maintain unique registrations, and that routing policy is of no concern to ARIN.
> 
> Either ARIN added a database entry assigning 2600::/12 to Merit, in which case I am confused for several reasons, starting with it not being a unique assignment...
> 
> Or ARIN didn't add a database entry assigning 2600::/12 to Merit, in which case what could the letter possibly have said?

Matthew - 
 
   This is not an "ARIN" process per se, it's more of a practice of 
   that some ISPs require; if you come to them seeking them to route 
   a block not assigned to you, they'll have you get a letter of 
   authorization from the party listed on the block.  For example, 
   this was provided to Merit for new /8's that we received from 
   IANA, so that they could do darknet testing on them before we 
   began issuing space out of them.

> I would hope that in the absence of both community-developed policy *and* a change in ARIN's chartered mission, ARIN would not issue routing authorization that covers any address space, with the possible exception of the addresses assigned to ARIN itself for its own servers.

   Would you also include doing testing on address space in the free
   pool before its issued to anyone, so that we can detect potential
   impairment of the space? 

Thanks,
/John

John Curran
President and CEO
ARIN




From matthew at matthew.at  Sat Mar 29 22:50:01 2014
From: matthew at matthew.at (Matthew Kaufman)
Date: Sat, 29 Mar 2014 19:50:01 -0700
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
Message-ID: <53378659.60605@matthew.at>

On 3/29/2014 7:06 PM, John Curran wrote:
> On Mar 29, 2014, at 8:23 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>
>> Here's what surprises me: that it is ARIN's business at all to provide an LOA allowing someone to announce a BGP route. I could have sworn that I have read hundreds of times that ARIN is *only* in the business of running a database in which they maintain unique registrations, and that routing policy is of no concern to ARIN.
>>
>> Either ARIN added a database entry assigning 2600::/12 to Merit, in which case I am confused for several reasons, starting with it not being a unique assignment...
>>
>> Or ARIN didn't add a database entry assigning 2600::/12 to Merit, in which case what could the letter possibly have said?
> Matthew -
>   
>     This is not an "ARIN" process per se, it's more of a practice of
>     that some ISPs require; if you come to them seeking them to route
>     a block not assigned to you, they'll have you get a letter of
>     authorization from the party listed on the block.  For example,
>     this was provided to Merit for new /8's that we received from
>     IANA, so that they could do darknet testing on them before we
>     began issuing space out of them.

I would think that the new /8s would need to be assigned to something in 
your database first. Then you could provide an LOA or alternative (see 
below).

>
>> I would hope that in the absence of both community-developed policy *and* a change in ARIN's chartered mission, ARIN would not issue routing authorization that covers any address space, with the possible exception of the addresses assigned to ARIN itself for its own servers.
>     Would you also include doing testing on address space in the free
>     pool before its issued to anyone, so that we can detect potential
>     impairment of the space?

Sure, that sounds fine. Use Section 11 of the NRPM to assign *unique* 
address space of the appropriate size to ARIN (and provide an LOA for 
the routing to your transit provider(s)) if ARIN is doing the testing, 
or have whomever is doing the testing apply under Section 11 and assign 
the (unique) space to them (so they can just point to the allocation if 
anyone asks them for a LOA) and have at it.

But assigning non-unique space, or worse, giving someone a LOA for space 
that is neither unique nor assigned to them? Sounds like the existing 
policy wasn't even followed... I hate when we get new rules to cover 
specific things that the old rules already covered, and this is going to 
be one of those cases.

Matthew Kaufman



From jcurran at arin.net  Sun Mar 30 05:00:08 2014
From: jcurran at arin.net (John Curran)
Date: Sun, 30 Mar 2014 09:00:08 +0000
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <53378659.60605@matthew.at>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
	<53378659.60605@matthew.at>
Message-ID: <A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>

On Mar 29, 2014, at 10:50 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> I would think that the new /8s would need to be assigned to something in your database first. Then you could provide an LOA or alternative (see below).
> ...
> Sure, that sounds fine. Use Section 11 of the NRPM to assign *unique* address space of the appropriate size to ARIN (and provide an LOA for the routing to your transit provider(s)) if ARIN is doing the testing, or have whomever is doing the testing apply under Section 11 and assign the (unique) space to them (so they can just point to the allocation if anyone asks them for a LOA) and have at it.

Matthew -

That sound like a very reasonable approach; in such a manner, testing is 
only done on space which was both were previously unallocated and is now
uniquely registered for that purpose.

However, I do not believe that was past practice in any of the RIRs; e.g. 
routing of newly received address space (without any form of suballocation 
or assignment to the RIR or any other party) has been a common practice to 
see whether there is any form of impairment on the received block. It is 
not "research" so much as consider prudent registry operational practice 
(when applied to space that has never been suballocated.)

NRPM 11 was designed for parties requesting allocations from ARIN for
research purposes; not ARIN checking the quality/integrity of new block
received from IANA.  Given the recent occurance, I believe it is prudent
for ARIN to utilize NRPM 11 going forward for purposes of this quality
checking, as it makes visible the organization doing the testing/making
use of the space, including duration of the activity and research nature,
as well as reaffirming the expected uniqueness requirement.

Thanks!
/John

John Curran
President and CEO
ARIN





From mysidia at gmail.com  Sun Mar 30 12:33:31 2014
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 30 Mar 2014 11:33:31 -0500
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
	<53378659.60605@matthew.at>
	<A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
Message-ID: <CAAAwwbXWSA0Vz+O_dV2ce2hrvr+oYCgSPZnzjzzLPXXekbn5uQ@mail.gmail.com>

On Sun, Mar 30, 2014 at 4:00 AM, John Curran <jcurran at arin.net> wrote:

I believe ARIN should just  create the temporary registration as a matter
of course, and conduct any testing and write any LOAs they determine is
appropriate on a newly received block,  before beginning allocations on the
block.

The registration should have an expiration date, and so should the LOA ---
 to ensure that  no authorization 'lingers'   after  ARIN begins to
allocate resources from the block.


The other important thing is that there is a WHOIS listing,  for space
temporarily held up for testing,  before being released for allocations,
 and it should not be overlapping with space already assigned.    ARIN
'owns' the "registration",  and appropriate contacts should be listed,
based on who is conducting the testing on behalf of the RIR.

I believe this is outside the scope of the NRPM....  as we are talking
about internal procedures to prepare resources for use:   not resource
management policy,

And a brief testing period with a definitive brief period before the
expiration date / test end date  used for ARN's internal purposes does not
constitute an allocation of the IP address resources  to a resource holder.

For one thing... criteria such as  "justified need",   "slow start"  or
 normal sizing rules do not apply to such a temporary set-aside......  it
is not a matter of  "X IP addresses needed for research use" ----  the
entire block likely needs to be sampled in a representative manner,   in
advance.





> Sure, that sounds fine. Use Section 11 of the NRPM to assign *unique*
> address space of the appropriate size to ARIN (and provide an LOA for the
> routing to your transit provider(s)) if ARIN is doing the testing, or have
> whomever is doing the testing apply under Section 11 and assign the
> (unique) space to them (so they can just point to the allocation if anyone
> asks them for a LOA) and have at it.
>
> Matthew -
>
> That sound like a very reasonable approach; in such a manner, testing is
> only done on space which was both were previously unallocated and is now
> uniquely registered for that purpose.
>
--
-JH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140330/7919a9fe/attachment.htm>

From springer at inlandnet.com  Mon Mar 31 14:56:38 2014
From: springer at inlandnet.com (John Springer)
Date: Mon, 31 Mar 2014 11:56:38 -0700 (PDT)
Subject: [arin-ppml] Term Limit Proposal
Message-ID: <alpine.BSF.2.00.1403311124560.52227@mail.inlandnet.com>

I notice from the 2013 ARIN Annual Report

https://www.arin.net/about_us/corp_docs/annual/report2013.pdf

(p. 11, BOARD OF TRUSTEES ACTIONS), an item, "Referred question of term 
limits to the ARIN Governance Committee".

It appears this happened on 1/7/2013.

https://www.arin.net/about_us/bot/bot2013_0107.html

Is there anything that can be publicly said about the deliberations of 
this committee, on this subject, so far?

There doesn't appear to be anything published in official BoT materials 
since:

site:https://www.arin.net/about_us/bot/ "term limits"

I ask because of the recent interest in the topic.

John Springer
as a member of the community



From hannigan at gmail.com  Mon Mar 31 15:11:18 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 31 Mar 2014 15:11:18 -0400
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
	<53378659.60605@matthew.at>
	<A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
Message-ID: <CAMDXq5MwkbT=2QHZYGV1kWkVeTxmbhM_q8g7F_g-sR4rHs3k3Q@mail.gmail.com>

On Sun, Mar 30, 2014 at 5:00 AM, John Curran <jcurran at arin.net> wrote:
> On Mar 29, 2014, at 10:50 PM, Matthew Kaufman <matthew at matthew.at> wrote:
>
>> I would think that the new /8s would need to be assigned to something in your database first. Then you could provide an LOA or alternative (see below).
>> ...
>> Sure, that sounds fine. Use Section 11 of the NRPM to assign *unique* address space of the appropriate size to ARIN (and provide an LOA for the routing to your transit provider(s)) if ARIN is doing the testing, or have whomever is doing the testing apply under Section 11 and assign the (unique) space to them (so they can just point to the allocation if anyone asks them for a LOA) and have at it.
>
> Matthew -
>
> That sound like a very reasonable approach; in such a manner, testing is
> only done on space which was both were previously unallocated and is now
> uniquely registered for that purpose.
>
> However, I do not believe that was past practice in any of the RIRs; e.g.
> routing of newly received address space (without any form of suballocation
> or assignment to the RIR or any other party) has been a common practice to
> see whether there is any form of impairment on the received block. It is
> not "research" so much as consider prudent registry operational practice
> (when applied to space that has never been suballocated.)
>
> NRPM 11 was designed for parties requesting allocations from ARIN for
> research purposes; not ARIN checking the quality/integrity of new block
> received from IANA.  Given the recent occurance, I believe it is prudent
> for ARIN to utilize NRPM 11 going forward for purposes of this quality
> checking, as it makes visible the organization doing the testing/making
> use of the space, including duration of the activity and research nature,
> as well as reaffirming the expected uniqueness requirement.
>

If I understand this correctly, Matthew suggested that an update to
Section 11 would be more useful? If that's the case I agree. It would
require a few, simple, modifications.

Why would ARIN ever need to issue an LOA if whatever is distributed is
in the registry? All the LOA responsibilities if even needed at that
point would fall to the registrant.

Best,

-M<


From csquat at ccsd.net  Mon Mar 31 15:13:31 2014
From: csquat at ccsd.net (Chris R. Squatritto)
Date: Mon, 31 Mar 2014 12:13:31 -0700
Subject: [arin-ppml] ARIN-PPML Digest, Vol 105, Issue 70
Message-ID: <fc.004c4e074f21317f3b9aca00350c2a29.4f213188@interact.ccsd.net>

I am out of the office this week and will not be checking email.  Please
contact Troy Miller for assistance..

Thank you for contacting me, and have a great day.

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

From bill at herrin.us  Mon Mar 31 15:19:28 2014
From: bill at herrin.us (William Herrin)
Date: Mon, 31 Mar 2014 15:19:28 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
Message-ID: <CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>

On Tue, Mar 25, 2014 at 12:05 PM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:
> I propose the following be used for AC:
>
> -Keep the 3 year terms in place  and add
> -a 6 year contiguous term limit
> -a 3 year ineligibility year period after a term ends be it 3year or 6years
> -After 3 year ineligibility is over a person my run for a position on the AC
> again.

Howdy,

I support this, however...

I think 6 years is too long. I would prefer to see one term contiguous
limits with a 1-year-out waiting period. This would assure that folks
rotate in and out of the advisory council, bringing fresh perspectives
with them.

I would NOT support this for the board. ARIN benefits from the board's
continuity.

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 hannigan at gmail.com  Mon Mar 31 16:02:31 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 31 Mar 2014 16:02:31 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>
Message-ID: <CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>

On Mon, Mar 31, 2014 at 3:19 PM, William Herrin <bill at herrin.us> wrote:
> On Tue, Mar 25, 2014 at 12:05 PM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:
>> I propose the following be used for AC:
>>
>> -Keep the 3 year terms in place  and add
>> -a 6 year contiguous term limit
>> -a 3 year ineligibility year period after a term ends be it 3year or 6years
>> -After 3 year ineligibility is over a person my run for a position on the AC
>> again.
>
> Howdy,
>
> I support this, however...
>
> I think 6 years is too long. I would prefer to see one term contiguous
> limits with a 1-year-out waiting period.

I agree.


>
> I would NOT support this for the board. ARIN benefits from the board's
> continuity.

If you really want change, term limit the Board and forget the AC.

Best,

-M<


From owen at delong.com  Mon Mar 31 16:40:13 2014
From: owen at delong.com (Owen DeLong)
Date: Mon, 31 Mar 2014 13:40:13 -0700
Subject: [arin-ppml] [arin-discuss]  Term Limit Proposal
In-Reply-To: <8335CAF4177E7A4CBC4670E5F9FA9B415EF4403C@CRC-Exchange02.corp.clearrate.net>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>,
	<CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>
	<8335CAF4177E7A4CBC4670E5F9FA9B415EF4403C@CRC-Exchange02.corp.clearrate.net>
Message-ID: <9222E787-9024-4B55-B819-926C6027D252@delong.com>


On Mar 31, 2014, at 1:08 PM, Paul Timmins <ptimmins at clearrate.com> wrote:

>> ________________________________________
>> From: arin-discuss-bounces at arin.net [arin-discuss-bounces at arin.net] on behalf of Martin Hannigan [hannigan at gmail.com]
>> Sent: Monday, March 31, 2014 4:02 PM
>> To: William Herrin
>> Cc: arin-ppml at arin.net; arin-discuss at arin.net> 
>> Subject: Re: [arin-discuss] [arin-ppml] Term Limit Proposal
>> 
>>> I would NOT support this for the board. ARIN benefits from the board's
>>> continuity.
>> 
>> If you really want change, term limit the Board and forget the AC.
> 
> Do people really WANT change though? I think part of what helps the community at large is the predictability of policy w/r/t number allocation.
> 
> A neutral entity controlling allocation uniformly per a generally stable policy provides a good regulatory environment for everyone, I'd think.

Further, in reality, if the voting constituency really wanted change, I suspect incumbents would be less likely to get re-elected.

I know I certainly don?t vote for incumbents who I am dissatisfied with. I doubt anyone else does, either.

Owen



From jcurran at arin.net  Mon Mar 31 16:52:01 2014
From: jcurran at arin.net (John Curran)
Date: Mon, 31 Mar 2014 20:52:01 +0000
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <CAMDXq5MwkbT=2QHZYGV1kWkVeTxmbhM_q8g7F_g-sR4rHs3k3Q@mail.gmail.com>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
	<53378659.60605@matthew.at>
	<A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
	<CAMDXq5MwkbT=2QHZYGV1kWkVeTxmbhM_q8g7F_g-sR4rHs3k3Q@mail.gmail.com>
Message-ID: <2DA95900-8FCB-484E-B998-5D1E1E1A7E75@arin.net>

On Mar 31, 2014, at 3:11 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> On Sun, Mar 30, 2014 at 5:00 AM, John Curran <jcurran at arin.net> wrote:
>> 
>> NRPM 11 was designed for parties requesting allocations from ARIN for
>> research purposes; not ARIN checking the quality/integrity of new block
>> received from IANA.  Given the recent occurance, I believe it is prudent
>> for ARIN to utilize NRPM 11 going forward for purposes of this quality
>> checking, as it makes visible the organization doing the testing/making
>> use of the space, including duration of the activity and research nature,
>> as well as reaffirming the expected uniqueness requirement.
> 
> If I understand this correctly, Matthew suggested that an update to
> Section 11 would be more useful? If that's the case I agree. It would
> require a few, simple, modifications.

I think his suggestion to make use of NRPM 11 for this purpose is quite
excellent.   It was not process that we used in the past, but shall be 
done that way going forward.   To the extent that the community wishes 
to improve NRPM 11 policy text for this purpose of address space testing, 
that is also welcome.

> Why would ARIN ever need to issue an LOA if whatever is distributed is
> in the registry? All the LOA responsibilities if even needed at that
> point would fall to the registrant.

Agreed; that is the major benefit of taking an "NRPM 11" approach to address
space testing - ARIN stays focused on being a registry and leaves the use of 
address space to registrants.  Since registrants are unique for a given address
block, we also preempt multiple parties with potentially conflict plans on the 
use (or routing) of any given portion of address space.

Thanks!
/John

John Curran
President and CEO
ARIN



From hannigan at gmail.com  Mon Mar 31 16:59:30 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 31 Mar 2014 16:59:30 -0400
Subject: [arin-ppml] 2600::/12 LOA
In-Reply-To: <2DA95900-8FCB-484E-B998-5D1E1E1A7E75@arin.net>
References: <5331CA99.2000806@arin.net>
	<e50ed8fcc61c40409979111f0f4b56c5@DM2PR03MB398.namprd03.prod.outlook.com>
	<5334711E.1000808@umn.edu>
	<60b4f3de29f946ef9f9826683f6beaf9@DM2PR03MB398.namprd03.prod.outlook.com>
	<5335A9D1.7020506@umn.edu>
	<B2773561-D0E7-4ED4-87EF-4E191F4F7E73@arin.net>
	<533763FC.7030302@matthew.at>
	<BD23C833-0608-4F05-9F39-8D11709052F1@arin.net>
	<53378659.60605@matthew.at>
	<A36E7C47-7D8C-45E6-8E23-5286B1A58ADB@arin.net>
	<CAMDXq5MwkbT=2QHZYGV1kWkVeTxmbhM_q8g7F_g-sR4rHs3k3Q@mail.gmail.com>
	<2DA95900-8FCB-484E-B998-5D1E1E1A7E75@arin.net>
Message-ID: <CAMDXq5PNBYH0+hhwCx-YsjXfZbomeE-RB+GY-Hb40CjvqLWc-Q@mail.gmail.com>

On Mon, Mar 31, 2014 at 4:52 PM, John Curran <jcurran at arin.net> wrote:
> On Mar 31, 2014, at 3:11 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>
>> On Sun, Mar 30, 2014 at 5:00 AM, John Curran <jcurran at arin.net> wrote:
>>>
>>> NRPM 11 was designed for parties requesting allocations from ARIN for
>>> research purposes; not ARIN checking the quality/integrity of new block
>>> received from IANA.  Given the recent occurance, I believe it is prudent
>>> for ARIN to utilize NRPM 11 going forward for purposes of this quality
>>> checking, as it makes visible the organization doing the testing/making
>>> use of the space, including duration of the activity and research nature,
>>> as well as reaffirming the expected uniqueness requirement.
>>
>> If I understand this correctly, Matthew suggested that an update to
>> Section 11 would be more useful? If that's the case I agree. It would
>> require a few, simple, modifications.
>
> I think his suggestion to make use of NRPM 11 for this purpose is quite
> excellent.   It was not process that we used in the past, but shall be
> done that way going forward.   To the extent that the community wishes
> to improve NRPM 11 policy text for this purpose of address space testing,
> that is also welcome.
>
>> Why would ARIN ever need to issue an LOA if whatever is distributed is
>> in the registry? All the LOA responsibilities if even needed at that
>> point would fall to the registrant.
>
> Agreed; that is the major benefit of taking an "NRPM 11" approach to address
> space testing - ARIN stays focused on being a registry and leaves the use of
> address space to registrants.  Since registrants are unique for a given address
> block, we also preempt multiple parties with potentially conflict plans on the
> use (or routing) of any given portion of address space.
>


Yes, I agree. This is the preferable route.

Best,

-M<


From bill at herrin.us  Mon Mar 31 17:21:48 2014
From: bill at herrin.us (William Herrin)
Date: Mon, 31 Mar 2014 17:21:48 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>
	<CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>
Message-ID: <CAP-guGUpsfY64btZXVg2VCbBJMSyE82NaMnbEC3d=hMnVROW_g@mail.gmail.com>

On Mon, Mar 31, 2014 at 4:02 PM, Martin Hannigan <hannigan at gmail.com> wrote:
> On Mon, Mar 31, 2014 at 3:19 PM, William Herrin <bill at herrin.us> wrote:
>> On Tue, Mar 25, 2014 at 12:05 PM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:
>> I think 6 years is too long. I would prefer to see one term contiguous
>> limits with a 1-year-out waiting period.

Just in case anyone missed the nuance, I see value in asking the
engaged and hardworking volunteers on the AC to sit out once in a
while, just long enough to regain perspective from the outside. I
don't see why that need be for longer than until the next election. I
also note that we haven't had so many qualified volunteers for the
position that we can afford to have folks sit out for three years.


>> I would NOT support this for the board. ARIN benefits from the board's
>> continuity.
>
> If you really want change, term limit the Board and forget the AC.

Change for change's sake is rarely for the better. Stability is
usually a good thing. I don't see rotating out AC members having a
negative impact on ARIN's overall stability. Frequent turnover on the
board, however...

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 hannigan at gmail.com  Mon Mar 31 19:12:17 2014
From: hannigan at gmail.com (Martin Hannigan)
Date: Mon, 31 Mar 2014 19:12:17 -0400
Subject: [arin-ppml] Term Limit Proposal
In-Reply-To: <CAP-guGUpsfY64btZXVg2VCbBJMSyE82NaMnbEC3d=hMnVROW_g@mail.gmail.com>
References: <25e50d53d9274f489b3c73bc43599d7f@BY2PR06MB488.namprd06.prod.outlook.com>
	<CAP-guGVopDTYEJLMDpQqy8u-m0KU5FBDP_JEnTPLcy3w9i5WUg@mail.gmail.com>
	<CAMDXq5NJaRnqs2qip6xAPC57oX7tnN23s8M5U5_kX_61ugw_CQ@mail.gmail.com>
	<CAP-guGUpsfY64btZXVg2VCbBJMSyE82NaMnbEC3d=hMnVROW_g@mail.gmail.com>
Message-ID: <CAMDXq5Oew3CydPvxXzOKm7p3ug9sh3hKJ6O+KpAmdbq=zciw5Q@mail.gmail.com>

On Mon, Mar 31, 2014 at 5:21 PM, William Herrin <bill at herrin.us> wrote:
> On Mon, Mar 31, 2014 at 4:02 PM, Martin Hannigan <hannigan at gmail.com> wrote:
>> On Mon, Mar 31, 2014 at 3:19 PM, William Herrin <bill at herrin.us> wrote:
>>> On Tue, Mar 25, 2014 at 12:05 PM, Azinger, Marla <Marla.Azinger at ftr.com> wrote:
>>> I think 6 years is too long. I would prefer to see one term contiguous
>>> limits with a 1-year-out waiting period.
>
> Just in case anyone missed the nuance, I see value in asking the
> engaged and hardworking volunteers on the AC to sit out once in a
> while, just long enough to regain perspective from the outside. I
> don't see why that need be for longer than until the next election. I
> also note that we haven't had so many qualified volunteers for the
> position that we can afford to have folks sit out for three years.
>
>
>>> I would NOT support this for the board. ARIN benefits from the board's
>>> continuity.
>>
>> If you really want change, term limit the Board and forget the AC.
>
> Change for change's sake is rarely for the better. Stability is
> usually a good thing. I don't see rotating out AC members having a
> negative impact on ARIN's overall stability. Frequent turnover on the
> board, however...
>


As far as term limits go, there are a multitude of organizations that
use them and suffer little from it including federal, state and
municipal governments, non profts like the Appalachian Mountain Club,
NANOG, and many others.

There are a variety of problems term limits may help with including
the self perpetuation concern, under representation (only a fraction
of resource holders are actually "represented" and stagnation (Gov
term limit task and PDP Simplification Committee). Term limits would
likely resolve or soften some worthwhile problems.

Why is ARIN different than all of these other venerable organizations?

Best

-M<